Senior Developers don’t need to learn. Right?

I vividly remember the three key events that changed my career forever.

The first one came when was working in a team of three on our own project. We were in charge of design, configuration, production, and maintenance. We launched the product on a production computer, users started interacting with it… and it worked for them, not just for us!

This was an epiphany. A moment of clarity that made me feel confident about my skills.

This success gave us the courage to start a consulting business and eventually open our own software house. After signing the first customers, I had to think in broader terms. On top of thinking HOW to deliver a given feature, I was also asking questions from the business perspective - like WHAT type of feature should be delivered. The questions typically asked by development and business teams are different. As developers, our goal was to understand HOW to overcome an obstacle and how to go from A to B. Our newly found business angle meant focusing on the RESULTS of going from A to B and IF it the journey was even worth taking.

My final breakthrough was understanding how distributed systems work. In the first decade of my career, I thought they were just like the multiplication table. I didn’t understand the reasoning but merely memorized the sets of decisions taken in certain scenarios. I didn’t question WHY action A resulted in phenomenon B. When things finally clicked, I launched my own distributed systems course.

The lessons learned in the first decade of my career are context-specific and hard to share. In this program, I am focusing on breakthroughs #2 and #3 - collaborating with business and understanding distributed systems.

When you start using TDD, Agile, or SCRUM practices in a large project, you’re bound to hit a wall. How to implement them in a large team? I used to think it was impossible...

Good code practices work perfectly well in small teams of programming veterans. Implementing them in a large team requires creating a new framework. To me, Domain Driven Design was a revelation - a gateway to the world of software architecture. Thanks to DDD, you can divide a project into segments to be handled by teams of several developers working autonomously. In other words, DDD is a bridge between business and programming.

In short, architecture is the missing building block that structures the entire project. It allows us to put the techniques we learn into practice and successfully develop the project.