The What, How and Why

I’ve thought a bit about learning a skill. How to progress. What the next steps are. This is probably because I’ve moved away from what I thought I used to be, career wise, to something else, and now I’m trying to determine what I will do when I grow up.

The only way to learn a skill is to actually perform the task. To do it. This ranges from the very basics – crawling, walking, running, cleaning your room, and so on. You can get inspired from a million YouTube videos and blog posts, but to learn to do something yourself, you need to do it yourself.

If we look at programming. This is something I’ve done since I was ~12. I know how to code. I can tell when other people know how to code. They get it. Then it is not as much about what language or framework to use. Instead they understand the concept of code. How to solve problems using code.

There is a tangent here about tools and frameworks and how the volatility of this side of the trade ruins my conception about knowing how to code, but let’s save that for later.

My issue with coding is that it quickly becomes “pick another ticket”. What intrigues me is the what to do, which leads to two very interesting questions – why? and how?

The why is interesting because it moves from the art of implementing code to the mysteries of figuring out what the customer whats. This quickly leads to business and how can we have a sustainable customer relationship. Something that is even more interesting when it comes to open source, as the customer is more empowered and in many ways acts as a partner instead of a customer.

The how is also interesting. Especially when you look at the question through the lens of a large project that will take time to build, or through a corporate lens. This is where methodology comes into play. I hate to say agile, because it means so many things, but there are supports that can be used to support both agile and less agile ways of working. I’m thinking of automation. Automated builds, automated tests, automated deployments, infrastructure as code (i.e. some sense automation of the automation). There is a mountain of non-recurring engineering that each software organization must climb to be productive.

For me, these stages came as a linear progression. First I did, then I thought about what to do, when why and how, but they are interconnected. There are various feedback loops hidden, which both limits and drives the progression of the product and team.

Looping back to the original question – what do I want to do when I grow up – I’ve started to circle in towards building teams. I’m still to fully define this, but this would be to help drive the why, how and what to provide purpose and a nice work place for a development team. The question I’m asking myself right now is towards whom to define the why, how and what. It very interesting to do it directly to the end customer, but in a corporate setting, that is rarely the case. Then, instead, this must be defined in relation to the surrounding organization, and how to do this in a good way is still something where I’m in the do stage.

Do you want me to dive deeper in any particular direction, or have thoughts of your own? Reach out to me in the comments or at Mastodon.

This post is a part of my 100 days to offload effort.