Everything's A Nail

Burnouts and hiatuses

Before I quit my job, after an ongoing battle to be allowed to spend more time working remotely, I asked if they would consider giving me a couple of months of unpaid leave to recharge and spend some time travelling. They said no. I quit. Now here I am, 9 months later very (okay, mostly) happily living the NEET life, travelling and working on personal projects.

During my notice period, the company started another callously executed round of redundancies - sorry, restructuring. On reflection, I think it is likely that my head would have been on the chopping block if I hadn't just quit1, and I had instead skilfully manoeuvred myself out of comfy severance package.

This is usually where I leave the story of quitting my job when people ask me about my career break. It is a nice tidbit of smalltalk, and I get the chance to participate in one of my favourite pastimes - complaining. If I'm feeling particularly spicy that day I might utter the magic word "burnout" in passing, receive some understanding nods, and the conversation will move on.

Which is probably where it should be left for casual exchanges. The ins and outs of reaching the point I would call "burnout" are a complex, personal topic, tinged with anger, guilt, sadness - most of the big-hitting negative emotions. It is Big Talk. Wanting to take control of my work-life balance is certainly reason enough to have left, but in reality there was so much more to my decision - the environment I was working in had been eroding my joy for what I do for months. Now, a year on from when the deep-set unhappiness and cynicism with my job really started, I still don't feel "over it" and I am still grappling with the emotional fallout. However, there is more emotional space available to put fingers to keyboard on the topic, and in this post I would like to start pulling on that thread.

How did I get here

Having bounced between sectors and different team structures for several years, I had gathered enough breadth of knowledge of backend engineering that my learning curve was starting to level out. I had slid out of my early career into the middle, and with the gloss of "everyday being a school day" starting to wear thin, something needed to change. I was in ad-tech, and for all the corporate hype about our industry-disrupting product2, nothing about the technology was remotely exciting to me - I had no passion, nothing I was doing impacted the world in any way I cared about.

So, when an opportunity arose at a health-tech company working on an issue in which I was personally invested, it felt like a puzzle piece falling into place. I don't want to name names, so let's call this company Y - as in "Y did you let me down". They used Scala, but were inexperienced, so lots of scope for teaching and establishing best-practices. They were a small team, so there was lots of room to have a big impact, take on plenty of responsibility, and help chart the course on engineering decisions. During the interviews, these factors made me feel like I'd found my golden goose, the obvious next step on my hero's journey - but this would be no fairy tale (dun, dun, DUN!). They turned out to be less so double-edged swords, and more so bludgeons that I would find myself being repeatedly beaten over the head with for the next 18 months.

I am going to preface all of what follows with this acknowledgement: I am aware that start-ups/scale-ups have budgetary and external constraints that strongly encourage a culture of "move fast and break things" just to stay afloat. Secondly, I am a great believer in Hanlon's Razor:

"Never attribute to malice that which is adequately explained by stupidity."

and variations which replace "stupidity" with "ignorance", "laziness", or "pressure from insane CEOs". People are mostly good and well-meaning, but their actions often obscure their intentions to the point where it seems like they are actively trying to cause you psychological damage. Later in the text when I make reference to the actions of individuals, I personally try my best to take what they did with a grain of Hanlon's salt, and in the understanding that I didn't have the full picture. But for the sake of brevity and storytelling, rather than prefixing everything I report with "it seemed to me that" or "this gave the impression that", just take that as read. All that said: no corporate-brained reason is an excuse for making your employees or colleagues feel disposable and worthless. The efforts made by this company to support people's mental health and satisfaction with their work were pitiful.

Your choices have consequences

