4 ms·

While the author is suggesting some good techniques, I suspect that if your code is being criticised for being “clever”, you’re unlikely to improve the situatio

While the author is suggesting some good techniques, I suspect that if your code is being criticised for being “clever”, you’re unlikely to improve the situation by arguing that in fact it’s “insightful”. In my view, the most important aspect of what we mean by “clever code” is that the “cleverness” primarily serves to demonstrate how clever the programmer is. In other words, in some sense it obfuscates what the code is actually doing or why certain choices have been made, without delivering sufficient benefit to outweigh the cost to readability and maintainability. To use their bucket sort example, probably you’d want to stick a quick comment in the code that bucket sort has been chosen (and why). That helps with readability. But there’s nothing “clever” about choosing a standard algorithm to solve a problem. Absolutely, making the right choice demonstrates insight - but it also demonstrates genuine cleverness. Really it boils down to how it doesn’t matter whether the code is being called “clever”, “insightful”, or “amazing”. It matters whether a) the tone is dripping with sarcasm, or b) the tone is respectful but the feedback also contains a warning to format and comment for readability.

mtrycz2 5y ago
We don't write code for computers to run, but for other programmers to read. Best make it so that they understand it. Who "they" is might be dependent on the situation.
- engmgrmgr 5y ago
  If you have either high performance real time needs, and it’s impactful to do so, or tight deliverables where performance is some component, the code is often written for a computer over a human. The more specialized or niche certain project areas are, the less likely anyone will ever be reading it directly as a programmer (and those that need to, are often able to disentangle the obscurity). The compromise is a clean interface to otherwise isolated or pure functions. Often times, this is unfortunately poorly executed or inappropriately assumed. Usually the people who should write clever code are the ones who have experience writing clever code, but almost certainly anyone starting to write clever code is writing terrible code. Inexperienced folks often write clever code to solve a business need at that time. They create tremendous tech and culture debt. It’s easy to not understand when you’re an IC or line manager, though, that the business could have been severely affected otherwise. I’ll take millions in tech debt opportunity cost and the future morale hit over a failed startup/vertical any day. Just my 2c in high performance or hardware constrained projects both as an IC, and as various levels of management who’s both inherited mountains of “clever” shit and and built my own directly or indirectly.
  - Cthulhu_ 5y ago
    True, but you'd be operating on a different level entirely - and clarity of the code is still important. You can have both, it's not a dichotomy. I see going "down" to low level, high performance code as crossing into a different domain, so you write the code aimed at that domain. It's all Klatchian to me personally, but I've seen high performance code that I could still decypher. decode. That. You can use naming, formatting and comments where needed to ensure that you and the next person can read and understand it without affecting performance.
- Chris_Newton 5y ago
  We don't write code for computers to run, but for other programmers to read. Well, maybe sometimes we shouldn’t. Let’s pick a topical example. Suppose we have a tool used by JS developers, itself written in straightforward JS. Its code is nice and easy to read, and it does the job. However, it takes 5s to process a source tree containing a few thousand lines of code. Now suppose we could have an alternative version of that tool, written by a skilled developer using a more performance-oriented language, and placing greater emphasis on runtime performance even if it means sacrificing some readability in the source code. This might do the same job in well under a second. As esbuild¹ has shown, this scale of performance improvement is realistic. Maybe this tool gets run 50 times per day. Then a single developer using it could justify spending about a week writing the faster alternative tool to break even on time saved over five years. (There’s an xkcd² about this that is worth a look if you haven’t seen it before.) But maybe this tool doesn’t have just one user, it has one million. Then those frequent 5s inefficiencies add up to several hundred users’ entire careers in lost productivity over that same five-year span. That’s a high price to pay for writing software in a way that is more convenient for developers but less good for users. ¹ https://esbuild.github.io/ https://esbuild.github.io/ ² https://xkcd.com/1205/ https://xkcd.com/1205/
  - rikroots 5y ago
    I found a practical example of this last week. For years (literally!) I've been on the lookout for an efficient Javascript blur algorithm. I've attempted to code them myself following various online tutorials, or lift the code from others who seemed to have better insights into various algorithmic approaches than me. Because I struggle with complex mathematical concepts, I've tended to steer clear of code that looks nothing like Javascript. Then last week I discovered a blisteringly fast gaussian blur algorithm in a GitHub repository[1] which translated work done by some very clever Intel developers[2] into Javascript. I copy-pasted the code on blind trust into my library code, then tweaked more in hope than knowledge to get it to bed in and play nicely[3] ... and it works! 40px radius gaussian blurs over 800x800px images at 60fps (in a 2D canvas - no webgl gets hurt by this algorithm). I consider myself a well-versed JS coder, yet I've stared at this code until my eyes water: none of it makes sense to me. All I know is that it works by magic, and that makes me happy! [1] - https://github.com/nodeca/glur/blob/master/index.js https://github.com/nodeca/glur/blob/master/index.js [2] - https://software.intel.com/en-us/articles/iir-gaussian-blur-filter https://software.intel.com/en-us/articles/iir-gaussian-blur-... - page redirects if you're not logged in [3] - my tweaked code - https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEngine.html#section-30 https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEn...
BrissyCoder 5y ago
I think there's another class of "clever/amazing" code that wraps up esoteric language features in easy to use APIs/libraries. So while the actual implementation can be quite hard to follow/understand (especially for novices) consuming the service is incredibly easy and makes an otherwise arduous task simple and requiring far less code. I've found myself writing these kind of modules often over the years. They often use RTTI/reflection and generics and make a task declarative rather than procedural. A couple that spring to mind are a messaging/subscription framework in C++ (heavy use of templates) and a reporting API in C# (lots of reflection). Always do my best to make the implementation comprehensible but there's only so much you can do when they require a deep understanding of the language.
Cthulhu_ 5y ago
I've written some (in my head) really clever code, changing a 15 line loop to a single line functional thing. But it didn't become clearer, and learning the functional language like map, filter, reduce etc takes some time. I read an article the other day that also pointed out how functional constructs in an otherwise imperative language are painful. Not completely useless, but not the be-all and end-all. It was in the context of Go, where if you were to naively write some algorithms into functional constructs (like the underscore.js utilities), performance would take a massive nosedive. It's not a functional language, and shouldn't be used as such.

