Closed ajschumacher closed 3 years ago
Another perspective: Maybe not as good for newer devs? Maybe better after you've gotten a "groove" going?
They note "Meyer's Uniform Access principle," which states that "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation."
In Python this doesn't have to mean exposing getters and setters; using @property is a good solution.
"If it isn't easy, people won't do it." (page 38)
"In fact, this book is written in Markdown, and typeset directly from the Markdown source." (page 45)
How? How do they do footnotes, etc.? Sounds like ConTeXt can do some part... But presumably they have their own custom stuff. Lots of details, I imagine.
"Model building can be both creative and useful in the long term. Often, the process of building the model leads to discoveries of underlying patterns and processes that weren't apparent on the surface." (page 67)
"During the calculation phase, you get answers that seem strange. Don't be too quick to dismiss them. If your arithmetic is correct, your understanding of the problem or your model is probably wrong. This is valuable information." (page 68)
The footnote on page 100 cites What Does Doodling do?, which seems kind of neat. I don't completely trust the result in the paper though, or at least the interpretation. Here's the abstract:
Doodling is a way of passing the time when bored by a lecture or telephone call. Does it improve or hinder attention to the primary task? To answer this question, 40 participants monitored a monotonous mock telephone message for the names of people coming to a party. Half of the group was randomly assigned to a ‘doodling’ condition where they shaded printed shapes while listening to the telephone call. The doodling group performed better on the monitoring task and recalled 29% more information on a surprise memory test. Unlike many dual task situations, doodling while working can be beneficial. Future research could test whether doodling aids cognitive performance by reducing daydreaming
"DBC [Design By Contract] is more efficient (and DRY-er) than defensive programming, where everyone has to validate data in case no one else does." (page 108)
"By expressing the domain of the square root function in the precondition of the
sqrt
routine, you shift the burden of correctness to the caller–where it belongs." (page 110)
And other "fail fast" kinds of things... "crashing early" etc...
In Python, with open
blocks help implement "Finish What You Start"
(page 118).
This chapter is very substantially different from the original version, and in interesting ways. Here's a quick summary:
"When we try to pick out anything by itself, we find it hitched to everything else in the Universe." (page 130, quoting John Muir, My First Summer in the Sierra)
On page 148, they list files such as dry.pml
which I guess means
they write using "Pragmatic Markup Language" as their custom
Markdown...
"Do you program in an object-oriented language? Do you use inheritance?
"If so, stop! It probably isn't what you want to do." (page 158)
"[Concurrency] is often implemented using things such as fibers, threads, and processes." (page 169)
I wasn't familiar with fibers. Cute name. Connected to coroutines (cooperative multitasking). Seems like fibers is common terminology in Ruby.
"... messaging systems (such as Kafka and NATS)" (page 189)
I wasn't familiar with NATS. It's a messaging system. According the FAQ:
"NATS stands for Neural Autonomic Transport System. Derek Collison conceived NATS as a messaging platform that functions like a central nervous system."
"Testing is not about finding bugs, it’s about getting feedback on your code: aspects of design, the API, coupling, and so on. That means that the major benefits of testing happen when you think about and write the tests, not just when you run them." (page 325)
"If you’re not sure why it works, you won’t know why it fails." (page 339)
"Tip 68: Build End-to-End, Not Top-Down or Bottom Up" (page 366)
"Testing, design, coding—it’s all programming." (page 374)
Property-based testing seems like fuzzing...
That NIST thing on having reasonable password rules: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
This is good stuff, but I didn't pull out specific notes. It's on working in tight feedback loops rather than trying to "collect requirements" all at the beginning.
"Programmers are a bit like cats: intelligent, strong willed, opinionated, independent, and often worshiped by the net." (page 437)
"Tip 85: Schedule It to Make It Happen" (page 441)
Mythical Unit Test Coverage is neat. Abstract:
"It is a continuous struggle to understand how much a product should be tested before its delivery to the market. Ericsson, as a global software development company, decided to evaluate the adequacy of the unit-test-coverage criterion that it had employed for years as a guide for sufficiency of testing. Naturally, one can think that if increasing coverage decreases the number of defects significantly, then coverage can be considered a criterion for test sufficiency. To test this hypothesis in practice, we investigated the relationship of unit-test-coverage measures and post-unit-test defects in a large commercial product of Ericsson. The results indicate that high unit-test coverage did not seem to be any tangible help in producing defect-free software."
"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." (page 464)
"Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code." (page 466)
"Tip 99: Don’t Enable Scumbags" (page 472)
Chapter 1: A Pragmatic Philosophy
The "broken windows" stuff on page 6 is complicated a little bit by broken windows policing... https://en.wikipedia.org/wiki/Broken_windows_theory
The "Knowledge Portfolio" metaphor is pretty good. ("Tip 9: Invest Regularly in Your Knowledge Portfolio" page 15) We want people to be life-long knowledge investors.
They list five items in managing a knowledge portfolio:
In Why Curiosity Matters they reference "Toyota’s 5 Whys approach."