The hardest part about writing software

The hardest part about writing software, for me at least. Is not learning the right language, or finding the right tools. It's not about using the correct algorithms or design patterns. For me, that's the fun part.

No, for me, the hardest part is process. Don't be deceived, although I have 'engineer' in my job title. I've never sat a formal examination, I've never had any formal training, or education on how to write software. I just spent a lot of time, mostly my free time, learning how to code, learning new languages etc.

In other words, I only taught myself the 'fun' parts. I didn't really know what Agile or Scrum meant, they might as well have been synonyms for 'sometimes putting things in Jira' for all I knew. It was just one of those things I put on my LinkedIn, and hoped I never got asked about it too much.

Well recently fate called my bluff, a decision was made to go 'full agile' at work. Previously I worked in isolation, I only updated people if they asked me several times, I found myself saying 'why don't people just look at my Jira?' - well, someone then pointed out that I'd not updated Jira in 3 days either.

I hated Agile at first, it felt unnecessary and bureaucratic. I'd scowl at my phone throughout stand-ups. I'd set my Slack to 'offline' so's not to be disturbed, and I'd update my Vim theme more than my Jira tasks.

I saw the rest of the team fly ahead, working together efficiently, and to be honest I started to feel frustrated and left out, but it was all my own doing. I finally had to admit to myself that I was struggling because I was working against the grain; against the process, and I had to start from scratch with my attitudes towards process in general.

But I don't think I could be blamed, in my 6 years as a Software Engineer, up until recently, had been marred by countless failed half implementations of processes, ever changing workflows and a lack of context or explanation.

It was too difficult to learn because it changed each week. It was like trying to board a moving train. So I found inconsistent process, was more damaging for me, than a lack of process at all.

An engineer in a traditional sense, would have learnt all of this from day one. It's great that you can buy a cheap laptop, spin up Code Academy and become a 'Software Engineer' within just a few years. Compared with the best part of a decade a traditional engineer would spend in formalised training. But you miss something truly vital.

This isn't me trying to sell you the 'agile way', or the 'scrum way'. This is a cautionary reminder to fresh faced engineers to learn to value process, because they aren't just prosaic relics of the bygone days of COBOL programmers in lab coats, cautiously tapping away at mainframes, glancing occasionally at clipboards. This is something salient to engineering as a craft, and it will make you a better programmer.

Process can sit well within your 'hip' start-up. It's not about 'rules' it's about having an agreed, efficient way of triaging problems, consuming them, and turning them into something tangible. Which is more an axiom of engineering than picking up a laptop and learning Javascript.