3 ms·
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 aste
by 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 agoI 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 agoThat is a helpful comparison. I guess it is risk aversion at the core. At some point risk aversion becomes abdication of decision making to others, which seems broken in roles that are specifically hired for making decisions, but that’s even more true of executives.
- runevault 2y agoI completely agree with you, mind I feel the same way about the people who the original comment was talking about. They are paid the big bucks to decide how to spend money to optimize the company.
- OnionBlender 2y agoWhich book are you referring to? The parent comment mentioned two books.
- ziml77 2y agoClean Code
- WalterBright 2y ago1. 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
- Cthulhu_ 2y agoThere'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)