7 ms·

Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the

Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.

solitus 7y ago
+1 from me. Every time I revisit code that I wrote cleverly I roll my eyes at myself. What was I trying to prove, now I have to put more effort in understanding my "cleverness" instead of quickly going through the change I have to implement.
lukifer 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?" http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/
- iudqnolq 7y ago
  Your link goes on to say that this doesn't mean the obvious. They say that cleverness isn't innate, and that writing code that you have trouble understanding later will force you to grow as a programmer > If we deliberately stay away from clever techniques when writing code, in order to avoid the need for skill when debugging, we dodge the lever and miss out on the improvement. We would then need other sources of motivation in order to grow as programmers, and if no such motivation appears, our abilities stagnate (or even deteriorate). I'm not experienced enough to guess if this is accurate, but I found it very interesting
WClayFerguson 7y ago
Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the same code that's difficult to understand, and difficult to debug. Always code for your future-self and future-others who really don't want to spend an hour figuring out what the hell you did in that awesome looking 30 lines of entropy.
- wutbrodo 7y ago
  Sometimes you're lucky enough to have this expedited; my first CL at my first job was beautiful and elegant and concise and needlessly complex, and I was told to unroll it to make it more readable. The lesson sunk in the minute I had to start reading other people's code.
  - WClayFerguson 7y ago
    "Expedited" haha. yep. I mean there are times when something is going to cause just totally complex code to be required, but in those cases there should almost always be a full paragraph of "explanation" (documentation) for about every 10 or so lines of code. Ends up with actually more documentation text than code itself, which is a good thing. But for the majority of code it an be kept simple and self-documenting.
- flukus 7y ago
  IME it's about time spent maintaining code rather than an age/experience thing, devs that flock like locusts from green field to green field will never learn, devs that maintain "clever" code will learn pretty quickly.
- Tainnor 7y ago
  Sure, but the converse is that when you have a 10k+ LOC project, you can't read that program linearly anymore. I find that sometimes proponents of "straight-forward code" strive for code to be immediately understandable line-by-line, but in big projects, this is not how you navigate a project; you have to create the right modules and abstractions, otherwise you will get lost.
  - WClayFerguson 7y ago
    I've worked mostly on massive apps with 400K to 1 or 2 million lines of code, in many projects, so the concept of linearly reading thru the code is something that just never happens. But with a "keep it simple" philosophy the number of lines of actual code never really matters that much, while code where the developers were clever and complex at every opportunity (often just showing off) the code is quicksand and a quagmire every every single line of the way, and is a nightmare.
alexanderscott 7y ago
^this +1. took me years to learn.
Buttons840 7y ago
Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too clever", was it because someone used a map, but you're more comfortable with for loops, or was it bigger than that? My first job was maintaining some PHP. The author didn't know what a function was. The code was a 5,000 line script, top to bottom, with basic control and looping logic nested up to 17 deep (I counted). It was horrible. Yet surely, the author had avoided cleverness at all costs; he had built a working system with only the most basic tools, those being all he knew.
- hellofunk 7y ago
  Generally bigger than that, though long clever statements using functional idioms like you suggest could be hard to read in some languages. Cleverness also refers to architecture, designing meta-types to encapsulate all sorts of things that just don't need the flexibility, over-designing a system in anticipation of future needs that may never come. Sometimes it's a delicate balance and often only experience can dictate how "clever" one should be. Many developers just out of university, or still in it, in certain languages, like to run with clever things they can do with the type system to abstract away all sorts of stuff, which becomes painful later.
- iainmerrick 7y ago
  A couple of examples from Java/Kotlin code: - Too much business logic hidden behind dependency injection (using Dagger in this instance). I think DI should be used sparingly, to decouple large subsystems like the database or the network. It can feel clever to inject everything, so your system is super modular and decoupled, but that just makes it much harder to understand, with little or no real benefit. - Somewhat related, excessive use of annotations to accomplish tasks that could be done in a more straightforward way with normal code. For example, in Android, you might have an annotation that adds some fragment to your activity as a mix-in; but is that really easier than just calling a function to do the same thing? This stuff starts to cause real trouble when there are 1000 occurrences sprinkled through your code, and suddenly you need to step through it to debug a tricky problem. Straight-line code is vastly easier to deal with. So I’d say “clever” is more of a problem at an architectural level, rather than inside individual functions. At the low level, shorter is almost always better. If somebody comes up with a clever way to reduce a function from 10 lines to 4, say, that’s great -- as long as its purpose is clear and it’s testable.

Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.

solitus 7y ago