Scala: How do I love thee? Let me count the ways. I really do like writing Scala: I enjoy its versatility, its expressive power, its ergonomics. All reasons why I seek it out professionally and use it in my personal projects. I arrived at Y expecting to find a team inexperienced with the language, but trying their best and willing to listen and learn. What I found instead was tens of thousands of lines written with barely a basic understanding of best practices for the language or industry standards. There was little in the way of care or craft, just a tower of haphazardly arranged blocks barely held together by sticky tape and a dream. They weren't even using a formatter3, which I promptly addressed, but that should have been taken as a sign to get out with my sanity intact.

I agree with the idea that "the best programming language to choose for a project is the language that you know". They had fallen at that hurdle, then failed to manage any of the consequences. But, I gave them the benefit of my patience - I started a Scala working group, ran lightning talks and weekly office hours, started building tooling and infrastructure to standardise the codebase4. I even wrote a five thousand word manifesto (rich in TL;DRs for the lazy reader) on how to build a stable, sustainable platform. This, after all, was what the senior engineering management seemed to have brought me in to help improve. I was sure that there was light at the end of the long tunnel, and if I poured enough of my passion and excitement into my work, then baby step by baby step we could turn the ship in the right direction.

Alas, a ship needs a willing crew, and from the start the near universal disdain for anything written in Scala was abundantly clear. I really do feel for my frontend colleagues who were being made to work on this Frankensteinian monstrosity of a codebase - the most innocuous change could cause a production bug that required a ritual sacrifice to unravel. I understand not wanting to touch that spaghetti more than I was contractually obliged, especially when many had been sold their role without Y being upfront about how much backend code they would be expected to write.

However, a culture had been allowed to develop in which Scala was seen as a Dark Art that was better gotten rid of instead of something to take any interest in understanding or mastering. My colleagues looked forward to The Great Rewrite, when the backend would be Node, not stopping to consider that some of us actually enjoyed having a job writing Scala. One engineering lead was particularly guilty of this, even going out of his way to tell our junior backend developer during a one-on-one just how little he thought of Scala. Can you imagine being at the start of your career, less than 6 months into a new job, and having your manager tell you that what you do for a living, the thing you do for 8 hours a day, is a waste of time?

A bit of playful teasing about languages is par for the course among developers - I do not resent my frontend colleagues for this, as they had issues enough of their own to handle without being forced into the backend hellscape. But the cultural aversion that began with the tenured leads chipped away at all of us over time, and dissolved my hope and excitement into pessimism and irritation. I raised this with the director of engineering on several occasions, but nothing was said, and nothing changed. The lack of action from management to address it was one of many indications that they were out of their depth.

More than just lines of code

I wish I could say that the arbitrary, uninformed choice of language was the end of the story, but there was a much more fundamental clash of ideals that I faced at Y, namely their attitude towards everything beyond the code. Software development is much more than just writing the code that accomplishes some function, and, as pretentious as it might sound, it takes much more than mastery of a programming language to go from being a code monkey to a software engineer.

It is not a perfect analogy, but let's say you want to build a table. A table is really just a flat surface that can hold things - but there is huge difference between a carefully and elegantly shaped piece with a nice, varnished finish, and a wobbly block that gives you splinters. Sometimes you might not have the budget for oak and instead have to use plywood, but a carpenter would still care about creating something that is pleasant and reliable to use, and know how to use the tools at their disposal to bring it to life. Software engineers likewise need to care about the craft of building software: understanding how and when to use a tool or technique, or being mindful of ergonomics and robustness. In fact these considerations are especially important in software as the projects are collaborative and iterative - not only does the end user experience need to be reckoned with, but also the experience of your fellow developers both present and future. Going further still beyond the analogy to other craftspeople, a software engineer needs to be thinking about testing, automation and data security, especially when people's sensitive healthcare data are being handled.

The craft of writing software is something that I care strongly about and pay great attention to honing, better understand, and wield with regard for my fellow developers. And it is not something I care about purely for philosophical reasons; I firmly believe that caring about craft helps developers make a better product, and makes development cycles easier and faster. Slow is smooth, smooth is fast. So it was jarring to find that at Y there were some folk - mostly those who had been there some time when I arrived - who were positively allergic to good engineering practices, and showed an unwillingness to improve. I've clashed with people before over technical decisions, but in most other cases it has come down to us both caring deeply about quality but disagreeing on the means to that end. This was the first time I had encountered anyone who showed hostility towards seeing software as anything more than a blunt tool.

