Just yesterday, when discussing our company's grades, someone joked that the difference between a junior and a senior developer is that a junior developer should learn to know when to use OOP/abstractions while a senior developer should learn to recognize when OOP/abstractions are to be avoided.

Used to be a similar joke in frontend a few years ago when css was at its complexity peak. Where the progression is junior: "I'll just use bootstrap", mid: "I'll write my own css custom tailored to the project", senior: "I'll just use bootstrap."

I also think some of this... attitude? learning? is what go is trying to activate/take advantage of. Everywhere I've worked has had some monstrously experienced senior dev who could easily crack out a solution to a problem of any difficulty but who refuses to use any abstraction more sophisticated than a for loop.

Go says you don't need anything more sophisticated than a for loop, in fact you can't have anything more sophisticated than a for loop. I guess I'm not there yet but it definitely seems suspicious that the people I know who are most into go are very early in their careers or deeply experienced.

I agree, but I would extend it a bit:

For a junior the answer is more "I'll just use bootstrap and customize as much as needed".

While for a senior it's more in line with "I'll just use bootstrap, but you bet I will be on the designer's ass if they ask to customize stuff where it's not necessary."

There is a reason the mid-level developer wanted to write custom CSS. And the reason is that they didn't have the political capital to make bootstrap alone work in a way that is good for the company.

Uncle Bob,the eternal noob of programming.

Which isn't a bad thing when you write books for noobs, writing resonates more with you when it comes from one of your own.

As an old-timer it is easy to forget that we all started as beginners and had to learn all the things which now are second nature to us. At some point the material which is valuable to a beginner seems trite, obvious and simplistic to a senior.

This begs the question: what do you recommend instead?

"Code Complete" by Steve McConnell and "A Philosopy of Software Design" by John Ousterhout.

I second this about Code Complete. (Also I think it's at its 2nd edition, maybe 3rd?)

It's more up to the point instead of going into dogmatic diatribe

It's more evidence based (giving examples, etc)

Go for this one and Bob's your uncle! (or maybe it stops being your uncle, I guess)

> "A Philosopy of Software Design"

What a great book. I second this and add my own "The Pragmatic Programmer: 20th anniversary edition"

"Structure and interpretation of computer programs", its not exactly in the same category but IMO is far better. At least it doesn't make you write tones of one line,single time used functions with 400 character length name.

Code complete, Steve McConnell

"The pragmatic Programmer" is one I would recommend.

That, and "Team Geek", in term of relationship with codes and teammates.

The pragmatic programmer is really keen on code generators. Which is the right thing to do. It's also very difficult to do in practice as the languages that are sufficiently impoverished to need external code generators are invariably bound to build tools that can't sanely deal with them.

edit: oh, and also it's hard to avoid people checking in and/or editing the generated code

Not the OP but HTDPv2 is a solid recommendation here

I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym.

For those wondering, "How to Design Programs"

Yeah fair comment. I guess i’ve fallen into that familiarity trap.

I also enjoyed the Hitchhiker's Tips for Deeper Pockets (v2).

Programming practice

I am not fond of Clean Code, but I am fond of Clean Architecture. It's a much smaller set of ideas, for a start.

I gave up on Clean Architecture after about one chapter. There's a section where he's graphing the number of lines of code in a hypothetical company's codebase over time - it grows rapidly at first and then it levels off, and he points at this like it means anything, specifically like it's a bad thing and it means the software has become difficult to work in. Also this isn't a line chart, it's a bar chart, and the X axis isn't time, it's unlabeled - eventually, in the text, you find that there's one bar per major release of the software, if that tells you anything about how retro this conception of software development is. Another bar chart shows the number of developers growing rapidly, as if that means anything either... It was just baffling.

I personally find that those two videos are much better at conveying the foundational knowledge needed to invent and understand something like Clean Architecture than the book itself:

https://www.destroyallsoftware.com/screencasts/catalog/funct...

https://www.destroyallsoftware.com/talks/boundaries

It seems unrelated in the surface, but I feel like they explain the "why" of a software architecture in a much simpler way and without the prescriptive and hand-wavy "trust me" nature of most software architecture books.