I really like this book on the basis of the philosophy overall, no this doesn’t solve all problems but it’s a good baseline of “guidelines/rules” to program by. Good metrics or goals to architect and design software projects high and low level projects.

Fight Software Rot
Avoid duplicate code
Write Flexible, dynamic, adaptable code
Not cargo cult programming and programming by coincidence.
Make robust code, contracts/asserts/exceptions
Test, Test, and TEST again and Continue testing.. this is a big one.. not so much meaning TDD.. but just testing in general never stop trying to break your software.. FIND the bugs.. you should want to find your bugs. Even after releasing code the field continue testing.

1) Learning little to nothing useful in formal post-secondary and wasting tons of time and money just to have pain and suffering.

"Let's talk about hardware disc sectors divisions in the database course, rather than most of you might find useful for industry."

"Lemme grade based on regurgitating my exact definitions of things, later I'll talk about historical failed network protocols, that have little to no relevance/importance because they fucking lost and we don't use them. Practical networking information? Nah."

"Back in the day we used to put a cup of water on top of our desktops, and if it started to shake a lot that's how you'd know your operating system was working real hard and 'thrashing' "

"Is like differentiation but is like cat looking at crystal ball"

"Not all husbands beat their wives, but statistically...." (this one was confusing and awkward to the point that the memory is mostly dropped)

Streams & lambdas in java, were a few slides in a powerpoint & not really tested. Turns out industry loves 'em.

2) Landed my first student job and get shoved on an old legacy project nobody wants to touch. Am isolated and not being taught or helped much, do poorly. Boss gets pissed at me and is unpleasant to work with and get help from. Gets to the point where I start to wonder if he starts to try and create a show of how much of a nuisance I am. He meddle with some logo I'm fixing, getting fussy about individual pixels and shades, and makes a big deal of knowing how to use GIMP and how he's sitting with me micromanaging. Monthly one on one's were uncomfortable and had him metaphorically jerking off about his lifestory career wise.

But I think I learned in code monkey industry, you gotta be capable of learning and making things happen with effectively no help at all. It's hard as fuck though.

3) Everytime I meet an asshole who knows more and accomplish than I do (that's a lot of people) with higher TC than me (also a lot of people). I despair as I realize I might sound like that without realizing it.

4) Everytime I encounter one of my glaring gaps in my knowledge and I'm ashamed of the fact I have plenty of them. Cargo cult programming.

5) I can't do leetcode hards. Sometimes I suck at white board questions I haven't seen anything like before and anything similar to them before.

6) I also suck at some of the trivia questions in interviews. (Gosh I think I'd look that up in a search engine)

7) Mentorship is nigh non-existent. Gosh I'd love to be taught stuff so I'd know how to make technical design/architecture decisions and knowing tradeoffs between tech stack. So I can go beyond being a codemonkey.

8) Gave up and took an ok job outside of America rather than continuing to grind then try to interview into a high tier American company. Doubtful I'd ever manage to break in now, and TC would be sweet but am unsure if the rest would work out.

9) Assholes and trolls on stackoverflow, it's quite hard to ask questions sometimes it feels and now get closed, marked as dupe, or downvoted without explanation.

Cargo cult programming at its finest. I need to build a separate project twice, and restart visual studio to get this one to work.

Why? No one knows anymore and there is not user story for "Unfuck the dev environment" so we're not allowed to spend time fixing it.

When a senior developer insists on using `Class.forName("foo.Bar")` instead of `new Bar()`, because she "saw it being used that way by her professor", but doesn't recall the context in which he did that, then you know what "Cargo Cult Programming" is all about.

I hate this crap and wish people would stop doing it. It makes my brain bleed and doesn't prevent any difficult to find bugs.

if (TERMINAL_COUNT <= index_thing)

English doesn't work that way, and I don't know about you but this crap is just awkward as hell. Sweet Jesus I wish there was less cargo cult programming in the world. Just because you saw something in a blog that convinced you that reverse comparisons is best doesn't mean it actually is. Use a damn static analysis tool to catch accidental assignments in expressions, don't twist my brain to interpret your weird phrasing of comparison operators. Some of your code reviewers may be dyslexic and have enough problems as it is.

And now for the mini-rant that I'm actually here for: You know what makes for difficult to find bugs? (Hint: It sure as hell isn't an assignment in an expression) Releasing an RTEMS semaphore you've never obtained. You'd think that would cause some kind of panic or assert failure but nope. Instead it causes... misaligned address exceptions? In statically allocated global memory? WTF??