[{"data":1,"prerenderedAt":52},["ShallowReactive",2],{"$f1gzi4yf9h7xz8":3,"recommended":21},{"title":4,"path":5,"date":6,"updated":7,"tags":8,"excerpt":10,"readingMinutes":11,"commentCount":12,"html":13,"comments":14,"next":15,"prev":18},"Code Should be Readable","\u002F2018\u002F10\u002Fcode-should-be-readable\u002F","2018-10-07T21:54:00.000Z","2019-05-11T10:04:55.472Z",[9],"programming","On the first day of my first job, at age 23, I learned the most important lesson of my life about programming: code should be readable . Four years of CS at university did not prepare me for this, but one day of work did…",2,0,"\u003Cp>On the first day of my first job, at age 23, I learned the most important lesson of my life about programming: \u003Cstrong>code should be readable\u003C\u002Fstrong>. Four years of CS at university did not prepare me for this, but one day of work did (thanks Achiel!).\u003C\u002Fp>\n\u003Cp>I had created something "clever" and was barked at by the Senior Engineer of the team that my solution was too complicated. For a second I thought he was suffering from low IQ, but he explained that:\u003C\u002Fp>\n\u003Col>\n\u003Cli>He was not able to \u003Cem>instantly\u003C\u002Fem> understand my code. \u003Cem>Lesson\u003C\u002Fem>: It was apparently \u003Cstrong>vital\u003C\u002Fstrong> that other people in the team understood \u003Cstrong>my\u003C\u002Fstrong> code. In fact, it was not even my code, \u003Cstrong>the team owned it\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003Cli>The problem I was solving was simple and not worth spending much mental capacity on. \u003Cem>Lesson\u003C\u002Fem>: \u003Cstrong>writing code is just a small part\u003C\u002Fstrong> of what happens with it, code is much more frequently read, tested, debugged and refactored. All these activities take time and mental capacity.\u003C\u002Fli>\n\u003Cli>In 6 months, I would have forgotten the code and would look at it the same way he did now (that is: with a frown and raised eyebrows). \u003Cem>Lesson\u003C\u002Fem>: \u003Cstrong>You are temporarily suffering from understanding the code too well\u003C\u002Fstrong>, make sure you compensate for that.\u003C\u002Fli>\n\u003Cli>We were paid (quite well) to make product for the company, not to be smart-asses. \u003Cem>Lesson\u003C\u002Fem>: \u003Cstrong>time is money\u003C\u002Fstrong> and there is something called \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOpportunity_cost\">Opportunity Cost\u003C\u002Fa> that makes your time even more valuable. \u003Cstrong>Boring code is good code.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>These lessons have stuck with me forever and made me allergic to complicated code. Of course sometimes problems really are complex, and there is big difference between "essential complexity" and "merely complicated". Senior Software Engineers should have a well-developed gut feeling to distinguish between the two.\u003C\u002Fp>\n\u003Cp>I don't care much for fanatic discussions about \u003Cstrong>Test Driven Development\u003C\u002Fstrong> or \u003Cstrong>Micro Services vs. Monoliths\u003C\u002Fstrong> because reality is much less clear-cut. I think it's \u003Cstrong>MUCH\u003C\u002Fstrong> more important that whenever you create software, or basically anything*, that you keep this in mind:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>the complexity of the solution should match the complexity of the problem\u003C\u002Fli>\n\u003Cli>what you create should be easy to understand for those who work with it\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>As long as you build your software by these two rules, \u003Cstrong>you should be alright.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>* read \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FThe_Design_of_Everyday_Things\">The Design of Everyday things\u003C\u002Fa> by Don Norman and \u003Ca href=\"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDon%27t_Make_Me_Think\">Don't Make me Think\u003C\u002Fa> by Steve Krug\u003C\u002Fp>\n",[],{"title":16,"path":17},"Highly Productive Teams and their Speed Bumps","\u002F2019\u002F01\u002Fhighly-productive-teams-and-their-speed\u002F",{"title":19,"path":20},"Necessary Evil","\u002F2018\u002F10\u002Fnecessary-evil\u002F",[22,27,32,35,39,42,45,49],{"title":23,"path":24,"note":25,"series":26},"Mapping out Dark Code","\u002F2026\u002F03\u002Fmapping-out-dark-code\u002F","2026",false,{"title":28,"path":29,"note":30,"series":31},"The software that I love","\u002F2022\u002F10\u002Fthe-software-that-i-love\u002F","Series · 36 posts",true,{"title":33,"path":34,"note":25,"series":26},"Navigating the Fog of War: Age of Empires, AI Agents, and the Rise of Dark Code","\u002F2026\u002F05\u002Fnavigating-fog-of-war-age-of-empires-ai\u002F",{"title":36,"path":37,"note":38,"series":26},"The Future of Programming Systems - four thoughts","\u002F2024\u002F09\u002Fthe-future-of-programming-systems-four\u002F","2024",{"title":40,"path":41,"note":38,"series":26},"Always Optimize the Feedback Loop","\u002F2024\u002F07\u002Falways-optimize-feedback-loop\u002F",{"title":43,"path":44,"note":38,"series":26},"\"Security Is Our Top Priority\" is BS","\u002F2024\u002F07\u002Fsecurity-is-our-top-priority-is-bs\u002F",{"title":46,"path":47,"note":48,"series":26},"10x teams","\u002F2025\u002F02\u002F10x-teams\u002F","2025",{"title":50,"path":51,"note":48,"series":26},"Hiring, from the Other Side","\u002F2025\u002F10\u002Fhiring-from-other-side\u002F",1792876809092]