17 ms·

Clear is better than clever

365 points by UkiahSmith 7y ago

stcredzero 7y ago
There was that recent post about innovation being a limited resource. Clever is a limited resource. Save your clever for good, insightful architecture, or for when you really need the algorithmic chops. Don't expend it just to impress your coworkers.
- runevault 7y ago
  And for the love of god when you do actually need to be clever, document the hell out of why and what the trade offs/benefits were. The first time I had to be clever to get performance I put a nearly half screen comment of why the hell I did it.
  - kosievdmerwe 7y ago
    Another trick to manage cleverness (or even just messiness) is to hide the code in a well-named function, so readers can understand what it's doing in the context of the rest of the code and only have to delve in when they need to.
    - georgebarnett 7y ago
      Only somewhat jokingly, this is the start of things like doBillCustomer().
      - stcredzero 7y ago
        "I'm gonna code me a new minivan!" --Wally
      - james_s_tayler 7y ago
        My favorite recently is a class named CustomerCommandMapEmbelisherConverter. It's not a good name. Nor is it concise, informative or anything vaguely useful. But I get the strong feeling it comes from someone spouting off a line along the lines of "we need to name things for what they do" and then someone else just coming up with that. In your case I'm going to guess doBillCustomer() is about 2.5k lines long with a copy of its entire logic duplicated and it branches based on annual or monthly billing and subtle bugs have been fixed in one implementation but not the other and now they are diverged such that they are only 93% the same but that means all bets are off. There are 15 levels of nesting and it interacts with at least 5 external systems during all of that. Am I close?
    - hinkley 7y ago
      Move the code that should be clever to a separate function, then add the clever in a single commit. People tend to tolerate clever code that is out in leaf functions they don’t have to step through, and knowing they could revert the change makes them tolerate the clever longer.
- deogeo 7y ago
  > Clever is a limited resource. Save your clever for good, insightful architecture I'd sooner say clever is a skill, that gets better with practice. Compare it to solving tricky math problems - the more you solve them, the more clever you 'expend', the better you get.
  - runevault 7y ago
    Some of A, some of B. But there's plenty of ways to expend clever that don't make the code harder to read as well (clever architectures that aren't obvious before you create them but once they are built are still readable). Clever tricks that require being clever to read as well as to write are the dangerous ones.
    - stcredzero 7y ago
      Clever tricks that require being clever to read as well as to write are the dangerous ones. There's a level of clever, where things seem complex and abstruse on the surface. There's another level of clever, where things seem clear and simple on the surface, but deep insight went into making things that way. (Then there's a level of faked deep-clever that relies on "automagic," but which isn't as clever as it seemed on the surface and costs a ton of extra debugging time.)
    - deogeo 7y ago
      Never meant to imply otherwise :)
      - stcredzero 7y ago
        Over the years, I have encountered dozens of programmers in their 20's and 30's who seem to prioritize impressing fellow programmers over the clarity of the code base as a whole. In fact, I'd say there's something about programming education which seems to produce these attitudes.
  - stcredzero 7y ago
    I'd sooner say clever is a skill, that gets better with practice. Exactly! However, keep in mind the difference between rehearsal and performance, and act according to the cost/benefit. It's very analogous to what stand-up comedians do. They do a form of practice, where they try material out with friends in private. There's another level of practice when they're on the road, but in small, obscure venues. Those are the times when they go "courageous," take risks, and try new things out. It's a different matter entirely, when it's their big HBO special filmed in some huge famous theater. That filmed show is going to be a permanent record which affects their reputation for years after. Think on this, when coworkers check code into production. Code in production might be executed and read years down the road.
_o-O-o_ 7y ago
> This article is based on my GopherCon Singapore 2019 presentation. In the presentation I referenced material from my post on declaring variables and my GolangUK 2017 presentation on SOLID design. For brevity those parts of the talk have been elided from this article. If you prefer, you can watch the recording of the talk. > Readability is often cited as one of Go’s core tenets, I disagree. In this article I’ll discuss the differences between clarity and readability, show you what I mean by clarity and how it applies to Go code, and argue that Go programmers should strive for clarity–not just readability–in their programs. > Why would I read your code? > Before I pick apart the difference between clarity and readability, perhaps the question to ask is, “why would I read your code?” To be clear, when I say I, I don’t mean me, I mean you. And when I say your code I also mean you, but in the third person. So really what I’m asking is, “why would you read another person’s code?” > I think Russ Cox, paraphrasing Titus Winters, put it best: > Software engineering is what happens to programming when you add time and other programmers. > –Russ Cox, GopherCon Singapore 2018 > The answer to the question, “why would I read your code” is, because we have to work together. Maybe we don’t work in the same office, or live in the same city, maybe we don’t even work at the same company, but we do collaborate on a piece of software, or more likely consume it as a dependency. > This is the essence of Russ and Titus’ quote; software engineering is the collaboration of software engineers over time. I have to read your code, and you read mine, so that I can understand it, so that you can maintain it, and in short, so that any programmer can change it. > Russ is making the distinction between software programming and software engineering. The former is a program you write for yourself, the latter is a program— a project, a service, a product— that many people will contribute to over time. Engineers will come and go, teams will grow and shrink, requirements will change, features will be added and bugs fixed. This is the nature of software engineering.
DiseasedBadger 7y ago
If it's both clear and conventional, gcc should be able to make it clever. If it can't, I'd rather pay a human to profile it, than to make it clever. There are too many developers who are "super good at writing clever code", and not enough who are comfortable with profiling and analytics.
snarf21 7y ago
I wonder though, isn't it even more clever to be simple (which is also clearer)?
- papito 7y ago
  Being simple is hard.
  - mercer 7y ago
    https://www.youtube.com/watch?v=34_L7t7fD_U https://www.youtube.com/watch?v=34_L7t7fD_U
makapuf 7y ago
I often cite this quote : Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (B. Kernighan)
SolaceQuantum 7y ago
This is a strange read as a fiction writer. This lesson is learned quite early in prose writing- explicitly due to the fact that written works must be read. Maybe because of this, I've never felt the need to write 'cleverly' in my programming either. Can other prose writers corroborate?
- thwd 7y ago
  Good prose often involves misdirection. Making the reader believe something to be one way, while it was something else all along. Then, in a built up climax, undo the knot in a single pull to blow the reader's mind. That, to me, is the antithesis of the article's argument.
  - kosievdmerwe 7y ago
    Sure, but if you know about misdirection, you also know how to appropriately direct attention to the parts of the code that is important.
