Peter Conway

Software Developer

Peter is a back-end developer for one of the Headforwards teams, working for a large telecoms/managed services client. Attending workshops and Agile on the Beach, he has a keen interest in best practices for software development. As a Physics grad, he channelled his love of statistics and numbers to become last year's Headforwards fantasy football champ. He also enjoys running and tending to an allotment in his free time.


During the first COVID lockdown I, like many others, had a lot of time on my hands, and became more interested in mental health and spirituality. I’ve spent hours reading articles and watching YouTube videos exploring concepts like karma. And the more I learned about karma, the more I felt like it shared similar principles with good programming.

Karma isn’t, as I once thought, simply the notion that good things happen to good people and bad things happen to bad people. Instead, it suggests that there are links between a situation today or in the future, and choices we’ve made in the past: “Good intent and good deeds contribute to good karma and happier rebirths, while bad intent and bad deeds contribute to bad karma and bad rebirths”.

So how does this relate to software development? Here are a few thoughts.

Sowing seeds

I find ‘sowing seeds in a garden’ to be a useful analogy for understanding how karma works. When you’re trying to cultivate a garden, you sow as many ‘good seeds’ as you can – hardy hedgerow plants or pretty flowers – and try to avoid sowing ‘bad seeds’, like invasive species.

When you’re writing software, you’re planting a garden of code. You sow good seeds along the way by documenting your work clearly, using test-driven development approaches, or taking the time to tidy up a messy workaround.

I believe that a good developer is one that sows as few bad seeds as possible – and that’s how you build good karma for the future. An example of a bad seed might be skipping writing a test for some new code because of a deadline, or giving a variable a non-descriptive name like ‘n’. And when that seed pops out of the ground later down the line, you – or another developer who’s working with your code – have to deal with the ugly, difficult-to-uproot weed.

A project with technical debt is a garden full of weeds

Technical debt is a name for work that should have been completed prior to a release, but had to be skipped due to time constraints. Any time a bad seed is planted, it adds to a project’s technical debt – and you can’t always be sure when it’s going to sprout.

There are a lot of ways technical debt gets planted in a project – if you don’t remember to update your documentation, or you decide to skip a nice-to-have feature, for example. Sometimes you just inherit someone else’s code and associated technical debt, and have to deal with it.

Working through technical debt isn’t always easy, but once you’ve put the work in to clear the weeds, future maintenance won’t take up a lot of your time.

Keep a record of your technical debt somewhere obvious to create a sense of ownership over it. I find physical walls work better than virtual boards. With real cards pinned to the wall, you can really visualize the scale of the debt you’re working with.

Good seeds pay it forward

While I’m programming, sometimes a task feels easier than I expected. This is what happens when good seeds blossom. Well-written and tested code, intelligent design and good maintenance are all good seeds sown before me that made my objective easier – the result of building good developer karma.

There’s a real element of altruism to good software practices. There’s no guarantee that you’ll be the one working on the code when your good seeds bloom – but giving another developer the benefit is useful for boosting your karma. With any luck, they’ll take a similar approach and your life will be a little easier somewhere down the line when you work on their code.

And if you need to plant a bad seed due to time constraints, here’s an important thing to remember: there’s nothing stopping you returning another day to dig it up.

Karmic programming in action

Karma says any situation is the product of prior circumstances and decisions. For coding, that means a developer often isn’t solely responsible for something going wrong – and their successes can be at least partially thanks to other people planting good seeds ahead of time.

And unlike manifestations of karma elsewhere in your life, programmers are blessed (or cursed) with ‘git blame’. If you’re finding it difficult to write some code and you can pinpoint why, it’s a troubleshooting command that can tell you the exact date and time a developer planted that bad seed. But if you’re trying to build up good karma (of the regular kind), it might not be worth the argument!

Want to know more about how we use mobbing to deliver quality software? Get in touch