Published on 28 May 2015 , last updated on 28 May 2015
As a child (I think I was around 6 at that time), I wanted to become an inventor, much like Gyro Gearloose. My father wisely pointed out that this wasn’t a job that existed on the job market, but that the closest thing was likely to become an engineer of some kind. And so I ended up becoming a telecommunications engineer with a specialization in the development of distributed systems.
Software is an excellent medium for expressing one’s creativity. It is cheap and malleable, and nowadays it is possible to see the result of what code does almost instantly. I haven’t yet figured out how to build a walking light-bulb with software yet but give it 15 years and we’ll have APIs for this, too. But programming is not easy, which also means that next to actually building things, we software people spend a lot of time learning how to build things and arguing about how things should be built.
I like to think of my career as a software professional in terms of “learning – applying” cycles. In an “applying” cycle, more than writing code and being concerned about how “beautiful” or “ugly” it looks (in my eyes), it is the act of getting something meaningful to work that I focus most on. By meaningful, I mean useful (which may well be a matter of personal taste). Which is to say that it doesn’t have to necessarily look like the most beautiful code I could possibly be writing, nor that it will have a code coverage of 100%. I don’t mean to say that all the previous learnings about writing clean code and continuous improvement and so on have to go straight out of the window in such a phase, just that their priority is outranked a little.
Which brings me to the core of this post. As a freelance consultant, I think that identifying the right priorities at any given point in a project or a task are a crucial part of the job. This also holds true if you are an employee – only that an employee may not be kicked out for failing to
be good at prioritizing find out what adds the most value at a given time, at least not in Europe (for having contracted in the US, I know that the situation can be quite different there). And, in my humble opinion, it may actually be legit as an employee to spend some time on the job learning and improving as this will benefit your employer on the long run (as a freelancer, you must do this as well, but you can’t quite bill the client for it).
If you are working in an environment wherein someone is doing a good job at prioritizing tasks, good for you! Depending on what situation you are in, it isn’t unusual to find yourself in a place where priorities are unclear and dictated by office politics, suboptimal company culture or rogue sales people more than by reason. Or maybe there are priorities but they are changing, because hey, agile! My impression is that “unprioritized” environments are more frequently to be found than “prioritized” ones, and I wouldn’t say that this is a bad thing, just that this is a kind of environment we software folks need to know how to operate in.
Ergo, let me write down some questions that in my opinion help the prioritization of the tasks at hand (this is not an exhaustive list, but it certainly is a start):
At the end of the day, code itself doesn’t help – in the contrary, the less of it there is, the better you are off. Finding the right priorities and the right order of tasks is not easy, but since it is also key for writing more useful code, I have the nagging feeling that it may well be the most important skill for a software person. After all, we derive much of our happiness by fooling ourselves that what we do has a meaning, and that isn’t always obvious to see when meddling with the wondersome world of computers.
Liked this post? Subscribe to the mailing list to get regular updates on similar topics.
© Copyright 2018. manuel bernhardt. All rights reserved.