- steveklabnik 7y ago
  I believe that approaching writing, including programming, to this, is reductive. At its base level, this is missing an important thing: context. Clear to who? Something can be very clear to one person, yet opaque to another. In writing, and in programming, you need to decide which audience that you're talking to, and write something that they will understand. This often comes up in discussions about jargon. Jargon is a way to increase the density of communication. This is often perceived as a loss of clarity, but the question again is, clarity for who? For two experts, discussing complex things in their field of expertise, jargon can increase clarity, by referring to shared context. Higher bandwidth communication allows for more discussion of more complex topics, because you're not wasting time and mental energy re-explaining things from first principles. Put another way, there is always some shared context going on; that's what language actually is in the first place. I have used a number of words in writing this comment, but I haven't set out any definitions; that's because I'm assuming that you know English in order to read my comment. If I were trying to communicate to a child, I wouldn't be using all of the words that I'm using here, because it is too complicated for them to comprehend. But, trying to explain the topic of this comment to that child would take much longer, and be much more difficult. So yeah, that's just one way in which discussions like these tend to frustrate me. Writing is a rich, wonderful thing, that has a huge variety of uses. Pigeon-holing it in this way makes me feel, well, dispirited. Or should I say "sad"... (I do believe that, for both commercial development of software, as well as commercial development of writing, "keeping things simple" can be important, for various reasons. But not everything we do in life must be in the service of business needs.)
o_nate 7y ago
I agree with the sentiment of the article, though I don't really like the example given. To me, using a switch statement instead of if-else-if is not any clearer.
- kosievdmerwe 7y ago
  I think for that particular example it's bad, but it might work better for a more complicated example with many more cases.
ngngngng 7y ago
The difficulty of giving examples to illustrate what "clarity" means really shows in this article. For the most part I evaluate software clarity by how many times I had to hit "goto definition" to see what was actually happening. But this takes us away from what the author was attempting to say. In my opinion, 95% of clarity comes down to writing good abstractions, and it is next to impossible to articulate what a good abstraction is. It's like describing the taste of salt.
- audience_mem 7y ago
  And even if one could articulate what a good abstraction is, someone would come along and disagree.
  - zzzcpan 7y ago
    Because "good" just as "clear" is not universal. But we can actually estimate how good abstractions can be in specific circumstances for specific users if we think of them in terms of familiarity, simplicity, consistency, flexibility and universality.
kosievdmerwe 7y ago
The concept of clarity is why I don’t like the consequence of SOLID, where you have lots of tiny classes. It’s easier to understand complex functions and a simple class structure than the other way around. Because jumping between multiple files/classes incurs a high understandability cost, whereas complex functions fit on your screen typically. And reading some more about it, I found this good article: http://qualityisspeed.blogspot.com/2014/08/why-i-dont-teach-solid.html?m=1 http://qualityisspeed.blogspot.com/2014/08/why-i-dont-teach-...
- azeirah 7y ago
  I typically find it very difficult to understand complex functions, (100+ lines of code, ~3 or more nesting levels deep) and even simpler complex functions (mixing 2-3 concepts into a 15 line function). I've only just started doing TDD the "Growing Object Oriented Software guided by tests" way, and I find it incredibly helpful that each and every class does just _one_ thing, even splitting up those 15 line functions into two or three separate classes implementing an interface -- single responsibility -- helps me a lot in reasoning about the code. I _have_ experienced the dependencies issue myself already though, it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying.
  - kosievdmerwe 7y ago
    Yeah, but I would say it depends on context, clarity is very context dependent. Do what makes the code easiest to read taking into account that human limitations. Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. For instance, logic that filters what jobs to run based on conditions, it might make sense to abstract the logic for the conditions into one class per condition, to make the filtering logic clearer.
    - azeirah 7y ago
      > Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. Yeah, that seems to be something I'll have to spend some time learning about. Right now I'm just mindlessly splitting off everything, and it kind of works, but it's annoying to navigate all over the place just to find some detail somewhere
tombert 7y ago
My rule of thumb has always been "the amount of comments I leave is directly proportional to how clever my code is". Code that is trivial really needs no elaboration, but occasionally I feel like I gotta go crazy with a bunch of hashmaps of lambdas and all that jazz, and I don't think that there's inherently anything wrong with that. However, when I do that, I make sure I document it like crazy with comments, so that when I have to look at the code two weeks later, I at least can figure out what I was doing.
- hinkley 7y ago
  I will agree with that but only if you put air quotes around “clever”. There is a point beyond which accurate documentation is more difficult than improving the code to negate some of that documentation. That makes the code cleverer still (without air quotes). This is not far off from St Antoine de Exupery’s comments on perfection being achieved when there is nothing left to take away.
RcouF1uZ4gsC 7y ago
The issue is that in Go speak, "clever" means any programming language technique that was invented after the 1970's. We are fortunate that the creators of Go felt comfortable with structured programming, or otherwise they might have felt that function calls with their compiler maintained stacks and local variables were "clever" and that we should all use goto statements since those are much clearer as to what is actually happening.
- apta 7y ago
  This is a summary of the mentality of the golang authors: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. Of course "good" software is subjective, as I've seen golang encourages otherwise.
  - deleted 7y ago
    [deleted]
smacktoward 7y ago
This put me in mind of a passage from the (excellent) 1982 book Inside the Soviet Army, by the Soviet defector Vladimir Rezun (which can be read in English in its entirety here: http://militera.lib.ru/research/suvorov12/index.html http://militera.lib.ru/research/suvorov12/index.html), which explained why ammunition for Soviet weapons hadn't been standardized across a common set of calibers: The calibre of the standard Soviet infantry weapon is 7.62mm. In 1930, a 7.62mm `TT' pistol was brought into service, in addition to the existing rifles and machine-guns of this calibre. Although their calibre is the same, the rounds for this pistol cannot, of course, be used in either rifles or machine-guns. In wartime, when everything is collapsing, when whole Armies and Groups of Armies find themselves encircled, when Guderian and his tank Army are charging around behind your own lines, when one division is fighting to the death for a small patch of ground, and others are taking to their heels at the first shot, when deafened switchboard operators, who have not slept for several nights, have to shout someone else's incomprehensible orders into telephones-in this sort of situation absolutely anything can happen. Imagine that, at a moment such as this, a division receives ten truckloads of 7.62mm cartridges. Suddenly, to his horror, the commander realises that the consignment consists entirely of pistol ammunition. There is nothing for his division's thousands of rifles and machine-guns and a quite unbelievable amount of ammunition for the few hundred pistols with which his officers are armed. I do not know whether such a situation actually arose during the war, but once it was over the `TT' pistol-though not at all a bad weapon-was quickly withdrawn from service. The designers were told to produce a pistol with a different calibre. Since then Soviet pistols have all been of 9mm calibre. Why standardise calibres if this could result in fatally dangerous misunderstanding? Ever since then, each time an entirely new type of projectile has been introduced, it has been given a new calibre... [West Germany and France] have excellent 120mm mortars and both are working on the development of new 120mm tank guns... [W]hat happens if, tomorrow, middle-aged reservists and students from drama academies have to be mobilised to defend freedom? What then? Every time 120mm shells are needed, one will have to explain that you don't need the type which are used by recoilless guns or those which are fired by mortars, but shells for tank guns. But be careful-there are 120mm shells for rifled tank guns and different 120mm shells for smoothbore tank guns. The guns are different and their shells are different. What happens if a drama student makes a mistake? The Soviet analysts sit and scratch their heads as they try to understand why it is that Western calibres never alter. (This specific chapter can be read here: http://militera.lib.ru/research/suvorov12/06.html http://militera.lib.ru/research/suvorov12/06.html)
cgrealy 7y ago
Debugging code is more difficult than writing it. If you write the cleverest code you can, you are, by definition, not smart enough to debug it. /shamelessly stolen from somewhere I'm too lazy to look up.
- steveklabnik 7y ago
  "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan, "The Elements of Programming Style"
  - jodrellblank 7y ago
    Writing "for (int i=0; i<limit; i+=step) {}" is easy. Debugging the off-by-one error requires that you understand the alignment issue you ignored in the first place. That would make debugging harder, not because debugging is inherently hard, but because that's the place you're forced to deal with the hard bit you skipped earlier. I wonder how often that applies, compared to well-understood-but-implementation-mistake code?
  - cgrealy 7y ago
    Damnit, I really should have remembered that :)
