How to kill a programmer
How to kill a programmer
I work as a programmer, and I love my job. I’ve worked in the past as a labourer, fitness trainer and now a programmer with small periods…
I work as a programmer, and I love my job. I’ve worked in the past as a labourer, fitness trainer and now a programmer with small periods of failed university along the way. Being a programmer is a unique mix of absolute creativity with solid deadlines; a way to take abstract business processes and make them repeatable, reliable and automatic.
However, it’s not always so excellent. Quite a few times in my now ~5 year career I have longed for the jobs before me, or thought about moving to another career after this. So far I haven’t made the choice kill my inner programmer and move on, but let’s chat a little about some of the challenges of the work.
Developing software is kind of like brick laying. Except not really.
Building a brick fence
Consider the building of a brick fence. You must first survey the land. Having built many fences before you, you carefully measure the variables; the sandiness of the soil, the clearance on both sides of the fence, the time required for you and your team to build the fence, any poor weather that’s scheduled to hit over the next few days. You arrive at a price which you’re confident with, and hand it to the customer. The customer agrees, you build a fence, and move onto the next fence.
Programming is kind of like this. At the start of each task, I will survey the software, the process to deliver it to production, how to test and ensure it will function as expected as well as how to be sure it continues to function as expected now and into the future. That’s about where the similarities end.
Building a rainbow brick fence in the sky
In the case of a brick fence, the bricks are there — you can see them. You understand their dimensions, and they fit together uniformly. Building software is more like legos. However, not the regular kind of legos; more like fucked up legos that your weird uncle glued together and then gave to your nephew who chewed on them for a while.
Gradually, you get used to these legos; you get to know them, and their quirks. New nicer and more straight forward legos are released, and you gradually refine the design of your software, but they’re still fucked up legos.
Then you take those legos and you put them in the clouds. Computers are no longer real in most cases, they’re virtualised. Hard disks are actually some form of replicated network storage. Imaginary devices hooked up to imaginary ports.
My point is, software is complex and doesn’t quite make sense 100% of the time.
Getting good at building rainbow buildings
As I’ve gotten better as a developer I have gotten much, much faster at implementing the tasks that are requested of me. My understanding about the domain in which I work (e-commerce) has increased, so I can understand clients further. As well, I’ve learned much more about how the software I build works, so can more effectively put together the bits of lego.
The rate at which I am able to deploy changes is a function of the following:
Dropping Requirements: Though it might sound weird, the fastest way to get things done is to decide that you don’t need them. Understanding more about the client’s intent is extremely valuable, but takes time and empathy.
How much I know about my lego: As I’ve grown as a developer, I understand more of the fundamental building blocks of the the software I build. This has lead to being able to quickly see and understand why it is not doing what I expect, and allowed me to write more elegant solutions that do not fight so hard against the software that sits underneath my software.
How many lego rainbows I have built: After having worked for several years as a programmer, I have gotten pretty good at certain kinds of solutions. It’s much, much easier for me to redistribute a solution I have already built and understood than to try and develop one from scratch, or even a template.
Killing a programmer
All of the above requires a large mental graph of knowledge, creativity to take that knowledge and compile from it an elegant solution that fits customer requirements and patience to discover the limits of my knowledge such that I can improve the solution I build now, as well as every solution henceforth.
The most efficient way I know of killing the development process is stress. It eats to the core of my brain, fundamentally curtailing my ability to be creative, as well as my motivation to complete the task. Dan Pink elegantly illustrates the link between motivation and reward. The link between stress and creativity appears a little more ambiguous, however from experience I find that I very quickly start solving the wrong problems.
So, without further ado, I present to you my favourite ways of killing (at least my) programming efficacy.
Death by impending deadline
Deadlines are a fact of life. We do not work in isolation, but rather as small cogs in a larger business set. We need to have work completed by a given date so that marketing can kick off, new people can be employed and trained and bugs found before large market releases.
However, I do not take issue with deadlines, but rather with the poor management thereof. If there are hard deadlines that are coming up, they should be known quite some time in advance, completed well in advance and in production prior to being needed (if behind a feature flag).
Leaving work too late leads to rapidly jammed together legos that will make new work forever more difficult. Additionally, requirements cannot be revisited due to time constraints and other developers cannot be brought into the project as it would not make sense to train them prior to the conclusion of the deadline.
An impending deadline rush is a lonely island in which you are toiling furiously.
Death by mismatched expectations
Early in my career I had quite a number of conversations with colleagues, managers or clients in which we would be unable to find common ground. We would settle on an uneasy truce, documenting our understanding of the requirements in preparation for the invariable he-said-she-said that would result following the work, and once the work was complete we would spend time simply attempting to blame shift. This is demoralising.
This has commonly happened in a few ways:
Shorthand communication in which I would say to the other person “Yah do you know that thing it’ll take about a day longer” “Oh! That thing? Sure, I know one. That’s fine”. We were not talking about the same thing.
Inherited responsibilities in which I would take over from another colleague who had left for another company, team or simply on holidays. That team member agreed to deadlines which they could quite reasonably achieve given their understanding of the product, but me?! I would spend a week burning time simply understanding how things work before proceeding at a crawl in comparison to the other person. This sets the client, who has no knowledge of this transfer, in for some super unhappy conversations.
Magically agreed upon deadlines in which you would be told that “hey we need this thing that you specialise in done in ${X} period of time and you took 4 weeks here so we just quoted 4 weeks over there that’s fine right”. It’s not fine. This sets both you and the client up for disappointment.
Death by changing environment
Software is an ever changing mental lego rainbow that is always under reconstruction to make it bigger, brighter and generally more awesome.
Often enough, I get asked to estimate what some ${TASK} will take. I am extremely lucky in that most of my work is in “time and material” mode, in which case we share the burden of estimation with the client. So, in January I will do an estimation of a fairly complex task. It won’t get scheduled — invariably, work gets shifted around during the year. That’s fine; business is dynamic, and I understand the shifting of priorities.
However, occasionally I will have a conversation in December that goes something like “Oh now that ${THINGS} have happened let’s do the ${TASK} for the next four weeks”.
This is not how estimations work. Estimations are a snapshot of how difficult it will be to implement ${TASK} at the particular time the estimate is asked. The project I am working on will be very different in June than January, and the estimation will need to be completed once again.
Should I be forced to adhere to that estimate (see “Magically agreed upon deadlines”) I will be an unhappy developer indeed.
Death by artificial stress
Sometimes, people simply seem to come to the understanding that if you are further pressured, you will work harder.
This is sort of true, but it’s not a good use of clients money. I will work harder solving the wrong problem but also I will hate you.
There is nothing good to say here. Reduce stress at nearly all costs.
Learning to live in a dangerous world
Unfortunately, many of the ways I have illustrated to kill programmers will still occur and there is little I can do about it.
However, there are things I can do in order to help me stay alive and sane.
Understanding that all people are human
In my ~30 years on this planet I haven’t yet met someone who is actively evil. Sure desperate, jaded, jealous, cheated or any number of other semi-legitimate motivations — but never evil.
It’s in that lens that I consider the situations that I find myself in that are decidedly uncomfortable. I am empathetic to those around me who also must work under fixed constraints. This does not mean I forgive them their jerk behaviour.
Empathy is understanding your compatriots. Sympathy is forgiving them.
Instead of forgiveness, I would rather work with that person such that they understand the constraints under which I operate, and are able to adjust their behaviour accordingly. As well, I try and take steps to make myself easier to work with — See the next suggestions.
Overestimate Everything
I consistently underestimate the objective difficulty of my tasks. It seems always something unexpected comes up, something that if it had gone correctly would leave my estimates intact. So, I have a choice — estimate accurately given the information I have, or overestimate?
It is much, much easier to come in under budget than it is over budget. Under budget means spare cash that can be spent on another project, over budget means another project has to suffer for this one, or worse, this one fails to launch.
The worst outcome of overestimating work is that the client will decide this is too expensive and move on. That’s fine, it’s not my task to be the cheapest but rather accurate.
Refuse to adhere to other’s estimates
As soon as a task comes down the pipe that you did not estimate but are required to complete, stop! Signal that it requires re-estimation.
This will probably annoy some people. It’s better if you warn everyone ahead of time of this requirement, but it’s far better to annoy people up front than go over budget.
Refuse to adhere to magic deadlines
As before, if there’s a deadline that you as the one who’s going to implement the change did not have a hand in creating, stop! It also needs a reevaluation.
As before, it will probably annoy some people. Do it anyway.
Learn to re-frame screw-ups
Occasionally, we all mess up. Estimates go sideways, work turns out to be far more complicated than initially implemented.
Generally speaking (at least where I work), we do a pretty good job of this. Sometimes, we do a superb job — netting (or saving) the clients a large amount of cash for a comparatively small investment. It’s important to both keep and remind others of this perspective when they’re mad about a given piece of work.
You are not your worst mistakes. You’re the general impact of your work — good and bad.
Thanks
To those who helped me design and review this post, including:
Patrick Kubica and Behrouz Abbasi for the initial discussion.
Patrick Kubica, Winston Nolan and Antonius Koch for reviews and feedback.
As well as to my colleagues who constantly put up with my … shall we say, opinionated way of doing things.