2023 is almost over. Time to reflect about the year and look to the future. Before I start, the newsletter will be on hiatus for the holidays, and it’ll come back on the 19th of January.

I started the newsletter in March, 9 months ago, in the middle of my break from January to September. The idea was to write in public with a “low effort” approach, giving updates on my journey, sharing some of the things I consumed over the week—articles, tweets, or videos—or writing in a very stream of thought style.

The idea of a “low effort” newsletter was a continuation of my efforts to write regularly on my blog, which was originally going to be for more technical or longer essays. The reality is that it didn’t work out for whatever reason, I couldn’t make it stick. Pivoting to a weekly low effort approach was the way to make sure that I could keep writing frequently, regularly and consistently. What makes a difference for me is that, with the newsletter, I know there are people that subscribed that “expect” to get an email every week, which puts pressure on me to actually deliver something.

It’s better to start small and imperfectly than shoot for the moon and never start. A journey of a thousand miles begins with a single step. Since March, I’ve published 41 articles, almost once a week every week. These are my favourite posts so far, in no specific order:

The first newsletter of 2024 is here, and it’s written from Madrid, that’s a new one! Unfortunately, I’m not on holidays, on the beach, sunbathing with a mojito in one hand and the laptop in another. It’s winter here this time of the year, cold and with some rainy days, but at least I’ve seen the sun for longer stretches. Nonetheless, changing the working environment from London to Madrid for a few weeks is priceless. Let’s jump now to the topic of this week.

I remember several times being in a meeting after an incident that caused the servers to go down. Appreciations flew my way on every occasion I resolved the issues and brought the service up again. While it didn’t feel bad to see my efforts recognised, it didn’t feel good. I knew that, most likely, something was going to happen soon, in a few days or next week.

As if it were normal that the application was the Hydra or the Nemean lion that had to be slain regularly in one of the many labours, I was being praised as a hero. Performing heroic deeds day in and day out took a toll on me, I was stressed, tired, I couldn’t relax or feel like I could take long holidays. At that time, I was the only developer, if I would’ve got hit by a bus, the company would’ve had a big problem, and so would I, but of another kind.

When I was being praised for the heroics, all I could think about is that I wanted to hang the hero’s hat. It can feel good to be “the guy”, the person everyone depends on, it might boost the ego or make you feel important, but, under the veneer of “the guy” there’s just a bottleneck, a single point of failure. Don’t be “that guy”.

The “Great Resignation” had people leaving their jobs in high numbers, creating staffing problems in the U.S.A.; with employees not wanting to go back to work unless conditions improved.

Nowadays, it's easy to see the discontent and distrust of people towards companies and institutions. I feel it too.

We see that nurses, who worked through the pandemic in extreme pressure conditions, understaffed, with low wages, are striking for decent conditions and a better public health system.

Education workers face a similar reality, to the point where it's an enticing prospect to work at a supermarket rather than to stay in schools:

Everything but the smallest things are complex. It’s a fact of life. From the simplest building blocks, we can get ever complex structures, by combining them in different ways. From atoms to a cell, from a cell to a human body.

Software cannot escape complexity. It itself sits on top of layers of complexity. We see the idea of combining building blocks in object composition or in functional programming, where we combine objects or functions to create sophisticated structures.

We developers are not foreign to this. In fact, an intrinsic part of software is to manage complexity. Think of the times we abstract or encapsulate, putting a simpler interface or facade on top of an intricate piece of functionality—with the risk of leaky abstractions. What about modularity—composition again— and separation of concerns?

I had in mind the first law of thermodynamics—energy cannot be created or destroyed, but it can be transformed from one form to another—but quickly realised that we even create complexity to manage our current complexity, or solve new problems.

Some teams talk about improving, they want to get better at their craft, produce higher quality code, deliver great products… but they never do, or take an incredibly long time getting there. There are many factors that contribute to it, some inside the team, some outside.

As always, things are complex and nuanced. High work in progress can make a team go nowhere. Since there’s no improvement, there will be decay. Decay of the architecture, or the quality of the code, an increase in bugs, lack of cohesion… you name it.

After many conversations, everything stays the same, there’s no action, no change, they keep doing what they do, business as usual. They didn’t rise to the levels of their goals, they fell to the level of theirs systems.

An awareness of pain points and improvements and a “will” to improve are important, but they don’t get you anywhere if you don’t act. Having the what (X is a problem, we need to do Y) helps. Understanding the why is essential, it makes us focus on the principles, fundamentals, the core, but when you want to improve, learn, adapt or, in general, when you want to do, we have to think about the how.