One of the book clubs I’ve joined last year with my fellow Improvers was on “The Pragmatic Programmer – Your Journey to Mastery – 20th Anniversary Edition”. I remember reading the 1st edition sometime around 2006 and am glad I reviewed its newer edition.
Here are some notes wrote down…
“You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations.”
That! I have (bad) memories of wasting a lot of time because a particular tech stack was chose for no reason other than a marriage to a particular vendor, despite of it not offering the best technology to achieve the client’s goals.
“Care about your craft: there is no point in developing software unless you care about doing it well.”
I wouldn’t trust surgeons who don’t care about doing their craft well. Would you?
“Over the long term, your time investment will be rapid as you and your team become more efficient, write code that’s easier to maintain, and spend less time in meetings”
I love the point above. I enjoy doing code review with team members so we can learn from each other. I’ve worked on teams where at some point we couldn’t tell which one of us wrote the code, because we’ve learned to value the same best practices, which we kept in mind in our daily work. Whenever someone learned something new, they’d share with the team, and we’d evolve together.
“We who cut mere stones must always be enviosioning cathedrals”
YES! Developers shouldn’t be content with dropping a button onto a form that when clicked shows whatever message; they should see through it and understand the bigger context.
“If technology seems to be passing you by, make time (in your own time) to study new stuff that looks interesting. You’re investing in yourself, so doing it while you’re off-the-clock is only reasonable.”
That’s precisely what I’ve been doing for a very long time. The main difference is that I started to apply that not only to technology, but also to many other areas of life. What I’ve done off-the-clock has always been the biggest driving force behind my continous improvement.
“Above all, your team needs to be able to trust and rely on you – and you need to be comfortable relying on each of them as well. Trust in a team is absolutely essential for creativity and collaboration. In a healthy environment based in trust, you can safely speak your mind, present your ideas, and rely on your team members who can in turn rely on you. Without trust, well…“
If you ever visit Improving.com, you’ll immediately see the following words: “Trust Changes Everything”. As I look back on my professional career, I can point out several opportunities and growth that came out of being trusted by people from all walks of life. A team without trust isn’t much of a team.
Pushing that concept a little further, I like a point raised by the authors of “Yes, And: How Improvisation Reverses ’No, But’ Thinking and Improves Creativity and Collaboration — Lessons from The Second City” (another book club we had last year!) The point they raised is to go from team to ensemble, which is an even more collaborative relationship. In Improv, it’s very easy for one to become very uncomfortable, but a strong ensemble is there to support each other when ramping up skills or going through an off night.
“Don’t live with broken windows. Hopelessness can be contagious.“
That one makes me think of teams that abandon their automated tests because they have become brittle, hard to maintain, hard to write, hard to fix when they start to fail.
“Be a catalyst for change“
Nobody else writes tests? You should do it, regardless. Nobody else writes clean code? You do it! Nobody else says “thank you” anymore? You do it. Thank you.
There were many other great things in this book and I strongly recommend it to anyone who’s anywhere near software development. Most of the lessons taught have stood the test of time, and the ones that didn’t (due changes in technology and such) were revised and updated in this 20th Anniversary Edition.
Claudio Lassala's Blog 