The Pragmatic Programmer

Preface

Programming is a craft.

Programming is translating requirements into machine instructions.

There are no easy answers. There is no best solution.

Pragmatic programmers are early adopters, fast adapters, they are inquisitive, critical thinking, realistic and jacks of all trades.

Pragmatic programmers are curious people who like to learn and deeply understand how things work under the hood.

Tip 1: Care About Your Craft.

Tip 2: Think! About Your Work

Individual contributions matter. And hence mastery of the craft is a desirable goal.

We who cut mere stones must always be envisioning cathedrals.

"Kaizen" - a continuous stream of small improvements.

Chapter 1 - A Pragmatic Philosophy

Change things and don't accept the status quo if it's not good. Clean up after yourself, boys out rule, leave things in a better shape than when you found them. But don't be 100% perfectionist either. Rather get things done.

Keep learning. All the time. The board of the game is changing rapidly. Don't forget that you have a team that you can (should) work together with.

1. It's your life

It is your life. You own it. You run it. You create it.

A question to ask to anything in life you worry about: "Why can't you change it?"

Most important tip in the book:

Tip 3: You Have Agency.

This of course is aligned pretty well with 7 habits. Be proactive. I.e. use your agency to manifest change in the real world.

Want to work remotely? Have you asked? If they say no, then find someone who says yes.

2. The Cat Ate My Source Code

Step 2 - be responsible for your actions. Because you have agency, you can mess up, when using it. Own that mess and try to reduce messing up over time by learning from mistakes.

For people to own their mistakes and grow from them trust is important in teams. This is a concept called psychological safety.

There are no excuses in a world where you have agency. It's up to you.

Tip 4: Provide Options, Don't Make Lame Excuses

Be ruthless in finding the fault within your circle of influence. Then see what you can do about fixing the fault or reducing it's impact by providing different solutions to the problem. Only things that you can control are within your agency, so only these should matter to you.

"I don't know yet, but I can and will learn" is a pragmatic programmers mantra. The mismatch between neural representation and reality triggers learning. Knowing that you don't know and wanting to change that, increases neural plasticity.

3. Software Entropy

Software dismantles itself over time in a process known as technical debt or software rot.

Broken windows lead to the rapid degradation of abandoned buildings. Signs of destruction are contagious. The same is true for software.

Tip 5: Don't live with broken windows.

Neglect accelerates software rot faster than any other factor.

Fix the small and big things you find right away, if at all possible. Put the house in order before taking on new things. Don't slack, or you'll rot.

Don't cause collateral damage in your desire to clean up. Don't cause broken windows yourself, ever, because you know about the broken windows effect you know how detrimental it is to even introduce a single broken thing.

Just tell yourself, "No broken windows."

4. Stone Soups and Boiled Frogs

Learn from the stone soup story, start with a small thing, then let people start liking it and incrementally suggest adding small bits and pieces until you have the whole project done the way envisioned. Just boil the frogs slowly so they don't notice.

Let people dream. And feel like they came up with the solutions themselves. Help them intuit solutions. Don't manipulate. But synergize. People will improve your original beyond what you thought possible once they are onboard with the ideas because they think of them as their own!

People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

Tip 6: Be a catalyst for change.

Tip 7: Remember the big picture.

Don't become wrapped up in the small minutiae of day to day coding and pitching small pieces of the bigger picture.

Pay attention. The more the better. The small things matter to get right because of broken windows effects.

5. Good-Enough Software

Write software for users. Once the users say software does what it should, you can stop making it do more things.

Scope and Quality of the system should be discussed as part of system requirements.

Tip 8: Make Quality a Requirement Issue

Great software today is often preferable to the fantasy of perfect software tomorrow.

Go with an MVP firsty then iterate to make that MVP actually do more and more things, slowly approaching all the functionality the users want.
But know when to stop!

6. Your Knowledge Portfolio

Knowledge can expire. Languages, libraries etc. change over time.

Hence ability to learn is an asset that needs to be cultivated, learning has to have priority. Knowledge should be considered as a portfolio that needs investing. That investing should be regular, diverse, conservative as well as high-risk (experimental) cheap but impactful and reviewed regularly.

Consistency and habits are important for learning. Diversify what you know. Try finding some high risk learning opportunity, things that are emerging technologies because arriving ahead of the curve can be rewarded handsomely.

Tip 9: Invest Regularly in Your Knowledge Portfolio (in a clever way)

Strategies for learning:
1 Language a year
1 technical book a month
1 nontechnical book a month
Classes and courses
Go to meetups
Use different operating systems
Stay current I would disagree with that point. There is timeless knowledge to be learned first that will serve as a foundation for the rest and should be prioritized. Currency of knowledge usually means it's not worth learning and can be instead looked up.