- zzzcpan 7y ago
  > Debugging code is more difficult than writing it. It's not. It's possible to not know how to do it well though. As it's something you have to experiment with, learn various approaches, instrumentation.
  - cgrealy 7y ago
    I'm interested to hear what your rationale for this is. When you are writing code, you generally know what it is you are trying to achieve. When debugging code, you're frequently trying to find out why a problem is happening in the first place; often in code that someone has written or that you wrote months or even years ago. I'm not saying that debugging isn't a skill you can learn, but it's a superset of writing code, so it's by definition harder.
thsealienbstrds 7y ago
All these quotes remind me of another quote that I like: Simple and dirty beats complex and clean any day. - Learn C the Hard Way
- stcredzero 7y ago
  Unless simple and dirty is O(n^2) and simple and clean is O(n).
  - mercer 7y ago
    and unless that matters.
    - stcredzero 7y ago
      I originally wrote O(n^4) vs. O(n^2), which is something that actually happened to me two days ago, but thought I'd go more basic. I should've gone real-world example. But yes, O(n^2) vs. O(n) can matter for large n.
      - mercer 7y ago
        I don't disagree though. Even though in much of my work performance is usually not a concern, I still run into plenty of situations where it really is. But I run into more situations where I probably spend more time optimizing when I don't need to. YMMV, obviously.
        stcredzero 7y ago
        I'm forced to optimize unnecessarily in code reviews at work. Gotta save that extra microsecond when the user pushes that button!
        mercer 7y ago
        Ha, I spend a decent amount of time trying to explain to clients how it's worth their while to decrease a page's load time from 20+ seconds to < 5 in just a few hours of work...
DogLover_ 7y ago
Have to really disagree with the "comp" function example. No need to have "else" statements. The one with early returns and only "ifs" is succinct and good. Also what is up with comparator function being used this way for most articles nowadays? If I am not mistaken "return a-b" is the much better solution and don't say that it is considered too clever :)
- panopticon 7y ago
  "return a-b" is susceptible to overflows and may lead to subtle bugs depending on your language.
  - audience_mem 7y ago
    In a sense it is the perfect example of "clear is better than clever", or perhaps "explicit is better than having buggy edge-cases"
  - DogLover_ 7y ago
    Thanks, did not think about that!
- city41 7y ago
  The author states it's just an example and also says > This is reasonable when you’re dealing with functions which fit on a slide, but in the real world complicated functions– the ones we’re paid for our expertise to maintain–are rarely slide sized, and their conditions and bodies are rarely simple.
bryanrasmussen 7y ago
brevity is the soul of wit and the veil of clarity.
- jonahx 7y ago
  “Only short programs have any hope of being correct.” - Arthur Whitney
- jodrellblank 7y ago
  But .. verbosity is the veil of clarity? > verbiage: excessively lengthy or technical speech or writing. > synonyms: verboseness, padding, superfluity, redundancy, long-windedness, protractedness, digressiveness, convolution, circuitousness, rambling, meandering; waffling, wittering, "there is plenty of irrelevant verbiage but no real information"
- deleted 7y ago
  [deleted]
