Change or Die.

A tad dramatic, perhaps. However, I feel this anecdote is important to hold onto throughout all stages of your career, especially in the tech industry.

Embracing change and accepting that you are playing an endless game of “catch up” is one of the hardest things for humans to do, yet one of the most important for developing oneself professionally and staying competitive.

A few months ago, I parted ways with a company I loved due to irreconcilable cultural differences. This left me questioning my career path, wondering “what do I want to do?” and “what am I actually good at anyway?”.

Career paths are hard.

It’s been a bit of a journey since then, but I think I’ve actually learned and grown more professionally in the last few months than I had in a couple of years.

You see, my career path hasn’t exactly been “textbook”, for any of the typical roles in tech. I started out as an internet-connected child who had learned the basics of HTML, accidentally became a freelance PHP developer, then spent the next 5 of my teen years contributing to the abyss of terrible procedural PHP 4 code on the internet instead of going to school.

GetAFreelancer.com – where I spent much of my teen years.

Before I was even aware of the existence of programming best practices, I had accumulated years of experience of writing “functional” code (literally, not in the Haskell sense – real functional programming still terrifies me). Don’t get me wrong, at the time I was proud of my code, and put effort into solving things in elegant ways to satisfy customer requirements.

I’d just never been exposed to OOP, version control, or testing.

Fast forward a few years and I’d attended university, achieved a Master’s degree to be proud of, and worked at a small SaaS company for a few years. Yet, while I’d certainly learned and embraced OOP and version control, and had written tens of thousands of lines of code, adding significant value to the company – I’d still managed to completely avoid learning to write tests.

In my defence, the whole company didn’t do unit testing!

I’m a fairly ambitious person, and by this point, my career had ended up moving from “individual contributor” into the “management” track. As such, while I was still very much involved in technical decisions, I spent most of my time in meetings or dealing with customers, staff and organisational issues, so wasn’t actually writing much code myself any more. In fact, in order to be effective at my role, I actually had to reinforce mental processes to restrain myself from getting too involved in coding.

To be honest, even if I had been still writing code regularly, I’d have found it very hard to develop myself. The codebase at the company I was working for was a large, legacy PHP monolith with hundreds of thousands of lines of code and 0 tests, and unfortunately, that had become my comfort zone!

Towards the end of my tenure with the SaaS company, we matured as a tech team, built a CI pipeline and started introducing unit testing to the team as part of a push to improve quality, driven partly by myself. Yet, while I had strong opinions about the automated testing pyramid and was vigorously preaching the right way to do things, I was secretly very much aware of my own inexperience of the basic building block – unit testing.

The “right way” to do automated testing

Skipping over a year of senior leadership roles, for the last couple of months I’ve found myself writing code again – and not a line of PHP! I know I’m way behind the curve here, but I’ve finally learned how to write decent Python, including publishing my first library on PyPI, complete with tests, documentation and CI/CD handled by Travis, following best practices for open source projects in the Python ecosystem.

Even better, today I’ve finally started to understand how to think the right way for TDD. Massive thanks to @martabeveridge here, for 20 minutes of TDD pillow talk last night which helped a few key concepts slot into place. I’ve now written followed the test-code-refactor cycle many times for my most recent project, and it’s starting to not only feel natural but actually motivate me to do the same for all future projects.

The TDD cycle – natural for some, hard to adjust to for others

At this point, I think my days of writing untestable spaghetti PHP code are over. I’m finally embracing TDD (albeit 10 years late), I’m excited about programming again, and I’m finally regaining the ability to be proud of the code I write.

I’ve still got a lot to learn (and always will), but I feel like I’m on the right track again.

Big thanks to:

Leave a Reply