It doesn't matter whether you ever use any of these technologies on a project, or even whether you put them on your resume.

I don't agree with that. Shallow learning is a thing and you understand by doing things and actually using a technology, so reading about something without actually using it is a waste of time.

Broken windows can exist within one's own mind. They are called knowledge gaps. Again. Don't live with broken windows. Don't be lazy, not even intellectually.

Knowledge Portfolio learning can translate into real projects to put on a portfolio. Making knowledge visible that way is an immensely useful strategy.

Tip 10: Critically Analyze What You Read And Hear

Ask 5 why's
Ask cui bono - who benefits, inform yourself about the context.

7. Communicate

Learn how to package your ideas so that others (especially non techy people) can understand them easily.

Tip 11: English is Just Another Programming Language

Plan out what you want to say and keep in mind who you say it to. Write an outline, reiterate. Make it good. Ask yourself - is this saying what I want to say? Again don't live with broken windows.

Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.

When writing a book or a blog, obsess over details. Typography, Design, Wording. Representation is key. And beautiful.

Use grammarly and a human proof reader with OCD. Involve the people that you are writing for in the process and gather feedback from them. Listen to people and get back to them. In other words - care for your audience and treat others like you would like to be treated.

Tip 12: It's Both What You Say and the Way You Say It.

Documentation is an integral part of the development process.

Tip 13: Build Documentation In, Don't Bolt It On.

Summary: Know what you want to say. Know your audience. Choose your moment. Choose a style. Make it look good. Involve your audience. Be a listener. Get back to people. Keep code and documentation together.

Book Recommendation: The Mythical Man Month: Essays on Software Engineering by Fred Brooks

Book Recommendation: Peopleware: Productive Teams and Projects by Timothy Lister

Book Recommendation: Dinosaur Brains: Dealing with All Those Impossible People at Work by Albert J. Bernstein

Chapter Summary:

Embrace action and responsibility. Be accountable for what you are doing. Don't use your cat as an excuse. Solve problems instead of creating them, give options. Care for others. And for yourself and your craft. Regularly invest in your knowledge Portfolio. Keep learning. Communicate effectively in both writing and speech. Don't be lazy. Don't slack. Don't live with broken windows, clean up after yourself and don't break any windows either. Don't let perfection get in the way of incremental improvements. Catch people onto parts of an idea first, them iterate. Use feedback from users for iteration. Make quality a system requirement.

Chapter 2 - A Pragmatic Approach

8. The Essence of Good Design

Tip 14: Good Design Is Easier to Change Than Bad Design

ETC Principle - Easier to Change.
Every design principle boils down to this idea.

ETC Is a Value, Not a Rule.

9. DRY - The Evils of Duplication

As programmers, we collect, organize, maintain, and harness knowledge.

Knowledge changes and things break. Hence maintenance is an integral part of the whole coding process.

Duplicating things, makes it harder to do maintenance. (Harder means nightmare)

Tip 15: DRY - Don't Repeat Yourself

Dry is about the duplication of knowledge, of intent.

It's not just about code!

Things that happen to do the same thing are not a violation of DRY... They are coincidences and that's not what dry is about, namely code duplication. It's about duplication of intent.

Inter developer duplication is a problem, discovering that a problem has already been solved and doesn't need another function to be implemented again is hard. Discoverability of code is key!

Tip 16: Make It Easy to Reuse

What you're trying to do is foster an environment where it's easier to find and reuse existing stuff than to write it yourself.

10. Orthogonality

Orthogonality means that things changing don't affect each other. Code pieces should be as orthogonal to each other as possible.

When components of any system are highly interdependent, there is no such thing as a local fix.

Tip 17: Eliminate Effects Between Unrelated Things

Book Recommendation: Structured Design: Fundamentals of a Discipline of Computer Programs and Systems Design by Edward Yourdon

Isolate components and modules from each other. Functions etc. should do only one thing and that thing well.

Orthogonality in design reduces risk and increases productivity. Because it can be better comprehended by humans. It is simple (not easy), not complex. See Rich Hickeys talk.

Use abstractions and layers in your code. Modularize things into small reusable components.

Book Recommendation: Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Get into the habit of being constantly critical of your code. Look for any opportunities to reorganize it to improve its structure and orthogonality.

Once again. Don't live with broken windows.

11. Reversibility

In systems where decisions are not easily reversible, a change in requirements often leads to missing the target. Often by a LOT.

Really abstracting a database out (or any third party tool thingy you use) makes it possible to reverse this decision at a later point. You valued ETC and produced something that is easy to change and can therefore adapt to new circumstances on the fly.

Tip 18: There Are No Final Decisions

Tip 19: Forgo Following Fads