I often get asked what I do as a programmer: Back-end, Front-end, Full stack? And my answer is always the same: I’m just a programmer. I believe that anyone who knows the basics of programming can learn whatever language or technology they put their minds to.
Very recently I bought the book “The Pragmatic Programmer” and I feel it offers an even better definition of what programmers are. I do not like to be labeled as a “Full stack” or “Front-end” developer. I believe in providing value to a position rather than being constrained by a title or a role that could change at any time, depending on whatever project I’m focusing on at the moment. As a result, I prefer to be considered as a Pragmatic Programmer, and here’s why.
If I have anything to offer other programmers at all, it’s what I gained from reading this book.
The Pragmatic Programmer Book
The remarkable thing about reading this book in 2017 is that after all these years, the book is still relevant. Andrew Hunt and Dave Thomas released it on 1999. To me, they’re sort of like visionaries because in software development,18 years is a lot of time.
The book is super easy to read. It’s basically a series of tips and lots of good advice, grouped by chapters (or topics). After giving some insights and examples, the authors deliver advice which you can put into practice.
Here is the complete list of tips.
Some tips had a larger impact on me so I will leave you with the ones I enjoyed the most. Please don’t take these as the most important, I believe all of them are essential to becoming a great programmer.
Tip #1: Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might look and help them participate in creating it.
So many times I’ve found myself wishing things were different and yet I do nothing. That’s a shame. Guess what? You can start changing. You can improve your context. The change is even better because you motivate people, creating synergy.
Tip #2: Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.
How many times should we try to make things perfect? Perfection doesn’t exist. Start with something that works and you can improve/adjust it on the next iteration.
Tip #3: Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
Refactoring is our best tool. Every time I can, I introduce small changes aiming to improve the codebase. I defend the things that are right. I protect our windows.
Tip #4: Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
I can’t be more at fault on this one. I really admire programmers who use their daily tools with such speed. I aim to achieve something similar or at least improve by learning more shortcuts in order to make my tools an extension of my hands.
Tip #5: Don’t Be a Slave to Formal Methods
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.
So often I’ve seen teams following a “widely recognized method” just for the sake of doing what everybody else is doing. Stop with that already! Think: is that really needed? Is there a better way? Is that suited for your team or even your project? You might be impressed with the results after answering those questions.
So, What is a Pragmatic Programmer, Then?
Pragmatic programmers “get the job done, and they do it well. They care about their craft. They are constantly thinking and critiquing their work”.
The book offers several descriptions but basically, pragmatic programmers share many of the following characteristics, as set below:
- Early adopter/fast adapter. Loves trying things out. Confidence is born of experience.
- Inquisitive. Tends to ask questions. A pack rat for little facts, each of which may affect some decision years from now.
- Critical thinker. Rarely takes things as given without first getting facts.
- Realistic. Tries to understand the underlying nature of each problem they face.
- Jack of all trades. Although current job may require them to be a specialist, they will always be able to move on to new areas and new challenges.
—
Whether you are a programmer, a software engineer or any other label you want to give yourself, consider reading this book. I think the best time to read it is during your first years as a professional. If you read it while you’re still in school or during your first months on the job, you might not appreciate all the advice. The tips might just go right over your head.
I think I read it a little bit late because most of the tips cover things I’m currently doing. I learned these things from my mistakes. Nevertheless, even though I was already aware of these tips, it was a nice time reading the book: it gave me other points of view and a deeper appreciation for what I do.