unicornporn 7y ago
...said Tom Cruise. (Sorry, I know this isn't reddit)
hyperpallium 7y ago
> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. https://wikiquote.org/wiki/Edsger_W._Dijkstra https://wikiquote.org/wiki/Edsger_W._Dijkstra > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? https://wikiquote.org/wiki/Brian_Kernighan https://wikiquote.org/wiki/Brian_Kernighan
- jodrellblank 7y ago
  Being quoted several times in this thread; what about the experience of finding something feels "clever" but then after a while of using it, finding it no longer feels clever but instead feels normal? > Every weightlifter is fully aware of the strictly limited size of his own muscles; therefore he approaches the weight lifting task in full humility and among other things he avoids heavy weights like the plague.
  - raincom 7y ago
    As more people are familiar with a clever trick, it becomes an idiom, which others master. Now it is in the realm of "clear", graduating from the realm of purgatory of clever tricks.
    - hyperpallium 7y ago
      ...if generally applicable. Then, hopefully, from idiom to abstraction.
  - usbseeker 7y ago
    You don't have to figure out how to lift the weight.
    - Kye 7y ago
      I'm no weight lifter, but I do know lifting weights is highly skilled unless you're into permanent injury.
mrkeen 7y ago
Two men enter a bar. One is taller than the other. Which one is taller? -1.
- mrkeen 7y ago
  I guess the downvoter didn't like me pointing out int is a shitty way to answer the question "which is bigger?" in an article supposedly selling clarity over cute tricks.
- hi41 7y ago
  The first one!
jodrellblank 7y ago
> Here we have a comp function that takes two ints and returns an int; Ah, "comp"utation. "comp"lex numbers? "comp"licated function? "comp"onent? "comp"anion numbers, is that a thing? "comp"rehensive example? Saving three characters of typing is more important than being clear?
ufo 7y ago
That switch case transformation in the end is just syntactic sugar for the equivalent if-else-if chain so I am not sure it is actually an improvement. That said, I still agree with the basic idea. An if-else-if chain is easier to reason about than if-return, and representing information with enum or algebraic data type can be more robust than using a combination of booleans.
- mdpopescu 7y ago
  The whole point of syntactic sugar is that it makes a code fragment easier to read / understand. That's why we're not calling it syntactic poison.
nightcracker 7y ago
I think clever stuff should be behind clear APIs.
apta 7y ago
> If software cannot be maintained, then it will be rewritten; and that could be the last time your company invests in Go. Maybe on to something there, golang code bases I've seen are a complete mess because of how "simple" the language is. Hopefully more people start realizing this and moving on to better languages.
- zzzcpan 7y ago
  In my experience Golang code bases are messy because of two things: OO and CSP. People all too often resort to goroutines, channels, objects and interfaces where a simple side-effect free function could do.
  - apta 7y ago
    It's ironic because the golang authors say that golang is not "OO". Of course, not that there's anything wrong with properly done OO, it's just that golang's implementation of it is botched.
miccah 7y ago
Code is written and read by humans, therefore it should be clear and concise. Cleverness should be used in constrained situations like performance (fast inverse square root [1] comes to mind), and comments explaining the cleverness is important. I should note [1] did a terrible job at commenting. [1] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root https://en.m.wikipedia.org/wiki/Fast_inverse_square_root
flowerlad 7y ago
Ability to make complex things simple is what sets apart a great programmer from an average one. So why do most programmer interviews at companies such as Google focus on writing performant code instead? Most professional programmers only occasionally need to look into performance issues, but need to take complex things and simplify them with every line of code they write. And yet most programming interviews don’t evaluate this ability. I think this should change.
- james_s_tayler 7y ago
  We have this discussion on HN every month. So far the answer I've worked out is: Because its optimal solution to let talent flow through BigCo in SV. There is no domain or tech-stack specific stuff. So studying for the interview process allows the applicant to apply for multiple companies. At the same time it's a pretty hardcore process, so the company knows they are getting engineering talent that is a) smart and b) obedient. For the rest of the world it absolutely doesn't make sense and that's why where I live, you don't see that style of interviews at all.
  - flr03 7y ago
    I came up with the same conclusion. It's not a technical test in such, it's more a competition/motivation test.
  - wpietri 7y ago
    One thing I'd add: One possible function of an interview process is to find qualified interviewees. Another is to make interviewers feel smart. I think typical BigCo interview processes are optimized for the latter. David Epstein's new book Range talked about academic research splitting domains into kind vs wicked. Kind learning domains are ones where "feedback links outcomes directly to the appropriate actions or judgments and is both accurate and plentiful", while wicked ones are "situations in which feedback in the form of out-comes of actions or observations is poor, misleading, or even missing". [1] The hard parts of real-world software development are generally in the "wicked" bucket. Schoolwork and puzzle questions are both generally "kind" in the sense that there's a right answer and you're expected to figure it out. It's impossible to be too smug working on "wicked" problems because you get your ass kicked often enough to stay humble. But in "kind" domains it's quite easy to indulge one's desire to feel superior by dragging people through things you know well. Personally, when I interview people I try to set things up so that there's no right answer; the goal is to see how well they get to good answers, and how well they collaborate during that process. I'd love to see more people do that. [1] https://pdfs.semanticscholar.org/5c5d/33b858eaf38f6a14b3f042202f1f44e04326.pdf https://pdfs.semanticscholar.org/5c5d/33b858eaf38f6a14b3f042...
vemv 7y ago
<subjective thing> is better than <subjective thing>. Oh thanks, that was so useful.
- dang 7y ago
  Please don't be snarky and please don't post shallow dismissals here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
AngeloAnolin 7y ago
I think one reason why people like to write supposedly clever code especially on the realm of software development is due to lots of these developers want to get acknowledgement of what they produce. And hearing someone say "Oh, this is a very clever implementation" sort of fix that inherent need to be recognized. I haven't heard (particularly in corporate environments) where a praise in the line of - "wow, this was a very clear and simple implementation" trump what managers and people deem as superior when the term clever was attached to it. I've challenged far quite a lot of implementations where understanding a piece of functionality has required for the developer to jump between more than 23 files across 8 different projects in implementing a very domain specific functionality. Splitting code into single independent parts introduces simplicity, only and if only you are reading that part by itself, but when you layer it overall to get the functionality it delivers and it becomes a web of tangled mess of code, then that clever solution was not really clever after all.
- hinkley 7y ago
  I have an intuition about library design that I’ve been slowly trying to formulate into a set of guidelines. I have extremely high standards in this area and not being able to state them concretely makes communicating them a struggle. One of the ways I complain about particularly bad decomposition (the sort of practices that lead to parodies like Enterprise FizzBuzz) is the ridiculousness of stacktraces for errors in these systems. We tell people to use delegation but many have trouble differentiating delegation from indirection. You know things have gotten particularly bad when you have traces with the same sequence of three or more functions appearing three times. Debugging this is a nightmare. It’s literally a maze of logic. This type of code has to be memorized to be understood, which further makes an existential threat of a saner person’s attempts to refactor it - moving things around to be discoverable and debuggable comes at a cost to the people who already memorized it. There is also DAMP vs DRY and “desertification” of code, which is related to the good versus bad indirection problem. When you get a prolific “clever” person who suffers from these problems, the whole team suffers with them (which is why I need a new job...). Someone above mentioned flame graphs, which is a trace of every call in the system, typically for the purpose of visualizing where time is spent by the CPU. In thinking about this thread, I now want to look into using them as a measure of time spent by the reader. My overall philosophy on code is that we should use our best days to protect ourselves from our worst days. I expend most of my clever on trying to make things look easy, which is a bit of a challenge come review time because one of the hallmarks of really clever reasoning is that people react by saying things like, “well of course it works that way”.
ksaj 7y ago
Nice. I said exactly this for the same reason yesterday. In that case it was a thread about Lisp. Here's the comment: > Even the open source Common Lisp compilers, written by arguably the lispiest of Lispers, don’t have a lot of “cleverness”. To which I replied my agreement: > Don't write clever. Write clear. Its a sentiment that you find attached to Lisp programming style fairly often, although ironically there is a whole lot of barely readable Lisp code out there. Personally, I think the code is (nearly) worthless crap if someone with skill has to spend as much time parsing it as the writer did writing it. https://news.ycombinator.com/item?id=20376344 https://news.ycombinator.com/item?id=20376344
k__ 7y ago
Often I only need clever for performance reasons. I write a filter/map, which is slow in some languages, but looks readable and if I need better perf I rewrite it with a for loop.
makecheck 7y ago
If you have only a final “else” instead of a bare “return” in a function that returns a value, you are making it worse. Now when I read the code, my first instinct is “seems to be a bug, undefined behavior” and I have to read more carefully. This is a terrible example and a code change I would never approve. The clarity-over-cleverness goal is good but not with these kinds of cases.
peter_vukovic 7y ago
Creating anything is a craft and creating software programs is no different. While everyone should strive to learn how to write programs well so the intent isn’t obfuscated, it ultimately boils down to two factors: programmer’s experience and talent. Most programs, like most works of art, will be utter crap and nonsense, as most artists are - with rare notable differences. This is why I heavily support frameworks and prescriptive style of programming, or “opinionated” systems as some would call them. They are usually invented by people much smarter than the average Joe and ultimately generate better long term results. It would benefit our productivity much more if we invested efforts into translating these brilliant minds into compiler features so the compiler checks for style as well, not just “spelling”. We need Grammarly for code.

365 points by UkiahSmith 7y ago

