This advice boils down to "write good code." Unfortunately, practical advice that goes beyond that is really hard.<p>Software engineering is hard because everything is a trade off! Should I add another layer of abstraction or just add another optional parameter? Should I add flexibility for future requirements or simplify the code so it's obvious to a junior programmer?<p>The answer to almost every question is, "It depends!"<p>What are the skills of the dev team? How much time do you have? Do you already have a lot of tech debt? Are you building a prototype or a safety-critical system?<p>Worse, many answers depend on unknowable facts: How will requirements change in the future? Will we ever need this functionality? Did we bet on the right ecosystem?<p>The best software engineers can balance all these questions, even the ones they don't have answers to, and come up with a design that works. The fact that we, as an industry, can build multi-million-line programs is a minor miracle. The wonder isn't that so many projects fail but that any succeed.<p>If anyone were to ask me for advice--which I notice they're not--I would just say two things:<p>1. Write lots of programs.<p>2. Work with good software engineers.
Write boring code. Dumb code - that's too much, no need for. Boring is just right. Steve Maguire's "Writing Solid Code" is the rare book that is both practical and abstract in the right amounts. With time passing, it looks to me that boring, obvious is close enough to solid.
Code that is hard to understand at first is fine; but once you do, it should make you think "wow, that's it?" and not "I can think of a simpler way to do this."<p>The counterpoint to dumbing down has been called "Kernighan's lever": <a href="https://www.linusakesson.net/programming/kernighans-lever/index.php" rel="nofollow">https://www.linusakesson.net/programming/kernighans-lever/in...</a><p><i>but I noticed that the interns were having trouble with it</i><p>That's their problem. The less they're incentivised to learn and grow, the less they will; and once they no longer consider themselves beginners, they will know less than those who came before. The vicious cycle continues.<p>It's worth noting that software development is an aberration; literally no other profession I know of has come to widely espouse the belief that beginners should be encouraged to remain stupid and unlearning while everyone else stoops to their level.
I think it is better to have a little "smarter" code if that means you will not bring a dependency. For example in Python or C I like things that do not need anything except the standard library. When you need to think about PIP or compilation of another library it is more code shifted to things that usually suck (like build systems) or you lose control and when something breaks you are still to blame. Sometimes it means to use something that is a bit more complex in comparison to using some nice libraries. Maybe the thing is that the library is not a dumb code anymore?
> We should not seek to build software. Software is the currency that we pay to solve problems, which is our actual goal. We should endeavor to build as little software as possible to solve our problems.<p><i>Slow clap</i>
Discussed at the time:<p><i>Write dumb code</i> - <a href="https://news.ycombinator.com/item?id=16257270">https://news.ycombinator.com/item?id=16257270</a> - Jan 2018 (66 comments)
There are too many articles that preach dumb code, KISS, etc. I think the issue is overemphasized, especially in the modern age of bootcamps and whatnot. Who is writing all that "smart code" people are complaining about? If code seems too smart for you, maybe PEBCAK. That seems far more realistic nowadays than ever before.<p>> Look! I replaced this recursive function with a for loop and it still does everything that we need it to. I know it’s not as clever, but I noticed that the interns were having trouble with it and I thought that this change might help.<p>Recursion is not clever, it is not a trick. It's a basic technique kids learn in high school in Advanced Placement CompSci A. I <i>do not</i> want to work with people who know less about their professional field of choice compared to kids. And if the educational system has failed interns, at least let them learn what recursion is on the job! Isn't that what internship is for anyway?<p>Honestly, I don't even get the sentiment. Many problems are naturally formulated in terms of recursion. And rewriting them as loops would be considered an optimization technique that obfuscates the reasoning.
Imagine if engineers at Intel were told: design circuits that an electronics novice can understand!<p>Sometimes, the novice doesn't understand the problem that the code is solving, no matter how the code is written, and even if it is documented in detail.<p>Now, sure, if people who easily understand <i>what</i> the code does have trouble seeing <i>how</i> the code does it, that could be a problem. Especially if the code uses a paradigm that they already understand.<p>If code solves a problem they understand, but with some unfamiliar paradigm like logic programming or functional programming, that's their problem, though.<p>"Don't use logic programming or functional programming because some novices don't understand it" isn't very good general advice. In situations where it makes sense, it's not about the quality of the code but about programmers being easily replaceable with novices off the street.<p>I don't see why any programmer should, as a matter of habit, write any code that can be maintained by people less knowledgeable or skilled than he or she. Unless it's stipulated as a contractual requirement. In whose interest is that, anyway?
I guess every adjective we put in front of code will create an endless stream of opinions.<p>I had comments in PRs where I should replace `str1 + str1` with `''.join([str1, str2])` (Python) because it's more "clean".<p>So I judge my code and others code whether it works or not. Works in the sense that it's correct but also in the sense that I can maintain it in the long run. That's it. It's kind of hard to get used to this and keep opinions to yourself though.
The easiest way to explain dumb code is that there’s a brain budget, and reading someone else’s code is 2x harder than writing code. Therefore, writing dumb code means: make sure the code you write never exceeds the budget when it needs to be read.<p>Also the brain budget is very low because you often have a wide mix of talent working on the same stuff. It’s that simple.
There are metrics for complexity that nobody who writes these articles ever mentions: Halstead complexity [1], LCOM4 [2], cyclomatic complexity [3] (and others) that directly measure how complex a given piece of code is.<p>Halstead complexity measures the complexity of the "vocabulary" of code and the code "size". It uses the number of unique terms (arguments, variables), the number of unique operations (functions/methods/symbolic operators), and the total number of terms and operators to calculate difficulty and effort to produce. Lower is better. Obviously, more things and aliases and combinations of things are harder to understand than fewer things.<p>LCOM4 measures how many different responsibilities a module of code has. It measures whether or not two things in a module belong together by treating the code as a graph of nodes and counting the unique connected components in the graph. Greater than 2 means there is too much going on in the module, and it should be split to enhance understanding and reduce churn during maintenance. Obviously, if you are reading parts of the code that end up being irrelevant to the task at hand, you are going to be slower to accomplish whatever you are trying to accomplish.<p>Cyclomatic complexity measures how many execution paths there are in a given piece of code. Obviously, the fewer the better.<p>There are others - the counting complexity of the number of possible inhabitants of a given interface is a favorite of mine as well (is your interface a product, or a sum? Do you need strings or will an enum work? Do you need Long or can you get away with something smaller like Short or Int? Sum interfaces are smaller than product interfaces, and smaller ranged sum types - Short/int vs. Long - are better than larger ones because they reduce the number of possible satisfying implementations of the interface).<p>But the point is that all good simplicity metrics are static analysis metrics that are quantitative and not qualitative. Most are automated checks that can be performed given an abstract syntax tree of a program.<p>1. <a href="https://en.wikipedia.org/wiki/Halstead_complexity_measures" rel="nofollow">https://en.wikipedia.org/wiki/Halstead_complexity_measures</a>
2. <a href="https://www.researchgate.net/publication/238729882_Measuring_coupling_and_cohesion_in_object-oriented_systems" rel="nofollow">https://www.researchgate.net/publication/238729882_Measuring...</a>
3. <a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity" rel="nofollow">https://en.wikipedia.org/wiki/Cyclomatic_complexity</a>
Blog posts like this have noble intentions but since they often lack real world examples and actual code, I don't find them very useful. Everyone has a different interpretation of what constitutes dumb or simple code. In fact, the absence of concrete, unambiguous, actionable advice is something I always found fascinating about software engineering.<p>My background is in medicine where it's much more common to follow flow charts, go through check lists and administer first line treatment that's based on empirical evidence.<p>I understand that this is very hard to implement in software, but the almost complete absence of it means that every project is more or less unique. Sure, if you zoom out far enough then a lot of back ends boil down to "get data from DB apply to template" but it can still be surprisingly challenging to take your knowledge from one such system and apply them to the next.
Let me quote the very first words of the article:<p>> Write Dumb Code<p>> The best way you can contribute to an open source project is to remove lines of code from it<p>What am I missing here? How is writing short code dumb? How could the author argue that using "smart" techniques, makes the code longer? This is not smart, this is actually dumb. Maybe the author should put the "Dumb" in quotes, as a critique of techniques that are praised as smart but actually are worse than the common "dumb" techniques. The linked-lists might be a good example of over-engineered solutions that usually are worse than a simple vector (array).<p>But no, the author clearly means code readability. WHY ON EARTH would you even consider using some kind of advanced syntax or pattern if it was longer? Typically such are used to shorten code, like various meta-programming techniques (macros, reflections, metaclasses, you name it) or patterns like iterators, abstractions, match expressions etc.<p>Why would the HN crowd dig up a low quality article like this?<p>Oh, one more thing, code could be longer but smarter because it's performing better. But I don't think that's what the author meant, if he did, I imagine a lot of us would disagree.
This should extend to dumb (boring) tech stack/architecture. Not sure what it is that makes people choose some crazy complex tech to implement systems used internally by a few hundred people. Scalability? Really!? UI that in no way needs to be reactive using React or Angular? Oh, and we need a workflow engine. And we are moving to the cloud, so rather than some simple flask built api, learn and deal with FaaS stuff. And then good luck deploying updates. Crazy.
Lines of code is a poor metric, as usual. You can easily have multiple transformations in one line, or write expressions with a dozen nodes without intermediates, like a mathematician. Perhaps you believe this makes code more readable. When you run that code in a debugger (the one true way to understand any program) that will come back to haunt you.
That's a neat idea. Do something simple, easy to understand. Can't go wrong, right? No chance of complexity sneaking in all sorts of ways.<p>I wonder if someone had this idea before.
Could we use LLMs to give a readability score to codes?<p>If a dumb LLM can understand a piece of code, then maybe that's one way to check if it's a sensible code.
while i agree that simple is better than complex, there is no absolute measurement nor definition for what simple is. and typically complex structures/foundations are what we build simple on top of. if our medium of expression isn’t already complex enough, we risk accidental complexity.<p>compare:<p><i>sapienti pauca</i>, a compact latin sentence which takes advantage of the complexity of latin grammar to say what may be translated into english as ‘a word to the wise is enough.’ there’s some poetic beauty in the latin sentence that adds to the force of the advice (it’s only two words after all). i don’t think we should avoid pithy expressions where the celebrate wonderful achievements (eg recursion) all in the name of sparing our audience some pain. no, write that compact code, please. we’re happy to spend time learning just as we’ve spent time learning and appreciating the works of masters of other fields.