10 ms·
They also tend to need objectively measured skills more than knowledge workers. We know what a good batting looks like but we still can’t say what good code is
by kasey_junk 2y ago
They also tend to need objectively measured skills more than knowledge workers. We know what a good batting looks like but we still can’t say what good code is in any reasonably objective way.
- wryoak 2y agoSince code is primarily for communication between humans, I suppose we should look to the humanities and ask them what good writing is, but therein lay a parallel exercise to one suggested in the article.
- zdragnar 2y agoWell written code in one language looks nothing like good code in a different family. They won't even share a similar syntax, grammar or idioms. The only real lesson to be learned is "write for your audience" in my humble opinion.
- wryoak 2y agoA good analogy for how good prose looks different in different languages, to different cultures or professions, etc.
- bluepizza 2y agoCode is primarily for execution. It is very important that it also communicates to people, for the sake of the business that the code supports, but the main thing is the execution.
- Gorath 2y agoNot intended to be pedantic or contrarian, but I think this falls apart when the code is making sure a signal is sent somewhere (aka communication). If I write a module that allows IPC am I focusing on execution or communication? I understand one can say they were “executing the communication” but at that point we ought to remove execute from the phrase if it has to preface anything you do. To fully disprove my point, at what point do we never execute something with code so the distinction is even worth mentioning?
- bluepizza 2y agoOP talks about asking humans what good code looks like, and that's the scope of my response. Code as a communication tool between developers is not its primary reason to exist.
- wryoak 2y agoThen why do we keep code after it has been compiled to a functional executable? Why do we (those of us working on teams) have rules limiting how code is written, or even in what language? Why do we study abstraction strategies like OOP and FP? Codifying and then storing a solution is not a necessity essential to a solution, it’s a necessity satisfying an external pressure. My conjecture is that that external pressure is the authors’ need to transmit solutions across time (eg to oneself when it stops running for w/e reason) and space (eg to collaborators), so the solution can be read and understood, revised and extended, in the same way we transmit other ideas in natural language prose or other symbolic systems. If we want to treat this outside of the humanities, we need to abandon high level languages like bash and C and return to manipulating registers and memory directly.
- bluepizza 2y agoBecause we need to change it on a regular basis. We usually only ship binaries - literally what you described.
- Dove 2y agoI say this often. Code is for people, and the qualities of great code parallel those of great writing: clarity, efficiency, and a sort of profound obviousness and inevitability. The job of software architects is the role Heidegger ascribes to man when he calls us "shepherds of Being". To understand the world as it is, and find the right abstractions to describe it. To constantly evolve those abstractions toward better ones, clearer ones, to seek out ways to represent things that make solutions seem obvious and inevitable. A mathematics professor once said to me that as time went by, the definitions in mathematics became more complex while the theorems became simpler. "Why is that?", I asked, and he replied, "It's progress!" This is the sort of progress that the software architect seeks as well: to set up the problem so excellently that the solutions are smooth and the process is enlightening. Great writing, and great code, are first and foremost about great ideas. About brilliant ideas that change how you view the world for the better.
- dbtablesorrows 2y agoNo. It needs to be treated as engineering if we want any stability and maturity in this field. Humanities are too subjective.
- austin-cheney 2y agoSure we do. * execution performance time * build time * regression frequency * defect quantity * code size * dependency quantity * test automation coverage * test automation execution duration The problem isn’t that we don’t know. The problem is that developers don’t measure things and simultaneously bitch about strong opinions.
- TimTheTinker 2y agoAt the same time, those criteria are very context-dependent. Thus, great developers are usually only identified as such because of how they perform relatively to others working under a similar context--not because of the above criteria in any universal or objective sense.
- deleted 2y ago[deleted]
- michaelt 2y agoLynx is a lean, efficient, fast-to-compile, low-dependency browser - and has the fewest open defect reports of any major browser. I'm not sure the metrics you propose capture what makes good software good.
- tjr 2y agoWould you say that Lynx is not good software?
- shiroiushi 2y agoAbsolutely: "good software" has to be useful for its intended purpose. Lynx may be well-written, but it's useless if you want to do most things on the modern web: it just isn't capable of doing them. If you want to use a web browser to, for instance, use your bank's web interface, a buggy browser that can do this is infinitely more useful than a non-buggy browser that simply doesn't have the technical capacity to do so.
- 2y ago