9 ms·
Smart Programmers Write STUPID Code (2022)
- gorenb 3y agoI don’t see the need for stupid in all caps.
- bdicroce 3y agoIt's an acronym. Each letter stands for a coding principle that I follow (and encourage others to follow) to write maintainable code. :)
- chrismarlow9 3y agoIt comes off as click bait. Personally I have no issue just figured I would relay my impulsive "news aggregation junkie" thoughts. "STUPID: A mnemonic for great code" might be less impulse triggering and be more forthright. But you have to bring them in somehow so meh.
- happytoexplain 3y agoBefore these two comments, I would have assumed most people know before clicking that it's an acronym that derives humor from the contrast between "smart" and "stupid". Maybe periods would help?
- jeremy_wiebe 3y agoFWIW: My hunch when I read the title was that it would be about “overly smart” programmers who tended to write code that was too dense/tricky to be maintainable by anyone but themselves. Hence smart programmers writing “stupid” (aka unmaintainable/inscrutable) code.
- chrismarlow9 3y agoMaybe. I don't feel strange for assigning the precedence of a word over an acronym at 6 letters when the context comes into play.
- dundarious 3y agoUbiquitous made little sense to me. Proper works much better in French I presume. Not much in the way of clear justification or examples, just a list of things. Altogether, some OK ideas, but quite generic and insufficient/incomplete. Coupled with the conversational marketing style, on the whole, frustrating. Keep thinking and writing.
- puchatek 3y agoSee my comment about the term here: https://news.ycombinator.com/item?id=37808198 https://news.ycombinator.com/item?id=37808198
- 29athrowaway 3y agoI prefer this related idea better https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html#philosophy-principle-of-least-power https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...
- ccvannorman 3y ago> A compiler will not call you in the middle of the night to tell you how amazing your code is. A co-worker, however, might call you in the middle of the night during his on-call night shift to ask you why you introduced an object X that has the same meaning as object Y What a treasure of an article. Definitely felt the leveling up happening as I was reading.
- kazinator 3y agoI don't understand what that passage is supposed to mean. Yes, you write code to please the compiler. Moreover, you first look for ways to make the compiler harder to please, rather than just use its defaults. You don't write code just to please the compiler, but it's a big deal. (Obviously, if you just wanted to please the compiler, it wouldn't have to be indented, and your variables could have names like l0327.) A sufficiently smart compiler could warn you that you're introducing an object X with the same meaning as object Y, so your coworker can sleep at night. Or if not compiler than some other tool. We can imagine tooling that scans the code base and tells you that a class exists that is very similar to what you just wrote. A compiler was written by your de facto coworkers, likely in another organization far away. When their ball-busting attempts turn up nothing against your code, that is a kind of praise.
- kshay 3y agoIt seems like the U should be “Unambiguous” rather than “Ubiquitous”?
- puchatek 3y agoIt's referring to the "ubiquitous language" concept popularized by the Domain driven development (DDD) literature. The assumption is that in every business there is an existing language, i.e. a set of terms that refer to the business concepts and are used by all employees when taking about goods, processes and so on. Developers should take care to elicit this language from their colleagues and use it in their code instead of using whatever terms come to their mind when they need to name things.
- zee2345 3y ago> about debugging our system at work that’s coupled to a SAP service in Wisconsin I think article is a bit naive. If your system is designed this way, you probably have no control over it. Maybe some legacy stuff, maybe you jump too fast between 300 microservices... It hat case you need other methods, like very good logging. If you can replay every interaction with that service, you do not have to decouple it!
- userbinator 3y agoUnfortunately, if this becomes popular, I suspect it'll merely turn into another useless dogma like SOLID and OOP and whatever other buzzwordy acronym-paradigms came before. I can make my own acronym with the same letters too: Simple Teachable Universal Powerful Intuitive Direct. Write some fluffy marketing-esque material with vague references about how each of those terms is a good thing, and with luck, you'll amass worshippers and develop consulting services and other sellable material about how much better you can make software by following these simple rules. Does all this "snake-oil" actually work? My decades of personal experience says otherwise. You can't teach surface-level rote memorisation crap like this and expect it to make things better. I agree that simplicity is good and accidental complexity is to be avoided, but it's not something that can be distilled into trite talking points to be taught. "There's no replacement for intelligence."
- jdougan 3y agoThe problem isn't intelligence, the problem is judgement. Many a smart person has built ridiculous and rickety towers of code, only understandable because they are smart. Good judgement mostly seems to come from bad judgement, failure, then picking the pieces up again while evaluating the causes. It also seems to require some emotional maturity and humility. You are correct that the various dogmas are not useful until the mental attitude is right. After then they are superfluous.
- deleted 3y ago[deleted]
- avidphantasm 3y agoI like to think I tend to write code that others like because I am usually not the smartest person in the room. I strive to make my code simpler because I can’t understand less simple code. If I find an approach to solving a problem that feels too complicated to me, I usually keep looking until I find something simpler.
- withinboredom 3y agoI would argue that this is not related to intelligence, but wisdom. Wisdom is something you earn through experience and can't be taught.
- MrYellowP 3y agoSmart programmers don't need any of this shit.
- lionkor 3y agoHave you ever worked in larger team where everyone was a brilliant developer? If you have, you were the dumb one.
- wizofaus 3y agoI would think the U should be "understandable"?
- Zecc 3y agoIt would have been much clearer. Ironic, isn't it?
- brabel 3y agoDecoupled code is much harder to follow. I see people thinking decoupling is always good, but it's not. It can be good when things are actually de-coupled... but I've seen coworkers decouple logic from HTTP handlers for example where that made no sense because the whole purpose of the logic was to do stuff for HTTP... so if you want to ensure that if certain conditions are met, a HTTP header has a certain value... well you can't anymore unless you abstract away even the concept of HTTP headers! The whole thing becomes a mess out of the good intentions of the developer. Do not ever decouple things that are intrinsically coupled.
- withinboredom 3y agoMost people decouple code for the sake of decoupling (cargo cult) vs. actually knowing when to do so. For example, I was reviewing a software project written by a bunch of junior/mid-level devs. They had decoupled the clock from the physical clock (good for unit testing time-based workflows), but when asked about why they did it, they didn't know or understand why it was done and there were no unit tests using it. When I asked the dev who implemented it, he explained that he decoupled it and so it was good. (to be clear, I was only seeking to understand, and not asking these questions in an accusatory way.) There also existed many interfaces with exactly one implementation, which just increases the cognitive load when writing code because you see an 'IDoX' interface only to discover it is ALWAYS an 'XAdapater' that if you had known, would have saved mountains of logic (ie, getting a new 'XAdapater' from the container while copying some stuff from the 'IDoX' interface). It was a mess. Are they going to be glad that all these abstractions exist at some point? Probably not. This is a pretty simple, but mature project. There's no real reason to refactor it at this point. The business owners just wanted to know what was going on and why simple changes took months to implement.
- MoreQARespect 3y agoFrankly I think even decoupling for the purposes of unit testing is another example of cargo culting. It emerged as a best practice when CPUs were much slower, containerization didn't exist and mock service tooling was far inferior - writing integration tests was an exercise in flaky futility in 2001. The technology has since moved on but the culture of best practices hasn't. It still can make sense if you've got a very complex bundle of isolated stateless business logic but in practice I find that most dependency inversion I see these days isn't for that. It increases the SLOC by 30% and reduces code coherence just so that a test can run in 20 milliseconds instead of 2.1 seconds. In many cases those unit tests check to see if you put a number in one end of a class that the same number comes out the other end. What bug is that going to catch? Meanwhile all of the actual bugs are probably hiding in the database queries or the interaction layers created as a sacrifice to bob the bearded god of unit testing. The most fascinating instantiation of this idea is, I think, the notion that because unit tests are horrible to work with that unit tests can therefore "drive" design because it'll make you fight to make the unit test less horrible. It's like advocating an abusive relationship to help fix your life because the abuser won't be afraid to point out all of your flaws which you can then fix. The two corollaries that never seems to permeate are A) maybe when unit tests become horrible to work it's means they were also the bad code that coupled too tightly? and B) maybe it's cheaper to spot bad design by learning what to look for rather than building a unit test that will punch you in the face for it?
- Loveaway 3y agoThe biggest pitfall is DRY imho. Write generic code, reuse abstractions. It's the most elegant way. Except it always tends to lead to these god classes, super systems, that try to be most flexible and to do everything. Then comes the point where it becomes impossible to understand all the interactions and half of your codebase falls apart if anything changes. All because you were to proud to copy & paste a few lines like it's a deadly sin.
- pjbster 3y agoDRY also removes an easy opportunity to expose patterns which are things that people are incredibly good at recognising and internalising. I used to religiously apply DRY but now I prefer to leave repetition in unless the git log shows changes being applied to the repeated sections.
- vi2837 3y agoThere is also more advanced AHA principle (https://en.wikipedia.org/wiki/Don't_repeat_yourself https://en.wikipedia.org/wiki/Don't_repeat_yourself in alternative section) - which is an evolution of DRY and is great for avoiding redundant complexity caused by DRY.
- pjbster 3y agoTo my mind, all discussions about code design boil down to the reduction of cognitive load (CL). “Cognitive load refers to the amount of effort that is exerted or required while reasoning and thinking. Any mental process, from memory to perception to language, creates a cognitive load because it requires energy and effort. When cognitive load is high, thought processes are potentially interfered with. To the UX designer, a common goal when designing interfaces would be to keep users’ cognitive load to a minimum.” (https://speakerdeck.com/fedepaol/reducing-cognitive-load-yet-another-idiomatic-go-talk?slide=7 https://speakerdeck.com/fedepaol/reducing-cognitive-load-yet...) In this context, "users" can be substituted with "other developers". Writing low-CL code is a constant balancing act and, like good UX design, when it works the nuances are invisible and therefore hard to learn from. So I appreciate the OP for the article even if we can quibble about some of the points.
- pydry 3y agoThere is no one metric of code quality. There are a bunch of competing concerns, some of which will push others down if you push them up. With cognitive load it doesn't even generalize. Who hasn't worked with somebody who joined a project and then immediately started changing the code to be more aligned to their taste in idioms to reduce the cognitive load. Their cognitive load that is. Not necessarily anybody else's.
- seadan83 3y agoFirst day of a new job, a new commute all have exceedingly high cognitive loads. Come back from that, all you did was just HR stuff and a new commute and are exhausted! After a year, suddenly that commute, the byzantine policy stuff has a cognitive load of, "yeah, this is all super simple." My point, the unfamiliar might have actually lower cognitive load. Cognitive load is a function of what you know and what you are used to.
- SillyUsername 3y agoGreat another one, throw it on the heap with - SOLID - KISS - YAGNI - DRY - ...
- log101 3y agoI'd prefer BORING instead of STUPID. I don't want to see coworkers talking about writing "stupid code" all-day.
- fsloth 3y agoYes! This! The code should be so boring it's never a point of discussion. This implies several things - for example when bringing in a new person, it should be straightforward to teach them how to work with codebase. Other implications include naming conventions, sufficient amount of documentation, what architectural patterns to choose (if you need to do something that even hints of accidental complexity you need to have really good justification for it)...etc.
- euroderf 3y ago> The code should be so boring it's never a point of discussion. This implies several things - for example when bringing in a new person, it should be straightforward to teach them how to work with codebase. Go is your friend.
- thefaux 3y agoGo is your friend with whom you can talk about the weather and sports but the relationship is ultimately superficial and unsatisfying.
- euroderf 3y agoBut neither is it an impediment to maintaining your friendship.
- code_biologist 3y agoGo is also the person who shows up when you need an extra hand for a home improvement project.
- euroderf 3y agoGo is a sort of pay-it-forward scheme, wherein you let go of your self-absorption and give the next guy a lucky break. Pun unintended.
- deleted 3y ago[deleted]
- tremere 3y agoI don't know if I necessarily agree, especially with D = decoupling. However I do like the idea of dead simple code. Often I'll find code written by self styled haxors who omit curly braces and nest ternary operators because they can. That's great but it ends up biting you in the ass. The code itself should be treated internally like part of the product and it should be easily extensible, of uniform style, and written so safely that if a child added a line to the code it wouldn't break it entirely. This is especially true of languages that support macros. If inclusion or modification of macros in your code cannot be done, it is probably a bad sign. When writing code to be resistant to hardware attacks for instance there is a different style that must be adopted entirely, if everyone is writing the fanciest for-loops fathomable then it becomes inefficient and a risk to code correctness to mutate the code to resist classes of attacks. This is terrible and not worth it just because an elite haxor wanted to write a for loop in a single line.
- smolder 3y ago> Often I'll find code written by self styled haxors who omit curly braces and nest ternary operators because they can. That's great but it ends up biting you in the ass. I've worked on codebases where omitting curly braces for single line IF was the style, but can't recall ever being 'bitten in the ass' by that particular style choice. I can see how when combined with other questionable style choices it could yield some very ugly and error prone code, but by itself I really have trouble understanding why people object to it.