Not all software advice is created equal. Some advice is practical. It tells you exactly what to do:
Write small functions.
Keep functions focuse...
For further actions, you may consider blocking this person and/or reporting abuse
Great article Remo! What I learn overtime is that it is easy to follow rules early on, but you have to be flexible as much as possible. When people just start to learn best practices, it's easy to apply because the things they are doing is relatively straightforward. Though as more experience gained, it tends to be complicated like the duplication example you mentioned.
Sometimes, you fall off the rails but as long as you stay near the rails, then you are fine :)
Yes. As you gain experience, it’s a lot like playing chess. You start thinking several moves ahead, weighing all the parallel trade-offs before choosing the best path forward.
Great post
Thank you!
This one:
"Don't reinvent the wheel!"
In production, it makes sense, but while learning if we don't start from scratch, then we can't even make a linked list on our own!
Great piece. I agree that practical advice scales because it’s teachable and verifiable, while judgment-based advice is harder to transfer and often more valuable. In the AI era, the real challenge is making that tacit judgment explicit enough for AI to consume—not as rigid rules, but as decision records, boundary conditions, counterexamples, evaluation sets, and context packs.
But I’d add a crucial division of labor: humans should focus on business clarification, domain decomposition, module boundaries, contracts, data ownership, and risk. Inside a module, whether to duplicate or abstract can largely be delegated to AI, as long as boundaries are hard and contracts are testable. Otherwise internal details leak and become architecture problems.
So humans stay on the loop (goals, constraints, accountability), in the seams (conflicts, interfaces, organizational gaps), and at the edge (taste, ethics, irreversible decisions). AI handles implementation; humans own boundaries and intent.
To answer the author’s question: the most pointless practical advice is any one-size-fits-all rule like “functions must be under X lines.” The most valuable judgment-based advice I’ve learned is “the wrong abstraction is more costly than duplication”—and its corollary: make the boundary clear first, then let the inside evolve.
Great article! Sometimes a little duplication is better than forcing things into the same structure too early. I’d rather wait until the pattern is clear than spend more time undoing a premature refactor.
this may be offtopic but there's a point where advice or argument stops being advice or argument and starts being dogma. take goto for example. simple primitive. easy to use correctly, easy to use abusively. dijkstra said "a case against the goto statement". nikolas made it "go to statement considered harmful". now it's a dogma. and now everyone calls it evil.
It is not off-topic at all; you are on point. I think treating advice like dogma is a big problem, but it is an even bigger problem when it is in the context of judgment-based advice. As the name implies, it requires judgment, and dogmatic thinking is the opposite of that!
basically exactly what i'm saying. that advice to dogma problem is now why everyone hates goto
Good one :)
I remember my first programming teacher ever; pretty much for every question we shouted to him, he would start answering with "It depends..." We never got "an easy" advice from him, and the more I look back to hsi approach, the more I make more sense of it.
That Scrum comparison makes a lot of sense. Teams love Scrum because you can schedule 15-minute standups, move Jira tickets, and pretend you're agile without changing how anyone actually works.
Linters and Clean Code checklists are the same thing. They're popular because you can enforce them in a PR without having to think about actual system design.
In a single word, constraint. How many developers does it take to screw in a lightbulb? 1 to do, 1 to write the tests? Wrong, it's a hardware problem.
We tend to overreach as developers, we're told 'implement x' and we see y is broken, but we depend on y, so we just patch it? Did you consider all the dependencies of y, before you changed it? How sure are you? That's where we've all been and where we've all failed.
Restraint is the lesson of a 'mature' developer (I'm immature)... Learning how to stick to task EXPLICITLY, is even more difficult now, when every AI you use is screaming at you 'but this needs fixing', 'please can I just fix it quick, PLEASE!!!!'. Ok exaggerating, but you've all seen it? AI either just fixes it for you, tells you afterwards, or it keeps telling you to fix it?
If you've been there, then you're like me, when you build a puzzle, you finish it, you dont just build the picture and leave the last 3 tiles out (because you know where they go). That's great in every scenario in life, EXCEPT development. Document it and leave it alone.
That's why we have issues, create one and backtrack when you're done, or raise it in the slack channel and get clearance first. If you get clearance, trace the dependencies and write tests to make sure there's no regression. Restraint isnt leaving it alone, it's taking your time to do it right, when the time is right.
So learn restraint. You dont need 50 tests for a single method and if you're asked to add a button, just add a button, dont overengineer it. You can always add to it later, but if you overengineer from the start, it's way more dangerous removing it, because you need to strip the docs, strip the tests, strip the code and fix compilation, JUST to backtrack it. Vs document and get clearance, do it incrementally as approved, so you isolate your fixes and dont pollute your worktree with bits and bobs.
I had to correct myself earlier on that 1. I got a hiring task, simple thing, 'create a POC of an abstract filesystem', HIGHLY restricted on the implementation requirements, specifically to catch overengineering. The purpose being that you write a POC, as fast and simple as possible, then expand on it as deemed worth it. It's easier to increment, than backtrack. The exercise is meant to weed out people who'd waste time. If I take 5 hours to complete it, they dont want half of it, it takes me 2 hours to backtrack. That's 7 hours, for 3 hours of work. So it's not just a skill you learn over time, it's 1 you need to actively enforce, especially with AI, because it's far too easy to ask 'what else can be made better' and expand, because the basic POC is 'too easy'.
So next time you implement something, ask yourself, did you keep it simple stupid (KISS)? Or did you overengineer it, making it more difficult to append and more fragile to maintain? Can you justify every single addition? Can you say with utmost confidence that without these additions, that it wouldnt meet the requirement?
Good one, Remo. I’ve always found the annoying software lessons are the ones that don't have a yes/no answer. They usually end up being the ones I remember.