Learning during lockdown — Reread The Pragmatic Programmer

Jamie Wen
3 min readNov 17, 2020

--

Put the book on your desk and read it whenever you can

Added some notes that inspired me the most when I reread The Pragmatic Programmer during lockdown.

The Philosophy

It was an eye-opener when I first read it 10+ years ago, and it continues to inspire me on every reread. Just list some concepts that I am interested in the most

Software Entropy

What is Entropy: A measure of this disorder is entropy. The law applies to software as well. By nature, your software becomes messier, but human’s efforts can make it neater.

Good Enough

Good enough or just enough, in other words, a developer should know when to stop. There is no perfect solution in the world. A pragmatic programmer doesn’t ask binary questions. They juts do trade-offs.

Knowledge Portfolio

Your knowledge is your portfolio. Treat your knowledge as seriously as your investment account. The two key points I like most are:

  • Invest regularly: like investing ETF, buy (periodically) and hold. Read a new book, learn new technology, go to a conference, meet other professionals…
  • Diversify: The strategy I would tell 20-year-old myself, focus on your profession and be an I-shaped person, grow your knowledge widely and deeply to build up your T-shaped skill sets, then improve your soft skills so that you can contribute more in collaboration and communication.

The Methodology

Orthogonality

Orthogonality is the most important concept. A short blog post from freecodecamp explains it in a simple way. Lots of principles help us build orthogonal code.

  1. Single Responsibility: Do one thing and do it well
  2. DRY: Don’t Repeat Yourself. If two modules are orthogonal, there should be no duplication between them.
  3. Decoupling/Minimize Coupling Between Modules: orthogonal code tends to minimise its dependencies.
  4. Strong Cohesion, Loose Coupling: similar to Decoupling principle
  5. Eliminate Effects Between Unrelated Things: design components that are self-contained. independent, and have a single, well-defined purpose.
  6. Open/Close Principle: open for extension but close for modification.
  7. Liskov Substitution Principle: an easier remember version is Design by Contract

I can continue listing more principles, but you get the idea, all those principles are trying to make software be orthogonal.

Pragmatism

There are no final decisions: Be agile, follow baby steps, move fast, fix your problems, and test your hypotheses in the real world.

When to Use Exceptions: An exception represents an immediate, nonlocal transfer of control, in other words, exception breaks from the normal control flow to the nearest catch statement. You should throw an exception when verifying assumption. Whereas, error handlers are part of normal flow.

Refactor Early, Refactor Often: Every PR should make your code slightly better. Tidy up on daily basis rather than do the heavy uplifting in one go.

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.

Yes Go or Rust may give your extra performance, but you a team of NodeJS developers, what should you do? Blockchain solves trust issues, do you really need it inside one organization. Consider things beyond technology. How hard to find a good haskell developer in your city?

Test Early. Test Often. Test Automatically

Fit perfectly to the Test Pyramid. Integrate your tests (unit tests, integration tests, regression tests, e2e tests, etc) to your CI/CD pipeline

Find Bugs Once

Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

Collaboration

Fix the Problem, Not the Blame

It doesn’t really matter whether the bug is your fault or someone else’s — it is still your problem, and it still needs to be fixed.

Sign Your Work

You should be proud of your Pull Requests and Commits. It has your name on it. Company-wise, each repository should have a technical owner and it should be an email group.

The Tips

There are 70 tips in the book, each tip deserve multiple deep-dive articles. Maybe I should track them in a GitHub repo.

--

--

Jamie Wen
Jamie Wen

Written by Jamie Wen

Software Engineer | Technical Lead | Engineering Manager https://justlearning.club

No responses yet