There was that recent post about innovation being a limited resource. Clever is a limited resource. Save your clever for good, insightful architecture, or for when you really need the algorithmic chops. Don't expend it just to impress your coworkers.

runevault 7y ago
And for the love of god when you do actually need to be clever, document the hell out of why and what the trade offs/benefits were. The first time I had to be clever to get performance I put a nearly half screen comment of why the hell I did it.
- kosievdmerwe 7y ago
  Another trick to manage cleverness (or even just messiness) is to hide the code in a well-named function, so readers can understand what it's doing in the context of the rest of the code and only have to delve in when they need to.
  - georgebarnett 7y ago
    Only somewhat jokingly, this is the start of things like doBillCustomer().
    - stcredzero 7y ago
      "I'm gonna code me a new minivan!" --Wally
    - james_s_tayler 7y ago
      My favorite recently is a class named CustomerCommandMapEmbelisherConverter. It's not a good name. Nor is it concise, informative or anything vaguely useful. But I get the strong feeling it comes from someone spouting off a line along the lines of "we need to name things for what they do" and then someone else just coming up with that. In your case I'm going to guess doBillCustomer() is about 2.5k lines long with a copy of its entire logic duplicated and it branches based on annual or monthly billing and subtle bugs have been fixed in one implementation but not the other and now they are diverged such that they are only 93% the same but that means all bets are off. There are 15 levels of nesting and it interacts with at least 5 external systems during all of that. Am I close?
  - hinkley 7y ago
    Move the code that should be clever to a separate function, then add the clever in a single commit. People tend to tolerate clever code that is out in leaf functions they don’t have to step through, and knowing they could revert the change makes them tolerate the clever longer.
deogeo 7y ago
> Clever is a limited resource. Save your clever for good, insightful architecture I'd sooner say clever is a skill, that gets better with practice. Compare it to solving tricky math problems - the more you solve them, the more clever you 'expend', the better you get.
- runevault 7y ago
  Some of A, some of B. But there's plenty of ways to expend clever that don't make the code harder to read as well (clever architectures that aren't obvious before you create them but once they are built are still readable). Clever tricks that require being clever to read as well as to write are the dangerous ones.
  - stcredzero 7y ago
    Clever tricks that require being clever to read as well as to write are the dangerous ones. There's a level of clever, where things seem complex and abstruse on the surface. There's another level of clever, where things seem clear and simple on the surface, but deep insight went into making things that way. (Then there's a level of faked deep-clever that relies on "automagic," but which isn't as clever as it seemed on the surface and costs a ton of extra debugging time.)
  - deogeo 7y ago
    Never meant to imply otherwise :)
    - stcredzero 7y ago
      Over the years, I have encountered dozens of programmers in their 20's and 30's who seem to prioritize impressing fellow programmers over the clarity of the code base as a whole. In fact, I'd say there's something about programming education which seems to produce these attitudes.
- stcredzero 7y ago
  I'd sooner say clever is a skill, that gets better with practice. Exactly! However, keep in mind the difference between rehearsal and performance, and act according to the cost/benefit. It's very analogous to what stand-up comedians do. They do a form of practice, where they try material out with friends in private. There's another level of practice when they're on the road, but in small, obscure venues. Those are the times when they go "courageous," take risks, and try new things out. It's a different matter entirely, when it's their big HBO special filmed in some huge famous theater. That filmed show is going to be a permanent record which affects their reputation for years after. Think on this, when coworkers check code into production. Code in production might be executed and read years down the road.

_o-O-o_ 7y ago

> This article is based on my GopherCon Singapore 2019 presentation. In the presentation I referenced material from my post on declaring variables and my GolangUK 2017 presentation on SOLID design. For brevity those parts of the talk have been elided from this article. If you prefer, you can watch the recording of the talk. > Readability is often cited as one of Go’s core tenets, I disagree. In this article I’ll discuss the differences between clarity and readability, show you what I mean by clarity and how it applies to Go code, and argue that Go programmers should strive for clarity–not just readability–in their programs. > Why would I read your code? > Before I pick apart the difference between clarity and readability, perhaps the question to ask is, “why would I read your code?” To be clear, when I say I, I don’t mean me, I mean you. And when I say your code I also mean you, but in the third person. So really what I’m asking is, “why would you read another person’s code?” > I think Russ Cox, paraphrasing Titus Winters, put it best: > Software engineering is what happens to programming when you add time and other programmers. > –Russ Cox, GopherCon Singapore 2018 > The answer to the question, “why would I read your code” is, because we have to work together. Maybe we don’t work in the same office, or live in the same city, maybe we don’t even work at the same company, but we do collaborate on a piece of software, or more likely consume it as a dependency. > This is the essence of Russ and Titus’ quote; software engineering is the collaboration of software engineers over time. I have to read your code, and you read mine, so that I can understand it, so that you can maintain it, and in short, so that any programmer can change it. > Russ is making the distinction between software programming and software engineering. The former is a program you write for yourself, the latter is a program— a project, a service, a product— that many people will contribute to over time. Engineers will come and go, teams will grow and shrink, requirements will change, features will be added and bugs fixed. This is the nature of software engineering.

DiseasedBadger 7y ago

If it's both clear and conventional, gcc should be able to make it clever. If it can't, I'd rather pay a human to profile it, than to make it clever. There are too many developers who are "super good at writing clever code", and not enough who are comfortable with profiling and analytics.

snarf21 7y ago

I wonder though, isn't it even more clever to be simple (which is also clearer)?

papito 7y ago
Being simple is hard.
- mercer 7y ago
  https://www.youtube.com/watch?v=34_L7t7fD_U https://www.youtube.com/watch?v=34_L7t7fD_U

makapuf 7y ago

I often cite this quote : Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (B. Kernighan)

SolaceQuantum 7y ago

This is a strange read as a fiction writer. This lesson is learned quite early in prose writing- explicitly due to the fact that written works must be read. Maybe because of this, I've never felt the need to write 'cleverly' in my programming either. Can other prose writers corroborate?

thwd 7y ago
Good prose often involves misdirection. Making the reader believe something to be one way, while it was something else all along. Then, in a built up climax, undo the knot in a single pull to blow the reader's mind. That, to me, is the antithesis of the article's argument.
- kosievdmerwe 7y ago
  Sure, but if you know about misdirection, you also know how to appropriately direct attention to the parts of the code that is important.
