I’ve written this blog post in the second person because I want it to feel personal. I am telling you, no matter who you are, no matter your experience level, that I want you to disagree with me more often. I hope you’re willing to give that a try. I know that’s not equally easy for everyone, and I’m going to make sure to highlight things that might make it less easy or possible for you to speak up, and what people like me can do to make it easier for you to raise your concerns.

I’ve used data immutability to bring stability and predictability to our code, and viewing teams as immutable entities can offer us new insights and approaches to how we lead, organise, and manage our teams. This perspective not only helps us navigate changes more effectively, but also fosters a healthier, happier, and more productive team environment.

In the world of software engineering, the qualities that make someone successful aren't always what you might expect, and they’re not shared by all successful engineers. Whilst stereotypical software engineers are sometimes seen as asocial, logical computer-whisperers, in fact many different ways to thrive as a software engineer exist.

As a long-term employee of Cleo, I recently had the opportunity to take advantage of one of the company's most generous benefits - a 2-month paid sabbatical.

This benefit is available to all Cleo employees who have been at the company for at least four years. During my sabbatical, I was able to relax, recharge, and pursue my personal interests without any financial strain.

As a staff engineer at Cleo, I have been asked many times what my role entails. The role of a staff engineer can vary between companies, but in general, staff engineers are technical leaders who help drive the direction and success of their company's engineering efforts.

Finding the time to challenge the status quo and come up with something that genuinely breaks the mould can often feel like an impossible ask. We tend to get stuck in our day jobs and struggle to create opportunities to think outside of our contracted tasks. At this point, innovation stops and even the most exciting companies find themselves standing still.

This blog post is intended for an audience that’s at least superficially familiar with the concept of technical debt, as well as with the concept of interest rates. If you know what both of those things are, then this blog post is for you. If you’re not, I’ve linked some short explanations of both above; reading them should give you enough information to understand the ideas I’m about to talk about.

I’ve spent over a decade working as a software engineer, and during that time I’ve learned a large variety of different techniques for effectively writing software and leading teams. This blog post is not about any of those techniques. Instead, this blog post is about the skills that will make you better at your career, not at your job.

For the purposes of illustration, we’re going to imagine there’s a bug in some software the team has written. For some small but not insignificant fraction of the user base, the new feature we’ve built for them does not work as intended. We’re going to look at what the different levels of problem solving would mean, from least to most desirable moving down the pyramid.