Dr. Mario's 2nd 🧠

đź“– The Pragmatic Programmer, 20th Anniversary Edition

10 min read

From a wonderful chapter called “Pragmatic Paranoia”, which has a reference to 📖 The Black Swan:

No one in the brief history of computing has ever written a piece of perfect software. But Pragmatic Programmers take this a step further. They don’t trust themselves, either. Knowing that no one writes perfect code, including themselves, Pragmatic Programmers build in defenses against their own mistakes.

Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway)

The phrase “good enough’’ does not imply sloppy or poorly produced code.

Good design is easier to change than bad design

Read a technical book each month. While there’s a glut of short-form essays and occasionally reliable answers on the web, for deep understanding you need long-form books. Browse the booksellers for technical books on interesting topics related to your current project. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project. Read nontechnical books, too It is important to remember that computers are used by people—people whose needs you are trying to satisfy. You work with people, are employed by people, and get hacked by people. Don’t forget the human side of the equation, as that requires an entirely different skill set (we ironically call these soft skills, but they are actually quite hard to master).

Raw highlights

3-01-25]]

Highlights

  • Try to flush out the lame excuses before voicing them aloud. (Location 347)
  • 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. (Location 365)
  • If there is insufficient time to fix it properly, then board it up. (Location 373)
  • People find it easier to join an ongoing success. (Location 419)
  • involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway). (Location 466)
  • Great software today is often preferable to the fantasy of perfect software tomorrow. (Location 468)
  • You constantly step back with a critical eye to view what you’ve done. Every now and then you’ll throw a canvas away and start again. (Location 472)
  • the hard work is ruined if you don’t know when to stop. (Location 473)
  • Your ability to learn new things is your most important strategic asset. But how do you learn how to learn, and how do you know what to learn? (Location 497)
  • Building Your Portfolio (Location 506)
  • Invest regularly (Location 507)
  • Diversify (Location 509)
  • more technologies you are comfortable with, the better you will be able to adjust to change. (Location 512)
  • It’s not a good idea to invest all of your money in high-risk stocks that might collapse suddenly, nor should you invest all of it conservatively and miss out on possible opportunities. (Location 514)
  • Buy low, sell high (Location 516)
  • Review and rebalance (Location 518)
  • Read a technical book each month While there’s a glut of short-form essays and occasionally reliable answers on the web, for deep understanding you need long-form books. Browse the booksellers for technical books on interesting topics related to your current project.[10] Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project. Read nontechnical books, too It is important to remember that computers are used by people—people whose needs you are trying to satisfy. You work with people, are employed by people, and get hacked by people. Don’t forget the human side of the equation, as that requires an entirely different skill set (we ironically call these soft skills, but they are actually quite hard to master). (Location 527)
  • why something is done, its purpose and its goal. The code already shows how it is done, so commenting on this is redundant—and is a violation of the DRY principle. Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on. (Location 654)
  • Keep code and documentation together. (Location 659)
  • In addition, Dinosaur Brains: Dealing with All Those Impossible People at Work [BR89] (Location 677)
  • Good Design Is Easier to Change Than Bad Design (Location 722)
  • Not All Code Duplication Is Knowledge Duplication (Location 901)
  • The two functions validate two separate things that just happen to have the same rules. That’s a coincidence, not a duplication. (Location 915)
  • your code has to have knowledge that is also present in the external thing. It needs to know the API, or the schema, or the meaning of error codes, or whatever. The duplication here is that two things (your code and the external entity) have to have knowledge of the representation of their interface. (Location 1024)
  • For internal APIs, look for tools that let you specify the API in some kind of neutral format. (Location 1027)
  • OpenAPI.[15] (Location 1031)
  • you need to change an object’s state, get the object to do it for you. (Location 1140)
  • In general, your code is easier to understand and maintain if you explicitly pass any required context into your modules. (Location 1144)
  • Writing unit tests is itself an interesting test of orthogonality. What does it take to get a unit test to build and run? (Location 1158)
  • Look for the important requirements, the ones that define the system. Look for the areas where you have doubts, and where you see the biggest risks. Then prioritize your development so that these are the first areas you code. (Location 1282)
  • Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. (Location 1348)
  • the burden of correctness to the caller—where (Location 2366)
  • For anything that you create that takes up a finite resource, consider how to balance it. (Location 2676)
  • In his book, The Black Swan: The Impact of the Highly Improbable [Tal10], Nassim Nicholas Taleb posits that all significant events in history have come from high-profile, hard-to-predict, and rare events that are beyond the realm of normal expectations. These outliers, while statistically rare, have disproportionate effects. In addition, our own cognitive biases tend to blind us to changes creeping up on the edges of our work (see Topic 4, ​Stone Soup and Boiled Frogs​). (Location 2796)

  • This is pretty poor style​ ​  amount = customer.orders.last().totals().amount; (Location 2934)

  • we need to get back to thinking of programs as being something that transforms inputs into outputs. When we do, many of the details we previously worried about just evaporate. The structure becomes clearer, the error handling more consistent, and the coupling drops way down. (Location 3279)
  • If your background is object-oriented programming, then your reflexes demand that you hide data, encapsulating it inside objects. These objects then chatter back and forth, changing each other’s state. (Location 3484)
  • This introduces a lot of coupling, and it is a big reason that OO systems can be hard to change. (Location 3485)
  • Don’t Hoard State; Pass It Around (Location 3487)
  • we can greatly reduce coupling: a function can be used (and reused) anywhere its parameters match the output of some other function. (Location 3491)
  • But, being a professional, you soldier on, taking step after muddy step: you have a job to do. Unfortunately, that’s probably the exact opposite of what you should do. Your code is trying to tell you something. It’s saying that this is harder than it should be. (Location 4618)
    • Note: As in “too much grit” in Range book
  • If you write the original code and you write the tests, is it possible that an incorrect assumption could be expressed in both? The code passes the tests, because it does what it is supposed to based on your understanding. (Location 5172)
  • Python, and uses the Hypothesis tool and pytest, but the principles are pretty universal. (Location 5187)
  • have a project glossary, listing the terms that have special meaning to the team. (Location 5653)
  • Our job is to help people understand what they want. (Location 5741)
  • The client uses programmers because, while the client is motivated by solving a high-level and somewhat nebulous problem, programmers are interested in all the details and nuances. (Location 5819)
  • Create and maintain a project glossary—one place that defines all the specific terms and vocabulary used in a project. All participants in the project, from end users to support staff, should use the glossary to ensure consistency. This implies that the glossary needs to be widely accessible—a good argument for online documentation. (Location 5845)
  • To outsiders, the worst project teams are those that appear sullen and reticent. They hold meetings with no structure, where no one wants to talk. Their emails and project documents are a mess: no two look the same, and each uses different terminology. Great project teams have a distinct personality. People look forward to meetings with them, because they know that they’ll see a well-prepared performance that makes everyone feel good. The documentation they produce is crisp, accurate, and consistent. The team speaks with one voice.[77] They may even have a sense of humor. (Location 6113)
  • Spend 30 minutes coming up with a zany logo, and use it. Use your team’s name liberally when talking with people. It sounds silly, but it gives your team an identity to build on, and the world something memorable to associate with your work. (Location 6119)
  • through the entire system. That means that you need all the skills to do that within the team: frontend, UI/UX, server, DBA, QA, etc., (Location 6140)
  • a good project may well have more test code than production code. The time it takes to produce this test code is worth the effort. It ends up being much cheaper in the long run, and you actually stand a chance of producing a product with close to zero defects. (Location 6259)
  • Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.” That’s what we do, and that’s the essence of a Pragmatic Programmer. We solve problems. (Location 6365)
  • Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. It becomes too easy to see yourself as just a cog in the wheel, producing lame excuses in endless status reports instead of good code. (Location 6381)
  • Your signature should come to be recognized as an indicator of quality. (Location 6386)
  • Some inventive ideas begin to skirt the bounds of ethical behavior, and if you’re involved in that project, you are just as responsible as the sponsors. No matter how many degrees of separation you might rationalize, (Location 6435)
  • Vard Antinyan, Jesper Derehag, Anna Sandberg, and Miroslaw Staron. Mythical Unit Test Coverage. IEEE Software. 35:73-79, 2018. (Location 6447)
  • Answer 23 (from exercise 23) (Location 6836)

Graph View

Backlinks