steveklabnik 7y ago
I believe that approaching writing, including programming, to this, is reductive. At its base level, this is missing an important thing: context. Clear to who? Something can be very clear to one person, yet opaque to another. In writing, and in programming, you need to decide which audience that you're talking to, and write something that they will understand. This often comes up in discussions about jargon. Jargon is a way to increase the density of communication. This is often perceived as a loss of clarity, but the question again is, clarity for who? For two experts, discussing complex things in their field of expertise, jargon can increase clarity, by referring to shared context. Higher bandwidth communication allows for more discussion of more complex topics, because you're not wasting time and mental energy re-explaining things from first principles. Put another way, there is always some shared context going on; that's what language actually is in the first place. I have used a number of words in writing this comment, but I haven't set out any definitions; that's because I'm assuming that you know English in order to read my comment. If I were trying to communicate to a child, I wouldn't be using all of the words that I'm using here, because it is too complicated for them to comprehend. But, trying to explain the topic of this comment to that child would take much longer, and be much more difficult. So yeah, that's just one way in which discussions like these tend to frustrate me. Writing is a rich, wonderful thing, that has a huge variety of uses. Pigeon-holing it in this way makes me feel, well, dispirited. Or should I say "sad"... (I do believe that, for both commercial development of software, as well as commercial development of writing, "keeping things simple" can be important, for various reasons. But not everything we do in life must be in the service of business needs.)

o_nate 7y ago

I agree with the sentiment of the article, though I don't really like the example given. To me, using a switch statement instead of if-else-if is not any clearer.

kosievdmerwe 7y ago
I think for that particular example it's bad, but it might work better for a more complicated example with many more cases.

ngngngng 7y ago

The difficulty of giving examples to illustrate what "clarity" means really shows in this article. For the most part I evaluate software clarity by how many times I had to hit "goto definition" to see what was actually happening. But this takes us away from what the author was attempting to say. In my opinion, 95% of clarity comes down to writing good abstractions, and it is next to impossible to articulate what a good abstraction is. It's like describing the taste of salt.

audience_mem 7y ago
And even if one could articulate what a good abstraction is, someone would come along and disagree.
- zzzcpan 7y ago
  Because "good" just as "clear" is not universal. But we can actually estimate how good abstractions can be in specific circumstances for specific users if we think of them in terms of familiarity, simplicity, consistency, flexibility and universality.

kosievdmerwe 7y ago

The concept of clarity is why I don’t like the consequence of SOLID, where you have lots of tiny classes. It’s easier to understand complex functions and a simple class structure than the other way around. Because jumping between multiple files/classes incurs a high understandability cost, whereas complex functions fit on your screen typically. And reading some more about it, I found this good article: http://qualityisspeed.blogspot.com/2014/08/why-i-dont-teach-solid.html?m=1 http://qualityisspeed.blogspot.com/2014/08/why-i-dont-teach-...

azeirah 7y ago
I typically find it very difficult to understand complex functions, (100+ lines of code, ~3 or more nesting levels deep) and even simpler complex functions (mixing 2-3 concepts into a 15 line function). I've only just started doing TDD the "Growing Object Oriented Software guided by tests" way, and I find it incredibly helpful that each and every class does just _one_ thing, even splitting up those 15 line functions into two or three separate classes implementing an interface -- single responsibility -- helps me a lot in reasoning about the code. I _have_ experienced the dependencies issue myself already though, it's very annoying to click on a method in my IDE, and then get shown the interface definition of that particular method. I'll then have to trace my way through a couple of files to find the dependency, very annoying.
- kosievdmerwe 7y ago
  Yeah, but I would say it depends on context, clarity is very context dependent. Do what makes the code easiest to read taking into account that human limitations. Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. For instance, logic that filters what jobs to run based on conditions, it might make sense to abstract the logic for the conditions into one class per condition, to make the filtering logic clearer.
  - azeirah 7y ago
    > Sometimes splitting out code makes sense by making the underlying structure clearer, sometimes it makes it bothersome to find the actual important details. Yeah, that seems to be something I'll have to spend some time learning about. Right now I'm just mindlessly splitting off everything, and it kind of works, but it's annoying to navigate all over the place just to find some detail somewhere

tombert 7y ago

My rule of thumb has always been "the amount of comments I leave is directly proportional to how clever my code is". Code that is trivial really needs no elaboration, but occasionally I feel like I gotta go crazy with a bunch of hashmaps of lambdas and all that jazz, and I don't think that there's inherently anything wrong with that. However, when I do that, I make sure I document it like crazy with comments, so that when I have to look at the code two weeks later, I at least can figure out what I was doing.

hinkley 7y ago
I will agree with that but only if you put air quotes around “clever”. There is a point beyond which accurate documentation is more difficult than improving the code to negate some of that documentation. That makes the code cleverer still (without air quotes). This is not far off from St Antoine de Exupery’s comments on perfection being achieved when there is nothing left to take away.

RcouF1uZ4gsC 7y ago

The issue is that in Go speak, "clever" means any programming language technique that was invented after the 1970's. We are fortunate that the creators of Go felt comfortable with structured programming, or otherwise they might have felt that function calls with their compiler maintained stacks and local variables were "clever" and that we should all use goto statements since those are much clearer as to what is actually happening.

apta 7y ago
This is a summary of the mentality of the golang authors: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. Of course "good" software is subjective, as I've seen golang encourages otherwise.
- deleted 7y ago
  [deleted]

smacktoward 7y ago

This put me in mind of a passage from the (excellent) 1982 book Inside the Soviet Army, by the Soviet defector Vladimir Rezun (which can be read in English in its entirety here: http://militera.lib.ru/research/suvorov12/index.html http://militera.lib.ru/research/suvorov12/index.html), which explained why ammunition for Soviet weapons hadn't been standardized across a common set of calibers: The calibre of the standard Soviet infantry weapon is 7.62mm. In 1930, a 7.62mm `TT' pistol was brought into service, in addition to the existing rifles and machine-guns of this calibre. Although their calibre is the same, the rounds for this pistol cannot, of course, be used in either rifles or machine-guns. In wartime, when everything is collapsing, when whole Armies and Groups of Armies find themselves encircled, when Guderian and his tank Army are charging around behind your own lines, when one division is fighting to the death for a small patch of ground, and others are taking to their heels at the first shot, when deafened switchboard operators, who have not slept for several nights, have to shout someone else's incomprehensible orders into telephones-in this sort of situation absolutely anything can happen. Imagine that, at a moment such as this, a division receives ten truckloads of 7.62mm cartridges. Suddenly, to his horror, the commander realises that the consignment consists entirely of pistol ammunition. There is nothing for his division's thousands of rifles and machine-guns and a quite unbelievable amount of ammunition for the few hundred pistols with which his officers are armed. I do not know whether such a situation actually arose during the war, but once it was over the `TT' pistol-though not at all a bad weapon-was quickly withdrawn from service. The designers were told to produce a pistol with a different calibre. Since then Soviet pistols have all been of 9mm calibre. Why standardise calibres if this could result in fatally dangerous misunderstanding? Ever since then, each time an entirely new type of projectile has been introduced, it has been given a new calibre... [West Germany and France] have excellent 120mm mortars and both are working on the development of new 120mm tank guns... [W]hat happens if, tomorrow, middle-aged reservists and students from drama academies have to be mobilised to defend freedom? What then? Every time 120mm shells are needed, one will have to explain that you don't need the type which are used by recoilless guns or those which are fired by mortars, but shells for tank guns. But be careful-there are 120mm shells for rifled tank guns and different 120mm shells for smoothbore tank guns. The guns are different and their shells are different. What happens if a drama student makes a mistake? The Soviet analysts sit and scratch their heads as they try to understand why it is that Western calibres never alter. (This specific chapter can be read here: http://militera.lib.ru/research/suvorov12/06.html http://militera.lib.ru/research/suvorov12/06.html)

cgrealy 7y ago

Debugging code is more difficult than writing it. If you write the cleverest code you can, you are, by definition, not smart enough to debug it. /shamelessly stolen from somewhere I'm too lazy to look up.

steveklabnik 7y ago
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan, "The Elements of Programming Style"
- jodrellblank 7y ago
  Writing "for (int i=0; i<limit; i+=step) {}" is easy. Debugging the off-by-one error requires that you understand the alignment issue you ignored in the first place. That would make debugging harder, not because debugging is inherently hard, but because that's the place you're forced to deal with the hard bit you skipped earlier. I wonder how often that applies, compared to well-understood-but-implementation-mistake code?
- cgrealy 7y ago
  Damnit, I really should have remembered that :)