The aforementioned lack of formatter was the tip of the Carelessness Iceberg, and like the Titanic I had steered blindly into its path by taking this job. I often found myself answering the same questions over and over again about the meaning of errors or how to read the logs, or having comments I left on pull requests completely ignored. Had my frustrations been allowed to grow any further I would have auto-responded to every Slack message with LMGTFY or RTFM5. I won't even get into some of the bizarre infrastructural decisions that were made, the misuse and abuse of certain tools, or how little regard some others paid to protecting user data.

It was easy at the time to feel an inkling of imposter syndrome. My work and push towards better practices were apparently futile, so maybe nobody was listening because I was in the wrong and didn't know what the fuck I was talking about. However on the very, very rare occasions that I received any sort of review or feedback on my work it was positive, so instead I can only conclude that I was right and my time and energy was simply not worthy of the same respect I was trying to afford others. Eventually the Carelessness Virus infected my mind too, and the only comfort I took in my work day was getting to bitch with my work friends about the sorry state of affairs in which we had landed.

Catharsis?

Setting out to write about this experience I expected something of a cleansing release of emotions; instead it has been an unpleasant walk down memory lane that only makes me more anxious to eventually rejoin the world of work and potentially find myself in another similar situation. There is still much that I didn't have space to cover here - like wasting several months pouring long hours into a huge infrastructural change that was ready to ship and then canned at the last minute, or how I was at times overbearingly micro-managed. I have mostly focused on the engineering aspects and how they were totally mismanaged, but there are also some non-technical interactions that still make me feel unreasonably angry when I replay them in my head. Reading back, I feel that I have been very fair in my presentation of Y, yet just the act of expressing such negativity makes me feel guilty.

I feel a real sense of loss for my wasted effort; I wanted so dearly for my work to have an impact - to Make A Difference - and I do not feel that I made any tangible difference at Y. I was also working on platform features during my entire tenure - on top of all the systemic engineering changes I was trying to bring in - and I don't think any of them produced anything that would actually help people. I can take comfort in some of the relationships that were forged during the heat of battle - if I had any influence, it was on my fellow underlings. Maybe that is enough.

As this is ostensibly a blog primarily about my personal projects, there is something to be said (maybe at another time) on how the experience of building software that is wholly my own has thrown into relief the pains and pitfalls of working for my previous company. Just to end this piece on a positive note, I had one tech lead at Y (who, notably, joined not long before I did) who taught me a lot about managing the politics of a software project in the face of ever-changing and ill-defined scope. They also helped me develop a better sense of when code is "good enough", and the art of not letting "perfect be the enemy of the good". These are probably the most powerful lessons that I try to apply to my game development, where the temptation to constantly refactor and refine runs the constant risk of grinding my progress to a halt. Aha. I think that's where a hint the catharsis was hiding.


  1. This is pure speculation, but I was both expensive and had little patience for the status quo and the micro-management, so I feel like I was ripe for the pruning. At the very least I might have saved one of my colleagues their job instead. 

  2. Snark mainly for narrative purposes if you guys are reading this, I generally had a nice time working there. 

  3. A formatter is a tool that enforces formatting (whitespace, line breaks, etc.) on your code. It ensures that when different people work on the same code the formatting doesn't constantly change. I can confidently say it is THE MOST BASIC tool that should be used in collaborative software development, aside from version control, which, thankfully, Y was using... 

  4. I was not alone in these endeavours, my fellow backend developers were just a passionate about spreading the good word as I was <3 

  5. "Let Me Google That For You", and "Read The Fucking Manual" 

Thoughts? Leave a comment