Introducing the Coding Carpenter

A series about software project management

Before getting started, a cliche′ flashback is in order:

It was the summer of '24 when I finished my first ever major carpentry project: a wooden deck for the back of my house. By the end of it, my flesh was bruised, my hands ached, and my legs burned. I had spent so much time crawling on the floor that my knees and turned black from the dirt and grit.

At one point, I ended up in A&E (Acute and Emergency Care) because nine 10 ft. long 2" x 4"'s had fallen square on my head (for those of us in the UK, that would be 3000mm x 50mm x 100mm). After this incident, my wife had doubts that I would ever get this done, and she was already contacting trades people (a.k.a. "tradies") for quotes. Much to my wallet's relief, I was able to carry the whole thing through to the end.

Looking at this picture and inspecting the finished work, it's possible one would never think this was the first time I made something like this. In all honesty, it was many days of tripping, bumbling around, tearing up and replacing boards, questionable patch work, etc. But rather than focusing on the mistakes made, the correct approach would be to look toward making the next one better. In the world of #agile, we call this continuous improvement. Here I am talking like I know something about software engineering.

Spoiler alert: I am not really a carpenter, I am actually software engineer that has taken up wood working as a hobby. However, "The Carpentry Coder" did not not roll off the tongue as well as "The Coding Carpenter" so here we are. That being said, I am an (un)registered trades person that does pro-bono or volunteer work when I can (in the UK, sole traders should only register if they have an annual revenue of more than 1000 GBP). That should count for something, right?

But I digress, this series of articles are actually about software project management and not necessarily about wood working. Ever since I took up this hobby, I have unexpectedly discovered a lot of correlations between software project management and construction-centric project management, i.e. building a deck.

One of the reasons why I decided to start this series (aside from shameless brand promotion) is that, at the time of this writing, I am starting to contribute more toward other pieces around agile software development practices. Looking broadly at most responses from those in strategic leadership positions, their answers are very similar: stay agile but be prepared to adhere to tight timelines, go the extra mile, lots of meetings, cameras on, try and bring people back into the office, etc.

Those of us on the merciless front lines of software engineering have a very different picture of what a successful agile software team looks like; these concepts are broadly accepted by those who study project management as a science and are even discoverable through individual empirical research. So why are they not widely accepted? Do they need a more consumable, appealing medium? More concise messaging? Some kind of meme? Do I need acronyms in my LinkedIn tagline and transform it into alphabet soup?

To help explain these concepts further, and hopefully defeat aforementioned fallacies, I decided to start this series, but through the lens of something seemingly unrelated: wood working.

Why wood working? As a craft, it requires both domain expertise and project management disciplines. Despite what people may glean from watching online tutorials, wood working is difficult, timelines are often tight, mistakes are costly, and risk is high; the project context surrounding a wood working project shares a lot of the same threats and weaknesses, and even some concepts, found within software projects.

I think that is enough of an intro whilst still leaving enough to the imagination. My dearest readers, I hope you enjoy the series.