{"id":3074,"date":"2025-05-05T00:51:04","date_gmt":"2025-05-05T00:51:04","guid":{"rendered":"https:\/\/sp2hari.com\/?p=3074"},"modified":"2025-05-05T03:35:26","modified_gmt":"2025-05-05T03:35:26","slug":"subtle-rules-of-software-engineering","status":"publish","type":"post","link":"https:\/\/sp2hari.com\/index.php\/2025\/05\/05\/subtle-rules-of-software-engineering\/","title":{"rendered":"Subtle Rules of Software Engineering"},"content":{"rendered":"\n

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. <\/p>\n\n\n\n

    \n
  1. You WILL regret complexity when on-call<\/li>\n\n\n\n
  2. Stop falling in love with your own code<\/li>\n\n\n\n
  3. Every single thing is a trade-off – no “best”<\/li>\n\n\n\n
  4. Every line of code you wrote is a liability<\/li>\n\n\n\n
  5. Document your designs and decisions<\/li>\n\n\n\n
  6. Everyone hates code they didn\u2019t write<\/li>\n\n\n\n
  7. Don’t use unnecessary dependencies<\/li>\n\n\n\n
  8. Coding standards prevent arguments<\/li>\n\n\n\n
  9. Write meaningful commit descriptions<\/li>\n\n\n\n
  10. Never ever stop learning new things<\/li>\n\n\n\n
  11. Code reviews are to spread context<\/li>\n\n\n\n
  12. Always build for maintainability<\/li>\n\n\n\n
  13. Always ask for help when stuck<\/li>\n\n\n\n
  14. Fix root causes, not symptoms<\/li>\n\n\n\n
  15. Software is never finished<\/li>\n\n\n\n
  16. Estimates are not promises<\/li>\n\n\n\n
  17. Ship early, iterate often<\/li>\n\n\n\n
  18. Keep. It. Simple.<\/li>\n<\/ol>\n\n\n\n


    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.<\/p>\n\n\n\n

    For instance: \u201cAlways build for maintainability\u201d<\/strong> vs \u201cShip early, iterate often\u201d<\/strong><\/p>\n\n\n\n

    Can you always do both? Maybe not. Sometimes you\u2019re racing to get feedback; other times you\u2019re investing in long-term good code. Real-world engineering often is a push-pull between quality and velocity. It\u2019s not that one rule is better<\/em>\u2014it\u2019s about understanding the trade-off you\u2019re making in the moment.<\/p>\n\n\n\n

    Now, just for fun\u2014what if I had to upvote only 5 of these and downvote 5?<\/p>\n\n\n\n

    This would be mine. <\/p>\n\n\n

    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    Why the top 5?<\/h3>\n\n\n\n

    1. Every single thing is a trade-off \u2013 no \u201cbest\u201d<\/strong>
    Because software engineering is rarely about absolutes. Understanding trade-offs helps you make pragmatic decisions. What\u2019s \u201cright\u201d today might be wrong tomorrow depending on the team, scale, or product maturity.<\/p>\n\n\n\n

    2. Never ever stop learning new things<\/strong>
    The field moves fast\u2014tools, best practices, and expectations shift constantly. Staying curious is how you stay relevant and sharp. <\/p>\n\n\n\n

    3. Always ask for help when stuck<\/strong>
    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.<\/p>\n\n\n\n

    4. Software is never finished<\/strong>
    There\u2019s always a bug to fix, a use case to support, or a refactor to make. Embracing this helps me to design for change. You\u2019re not building monuments\u2014you\u2019re evolving living systems. Think milestones and basecamps. It is not about the summit all the time. <\/p>\n\n\n\n

    5. Ship early, iterate often<\/strong>
    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.
    <\/p>\n\n\n\n

    How would you order this list? Try the app here and share your list – https:\/\/sp2hari.com\/software-rules\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    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. Lists like this are both inspiring and… a little maddening. The advice is good. But like most software engineering …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21],"tags":[],"class_list":["post-3074","post","type-post","status-publish","format-standard","hentry","category-tech"],"_links":{"self":[{"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/posts\/3074","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/comments?post=3074"}],"version-history":[{"count":8,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/posts\/3074\/revisions"}],"predecessor-version":[{"id":3088,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/posts\/3074\/revisions\/3088"}],"wp:attachment":[{"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/media?parent=3074"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/categories?post=3074"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sp2hari.com\/index.php\/wp-json\/wp\/v2\/tags?post=3074"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}