The mission

Principles.dev exists to make software engineering better for everyone. By capturing the best principles from the best in the world at what they do. And to organise and share that knowledge, freely.

Origin Story

It was a summer's day in Berlin 2010. I'd moved abroad to start a new job at Nokia. I arrived at the apartment block that I would soon be calling home. I could barely breathe after pulling my bag of luggage up four flights of stairs.

I put the key in the door; it didn't work. I tried again - It wasn't the right key. I called up the girl who had given me the keys - She delivered the devastating news that I'd walked up the wrong set of stairs.

You see, I had a secret that I could tell nobody. I had chronic fatigue. Berlin offered me a slower pace of life. I hoped I'd be able to figure out my health problems away from the chaos of London.

I sat outside the closed door for 10 minutes, getting my breath back before heading across the courtyard and climbing four more flights of stairs.

I opened the door, laid down, and fell to sleep.

New beginning

The first two days of my job were meetings. But day three: I had to code. I stared at the screen looking through an unfamiliar codebase. My brain was barely functioning - I couldn't do it.

I left early, telling my boss I needed a few days off. It was a terrible start. It already felt like I was going to lose my job.

In my panic, I resolved to find a way to make programming easier for me. I organized pieces of old code to be used as references and created process documents to walk through problems step by step for specific tasks. The idea was that I would reduce complexity by capturing my decision-making so I wouldn't have to remember how to handle a problem each time. I would only have to remember how to find the snippet of code or process for a similar situation.

I went back to work the following week. It was a punishing few months. But I'd built up enough process and code samples that I'd adapted to the team.

By the end of my role, I'd ended up working on the most complex part of the application. I left Berlin with a sense of success and enough experience to begin leading other teams. But I was about to find out; my processes wouldn't scale.

First Steps

With my newfound ability to work at higher levels of complexity, I wanted to share what I'd learned. But no matter how much I explained my designs and architectures, very few people understood it anywhere near the same way as I did. I was the most productive member by far. But my team was hindered by my process.

During all this, my chronic fatigue lingered in the background. Most of my weekends were spent in bed, trying to regain some energy for the next week. I no longer had the energy to dedicate to this.

Instead, I adopted more rigid frameworks - It was then up to the framework to determine the architecture. It wasn't the best way to solve the business problem, but it was best for the team, which mattered more.

Discovery

A while later, I joined McKinsey & Company. It was a job that involved traveling throughout Europe, working with lots of different people. I landed on an incredibly productive team. For the first time in my career, everyone was in sync. I'd arrived in Software Engineering utopia. It became apparent we shared similar thoughts on Software Engineering. Most importantly, I realized we had similar habits.

I'd never really thought about my automatic behaviors before. And because much of what I did was automatic, I didn't honestly know why I engineered the way I did. How could I convince others to follow me or to get the team to share a similar vision if I couldn't clearly explain my thought process?

I understood what I needed to do. I needed to convert my processes and habits into principles. To expose my automatic behaviors and re-attach them to the reasons that created them. So they could be shared, understood, and questioned by others.

Once I did that, it allowed me to be understood and communicate much more convincingly. Team members could share their principles and use that knowledge to enhance everyone's decision-making process. Teams became autonomous.

Software Engineering on teams finally became a joyful experience.

In the end, no one found out my secret. And with much work, my chronic fatigue went away. However, that's a story for another time.