+1 from me. Every time I revisit code that I wrote cleverly I roll my eyes at myself. What was I trying to prove, now I have to put more effort in understanding my "cleverness" instead of quickly going through the change I have to implement.

lukifer 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?" http://www.linusakesson.net/programming/kernighans-lever/ http://www.linusakesson.net/programming/kernighans-lever/

iudqnolq 7y ago
Your link goes on to say that this doesn't mean the obvious. They say that cleverness isn't innate, and that writing code that you have trouble understanding later will force you to grow as a programmer > If we deliberately stay away from clever techniques when writing code, in order to avoid the need for skill when debugging, we dodge the lever and miss out on the improvement. We would then need other sources of motivation in order to grow as programmers, and if no such motivation appears, our abilities stagnate (or even deteriorate). I'm not experienced enough to guess if this is accurate, but I found it very interesting

WClayFerguson 7y ago

Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the same code that's difficult to understand, and difficult to debug. Always code for your future-self and future-others who really don't want to spend an hour figuring out what the hell you did in that awesome looking 30 lines of entropy.

wutbrodo 7y ago
Sometimes you're lucky enough to have this expedited; my first CL at my first job was beautiful and elegant and concise and needlessly complex, and I was told to unroll it to make it more readable. The lesson sunk in the minute I had to start reading other people's code.
- WClayFerguson 7y ago
  "Expedited" haha. yep. I mean there are times when something is going to cause just totally complex code to be required, but in those cases there should almost always be a full paragraph of "explanation" (documentation) for about every 10 or so lines of code. Ends up with actually more documentation text than code itself, which is a good thing. But for the majority of code it an be kept simple and self-documenting.
flukus 7y ago
IME it's about time spent maintaining code rather than an age/experience thing, devs that flock like locusts from green field to green field will never learn, devs that maintain "clever" code will learn pretty quickly.
Tainnor 7y ago
Sure, but the converse is that when you have a 10k+ LOC project, you can't read that program linearly anymore. I find that sometimes proponents of "straight-forward code" strive for code to be immediately understandable line-by-line, but in big projects, this is not how you navigate a project; you have to create the right modules and abstractions, otherwise you will get lost.
- WClayFerguson 7y ago
  I've worked mostly on massive apps with 400K to 1 or 2 million lines of code, in many projects, so the concept of linearly reading thru the code is something that just never happens. But with a "keep it simple" philosophy the number of lines of actual code never really matters that much, while code where the developers were clever and complex at every opportunity (often just showing off) the code is quicksand and a quagmire every every single line of the way, and is a nightmare.

alexanderscott 7y ago

^this +1. took me years to learn.

Buttons840 7y ago

Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too clever", was it because someone used a map, but you're more comfortable with for loops, or was it bigger than that? My first job was maintaining some PHP. The author didn't know what a function was. The code was a 5,000 line script, top to bottom, with basic control and looping logic nested up to 17 deep (I counted). It was horrible. Yet surely, the author had avoided cleverness at all costs; he had built a working system with only the most basic tools, those being all he knew.

hellofunk 7y ago
Generally bigger than that, though long clever statements using functional idioms like you suggest could be hard to read in some languages. Cleverness also refers to architecture, designing meta-types to encapsulate all sorts of things that just don't need the flexibility, over-designing a system in anticipation of future needs that may never come. Sometimes it's a delicate balance and often only experience can dictate how "clever" one should be. Many developers just out of university, or still in it, in certain languages, like to run with clever things they can do with the type system to abstract away all sorts of stuff, which becomes painful later.
iainmerrick 7y ago
A couple of examples from Java/Kotlin code: - Too much business logic hidden behind dependency injection (using Dagger in this instance). I think DI should be used sparingly, to decouple large subsystems like the database or the network. It can feel clever to inject everything, so your system is super modular and decoupled, but that just makes it much harder to understand, with little or no real benefit. - Somewhat related, excessive use of annotations to accomplish tasks that could be done in a more straightforward way with normal code. For example, in Android, you might have an annotation that adds some fragment to your activity as a mix-in; but is that really easier than just calling a function to do the same thing? This stuff starts to cause real trouble when there are 1000 occurrences sprinkled through your code, and suddenly you need to step through it to debug a tricky problem. Straight-line code is vastly easier to deal with. So I’d say “clever” is more of a problem at an architectural level, rather than inside individual functions. At the low level, shorter is almost always better. If somebody comes up with a clever way to reduce a function from 10 lines to 4, say, that’s great -- as long as its purpose is clear and it’s testable.