zzzcpan 7y ago
> Debugging code is more difficult than writing it. It's not. It's possible to not know how to do it well though. As it's something you have to experiment with, learn various approaches, instrumentation.
- cgrealy 7y ago
  I'm interested to hear what your rationale for this is. When you are writing code, you generally know what it is you are trying to achieve. When debugging code, you're frequently trying to find out why a problem is happening in the first place; often in code that someone has written or that you wrote months or even years ago. I'm not saying that debugging isn't a skill you can learn, but it's a superset of writing code, so it's by definition harder.

thsealienbstrds 7y ago

All these quotes remind me of another quote that I like: Simple and dirty beats complex and clean any day. - Learn C the Hard Way

stcredzero 7y ago
Unless simple and dirty is O(n^2) and simple and clean is O(n).
- mercer 7y ago
  and unless that matters.
  - stcredzero 7y ago
    I originally wrote O(n^4) vs. O(n^2), which is something that actually happened to me two days ago, but thought I'd go more basic. I should've gone real-world example. But yes, O(n^2) vs. O(n) can matter for large n.
    - mercer 7y ago
      I don't disagree though. Even though in much of my work performance is usually not a concern, I still run into plenty of situations where it really is. But I run into more situations where I probably spend more time optimizing when I don't need to. YMMV, obviously.
      - stcredzero 7y ago
        I'm forced to optimize unnecessarily in code reviews at work. Gotta save that extra microsecond when the user pushes that button!
        mercer 7y ago
        Ha, I spend a decent amount of time trying to explain to clients how it's worth their while to decrease a page's load time from 20+ seconds to < 5 in just a few hours of work...

DogLover_ 7y ago

Have to really disagree with the "comp" function example. No need to have "else" statements. The one with early returns and only "ifs" is succinct and good. Also what is up with comparator function being used this way for most articles nowadays? If I am not mistaken "return a-b" is the much better solution and don't say that it is considered too clever :)

panopticon 7y ago
"return a-b" is susceptible to overflows and may lead to subtle bugs depending on your language.
- audience_mem 7y ago
  In a sense it is the perfect example of "clear is better than clever", or perhaps "explicit is better than having buggy edge-cases"
- DogLover_ 7y ago
  Thanks, did not think about that!
city41 7y ago
The author states it's just an example and also says > This is reasonable when you’re dealing with functions which fit on a slide, but in the real world complicated functions– the ones we’re paid for our expertise to maintain–are rarely slide sized, and their conditions and bodies are rarely simple.

bryanrasmussen 7y ago

brevity is the soul of wit and the veil of clarity.

jonahx 7y ago
“Only short programs have any hope of being correct.” - Arthur Whitney
jodrellblank 7y ago
But .. verbosity is the veil of clarity? > verbiage: excessively lengthy or technical speech or writing. > synonyms: verboseness, padding, superfluity, redundancy, long-windedness, protractedness, digressiveness, convolution, circuitousness, rambling, meandering; waffling, wittering, "there is plenty of irrelevant verbiage but no real information"
deleted 7y ago
[deleted]

unicornporn 7y ago

...said Tom Cruise. (Sorry, I know this isn't reddit)

hyperpallium 7y ago

> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. https://wikiquote.org/wiki/Edsger_W._Dijkstra https://wikiquote.org/wiki/Edsger_W._Dijkstra > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? https://wikiquote.org/wiki/Brian_Kernighan https://wikiquote.org/wiki/Brian_Kernighan

jodrellblank 7y ago
Being quoted several times in this thread; what about the experience of finding something feels "clever" but then after a while of using it, finding it no longer feels clever but instead feels normal? > Every weightlifter is fully aware of the strictly limited size of his own muscles; therefore he approaches the weight lifting task in full humility and among other things he avoids heavy weights like the plague.
- raincom 7y ago
  As more people are familiar with a clever trick, it becomes an idiom, which others master. Now it is in the realm of "clear", graduating from the realm of purgatory of clever tricks.
  - hyperpallium 7y ago
    ...if generally applicable. Then, hopefully, from idiom to abstraction.
- usbseeker 7y ago
  You don't have to figure out how to lift the weight.
  - Kye 7y ago
    I'm no weight lifter, but I do know lifting weights is highly skilled unless you're into permanent injury.

mrkeen 7y ago

Two men enter a bar. One is taller than the other. Which one is taller? -1.

mrkeen 7y ago
I guess the downvoter didn't like me pointing out int is a shitty way to answer the question "which is bigger?" in an article supposedly selling clarity over cute tricks.
hi41 7y ago
The first one!

jodrellblank 7y ago

> Here we have a comp function that takes two ints and returns an int; Ah, "comp"utation. "comp"lex numbers? "comp"licated function? "comp"onent? "comp"anion numbers, is that a thing? "comp"rehensive example? Saving three characters of typing is more important than being clear?

ufo 7y ago

That switch case transformation in the end is just syntactic sugar for the equivalent if-else-if chain so I am not sure it is actually an improvement. That said, I still agree with the basic idea. An if-else-if chain is easier to reason about than if-return, and representing information with enum or algebraic data type can be more robust than using a combination of booleans.

mdpopescu 7y ago
The whole point of syntactic sugar is that it makes a code fragment easier to read / understand. That's why we're not calling it syntactic poison.

nightcracker 7y ago

I think clever stuff should be behind clear APIs.

apta 7y ago

> If software cannot be maintained, then it will be rewritten; and that could be the last time your company invests in Go. Maybe on to something there, golang code bases I've seen are a complete mess because of how "simple" the language is. Hopefully more people start realizing this and moving on to better languages.

zzzcpan 7y ago
In my experience Golang code bases are messy because of two things: OO and CSP. People all too often resort to goroutines, channels, objects and interfaces where a simple side-effect free function could do.
- apta 7y ago
  It's ironic because the golang authors say that golang is not "OO". Of course, not that there's anything wrong with properly done OO, it's just that golang's implementation of it is botched.

miccah 7y ago

Code is written and read by humans, therefore it should be clear and concise. Cleverness should be used in constrained situations like performance (fast inverse square root [1] comes to mind), and comments explaining the cleverness is important. I should note [1] did a terrible job at commenting. [1] https://en.m.wikipedia.org/wiki/Fast_inverse_square_root https://en.m.wikipedia.org/wiki/Fast_inverse_square_root

flowerlad 7y ago

Ability to make complex things simple is what sets apart a great programmer from an average one. So why do most programmer interviews at companies such as Google focus on writing performant code instead? Most professional programmers only occasionally need to look into performance issues, but need to take complex things and simplify them with every line of code they write. And yet most programming interviews don’t evaluate this ability. I think this should change.

james_s_tayler 7y ago
We have this discussion on HN every month. So far the answer I've worked out is: Because its optimal solution to let talent flow through BigCo in SV. There is no domain or tech-stack specific stuff. So studying for the interview process allows the applicant to apply for multiple companies. At the same time it's a pretty hardcore process, so the company knows they are getting engineering talent that is a) smart and b) obedient. For the rest of the world it absolutely doesn't make sense and that's why where I live, you don't see that style of interviews at all.
- flr03 7y ago
  I came up with the same conclusion. It's not a technical test in such, it's more a competition/motivation test.
