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 an independent 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 an independent consultant, 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):

  • who am I doing this for? Do you truly serve the interest of your client / employer / user, or did you just start refactoring this working piece of code because it didn’t fit your standards of “beautiful” code without anyone asking you for it? If you were tasked with reducing technical debt, great! If you were tasked with building a new feature, ask yourself if you are maybe not procrastinating. Unless you are planning on significantly re-using or extending said code, chances are that you are not providing value to anyone but yourself in that very moment, and that the refactoring you have in mind - be it a good idea or not - can wait some more and sit in a ticket of some kind. I think that it is especially easy to get carried away in a “learning” cycle.
  • is this a “nice to have” or a “can’t do without” feature? This one is not always easy to answer, and communication is key. Ask the end-user (or the closest thing you have to an end-user), other people on the team, so as to get yourself a few different points of view on the matter. If it is a “nice to have” feature, question it, maybe write it down somewhere (many ticketing systems have a kind of “nice to have” flag), and keep moving on. Beware: if the feature significantly improves usability, then this may well be a “can’t do without” feature. Don’t make your users go insane.
  • do I need this now, or can it wait until later? (and if yes, don’t do it now). Also known as YAGNI, kind of.
  • how critical is time to market of this feature? If you’re in an “unprioritized” environment, then you may end up with a slightly odd impression that bloody everything is equally critical and has to be done this instant, NOW (WHAT ARE YOU DOING SITTING HERE READING THIS ARTICLE? GET BACK TO WORK!). Trust me, it isn’t. Finding out what is and what isn’t does again involve a subsequent amount of communication and may sometimes be out of your “turf” in the organization. But if you have a chance of putting that very feature you are working in into a business perspective, you will get a much better appreciation for its priority.
  • does it really have to be that complicated? Sometimes a feature hides another, much simpler truth. Talking with the end-user or their closest relative to get closer to the core of a problem is quite useful in this regard.

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.