This review is an insult based on lies about the book's content. The author says "unlike the authors, I know that DRY does not hold true everywhere". Meanwhile, on pg. 35 of Pragmatic Programmer: "Later on in the development process, you may choose to violate the DRY principle".
Similar exaggerations and mischaracterizations pollute the review. I could go on but it is too infuriating. Delete this.
I really don’t like these trends of telling people what to do. Your opinion is fine, but I find it rude to command someone to do something. “Delete this” just reeks of arrogance and faux dominance.
>“Delete this” just reeks of arrogance and faux dominance.
It's a meme. On imageboards, Discord etc it is commonplace to post a funny image, usually of a cute character, with a gun, and the "delete this" caption. Doing an image search should show it. So instead of this feel, I think the intent is to show the comment should not be taken too seriously (so the exact opposite of your reaction).
It's an issue of shared language -- or zoomer-talk as some would put it.
But "zoomer" is itself a term that would probably require some explanation.
I've also had some very bad reactions to talking about "high-level programming", with computer scientists, every time to my surprise.
There was recently a heated debate about the right to use the word "normal" in mathematical context. Aggressiveness is a relative concept...
When in Rome, do as the Romans do. HN is HN, and the vast majority of messages don't use irony or sarcasm. Humor is relatively rare. Often messages are annotated with a "/s" to indicate sarcasm. After spending a bit of time on HN, it becomes obvious how to handle sarcasm, humor, zoomer-talk, anything like that: be very obvious that you are using it. Or, as they say on the other side of the internet, "lurk 1000 years before posting".
Frankly, I don’t like the meme either. I realize it’s meant to be taken in jest, but it still has an impact on the tenor of discourse.
There’s a Jonathan Coulton song from the TV show “The Good Fight” about how memes can evolve online:
At first it’s just a meme,
Then it’s a joke about the meme.
The joke is that it’s fake,
It’s not as fake as it may seem.
Confusion when they use one,
And it seems like what they mean.
And then, ta-da, a cartoon Nazi frog!
Both replies make it seem like I'm suggesting people should express themselves like that.
I'm not using any of these memes, and as pointed out it's quite out of place on hn.
I just wanted to clarify the misunderstanding.
"Delete this" is the almost like a motto of the current age. Whenever you don't agree with something it has to have no value and only recourse is to demand it's deletion.
People don't want wild forest of ideas they want neat cultivated gardens with very high walls.
HN should be able to use Memes, OP would have added [0], we'd laugh about it. Possibly OP could have used "Delet this" to make the words take on their alternative, more humorous, richer, meme-ish meaning.
My impression from reading half of the article is that the author _really_ prides himself with being anti-dogmatic. Smells like the type with strong opinions on everything where a "healthy discussion" is the most important thing rather than actual teamwork getting things built with a (gasp) suboptimal tech stack and imperfect ways of working.
I should know because I was like that before I read the pragmatic programmer.
I'm not finding I agree with this review, but because the author has chosen their quotes selectively, I want to point out:
"broken windows". The book uses the turn of phrase, but does not (unless maybe in the original edition? I have the 20th anniversary one) actually quote the debunked theory beyond this phrase. Take it as the turn of phrase that it is, no need to read more into it than is present. If you don't like it, consider something more like "if you see trash on the ground, pick it up, don't step over it." Though that's a heck of a lot wordier. But about the selective quotes, let's take the whole phrase from the book:
> Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. [emphasis mine] -- page 7
The emphasized part is what the reviewer didn't include. By only reading the first two sentences, sure it reads as a bit dogmatic. But reading the whole thing, it's clear that there is more to it. What does "board it up" mean? Well, they expand on it in the following sentences:
> Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation. [emphasis in original]
That seems pragmatic to me, "I can't handle it properly now, but I'll do something that reduces the problem or draws attention so it can be properly handled later." In the JIRA-driven world, put in a new ticket.
They don't prescribe one answer or one set of answers to the problem, except to address it. Which is pragmatic because leaving garbage in a system is a really good way (over a few years, anyone who has worked on long-running systems will have experienced this) to end up with a load of garbage.
I'm also dealing with that at work. Current situation: 11 files all derived from an initial baseline, there was only supposed to be a one line change for each (apparently the programmer had never heard the term "parameter"), everything else was supposed to be the same. However, what was two copies (and maybe easy to keep in sync) became 11 total, copied at different times and from different versions. They're all out of sync with each other and the end users now have to know 10 (one is correct) workarounds to deal with the 10 bad states the system can get into. And this isn't the only place this happened in this codebase, it's rampant.
I have the 20th anniversary edition. It quotes the debunked magazine article directly:
"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]"
Fair enough, I apparently didn't look closely enough at that page and focused on "Tip 5" itself, the problem with using a physical book versus something searchable. Still, my primary issue with this review is the selective quoting that made the authors' views seem dogmatic in a way that they weren't. They specifically provide a pragmatic out versus stop-and-fix and rchaves neglected it to make a misleading point.
Personally I think the broken window theory still holds up, at least at a superficial level. The notion of permissibility drives behavior in these human operated systems (neighborhood vandalism/software development), and visible examples are signs of what's allowed or acceptable that if left unchecked will soon be widespread - people like to push the limits. The study doing the "debunking" was itself looking at other studies tying broad local criminal behavior to signs of vandalism, which is not what should be correlated here, just more broken windows. Of course the theory itself has been weaponized quite unscientifically, but that doesn't take away its explanatory power. Maybe for software we can call it the "temporary hack" theory, where a codebase will soon be held together with duct tape and one liners if things aren't nipped at the bud.
A related concept is "normalization of deviance", but it's not quite the same as "broken windows" as it's meant to apply to processes (so does apply to software engineering practices and discipline) and not artifacts (that is, the code itself).
Basically, you have a, reasonably, safe and disciplined process. You have controls in place for a good reason, but you relax them. Possibly for a good reason, possibly not, and nothing bad happens (at least not yet). This relaxation gradually becomes normalized (think about a safety critical system turning off alarms and leaving them off, "because they're always false alarms"). The odds of a problem occurring is increased by this relaxation of controls and potentially shifts from being "possible" to "inevitable" (in sysadmin stuffs, consider manual data entry at a critical juncture, a fat-fingered value can cause catastrophic problems when it could have been automated and pulled from a regularly reviewed data source).
I observe it in my personal behavior. For example, if there's a dirty dish in the sink, I'll leave my dirty dish there too and not clean it. If there are no dishes there, I'll do my dish immediately.
It says there is a correlation between the number of broken windows and crime, that's not causation. Or were you making an attempt to illustrate the common misconception
Literally first result in google: The broken windows theory is a criminological theory that states that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes
I've seen this sentiment more and more recently. This sentiment is shared with books like Clean Code, which, when I first heard this, was shocking. Clean Code was one of the best books I ever read on programming, and at the time was hugely influential to my career growth. In fact, it helped me so much that I was able to uplevel other engineers by mentorship at several organizations that I've worked at.
That being said, there have been some great critiques of these books and it's kept me wondering if maybe I'm misremembering these books for what they were. Here's a critique on Clean Code: https://qntm.org/clean
Has it really been that long? Are these books really this outdated now? I saw a similar thread on Reddit recently and the alternative they recommended was this book... https://sandimetz.com/99bottles I've read only a couple of chapters, and I'm struggling to see why this book is so much better. Anyone have any opinions on this?
Nuance may leave a good feeling with the one reader. Black and white however will make your post go so much further as it either enrages or wins accolades and really who cares if it just gets forwarded and promoted and with it your name.
I wouldn't lump The Pragmatic Programmer together with Clean Code. Bob Martin is notoriously dogmatic about just about everything he says. The Pragmatic Programmer, on the other hand, was the book that first exposed me to the idea that there are principles that are good in general, but it's also good to know when and how to violate them.
IMO many programmers simply don't like Clean Code because their greybeard mentors have been bothering them with it too much. They want something fresh and new, something that makes them feel they understand software development better than most of their peers including their mentors.
Clean Code was horribly dogmatic. He would lay down "laws" that were actually trade offs that worked well for him in specific instances in the past, blithely lacking understanding of the context that made them work.
The danger with Clean Code is that a lot of the advice would work a lot of the time so it's very easy to think it's exactly on point right up until it guides you face first into a brick wall.
Except it isn’t dogmatic. Re-read chapter 1 where they write that there is not One True Way and advise the reader to go find other sources along with reading their own book. That is not something dogmatic writers would include.
Again, read the first chapter. A dogmatic text would not tell you to go find and study other sources and develop your own path. That they then tell you their ideas in an opinionated fashion is not in (total) conflict with that sentiment.
The claims of dogma are, in my opinion, grossly exaggerated and a consequence of people failing to read (or failing to comprehend) the authors' own caveats in chapter 1. If they didn't include those statements in chapter one, maybe I'd agree with you. I still wouldn't discard the text out of hand, because, you know we have brains and can think critically and read a text to evaluate it ourselves.
(I say "authors" because Bob Martin was the primary author, several chapters are written by other people.)
I bought TPP when it was published and it changed my thinking about software development in many very positive ways (unit testing and refactoring for example).
But, the author of this article seems to forget that this book is now over 20 years old and not everything written by Hunt and Thomas still holds true. But thinking about and trying to define how best to produce good software is an ongoing dialectic and one size doesn't fit everyone, some ideas reach their sell-by date. Pick the best bits and get on with the job.
Would I recommend TPP to novice developers? I've not read the 20th anniversary edition yet which apparently addresses how software development has changed since the original publication so my verdict is out on that question.
The article author doesn't make it clear which edition of TPP he's criticising, but if it's the original edition then I think he's unfairly beating a dead horse.
Most of these books that were standards in the 2000s don't hold up great now, just because most of the important parts have diffused and become ambient omnipresent practices.
Putting so much emphasis on variable naming, to take one common theme from Code Complete, Pragmatic Programmer, Clean Code, et al, makes a lot more sense coming out as a reaction against some of the worst excesses of Hungarian notation.
They just aren't the kind of revelation that they were 20 years ago, in part because they've been so successful at molding multiple generations of programmers now.
> Putting so much emphasis on variable naming, to take one common theme from Code Complete, Pragmatic Programmer, Clean Code, et al, makes a lot more sense coming out as a reaction against some of the worst excesses of Hungarian notation.
I don't know about that. I just finished cleaning up a codebase where my predecessor named literally any response from any API call "tempJson", regardless of how many hundreds of subsequent lines ended up using it. Some of these "tempJson" variables would get passed to other functions with the parameter also being named "tempJson" or "json". It was nightmarish. I wish this programmer had read and applied the principles in The Pragmatic Programmer, but he hadn't.
I suspect it's not that the context has changed such that the book is unnecessary, it's that most of us have forgotten that many of these principles aren't obvious to newcomers.
Having been there I think it is other stuff, rather the cargo cult bubble selling conferences and consulting gigs is now gone and we got back to the good old days in most companies.
The exception being startups that are still in the phase of attracting dreamers that are going to change the world.
I agree they're omnipresent practices, but still good reading for new-ish devs. Probably about half of my comments on young FAANG peers PRs are "greatest hits" from Code Complete and Clean Code like variable naming, etc.
Regarding variable names I think the correct answer is somewhere in the middle. There's such a thing as too short a variable name, and these days I see it more frequently than I see too verbose a variable name.
I believe the best answer is dependent on context.
How short is too short? How large is too large?
On a shallow for-loop, i and j as variable names is perfectly acceptable and probably desirable - it conveys their meaning in a very concise and familiar manner.
On the other hand, if you're writing a function that's a little outside of your codebase's core areas it might make sense to name things a bit more verbosely and perhaps (the horror) add comments explaining in more detail what those data containers are supposed to hold.
I would love to see the next generation of opinionated formatting tools perhaps use AI models to automatically set and enforce variable naming. Maybe even just some simple heuristics like iteration count variables are 3 characters or less, state values are nouns, etc. would be good enough. Please just completely automate and remove any and all bikeshedding around naming, much like we've done with formatting--it would probably remove 25% or more of all commentary on code reviews.
Design Patterns - I think there are a few obvious ones like Singleton and Bridge, a few non-trivial like Strategy and the rest are just historic artifacts for interviews
Those are comments on the implementation patterns in the Gang of Four book, which are indeed historically situated in the period of the book’s publication and relate to common solutions to problems then encountered. And indeed many of the non-trivial ones are interchangeable: what is State but a Strategy for handling time? What is Abstract Factory but a Strategy for creating objects?
Underlying this is the idea of a Patterns Language for programming: the idea that specific problems can be categorised into general problem shapes, that a satisfactory solution that fits the shape can be named, and that communication is aided by discussion involving those names. The idea of the patterns language is still very much relevant today. Whenever a developer says “this can be a redux saga” or “we’ll use serverless for that”, they are naming a general solution that they believe fits the shape of their specific problem.
I find the names of the patterns unintuitive, more like a language barrier to adoption. Same feeling I got from AngularJS when it was initially published.
All names are unintuitive. The point of Design Patterns is to have a catalog of solutions with names (aka jargon) so we can have higher-level discussions. This requires those involved in the discussion to have a clear understanding of the pattern, which isn't always the case.
This review is trash. Calling a style guide for programming bad because it is opinionated is like calling sugar bad because it is sweet.
The whole review just drones on and on about why the book should not be opinionated about coding practices not realising that the books of this genre are useless without strong opinions.
The point about broken windows having been debunked for crime is a non-argument when applied to programming. He's comparing apples and bananas. Someone just happened to use a term for two things that are only kinda related.
I don't even use the term 'fixing broken windows' for programming, I use the term 'repaying tech debt' . That's pretty universally seen as a good thing, if not without difficult tradeoffs in real world business software eng.
There's a fair bit else that's off in this article and it's quite an uncharitable reading of a classic book. There are no sacred cows but PP doesn't warrant a hatchet job.
> Dogmatic Programmer: let’s make everything abstract, what if we need to switch databases?
> Pragmatic Programmer: we will never switch databases.
In other words, the blog author is saying "I don't have much software experience." I used to think I'd never switch databases too, until I built a very large system and had to switch databases.
I think both the dogmatic programmer and the pragmatic programmer are wrong here and the truth is somewhere in the middle. The code actually touching the database and doing queries should be a small percentage of a large application. Mixing database logic and application logic in a large application is just bad. This does not mean that one should make everything abstract, it just means business logic should request data from the database through a layer saying things like Customer cust = GetCustomerById(id) (for instance, there are other possibilities but at least one does not see database code in this explicitly). It will still be a bit painful to switch databases but it will not be impossible. It is okay that it is a bit painful to switch databases if everybody was thinking with good reason that it would not happen. It is not okay that it is impossible to switch databases even if everybody was thinking this would not happen.
The point from the book as I remember it is that of YAGNI: You Ain’t Gonna Need It. Don’t proactively build these layers of abstraction until you discover that you do need them. After a migration, toss it.
The author misses the point of abstracting portions of systems away. First, you can create shim layers for unit, component, and functional testing. Many of these tests can be automated, without the need of a database, or other functionality required during deployment. Next, if your software is written for you, and only you, then you're losing on others using it or other customers. Customer A might not use DB 1. Customer 2 might use DB1 at certain locations, and DB2 at others.
The abstraction portion also gives a tester the ability to see if what comes in, is what needs to come out, without reliance on additional hardware and other sunk costs. A simple example is a currency/bill validator. These are expensive pieces of hardware, and not needed to verify other portions of the system, but a module for that device can be emulated.
Next, it appears he hasn't read the book Pragmatic Programmer, or the book went over his head. "Don't live with broken windows", "Make it easy to reuse", and "Decoupled code is easier to change" are three hallmarks of the book. All three are in contradiction to his article.
If you haven't read the Pragmatic Programmer, I highly encourage you to read it. It is a required read in my company.
> Why? And “strategic”? I thought this book was about being pragmatic (foot on the ground, present) not “strategic” (heads in the cloud, future)
It's a good summary of the article. All of the time is spent trying to frame the book in a way (non pragmatic) and the author of the article in another (pragmatic). Articles like that usually have little to no value. At most, 5% of the book has been covered in the article, and that seems to be enough to reject everything.
"We've never tried this—honest. But “they” say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won't notice the slow increase in temperature and will stay put until cooked."
It makes it hard for me (personally) to use the lessons of the book (cognitive dissonance ... "wait but a frog would jump out" ... ).
Given the work that went into the anniversary book, I am wonder if the authors could not have found better fitting metaphors.
I am looking for a list of type of developers posted here more than 10 years ago. Types like the shotgun programmer, the duplicator, the abstractor etc. It was an awesome text only list of many different types. I cannot find it.
Not the list you were looking for, but I have (inherited from a mentor much earlier in my career) a developer-classification scheme: The four Ducks. Wild Duck, Tame Duck, Lame Duck and Quack. https://www.mikro2nd.net/ducks/
Similar exaggerations and mischaracterizations pollute the review. I could go on but it is too infuriating. Delete this.