91–100 of 121 posts
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.
So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and software craftsmanship aren’t worth it, it’s that companies and the engineers who build them from startups don’t care and are focused on keeping their doors open. Long term health is a very secondary concern.
I’ve done my fair share of preaching that we should refactor and start focusing on quality during code reviews and it’s basically just shouted down with “don’t fix what isn’t broken” and YAGNI.
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…
Earlier quoted context omitted.
You’re lucky it’s intuitive for you. I think it’s valuable to have credible sources backing up my intuition because I’ve worked in orgs that document way too much and way too little. So just calling out a desire for just right documentation (with copious examples) is handy to me so that people don’t idealize no doc systems or spend half their time documenting.
I think the complaint wasn't that the book was intuitive or not, but that it lacks actionable guidance. "Make sure to write the correct amount of documentation in a clear manner." sounds great on the surface, but doesn't actually help someone who is trying to figure out what the "correct amount of documentation" or "clear manner" actually is.
Step 1: choose a metric that makes sense.
Step 2: set a target for the metric.
Step 3: iterate until you hit the target.
So for "good, clear documentation" the right metric might be "other people using the documentation to do things and/or demonstrate they've learned something."
The target might be set a quiz or asking people to use the documentation to do something, and get a 80% passing rate.
The truly pragmatic thing is to not insist on getting anything right thr first time, to measure by outcomes not outputs, and especially to value the input of other people and be empathetic to your users, fellow developers, bosses and yes, even yourself (no failures, just data...)
Earlier quoted context omitted.
I don't think you understand what "maintenance" means here. If you make them well enough for the job, you haven't succeeded at your job. If you make them well enough for the job and you don't need to constantly watch for failures, you have succeeded at your job. If you can't say "this is as good as it can be done" for a given piece of software, you might have room to grow.
I understand just fine, it just sounds like software is too hard for some folks, and while that's okay, but there are those of us who aren't burned out by doing our jobs.
> Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time?
> Because companies like to make money, and they can't make money when systems fail.
The second issue you raised is a nonsequitor, because you clearly misconstrued the initial point. Your refusal to acknowledge there was a different interpretation, pretending you meant something nonsensical on purpose, has compounded the optics. GL with that.
The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.
I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free. So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and sof…
If you have an established, cashflow-positive company that's not hell-bent on scaling fast (or being forced to scale unnaturally by VC backers) then the balance swings back and it becomes worth investing in your codebase.
I don’t think a month goes by that I don’t quote this concept to a group or individual. Really appreciate how they put all these ideas together.
Earlier quoted context omitted.
Add Fogel's "Producing Open Source Software" and Brooks' Mythical Man Month and you've perfectly described my shelf too. I found most of those when I was a lowly junior developer and they were instrumental in shaping my thinking, approach, and understanding of tradeoffs. I'd love to see more people pick them up.
I just looked and realized that I actually have Mythical Man Month next to the Pragmatic Programmer book...
Earlier quoted context omitted.
When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were in it.
When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were __from__ it. There, I fixed that for you. ;)
Earlier quoted context omitted.
30 years ago? That was 1989. How many companies were using source control in 1989? How about 1999? Still not very many. 2009? Well, now you will find quite a few using SVN, but Git hasn't really taken off yet.
They did use SCCS, RCS, and CVS, and also commercial SCMs such as PVCS. There were also file systems with integrated revision support on VAX/VMS and other "midrange" systems such as Norsk Data/SINTRAN. Of course, most people were applying adhoc "Cognac" SCM: rename your old revisions by appending ".old", ".vo" (very old), ".xo" (extra old) and so on until it becomes untenable, store individual customer builds, etc.
Versioned file systems were developed for source code management and go back to ITS and TENEX in the late 1960s. So version control as we know it, as a widespread (at least in the DEC world) practice dates back to the 1970s.