I once had an engineer, just a few years my junior, come to me quite annoyed. They had several months previously invested quite a bit of time into planning and building a feature, and had delivered it on-time and to-spec. That feature was being removed in order to reduce our maintenance burden; it hadn’t been a hit with customers.

Software is a strange field. It’s a creative discipline1 where the works we create are ephemeral, often disposable. I think this is even sadly true in games, but that’s a discussion for another time. I’m not sure it’s possible to do good work in any creative field, no matter its target audience or purpose, without caring about it at least a little bit. How do you reconcile that with knowing that any code you write will, some day, no matter how good2, end up in someone’s red PR?

The advice I gave at the time, which I do still stand by, was “we aren’t paid to write code; we’re paid to solve problems”. The feature was being removed, yes, but in building and shipping that feature we were able to validate (or in this case invalidate) some assumptions about what the customers wanted. The work had done exactly what it was supposed to - get us some new information about customer behaviours and needs. The fact that it was now being decommissioned was almost irrelevant - an experiment where the result was a failure is still a valid, and valuable, exercise.

I find a lot of those “junior vs. senior engineer” memes to be a bit cringe and patronising, but I think there is a trend that the more experience you accrue the happier you are to delete large swathes of code. I love it. A red PR makes my day.

I think my advice was good, but I’m also aware that if I’d given it to myself a few years prior I wouldn’t have been able to separate the work from my emotional attachment to it.

That time I misunderstood “defensive programming”

There was a period in my career, around half a decade ago and lasting around half a year, of which my overwhelming memory is one of despair. I wasn’t in a great place mentally, and was determined to prove myself with the work I was doing, at a time when the company was going through a lot of rapid changes.

This resulted in projects I had a huge emotional investment in being cancelled or given to other people, making me an anxious, grouchy, pain in the ass to work with. Challenges to my vision or criticism during the design process were met with disdain or outright hostility. I dreaded going into the office. The feeling from my colleagues was probably mutual.

I somehow maintained the good sense to seek mentorship from my first manager, still one of the best I’ve ever worked with. We covered a lot of good ground, ranging from professionalism to emotional regulation, but there were a couple of things in particular that stuck with me.

The first was a simple way to avoid the defensive, emotional first response to negative things3. It was the understanding that your first response to something is always going to be emotional, and it’ll take a beat for your rational brain to catch up. Waiting for that rational response before speaking takes a bit of practice to someone like me who runs a little hot, but I found it amazing how effective it was.

A useful phrase I learned when responding to negative feedback, especially while waiting for the inner lizard to chill, was to say “thank you for telling me this”. You don’t have to agree or disagree - probably shouldn’t, not right away - but it gives you the time to absorb the blow and can make the experience of the person giving the feedback more comfortable. It’s also polite4, which is nice.

The other thing that stuck with me came from a book.

The Four Agreements

The Four Agreements is a self-help book by Don Miguel Ruiz, and at the time it was recommended to me it was the first such book I’d ever read.

The author suggests four agreements, to be made with oneself, which are as follows:

  1. Be impeccable with your word.
  2. Don’t take anything personally.
  3. Don’t make assumptions.
  4. Always do your best.

The back half of the book goes into some spirituality stuff that may not land for everyone, but I found these four rules to be really valuable to keep in my head. I’d remind myself of them before heading out to work, and worked them into the meditation practice I had at the time5.

The rules are self-balancing. The second one helps you not take negative feedback so harshly, while the first and fourth prevent that from making you an unfeeling monster. The third helps prevent the sort of spiralling the anxious mind can conjure, and combined with the first results in much healthier communication.

This was what got me closer to that impossible balance - caring about the work, but caring about where the work gets us more, and caring about people most of all. At that point in time I was in danger of losing my job. This helped me turn that around. The next year, I ended up getting promoted6.

I’m not trying to sell you on this book, dear reader, but I am trying to sell you on deleting code. Go Marie Kondo on your codebase. Thank you, microservice. Goodbye.


  1. It is, fight me. ↩︎

  2. We used to have a saying which was “you either die in beta or live long enough to see yourself put /v2 on your APIs”. ↩︎

  3. Or “snapping at people”, as we call it in the business. ↩︎

  4. I reread Paul Ford’s essay, How to Be Polite, at least once a year. ↩︎

  5. Meditation is wonderful and I am very, very bad at it. ↩︎

  6. I quit very shortly afterwards but I promise it was unrelated. ↩︎