This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source.
Then when he shows the visualization I was like "hey that looks like the d3 script I got out of some git analysis book years ago and still use at every job I work."
It's the same guy! Looks like he productized the scripts distributed with that book, which nice. I'll definitely try it and push for places I work to pay for that instead of the bundle of customized scripts I've been dragging around for years.
I really endorse that book too! I read it at the right time in my career I think, where I had truly seen some shit and so had the experience to understand the value of that approach, but not so far in that I had become set in my ways.
> The idea that, basically, bad code no one ever has to touch again is in fact good code
How do you know no one would ever have to touch that code again, at the moment of writing it?
Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not bad code.
It's less a guideline for writing code than one I use when deciding where to spend my efforts with existing code. I've mostly worked in long-lived codebases of profitable software, so nearly everything is a strong candidate for refactoring off of "quality" alone.
When you find something real blood-curdling but the last commit in that file was three and a half years ago, you just close it and pretend you didn't see. Better to spend the effort somewhere it will definitely benefit someone soon, rather than maybe some day.
The key idea is to break code into "chunks" that each do one thing.
Then, if you have to add a new feature, it goes into another chunk, instead of editing/modifying existing code.
The same logic applies to system design at different scales, whether fine-scale OOP or coarser-scale (micro)service architecture. The ideal size of an individual "chunk" is somewhat subjective & debatable, of course.
It's like Haskell-style immutable data structures, but applied to writing the code, itself.
Then visualize it however. I have some d3 scripts that came with the book that I've modified and you can track down somewhere on github I'm pretty sure. I mostly use those for demoing it to devs unfamiliar with the techniques though, since it looks cool and is immediately obvious what it's for.
For serious use I dump it into sqlite and use a mix of different scripts and techniques to figure it out. It's been kind of a language playground for me over the years so is in a lot of different languages and is "learning code" in most of them. Cleaning them up and sharing is one of those "maybe some day" things though.
Then when he shows the visualization I was like "hey that looks like the d3 script I got out of some git analysis book years ago and still use at every job I work."
It's the same guy! Looks like he productized the scripts distributed with that book, which nice. I'll definitely try it and push for places I work to pay for that instead of the bundle of customized scripts I've been dragging around for years.
I really endorse that book too! I read it at the right time in my career I think, where I had truly seen some shit and so had the experience to understand the value of that approach, but not so far in that I had become set in my ways.