Found this good list while browsing the internet as the ‘Subtle Rules of Software Engineering’. These kinds of lists float around often, but this one felt especially thoughtful and more practical.
- You WILL regret complexity when on-call
- Stop falling in love with your own code
- Every single thing is a trade-off – no “best”
- Every line of code you wrote is a liability
- Document your designs and decisions
- Everyone hates code they didn’t write
- Don’t use unnecessary dependencies
- Coding standards prevent arguments
- Write meaningful commit descriptions
- Never ever stop learning new things
- Code reviews are to spread context
- Always build for maintainability
- Always ask for help when stuck
- Fix root causes, not symptoms
- Software is never finished
- Estimates are not promises
- Ship early, iterate often
- Keep. It. Simple.
Lists like this are both inspiring and… a little maddening. The advice is good. But like most software engineering principles, they occasionally pull in different directions.
For instance: “Always build for maintainability” vs “Ship early, iterate often”
Can you always do both? Maybe not. Sometimes you’re racing to get feedback; other times you’re investing in long-term good code. Real-world engineering often is a push-pull between quality and velocity. It’s not that one rule is better—it’s about understanding the trade-off you’re making in the moment.
Now, just for fun—what if I had to upvote only 5 of these and downvote 5?
This would be mine.
Why the top 5?
1. Every single thing is a trade-off – no “best”
Because software engineering is rarely about absolutes. Understanding trade-offs helps you make pragmatic decisions. What’s “right” today might be wrong tomorrow depending on the team, scale, or product maturity.
2. Never ever stop learning new things
The field moves fast—tools, best practices, and expectations shift constantly. Staying curious is how you stay relevant and sharp.
3. Always ask for help when stuck
This is one attribute I’ve found in the best engineers I’ve worked with. They know when to ask for help and how to unblock themselves quickly. Like every other rule, there is a trade-off here and asking help too quick and too often might also land you in trouble in the long run.
4. Software is never finished
There’s always a bug to fix, a use case to support, or a refactor to make. Embracing this helps me to design for change. You’re not building monuments—you’re evolving living systems. Think milestones and basecamps. It is not about the summit all the time.
5. Ship early, iterate often
Feedback beats perfection. Getting real-world usage fast helps you build the right thing, not just a well-built wrong thing. Early shipping helps validate ideas and keeps teams grounded in user needs.
How would you order this list? Try the app here and share your list – https://sp2hari.com/software-rules/