Things I need to improve on: software engineering, part 2

Okay so the last time I wrote about this I forgot one really crucial question out: “can you describe what you want to happen and what needs to be called and where to get to the next step?”

Can you describe what you want to happen and what needs to be called and where to get to the next step?

So anyway on the post that I wrote yesterday I want to write some more.

I am about to approach a new piece of code and I don't really understand it and so this seems like a perfect moment. So I need to

• When arriving at a ticket or a large problem
• Take a look at the code
• And then I need to:
• Think about the outcome that is trying to be achieved 
• Try to identify 
• what currently exists
• what parts of the codebase are talking to each other
• AND WHAT IS THE POINT OF EACH PART

So I am just about to do this now with a new ticket. It should be really hard. But let me give it a go.

I know. Let me try and do it for a bit and then write some more.

This bit has just jumped out at me.

"draw out a diagram - describe what is happening - and point to each step of the description where that code is happening." 

Okay I'm off to read a bit and write elsewhere.

Okay so

Writing a fake blog didn't happen and I can just imagine my boss in my head going "Explain to me what the code does!!!". And I can't. But let me try again thank you. Cos I can do it when someone's listening and now I just need to do it alone.

Also need to check two files...

Recap and lessons learned 

(Writing next working day). I have completed this ticket now and it is merged. Everything I did was super helpful. I would say two things.

Point one is repeating the lessons in this blog.

Point two is what I learned about waiting and doing things well, and finishing on time, which I have in total combined at least four more blog posts coming on.

Repeating the lessons learned here

I want to remind myself that

• When arriving at a new ticket or problem
• I need to think about the outcome of the code that is currently being achieved
• Especially what the outcome of the code is before I change anything there
• I need to IDENTIFY: 
• What parts currently exist?
• What systems are talking to each other?
• And: what parts of the code are talking to each other???!!!!
• That is something I can do well. I just forgot to do it in the heat of the moment. Thanks.
• I need to ask myself WHAT IS THE POINT OF EACH PART?
• I need to talk about WHAT IS THE POINT OF EACH PART?
• I need to try and draw it out
• I need to be able to describe what is happening and to point each step in the description to where it is happening in the code
• This is easy for me to do, I have been doing it for years
• I am a blogger...
• I need to be able to describe what is happening and each step in the process, point to where EXACTLY that is happening in the code please... thanks. ♥️

(Watching and) waiting

On Friday I was tired and I didn't really get any of the code and I didn't really have any idea at all of what I was doing. I was tempted to ask my colleague for some help. I didn't. I waited. By waiting I: got clear on my options, explored new avenues of help, and was able to articulate my points concisely. It turned out there was a lot going on.

I had so many environment variables missing due to being new to the repo. I had to debug a lot of things with the tests.

Imagine if I had asked that late on a Friday night! Imagine if I hadn't taken the time to articulate all of those issues properly (I know... I have done that before and I have been bad). I used to rush things but now I see so clearly to

• Take my time
• Try things out
• And if I'm still really lost then it is okay to ask clear and concise and STRUCTURED questions