You’re working on a new feature, a bug fix or on extending a piece of functionality. After identifying what needs to change, you go ahead and make the change. Backed by the confidence of some unit and manual tests, and by the fact that another developer checked your work and approved the Pull Request, you merge the code into the main branch a week or two after you started.

Everything’s hunky-dory, you look at your backlog and pick the next item. The Wheel of Time turns.

You find yourself working on another piece of work when a message pops up on Slack or, worst, you get an alert on your pager. It turns out that ticket you worked on a few days ago is causing the app to go down! You fix it in no time, no big deal.

Another piece of work goes live. After the previous bug experience, you now double-check everything. The change was even approved, it feels safe. Two days after, there’s a bug ticket on the board, which doesn’t seem related to your work. The app doesn’t crash this time, but a section of a user flow is not behaving correctly. With some investigation, it was your work that’s affecting that flow! Didn’t you double-check everything? Moreover, the fixes take ages to reach production.

Now you’re feeling paranoid. You started triple-checking things for a while, but had to take it up a notch, leaving no stone unturned. Since the first ticket that caused an incident, a feeling began to creep up on you with every new incident and bug. Safety doesn’t exist, you’re afraid to push code, deployments get less frequent, integrating the changes gets delayed, the branches bigger, a death spiral. If you pride yourself on your skills to create quality code and want to do an outstanding job, you also feel conflicted. Nothing seems to improve, always waiting for “that” time that never comes. Coincidentally, over the weeks you’ve seen the same thing happening to other developers, bug fixes create more bugs, the new features break other features or spawn new issues.

This kind of situation means there’s little to no safety net and not a lot of shared understanding. It’s not even about not making a single error. Failure is inevitable, embracing failure is more effective than hiding from it. The shortest the feedback loop, the better. The sooner the learning, the better. If you could catch a bug the moment it was introduced, or have the ability to observe your system to see if its behaviour has changed based on your code, you can respond and fix it. If, nevertheless, the system gets to a broken state, you could have the tools to observe and to know why and the means to recover fast (rolling back changes, switching off a feature flag automatically, etc.).

With the safety net, you don’t fear failure, you embrace it and make it part of how you view software development. You know that you can go as fast as possible because you have amazing airbags, outstanding brakes, top of the line seat beats.

To me, the feeling of having a safety net is one of the bests: tests that go red because the behaviour of the system is wrong, the compiler complaining when my types are invalid, deploying changes straight to production in a short time, working collaboratively and sharing knowledge via pair programming or software teaming, tracing and debugging a problem in production with observability…

Interesting links

• Bounce Back - Strengthen your Teams to Weather Change. Heidi Helfand, writer of the fabulous book Dynamic Reteaming, writes about signals to recognise brittle teams and dynamic teams. I can definitely recognise plenty of signals of the brittle teams. I believe this article is quite relevant to this week’s topic, since brittle teams, in my experience, tend to have less safety nets.

• I Accidentally Saved Half A Million Dollars. “The competent people are there, just made totally impotent by the organization”.

• Nothing is Something. Sandi Metz’s talk about hidden assumptions and how to represent missing concepts and exposing them with code is brilliant.

Off-topic

I recently saw a viral TikTok video that got me thinking. The person in the video talks about the experience of having her first job after colleague, how little energy and time she has after the 9-5 job. Many comments on LinkedIn mentioned how she had to get over it, grow up and accept reality, that she’s just a Gen-Z that wants it easy (“back in the day we used to start working when we were 10!”).

@brielleybelly123

im also getting sick leave me alone im emotional ok i feel 12 and im scared of not having time to live

After watching the video, I got a question in my mind: why things have to be the way they are? Maybe she’s seeing her first job experience with fresh eyes, perhaps there’s truth in her words. In fact, the 9 to 5 didn’t exist until the 20th century, and nowadays, we hear more about the four-day work week, greater flexibility and mental health.

After my six-month sabbatical at the beginning of the year, I can say that was one of the best times of the past years for me. Was it because I didn’t have to work and was on “holidays”? Not really, it was the feeling of having ample time and energy to be able to do what I wanted, when I wanted it, how I wanted it, which of course included time to relax. I wasn’t playing video games or partying wild all day every day, I was just doing what I wanted to do, on my terms: learning about product management and tech stuff, focusing on my health, thinking about new projects (the newsletter being one of them), reflecting about my future, etc.

Coming back to work after the sabbatical was, on one hand, good, because of the financial stability, but on the other hand it was a shock and depressing for various reasons. From having all day for myself, now I have at best 5 hours, which is not bad if put to good use, since habits accumulate over time—better to do something than nothing whatsoever. My energy levels go up and down more often, etc.

So yes, I grew up and accepted it, but deep down there’s always this feeling of “what if things could be different?”. I think newer generations have it as well and are keen on challenging the status quo over time.