What They Never Taught Me About Software Engineering 

My heart is filled with love. I am back home in Luxembourg. I would give anything to stay here. Maybe one day when I can drive. Maybe one day I’ll get a renewable energy job out here. Maybe one day I’ll find a way to get back here. But for now I dance through the energies as the air kisses me. And the air is filled with love. From all of the thousands of trees. And from the fresh air following the rain

Thank you 

Now what they never taught me about software engineering is this:

Is how to read and process tickets in a way that makes sense to me. And while some people told me and I have pieced it together over the years no one gave me a formal and structured process. So I am here to devise my own frickin method. Here it is. After all of these years. How it is I should approach a ticket:

How to Approach A Ticket in 5 Easy Steps 

1. Make sure you are clear on the acceptance criteria. Check if the ticket has acceptance criteria. Let’s assume it doesn’t as otherwise I would obviously not get stuck on this step. So let’s say there are no friggin acceptance criteria. So what do I do? I create a comment on the ticket. And then I write down what I think the acceptance criteria are. And then send them to my boss or anyone else involved with the ticket. Then they can tell me if I am going the wrong way or if it’s right. Spoiler alert I never normally get it wrong…
2. Find the problem in the UI. This is a frontend thing. Because most of my previous work was AI I didn’t normally have this. But now - I can go - okay, where in the UI can I find this. I don’t like this. While the product is new and unfamiliar this is really hard for me to do. I hate new and overwhelming things. Either way - I need to try and find stuff in the UI. I don’t know how. Every day another miracle right? Or I can ask someone
3. Find the problem in the code. This bit is actually easier once you have the UI or a screenshot of the UI. Often you just copy a string or some HTML text. Then find the problem in the code. Nb what you find here could change the acceptance criteria and so this is an iterative process
4. Read all the code in the relevant files. My code comprehension is great. And where there is something that is really not clear there are ways to decipher a small block of code - I am fairly new back to react - but it all makes sense. So really the key thing is to read and understand the code. The issue I have is that I struggle to do this alone. If there is someone with me and I have to explain it to them I find it so much easier. Kind of like with my blog posts. So I have been thinking about using AI or something in voice mode to speak into. Because I can’t always have someone with me. Writing out is good to - but usually only works after speaking it out first once
5. Ask the ticket author or anyone related any questions about the existing code or the ticket based on having read the code

And that’s it! I will be iterating over this

I would still prefer it if information came to me in a consistent reliable format. If a ticket always had the same structure or if a call was always guaranteed around a ticket. That is the challenge of autism.