Book Summary: The Pragmatic Programmer 20th Anniversary Edition- Chapter 1

guifroes -

This article is the first from a series where I’m going to summarize important books for the software engineering career. The Pragmatic Programmer is the perfect one to start.

Subscribe to my newsletter to know when the next chapters and books are published.

What is a Pragmatic Programmer?

Pragmatic Programmers get the job done, and do it well.

Pragmatic programmers aren’t wedded to any particular technology. Instead, they understand principles of computer science and have experience from real projects.

They are:

  • Early adopters
  • Inquisitive
  • Critical Thinkers
  • Realistic
  • Jacks of all trades

And most important:

They care about their craft!

How to become a Pragmatic Programmer

Pragmatic Programmers live by a philosophy based on ownership.

It’s your career, it’s your life. Own it!

Software development is one of the careers that gives us the most control. Our abilities are valued and our knowledge applicable anywhere in the world, we can work from anywhere we want. We’re well paid.

You have the power.

Is your environment bad or is your job boring? Fix it! But don’t try to fix it forever. Want to work remotely? Have you asked? If they say ‘no’, find someone who says ‘yes’. Martin Fowler said: “you can change your organization or change your organization”. Be proactive and seize the opportunities the market gives you.

But these opportunities are not available to everybody. There’s plenty for those who have a responsible attitude. One fundamental aspect of the pragmatic programmer’s philosophy is being responsible for everything one is involved.

This means being direct and honest. Means accepting responsibility over the results and, if something goes wrong, offering solutions, not excuses. Means being proud of our skills and owning our limitations, lack of knowledge and mistakes. And it means not fearing asking for help or confessing not knowing something. And when you don’t know, saying “but I’ll find out.”

Besides being responsible for the work, pragmatic programmers are responsible for their learning, inside and outside of work, and for the advance of their career.

Investing in knowledge and skills

We always talk about investing in our career. But have you thought about why we use the word “invest”?

Pragmatic Programmers treat their knowledge as an investment portfolio.

Skills and experiences are assets and they expire over time. And as your portfolio loses value, you lose value to your employee or client.

That’s why acquiring assets, in other words, learning, is the most important thing you must do to increase your value as a programmer.

Use investment strategies to increase your knowledge portfolio value:

  • Invest frequently: even if it’s a small amount;
  • Diversify: the more things you know, the more value you’ll have and the easier will be to get new skills;
  • Manage risk: don’t put all your technical eggs in the same basket;
  • Buy low, sell high: learning an emergent technology might be lucrative when it gets popular;
  • Review and rebalance.

By investing in knowledge, you’ll be consuming lots of information. Just consuming without critical thinking is a risk. Never underestimate the marketing hidden in technical content.

Critically analyze everything you hear or read:

  • Ask the 5 whys;
  • Who benefits from this?
  • When and how could this work?
  • Why is this a problem?

Communicate as well as you code

How good is an idea if we can’t put it to work? Software development is a social activity so it’s important to know how to communicate.

Treat your idiom the same way you treat your programming language. One thing is knowing how to write, the syntax and not making mistakes. Another thing is writing well, in an expressive way and according to the best practices.

Communication must be customized to the audience. Say you want to adopt a new 3rd party message broker to disseminate notifications. End users will appreciate that their systems can now interoperate with other services that use the broker. Your marketing department will be able to use this fact to boost sales. Development and operations managers will be happy because the care and maintenance of that part of the system is now someone else’s problem. Finally, developers may enjoy getting experience with new APIs, and may even be able to find new uses for the message broker. By making the appropriate pitch to each group, you’ll get them all excited about your project.

Before showing your ideas to each group, plan. Pay attention and care to the manner in which you’ll show your ideas:

  • Choose your moment: there’s a right and a wrong time for everything;
  • Choose your style: what’s their skill level? Do they need long explanations or just a short summary? If you don’t know, ask;
  • Make it pretty: your ideas are important and deserve a nice vehicle. Get the grammar and punctuation right. Put effort into your slides and documents design;
  • Get you audience involved: if possible, show people your drafts and ask them for feedback and new ideas;
  • Listen to people;
  • Get back to people: Always respond to emails and voicemails, even if the response is simply “I’ll get back to you later.’’

“It’s easier to ask for forgiveness than it is to get permission.“

Rear Admiral Dr. Grace Hopper 

A lot of times people know things are wrong or could be better, but inertia keeps them in the same place.

Be an agent of change. Use your knowledge to improve things around you.

Many times, it is enough that you do something new, different and show some small positive results for people to get excited and start to collaborate on bigger changes.

Death by a thousand cuts

The same way you should be an agent of transformation through small changes, you must pay attention if things are not getting broken little by little and eroding team morale.

Be vigilant and keep an eye on the overall scene. Pay attention to everything that happens around you, not only to what directly affects you.

2nd Law of Thermodynamics

Software rots. Software is part of the universe and being so, its disorder, its entropy, only gets higher.

And the most important factor for software rotting is psychological, cultural:

In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict.[5]

A broken window.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short span of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

Leaving a broken window reinforces the idea that nothing can be done, nobody cares, and all is lost. This feeling is contagious, and soon the whole team feels this way.

The solution is not to live with broken windows.

If you see something broken, fix it. If you can’t fix it right away, at least signal that it was seen, won’t be tolerated and will be fixed ASAP.

The first thing is not to break windows. If you’re in a project with pristine clean code, and beautiful design, make an extra effort not to break stuff.

Good enough

Keeping the code clean and proper design is fundamental, but it doesn’t mean that we should invest indefinitely in technical quality.

Our job is to build software that brings value to our company or client. Most times, it is better to have a productive software today that has some rough edges than a perfect software one year from now.

We’re not defending that you deliver low quality work. We’re advising to involve the user in the decisions.

Know when to stop.

Artists say that a work is ruined when one doesn’t know when to stop working on it. Don’t spoil a perfectly good piece of software by overembellishing it and overrefining it.

Don’t miss Chapter 2 and the summaries of the most important books for Software Developers.

Subscribe to my newsletter!