mtrycz2 5y ago

We don't write code for computers to run, but for other programmers to read. Best make it so that they understand it. Who "they" is might be dependent on the situation.

engmgrmgr 5y ago
If you have either high performance real time needs, and it’s impactful to do so, or tight deliverables where performance is some component, the code is often written for a computer over a human. The more specialized or niche certain project areas are, the less likely anyone will ever be reading it directly as a programmer (and those that need to, are often able to disentangle the obscurity). The compromise is a clean interface to otherwise isolated or pure functions. Often times, this is unfortunately poorly executed or inappropriately assumed. Usually the people who should write clever code are the ones who have experience writing clever code, but almost certainly anyone starting to write clever code is writing terrible code. Inexperienced folks often write clever code to solve a business need at that time. They create tremendous tech and culture debt. It’s easy to not understand when you’re an IC or line manager, though, that the business could have been severely affected otherwise. I’ll take millions in tech debt opportunity cost and the future morale hit over a failed startup/vertical any day. Just my 2c in high performance or hardware constrained projects both as an IC, and as various levels of management who’s both inherited mountains of “clever” shit and and built my own directly or indirectly.
- Cthulhu_ 5y ago
  True, but you'd be operating on a different level entirely - and clarity of the code is still important. You can have both, it's not a dichotomy. I see going "down" to low level, high performance code as crossing into a different domain, so you write the code aimed at that domain. It's all Klatchian to me personally, but I've seen high performance code that I could still decypher. decode. That. You can use naming, formatting and comments where needed to ensure that you and the next person can read and understand it without affecting performance.
Chris_Newton 5y ago
We don't write code for computers to run, but for other programmers to read. Well, maybe sometimes we shouldn’t. Let’s pick a topical example. Suppose we have a tool used by JS developers, itself written in straightforward JS. Its code is nice and easy to read, and it does the job. However, it takes 5s to process a source tree containing a few thousand lines of code. Now suppose we could have an alternative version of that tool, written by a skilled developer using a more performance-oriented language, and placing greater emphasis on runtime performance even if it means sacrificing some readability in the source code. This might do the same job in well under a second. As esbuild¹ has shown, this scale of performance improvement is realistic. Maybe this tool gets run 50 times per day. Then a single developer using it could justify spending about a week writing the faster alternative tool to break even on time saved over five years. (There’s an xkcd² about this that is worth a look if you haven’t seen it before.) But maybe this tool doesn’t have just one user, it has one million. Then those frequent 5s inefficiencies add up to several hundred users’ entire careers in lost productivity over that same five-year span. That’s a high price to pay for writing software in a way that is more convenient for developers but less good for users. ¹ https://esbuild.github.io/ https://esbuild.github.io/ ² https://xkcd.com/1205/ https://xkcd.com/1205/
- rikroots 5y ago
  I found a practical example of this last week. For years (literally!) I've been on the lookout for an efficient Javascript blur algorithm. I've attempted to code them myself following various online tutorials, or lift the code from others who seemed to have better insights into various algorithmic approaches than me. Because I struggle with complex mathematical concepts, I've tended to steer clear of code that looks nothing like Javascript. Then last week I discovered a blisteringly fast gaussian blur algorithm in a GitHub repository[1] which translated work done by some very clever Intel developers[2] into Javascript. I copy-pasted the code on blind trust into my library code, then tweaked more in hope than knowledge to get it to bed in and play nicely[3] ... and it works! 40px radius gaussian blurs over 800x800px images at 60fps (in a 2D canvas - no webgl gets hurt by this algorithm). I consider myself a well-versed JS coder, yet I've stared at this code until my eyes water: none of it makes sense to me. All I know is that it works by magic, and that makes me happy! [1] - https://github.com/nodeca/glur/blob/master/index.js https://github.com/nodeca/glur/blob/master/index.js [2] - https://software.intel.com/en-us/articles/iir-gaussian-blur-filter https://software.intel.com/en-us/articles/iir-gaussian-blur-... - page redirects if you're not logged in [3] - my tweaked code - https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEngine.html#section-30 https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEn...

BrissyCoder 5y ago

I think there's another class of "clever/amazing" code that wraps up esoteric language features in easy to use APIs/libraries. So while the actual implementation can be quite hard to follow/understand (especially for novices) consuming the service is incredibly easy and makes an otherwise arduous task simple and requiring far less code. I've found myself writing these kind of modules often over the years. They often use RTTI/reflection and generics and make a task declarative rather than procedural. A couple that spring to mind are a messaging/subscription framework in C++ (heavy use of templates) and a reporting API in C# (lots of reflection). Always do my best to make the implementation comprehensible but there's only so much you can do when they require a deep understanding of the language.

Cthulhu_ 5y ago

I've written some (in my head) really clever code, changing a 15 line loop to a single line functional thing. But it didn't become clearer, and learning the functional language like map, filter, reduce etc takes some time. I read an article the other day that also pointed out how functional constructs in an otherwise imperative language are painful. Not completely useless, but not the be-all and end-all. It was in the context of Go, where if you were to naively write some algorithms into functional constructs (like the underscore.js utilities), performance would take a massive nosedive. It's not a functional language, and shouldn't be used as such.