There are many forces outside of a developer’s control that can make their life harder, from an uncomfortable chair or an incompetent manager all the way to geomagnetic storms that can fry the electrical grid of a nation.
But there are also times when something goes wrong and developers can point the finger at nobody except themselves.
Here is a concrete example – or more precisely, six concrete examples, imagined as possible scenarios on the job.
These are general case studies and it is important to stress from the outset that there will always be exceptions. The purpose of this article is to encourage you to take responsibility for what is under your control, not to have you consistently blame yourself even in the most extreme circumstances. So if your personal experience tells you something different than this article, well, go with your personal experience!
That being said, let’s get started with…
Case 1: “My teammates don’t understand how useful I am”
For developers emerging from an educational environment, it’s often a minor shock to find that most of their new teammates may not be proficient with technology at all. If luck isn’t on your side, this may well include management, and as a result you will find yourself surrounded by people who do not understand what your work really involves.
If that is the case, it’s your responsibility to make sure that others understand the way you contribute to a project and that they appreciate your value to the team. This is not to say that you should spend half your day bragging, but if an idea you came up with improved the performance of your company’s website, or something you worked on by yourself enhanced your user experience, then the next time you sit down with your boss or at a team meeting, tell them what you did and how it made a difference. Don’t just clam up and expect others to simply know.
Also, do not fall for the common misconception that ‘good work speaks for itself’. That may be true if you’re painting a house – it doesn’t really translate to software development.
Case 2: “Debugging my own code eats up a ton of my time”
Every developer knows at least one story about some legendary, cryptic bug that was impossible to find. Many will find themselves as the protagonists of such a story at some point in their careers.
But these stories should really be the exception, and if you regularly find yourself wasting hours or even days looking for bugs that turn out to be relatively simple in code you wrote yourself, then it’s high time you changed something about the way you write code in the first place.
Wasting too much time on bugs is a classic sign that you are not testing your code properly, or perhaps only testing it it as a finished product, in big chunks. Instead, develop a habit of writing unit tests, which proof your code at much lower levels. That should drastically reduce the issues you’ll encounter at a later stage. If you’re wondering where to start on this, Katy A has an excellent introduction to unit tests, and you can also take a look at our previous articles on the art of debugging.
It goes without saying that this argument only holds for code of your own writing. If someone puts you to work on poorly-written legacy code created by somebody else, well, that’s not a bed of your own making.
Case 3: “There is no way I can meet the new deadline”
Here’s one mostly for freelancers and solo (or semi-solo) developers in start-ups.
“How long do you need to add this feature to the project?”
“Seven days.”
“That won’t do. Can you do it in five?”
If you are ever asked that question by a client or by management, the correct answer is always no. They asked how long you need to get your work done, and you told them. If this is not acceptable to them, then they can either look somewhere else (as clients) or you can explain to them that a delay in the project is inevitable.
Do NOT, under any circumstances, commit to completing a task in a shorter time than you know is possible. If you do that, and you find yourself up at 3 a.m. on Sunday working on your console, then you really have nobody to blame but yourself. Don’t become the sort of developer who doesn’t know how to say no.
Of course, freelancers working with clients have some room to be flexible – for example, you may choose to charge a premium if you think working longer hours is worth the money. But even then, be careful what you’re signing up for. No premium is ever so high that it’s worth risking burnout for it.
Case 4: “I used somebody else’s code, but now I no longer understand it”
We actually wrote a fairly extensive guide on when it is and isn’t ok to copy code, but the long and the short of it is that no matter the situation, if you are using code that was originally written by somebody else, then you have to make sure you understand it first. Even if it’s just a short snippet which comes with a direct description of what it does, before plugging it anywhere it is imperative that you read it line by line and get a clear, first-hand understanding of its contents and its logic.
If you don’t, then any unexpected and undesirable effects of the code you used are totally on you, and certainly not on whoever wrote the original code. And, if you make it a habit of working this way, then be certain that those “effects” will be coming sooner or later.
Naturally, this scenario does not extend to using libraries – you’re not expected to verify the codebase before using it. Bear in mind though, that doesn’t mean that when using a library there is no due diligence to be done – how many stars does it have on GitHub and what does its issue tracker look like? Is it being used by larger companies? Is it still maintained? Google the library and see what results pop up, don’t just grab anything that looks good.
Case 5: “I can never understand code that I wrote more than a year ago”
This is a very common experience, and often there’s nothing problematic about it. As your coding style evolves, you may often find yourself looking back at programs you wrote in the past – particularly those you came up with as a beginner – and wonder what on earth it was that you were trying to do.
On the other hand, if you create a boilerplate project that is intended to be reused, and upon looking at it after a long time you don’t understand what it is doing, then that simply means you haven’t properly commented your code. It’s a fairly common mistake to make, but still one that is completely avoidable with just a little bit of patience and foresight.
This isn’t just something that you should be doing for yourself alone, either – others will have to maintain your code in the future, so make sure it comes with the ‘user manual’ it needs to be rapidly picked up and understood. If you don’t do that, and a couple of years down the line you find yourself baffled by something you wrote yourself, well, that’s karma for you.
(In fairness – we should also be commenting code that is not meant to be reused. But we should also not eat food high in cholesterol. I won’t take the moral high ground…)
Case 6: “Coding is harming my physical health”
This one comes with a few caveats, as there are some companies that do not provide adequate office chairs or standing desks, and they must be held accountable for their working environments. Also, it’s important not to conflate physical health with mental health – the latter is a lot more subtle and not something that we can always take care of by ourselves.
With all that said, it is astonishing how many developers – particularly among the youngest – won’t bother with even the most basic adjustments to their routines in order to take care of their bodies. Sitting all day in front of a monitor is not something that is good for you, and if you intend to do it for a career, then managing your health is your responsibility – one of your top responsibilities, at that.
Stay hydrated, take regular walks, keep a correct back posture, get yourself an ergonomic chair and a good keyboard, and most importantly, exercise. None of these things are optional, and nobody will do them for you. So start now.
***
And with that, we have come to the end of our overview! Can you think of any case in which you felt that you could only blame yourself, which we forgot to mention? If so, remember that it happens to all of us – don’t beat yourself up about it!
