Comment by ilrwbwrkhv
9 months ago
john ousterhout's book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev's life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they finally grow.
That book really poisons the mind. Even if there's some good things to learn in there, it's stashed among a lot of advice that is either plain bad or needs asterisks. But there aren't really any asterisks and instead it presents what look like rules that you shouldn't be breaking if you want to be a good programmer.
When I first read the book I'd already been programming for 10 years, but I was in my first job out of college. I'd heard a lot about the book and so I trusted what it had to say. I let it override how I would have written code because I figured coding professionally was just far different than what I would consider the best way to write code.
Interestingly, 5 years sounds about right for how long it took me to finally start trusting my own judgement. I think it was a combination of being more confident in myself but also because I was doing larger projects and it was more frequent that I was putting down a project and then coming back a couple months later. That's how I was able to see how bad the code was to work with once my mental model of it had flittered away.
Now I take a much less strict approach to my code and I find it a lot better to work with later.
1. newbie follows the rules because he is told to
2. master follows the rules because he understands them
3. guru breaks the rules because they don't apply
There's a step between 1 and 2, someone who writes rules because he believes he understands them.
There was an era where every just-above-newbie PHP developer would start writing their own authoritative blog posts and frameworks, I strongly feel that had a big impact on the fragmentation and reputation of the PHP ecosystem as being insecure (because a lot of these authoritative blog posts demonstrated how to introduce SQL injection vulnerabilities)
> instead it presents what look like rules that you shouldn't be breaking if you want to be a good programmer.
I see this a lot, especially among more junior programmers. I think it likely stems from insecurity with taking responsibility for making decisions that could be wrong. It makes sense, but I can’t help but feel it is failing to take responsibility for the decisions that are the job of engineering. Engineering is ultimately about choosing the appropriate tradeoffs for a specific situation. If there was a universally “best” solution or easy rule to follow, they wouldn’t need any engineers.
I always think of this as the programmer version of "No one got fired for choosing IBM." that was a common phrase about executives back in the day. Do the thing that you can just point to "experts" and blame them.
2 replies →
Which book are you referring to? The parent comment mentioned two books.
Clean Code
"john ousterhout's book is the only book on how to write software that has any actual evidence behind it."
This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example.
There are lots of other architecture/design books that use real world systems as examples. "Evidence" is definitely lacking in our field, but you can find it if you try.
Greg Wilson indeed is tremendously helpful in facilitating "the industry" to think about our craft:
https://github.com/gvwilson
edit: wow, in his project "It will never work in theory" he's fairly sober about the ability of "the industry" to reflect on "the craft"
https://neverworkintheory.org/
> about the project:
> People have been building complex software for over sixty years, but until recently, only a handful of researchers had studied how it was actually done. Many people had opinions—often very strong ones—but most of these were based on personal anecdotes or the kind of "it's obvious" reasoning that led Aristotle to conclude that heavy objects fall faster than light ones.
in the 2024 retrospective:
> Conclusion
> The comedian W.C. Fields once said, “If at first you don’t succeed, try, try again. Then quit. There’s no point in being a damn fool about it.” Thirteen years after our first post, it is clear that our attempts to bridge the gulf between research and practice haven’t worked. We look forward to hearing what actionable plans others have that will find real support from both communities.
The annals of the IEEE and ACM would argue against:
>only a handful of researchers had studied how it was actually done
I am pretty sure that there are more than 5 references to papers in APoSD.
> no links
Here is a whole course, with videos and links to slides and readings.
https://github.com/margaretstorey/EmseUvic2020
5 years is about right.
when i found a copy of clean code in a bookstore, it only took me a few minutes to put it back. I had read John Ousterhout's book prior.
In typical HN commenter smugness. It took me less than that to realise it was bullshit. It didn’t make things clear, it made them more abstract and more resistive to change. Similarly with DDD. Just build what you need and deal with the consequences of inevitable change later. No one cares if you miraculously perfectly modelled your “definitely the final form” of your domain from day 0.
Oh and TDD?! Ah yes those perfectly defined unit cases you write for implementation details. The best comment I read recently (sorry I can’t find it) something akin to “The first unit I write is to validate the intended side effects through properly exercising associated mocks”
As with everything there is no “best way” to do something, but in software engineering… there are far more bad “best ways” than best “best ways”
DDD is a good way to extract the business logic from the implementation.
By modelling the business you raise the business logic up to a 1st class element.
By implementing the business objects you encapsulate their functionality in the business.
The words "Account" or "Outstanding Balance" have business meanings. Modelling them allows you to express the business logic explicitly.
It also allows you to create tests that are related to that business logic, not the implementation.
You can still "build what you need and deal with the consequences of inevitable change later".
Model what you need to build, the business is going to have to make changes to that model to implement their changes, IT systems are a detail.
Change by extending and changing the DDD models.
To reverse the question, how do you write code that "does what you need" without understanding the domain?
There's a huge difference between understanding the domain and modelling it as objects. Accounts and Balances have no behavior.