5 ms·

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 t

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.

owl_vision 2y ago
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.
pinoy420 2y ago
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”
- rswail 2y ago
  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?
  - sirwhinesalot 2y ago
    There's a huge difference between understanding the domain and modelling it as objects. Accounts and Balances have no behavior.
ziml77 2y ago
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.
- MobiusHorizons 2y ago
  > 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.
  - runevault 2y ago
    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.
    - MobiusHorizons 2y ago
chillpenguin 2y ago
"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.
- recursivedoubts 2y ago
  > no links
  - chillpenguin 2y ago
    Here is a whole course, with videos and links to slides and readings. https://github.com/margaretstorey/EmseUvic2020 https://github.com/margaretstorey/EmseUvic2020
- froh 2y ago
  Greg Wilson indeed is tremendously helpful in facilitating "the industry" to think about our craft: https://github.com/gvwilson 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/ 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.

owl_vision 2y ago

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.

pinoy420 2y ago

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”

rswail 2y ago
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?
- sirwhinesalot 2y ago
  There's a huge difference between understanding the domain and modelling it as objects. Accounts and Balances have no behavior.

ziml77 2y ago

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.

MobiusHorizons 2y ago
> 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.
- runevault 2y ago
  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.
  - MobiusHorizons 2y ago

chillpenguin 2y ago

"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.

recursivedoubts 2y ago
> no links
- chillpenguin 2y ago
  Here is a whole course, with videos and links to slides and readings. https://github.com/margaretstorey/EmseUvic2020 https://github.com/margaretstorey/EmseUvic2020
froh 2y ago
Greg Wilson indeed is tremendously helpful in facilitating "the industry" to think about our craft: https://github.com/gvwilson 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/ 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.