Software Engineering Goals: Independently Completing Routine Tasks and Simple Features

Software Engineering Goals: Independently Completing Routine Tasks and Simple Features

I am on to the 5th out of 8 of my goals. I am 3/4 of the way through with processing these. I'll still have to revisit things afterwards but this has been a huge piece of work which will make all the difference to me I believe.

These have gotten harder and harder to write up. I'm not gonna lie; I've gotten pretty tired. Not sure if it's been 2 or 3 weeks that I've been doing these on the side. 

When I finish, my side projects will be:
  • My Python course, and then Django course, and then other courses and so on...
  • Anything more to do with this
  • Anything else that comes up like git study or whatever
They are getting harder to write up because I'm tired but they are easier and smaller to process and to write up as we go on.

So without further ado, here is my 6th out of eight goals: independently completing routine tasks and simple features.

a brightly coloured image of a sun and holographic colours. text reads: software engineering goals: Independently completes routine tasks and simple features

Here is the goal then:

In my last job I didn't get as much practise with these things as I wanted to.

I won't go into it as I don't want to talk too much about my last job. But I didn't get enough practise with things like IDE issues, git issues, Circle CI stuff failing and my code breaking other people's tests and so on.

Plus I've changed stack here as well, with Python and Django and Pycharm.

So there's lots to learn here and a lot of room to make progress and to improve and to grow!

Understanding all the tools

It's about understanding all the tools that we're using and being able to IDENTIFY when they break. And when to fix them - and you know - just fixing them, basically - thanks.

A bright and holographic landscape image with myriad holographic shapes, featuring text outlining all of the goals in this blog post.

Being a master of the tools around me

It's about being a master of the tools around me.

And then:
  • We'll introduce things sometimes that will break the codebase
  • For example, my change might make my senior's test fail
  • So instead of telling him I can just go in and change the code myself
  • And not even tell him - just highlight it as a comment in the PR!!! - and then wait for him to see it for himself - and then to tell me IF something is wrong
  • Even if it's wrong, IT'S BETTER THAT I TRIED IT ALONE!!!

Some examples

Maybe a good example of this would be like the time I pushed something into the wrong PR. Being able to confidently, quickly and independently fix this on my own would be a very good thing.

Or just seeing that the CI tests are failing - and the CI is failing because of something that someone else has introduced - and be like: "okay a little thing has happened - I know what is happening - I'LL JUST QUICKLY FIX THIS!" I have improved a lot at Circle CI recently though anyway - MASSIVELY, I would say.

And it's just like being able to fix git stuff and IDE stuff - all of the stuff around TOOLING anyway.

Final Thoughts On This

It's about confidence and practise on the engineering side of things. It's about going: "Yeah, I've got this issue. Yeah, I see this thing." It's about GETTING USED TO THE TOOLS AROUND ME. But tbh I have progressed at this thing LIKE INCREDIBLY FAST and I am continuing to progress every day.

An when stuff goes wrong...

TOOLING

And when stuff goes wrong...

Being able to go: "Ugh! Okay okay yeah. I've seen this before."

"This has happened to me loads of times now."

"I know what it is."

"I'll fix this."

"I'LL FIX IT."

It's just on the engineering side.

It's just about self-autonomy AS AN ENGINEER!!!

Comments

Popular posts from this blog

Hello World

Yosemite

Where To Hide A Star