- wpietri 7y ago
  One thing I'd add: One possible function of an interview process is to find qualified interviewees. Another is to make interviewers feel smart. I think typical BigCo interview processes are optimized for the latter. David Epstein's new book Range talked about academic research splitting domains into kind vs wicked. Kind learning domains are ones where "feedback links outcomes directly to the appropriate actions or judgments and is both accurate and plentiful", while wicked ones are "situations in which feedback in the form of out-comes of actions or observations is poor, misleading, or even missing". [1] The hard parts of real-world software development are generally in the "wicked" bucket. Schoolwork and puzzle questions are both generally "kind" in the sense that there's a right answer and you're expected to figure it out. It's impossible to be too smug working on "wicked" problems because you get your ass kicked often enough to stay humble. But in "kind" domains it's quite easy to indulge one's desire to feel superior by dragging people through things you know well. Personally, when I interview people I try to set things up so that there's no right answer; the goal is to see how well they get to good answers, and how well they collaborate during that process. I'd love to see more people do that. [1] https://pdfs.semanticscholar.org/5c5d/33b858eaf38f6a14b3f042202f1f44e04326.pdf https://pdfs.semanticscholar.org/5c5d/33b858eaf38f6a14b3f042...

vemv 7y ago

<subjective thing> is better than <subjective thing>. Oh thanks, that was so useful.

dang 7y ago
Please don't be snarky and please don't post shallow dismissals here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

AngeloAnolin 7y ago

I think one reason why people like to write supposedly clever code especially on the realm of software development is due to lots of these developers want to get acknowledgement of what they produce. And hearing someone say "Oh, this is a very clever implementation" sort of fix that inherent need to be recognized. I haven't heard (particularly in corporate environments) where a praise in the line of - "wow, this was a very clear and simple implementation" trump what managers and people deem as superior when the term clever was attached to it. I've challenged far quite a lot of implementations where understanding a piece of functionality has required for the developer to jump between more than 23 files across 8 different projects in implementing a very domain specific functionality. Splitting code into single independent parts introduces simplicity, only and if only you are reading that part by itself, but when you layer it overall to get the functionality it delivers and it becomes a web of tangled mess of code, then that clever solution was not really clever after all.

hinkley 7y ago
I have an intuition about library design that I’ve been slowly trying to formulate into a set of guidelines. I have extremely high standards in this area and not being able to state them concretely makes communicating them a struggle. One of the ways I complain about particularly bad decomposition (the sort of practices that lead to parodies like Enterprise FizzBuzz) is the ridiculousness of stacktraces for errors in these systems. We tell people to use delegation but many have trouble differentiating delegation from indirection. You know things have gotten particularly bad when you have traces with the same sequence of three or more functions appearing three times. Debugging this is a nightmare. It’s literally a maze of logic. This type of code has to be memorized to be understood, which further makes an existential threat of a saner person’s attempts to refactor it - moving things around to be discoverable and debuggable comes at a cost to the people who already memorized it. There is also DAMP vs DRY and “desertification” of code, which is related to the good versus bad indirection problem. When you get a prolific “clever” person who suffers from these problems, the whole team suffers with them (which is why I need a new job...). Someone above mentioned flame graphs, which is a trace of every call in the system, typically for the purpose of visualizing where time is spent by the CPU. In thinking about this thread, I now want to look into using them as a measure of time spent by the reader. My overall philosophy on code is that we should use our best days to protect ourselves from our worst days. I expend most of my clever on trying to make things look easy, which is a bit of a challenge come review time because one of the hallmarks of really clever reasoning is that people react by saying things like, “well of course it works that way”.

ksaj 7y ago

Nice. I said exactly this for the same reason yesterday. In that case it was a thread about Lisp. Here's the comment: > Even the open source Common Lisp compilers, written by arguably the lispiest of Lispers, don’t have a lot of “cleverness”. To which I replied my agreement: > Don't write clever. Write clear. Its a sentiment that you find attached to Lisp programming style fairly often, although ironically there is a whole lot of barely readable Lisp code out there. Personally, I think the code is (nearly) worthless crap if someone with skill has to spend as much time parsing it as the writer did writing it. https://news.ycombinator.com/item?id=20376344 https://news.ycombinator.com/item?id=20376344

k__ 7y ago

Often I only need clever for performance reasons. I write a filter/map, which is slow in some languages, but looks readable and if I need better perf I rewrite it with a for loop.

makecheck 7y ago

If you have only a final “else” instead of a bare “return” in a function that returns a value, you are making it worse. Now when I read the code, my first instinct is “seems to be a bug, undefined behavior” and I have to read more carefully. This is a terrible example and a code change I would never approve. The clarity-over-cleverness goal is good but not with these kinds of cases.

peter_vukovic 7y ago

Creating anything is a craft and creating software programs is no different. While everyone should strive to learn how to write programs well so the intent isn’t obfuscated, it ultimately boils down to two factors: programmer’s experience and talent. Most programs, like most works of art, will be utter crap and nonsense, as most artists are - with rare notable differences. This is why I heavily support frameworks and prescriptive style of programming, or “opinionated” systems as some would call them. They are usually invented by people much smarter than the average Joe and ultimately generate better long term results. It would benefit our productivity much more if we invested efforts into translating these brilliant minds into compiler features so the compiler checks for style as well, not just “spelling”. We need Grammarly for code.