EN 27: A story about the ideal world

Top of the morning to you!

It’s already my second week in the new role. I’m getting there in terms of feeling comfortable and getting a reasonable routine going.

Interestingly, when I’m working at home, I think I’m not taking as many breaks as I need. Normally when you’re in the office, you go to the kitchen, make some coffee, walk back and forth, and with the commute, you probably accumulate a decent number of steps. At home, it’s been difficult to take those breaks naturally. I used to have a more “rigorous” schedule, I took breaks often and went for a walk before starting work, at lunch and immediately after finishing the workday.

The first time I discovered pair programming in the wild—outside of books and articles—was at Findmypast. Before joining the company, I had the strong intuition that things could be much better and a desire to improve, which drove me to look for answers, read books, watch conferences about agility, DevOps... In this journey, Findmypast was instrumental. It showed me that the things most developers would consider the “ideal world”, unattainable, unreachable, could actually be real. At the same time, my tenure there raised the bar of what good looks like at an engineering level.

Over the years, I’ve found many people talking about how plenty of great engineering practices are not applicable, only reside in the ideal world and some percentage of people even attempt to discredit the ones promoting them. It reminds of the allegory of the cave, which describes people chained in a cave, whom only have ever seen shadows on a blank wall projected by objects passing in front of a fire behind them, without ever knowing what the outside looks like and that what they see are shadow in front of a fire.

Scrum, sprints, story points, tickets, long-lived branches, working solo… are the shadows on the wall, the prisoners’ reality.

The first weeks and months in the company, while typically a bit chaotic, were the most supported and accepted I’ve ever felt. From the get go, I was pairing with the rest of my teammates. We rotated pairs periodically, which allowed me to know them, build trust and see different pieces of work frequently.

If I’m not mistaken, my first change to production happened in the first days. That first change made me feel nervous, what if I broke something, dropped the production database or caused a server to go down? While it can be normal to feel this way as the new person, I realise now that my previous experience taught me to fear releasing code to production, to see it as a dangerous thing and to act extremely cautious. Now I know that “if it hurts, do it more often”. Was my first change(s) difficult and frustrating, did I have to struggle mightily alone for hours to understand the code? Not at all, since we were pairing by default, Rob, one of my teammates and onboarding buddy, was there answering questions, providing context…

By now somebody could say that yes, pair programming can work for onboarding people or junior developers, apart from that, it’s no use, and that it’s better to have senior developers working alone. While pair or mob programming can help speed onboarding a new developer immensely (and, honestly, I wouldn’t do it any other way if I had a say in it), their benefits go beyond it, specially when you think about high work in progress and sharing understanding. With pairing and more so with mob programming, we have more minds on the problem, and in the latter, the whole team (not only developers) can participate and unblock itself faster.

Leaving pairing aside, my first push to production was low stakes, and the second, and the third and the rest of them until my last day. We worked with the goal of making small batches of changes and having the system always in a releasable state. We pushed constantly to production, straight to the main branch, even on Fridays! The company was not in a chaotic wild west that you might imagine if you come from places where pull requests and long-lived feature branches are the norm, it was actually quite the opposite, it felt incredibly safe. Pushing to production was extremely boring.

The company, of course, wasn’t perfect and without flaws, but it was highly influential in my understanding of software engineering and in realising that things that others could consider only “ideal” and not practical can be very real.

This ideal world vs the real-world dichotomy is ubiquitous, there’s always a resistance to change, a scepticism to consider that things can be better. It’s a similar scenario in the world of product management. Many product managers label books like Continuous Discovery Habits, Escaping The Build Trap, Testing Business Ideas… as idealistic, unattainable, and say that they live in the real world. This real world is a world where they are continuously busy and swamped by demands for new features, and that “busyness” (or the business) doesn’t allow them to speak to customers, run quick experiments, start together… Busyness, the absence of slack/idle time in the system to improve, reflect, experiment is a major obstacle. It affects everyone, not only product managers.

I once read a developer tweeted that that once you’ve been in a great environment, have done pairing/mobbing and modern practices, it is difficult to go back. I can attest to that. Since my experience in such an environment, I have yet to find a similar feeling of safety, support and collaboration, and yearn for it. Not only because it feels great to be part of such an engineering culture, but because you can clearly see its benefits and the immediate effects of not working that way. I’m keen to create such an environment wherever I go, although that kind of change is always a challenge, as it goes against the typical—and flawed—conception of creating software, but that won’t stop me from trying. I rather work to make the ideal world real.

Interesting links

Outcomes over Outputs, Product Thinking Podcast

Debating type systems: static vs dynamic

Fundamentals, not silver bullets