Learn from the past to build a better future as a software developer.

Working as a software development instructor and consultant meant that i got to meet lots of people with different cultural and professional backgrounds. This was a joyful experience, and i loved it, even though it was exhausting. Being able to tackle common problems that we face every day, from different perspectives, was challenging and exciting. I’ve developed different didactic methods along the way and every project meant something new. I’m sure that i learned much more than i got to teach.

During those years, i have noticed one pattern emerge from all teams, regardless of their experience or knowledge: they repeated the same mistakes. Not their own mistakes, but mistakes that other teams made. And i’m not talking about mistakes caused by the conflict between software development knowledge acquisition and the natural cognitive process. I’m talking about collaborative mistakes: teams were making the same bad decisions and coming up with the same bad solutions.

In my method, i always allowed them to proceed. Only later in the process i would present elements that would put their design to test. At first, i just explained what went wrong and what they should do instead. I also explained how this was a known problem and that Book A and Book B covered the subject in a much better way than i ever could. I always noticed some comfort in this specific part of the project: they felt good about their mistake, knowing that someone had written something about it, years ago. As if they were evolving and were becoming part of something bigger.

I wanted to make this feeling stronger for everyone, so i started keeping a log of the common mistakes that previous teams made and shared a story with each new team. I shared code, design documents and whiteboard doodles. Knowing that they were not alone in this journey was reassuring and sparked a renewed interest in knowing more and more about our past as an industry. What else could they read? How many different and exciting ways could they approach the problems they had?

As an industry, we have a problem. We don’t care about our past. Maybe this happens because we are such a new industry, but i don’t see junior developers interested in dedicating a few hours of their time to Pragmatic Programmer, Clean Code or Patterns of Enterprise Application Architecture. It seems that every new generation of software developers is doomed to repeat the same mistakes, blinded by the thought that they are pioneers. But what is the real problem here? Why aren’t people connecting with the previous generations? Is it the publishing format? Do we have a communication gap? More on this later.