{"id":3742,"date":"2024-11-27T14:50:30","date_gmt":"2024-11-27T06:50:30","guid":{"rendered":"https:\/\/tzlee.com\/blog\/?p=3742"},"modified":"2024-11-27T14:50:30","modified_gmt":"2024-11-27T06:50:30","slug":"what-is-good-code","status":"publish","type":"post","link":"https:\/\/tzlee.com\/blog\/2024\/11\/what-is-good-code\/","title":{"rendered":"What is Good Code?"},"content":{"rendered":"\n<p>Many junior to mid-level engineers have misconceptions about what \u201cgood code\u201d truly mean. Unfortunately, these misunderstandings are often reinforced by flawed hiring practices. LeetCode problems, parroting SOLID principles, or memorizing framework features might showcase technical knowledge, but they don\u2019t inherently make someone a good Software Engineer.<\/p>\n\n\n\n<p><strong>Mess is Everywhere<\/strong><\/p>\n\n\n\n<p>Throughout my career, I\u2019ve encountered my fair share of messy codebases. An example would be functions\/methods that stretched over a thousand lines of business logic\u2014an unmaintainable monstrosity. Such code is a hallmark of inexperienced teams and often plagues poorly managed software outsourcing projects. I\u2019ve probably written my share of such code when younger too.<\/p>\n\n\n\n<p>Seasoned engineers would say that this is <em>\u201ccommon.\u201d<\/em> Even at tech giants like Google or Microsoft, codebases aren\u2019t pristine. Messes are inevitable, and documentation can also be inconsistent.<\/p>\n\n\n\n<p>Still, there\u2019s a difference between an unavoidable mess and a completely avoidable disaster.<\/p>\n\n\n\n<p><strong>If It Ain\u2019t Broke, Don\u2019t Touch It?<\/strong><\/p>\n\n\n\n<p>A few years ago, I was troubleshooting a particularly stubborn issue with another team. The tech lead said that adding more code to an already bloated, thousand-line controller method was risky. He wasn\u2019t wrong\u2014it could take days to figure out where to make even minor changes, and the risk of breaking something was high. To add to the problem, the codebase did not have unit tests.<\/p>\n\n\n\n<p>But what happened next left me speechless.<\/p>\n\n\n\n<p><strong>The Undocumented, Untraceable Code<\/strong><\/p>\n\n\n\n<p>The tech lead decided to \u201csolve\u201d the issue by writing a standalone PHP script, completely outside the Laravel framework we were using. His justification? Frameworks were \u201ctoo slow\u201d and \u201ctoo complicated.\u201d<\/p>\n\n\n\n<p>His script lived in some random folder on the server, undocumented and untracked. Hours of debugging later, we stumbled upon it by sheer luck. And it wasn\u2019t a one-off\u2014we later found there were <em>several<\/em> such scripts scattered across the server, mostly undocumented and introducing untraceable logic into production.<\/p>\n\n\n\n<p>At that point, nobody cared about the quality of his algorithms (they were terrible, by the way) or whether his code followed SOLID principles (it didn\u2019t). The real issue was far worse: he prioritized personal convenience over team collaboration. His decisions created a codebase that was not only a nightmare to maintain but also actively sabotaged the team\u2019s ability to function effectively.<\/p>\n\n\n\n<p><strong>Coding Beyond Yourself<\/strong><\/p>\n\n\n\n<p>As software engineers, we don\u2019t work in silos. Writing code that you alone can understand is easy. Writing code that a hundred others can maintain? That\u2019s the real challenge.<\/p>\n\n\n\n<p>The example above is a cautionary tale of what <em>not<\/em> to do. Good engineering isn\u2019t about showing off your technical prowess; it\u2019s about making thoughtful decisions that benefit the team, ensure long-term maintainability, and foster a culture of collaboration.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Many junior to mid-level engineers have misconceptions about what \u201cgood code\u201d truly mean. Unfortunately, these misunderstandings are often reinforced by flawed hiring practices. LeetCode problems, parroting SOLID principles, or memorizing framework features might showcase technical knowledge, but they don\u2019t inherently&#8230; <a class=\"more-link\" href=\"https:\/\/tzlee.com\/blog\/2024\/11\/what-is-good-code\/\">Continue Reading &rarr;<\/a><\/p>\n","protected":false},"author":2,"featured_media":3743,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[8],"tags":[547],"class_list":["post-3742","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tech","tag-programming"],"jetpack_featured_media_url":"https:\/\/tzlee.com\/blog\/wp-content\/uploads\/2024\/11\/pexels-yew-hui-tan-16348509-scaled.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/posts\/3742","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/comments?post=3742"}],"version-history":[{"count":1,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/posts\/3742\/revisions"}],"predecessor-version":[{"id":3744,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/posts\/3742\/revisions\/3744"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/media\/3743"}],"wp:attachment":[{"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/media?parent=3742"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/categories?post=3742"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tzlee.com\/blog\/wp-json\/wp\/v2\/tags?post=3742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}