I've noticed a lot of questions lately relating to different abstraction techniques, and answers saying basically that the techniques in question are "too clever." I would think that part of our jobs as programmers is to determine the best solutions to the problems we are given to solve, and cleverness is helpful in doing that.

So my question is: are the people who think certain abstraction techniques are too clever opposed to cleverness per se, or is there some other reason for the objection?

EDIT: This parser combinator is an example of what I would consider to be clever code. I downloaded this and looked it over for about half an hour. Then I stepped through the macro expansion on paper and saw the light. Now that I understand it, it seems much more elegant than the Haskell parser combinator.

  • 116
    I think perhaps you're misunderstanding - cleverness in a person is a virtue, but cleverness in a system is a vice. Systems and code should not be clever, they should be clear as crystal. It often takes a clever individual to create such things. – nlawalker Dec 10 '10 at 17:15
  • 3
    Similar to What's so bad about creative coding? – Nicole Dec 10 '10 at 17:17
  • 15
    @nlawalker: I think I get it now. People use the word "clever" when referring to code as an antonym for "clear" or "simple" because they really mean to use a word that is an antonym for "clear" or "simple". – Larry Coleman Dec 10 '10 at 17:19
  • 2
    @Larry: I'm not sure what that would imply. Clever as in inventive, original, ingenius and by implication using things in a way you've never seen before. Sometimes it's great (a lot of design patterns are clever) but the foreignness of the solution could also make it difficult to work with. – doppelgreener Dec 10 '10 at 17:49
  • 2
    Does no-one comment code any more? That's where you explain the cleverness, so those that follow can understand. Like you in 6 months time. – Phil Lello May 5 '11 at 2:54

28 Answers 28


Simple solutions are better for long-term maintenance. And it's not always just about language familiarity. A complex line (or lines) takes time to figure out even if you're an expert in the given language. You open up a file and start reading: "ok, simple, simple, got it, yep, WTF?!" Your brain comes to a screeching halt and you now have to stop and decipher a complicated line. Unless there was a measurable, concrete reason for that implementation, it is "too clever".

Figuring out what's going on gets progressively harder as complexity grows from a clever method to a clever class to a clever pattern. Aside from well-known approaches, you have to figure out the thought process that went into creating a "clever" solution, which can be quite difficult.

That said, I hate avoiding a pattern (when its use is justified) just because someone might not understand it. It's up to us as developers to keep learning and if we don't understand something, it's a reason to learn it, not to avoid it.

  • 7
    +1 Nicely said. I think it's a balance thing. If I can expect someone with a decent amount of knowledge to understand the code with a little thinking of himself, you can go for clever and maybe add a comment. If it takes four times as long to understand the code just because someone wanted to prove their coding skills - nah! If someone is smart enough to come up with a clever solution, they should be smart enough to decide whether it's understandable or not. Otherwise it's just showing off. – Anne Schuessler Dec 10 '10 at 17:21
  • The last paragraph I like. The rest is true, but unfortunate. – Orbling Dec 10 '10 at 20:51
  • Looks like you've seen the source code to Zend PHP :) – Tim Post Dec 11 '10 at 7:44
  • +1 A simple pattern may not perform as well as a clever pattern, and like you said, it's up to us as developers to continue to push the envelope of "clever" by understanding it. – Stephen Furlani Dec 14 '10 at 15:53
  • 3
    As someone who has had to justify doing something "clever" when it was really just "minimally, orthogonally correct", I would like to add that there is some subjectivity on the question of what exactly is clever. For example, some people will always want to write out if FuncX() then return true, else return false, and will never want you to just write return FuncX(). I'm not kidding, I've literally had that conversation. Because people want somewhere to hang their breakpoints, or something. :-) – Warren P Mar 21 '13 at 21:05

KISS Principle

Keep it simple, stupid. Clever solutions are great, but often the simplest straight forward solution is best.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Brian Kernighan

  • 8
    On the other hand, if you write code as cleverly as you can, you then must learn to debug it, and in doing so you become more clever. Or something like that. – James McNellis Dec 10 '10 at 18:18
  • 11
    @James: Or you just fail. ;) – Josh K Dec 10 '10 at 19:37
  • 10
    @Josh K: I've always known KISS as "Keep It Simple, Stupid!" - en.wikipedia.org/wiki/KISS_principle – Orbling Dec 10 '10 at 20:52
  • 1
    @Orbling: I recalled it differently, oh well, now I know. – Josh K Dec 11 '10 at 3:54
  • 1
    "Keep it simple and be stupid", according to Wikipedia? :) Does this mean keeping it simple is stupid or that to keep it simple you must be stupid? :P – Mateen Ulhaq Oct 19 '11 at 0:19

Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. -- Alan Perlis

  • 5
    +1 for the nice quote and for being the first answer without the implicit assumption that something can't be both simple and clever – Larry Coleman Dec 10 '10 at 17:07
  • 15
    What is important is that it is the programmer who is supposed to be clever, not the code. – Kristopher Johnson Dec 10 '10 at 20:58
  • Way better quote then an idiot misusing the word clever in a clever way. – Derek Litz Sep 30 '13 at 4:40

The best solution is not always the most clever solution. Sometimes simple solutions are equally good.

In Software you always need to think in terms of maintainability. If a piece of code is too clever for someone who is going to maintain it, I would say that cleverness is not worth it.

  • 3
    A simple solution to a complex problem is about as clever as anyone can get. – JeffO Dec 10 '10 at 19:18
  • although there is always the caveat that you don't want to over-simplify just because the maintainer can't code (or read it). – Ken Henderson Dec 10 '10 at 23:08
  • @confusedGeek - but if you know the maintenance programmer's can't handle it, then the clever solution becomes a time bomb. Balance is key here - and this only applies if you happen to know the maintenance team. If you have no idea, then being clear in your cleverness is the best you can do. – Michael Kohne Dec 11 '10 at 2:53
  • 1
    @Michael, performance constraints may require that your code be clever. It is then the maintainer's job to learn, and if they can't, hire new maintainers. – Stephen Furlani Dec 14 '10 at 15:59
  • @Stephen, if the code NEEDS to be clever, the programmer should take great care to explain WHY it needs to be, so the maintainer do not have to start from scratch. – user1249 Feb 8 '11 at 19:36

To quote Brian Kernighan:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

  • "... Unless you used the correct definition of clever and the code is actually simple to understand and debug." – Derek Litz Sep 30 '13 at 5:03
  • Depends on whcich dictionary you thumb, I guess. In my experience, any "clever" code - easy to udnerstand or not - still exploits a fortunate conjunction in the spec. Even if it's obvious, it should be marked if such an assumption may change and shouldn't leak to different parts of the code. – peterchen Oct 1 '13 at 15:24
  • You are right, but I'd like to add the caveat that it depends on how easy the language and implementation is to read and understand, and your comments may just be code noise instead of something helpful. And while it is common to use clever to mean its opposite, we should strive to be more clear so others cannot misconstrue things for their own advantage. – Derek Litz Oct 1 '13 at 17:09
  • No objection to that :) – peterchen Oct 2 '13 at 8:05

cleverness is a tool; by itself it is not harmful. It only becomes harmful in context where it is not necessary.


"Clever", when applied to code, is almost always just a euphemism for "needlessly complicated".

Reading good, clear, simple code is hard enough. Reading "clever" code is like studying latin poetry all over again.

The confusion arises because "clever" as an attribute of a person has a completely different meaning. This case can also be seen as an example of why designing software for real people is hard: Because they are ambiguous.

And because some programmers suffer to understand the social protocols most people follow, which forbid them to directly denounce code as "needlessly complicated", they may find it hard to differentiate between the two meanings of the word clever. Contrary to what some may think, I think ultimately better "people persons" (meaning: people who have empathy and introspection and patience) make better developers. Because they know who to write for.

  • 5
    I would have upvoted this had you not gotten preachy about social protocols and "people persons [sic]". – Jason Baker Dec 11 '10 at 1:27
  • 2
    That's OK- and thanks for reminding me. I tend to get too preachy. But I'm rellay irked by some (many?) Programmers' inability and/or unwillingness to deal with ordinary human behavior, and the general lack of empathy and introspection I see in our field. Maybe I should've put "people persons" in quotes instead of italics. English is not my first language, I just didn't know how to get the point across shorter that, in order to be a great developer, you have to understand not only code, but people too. IMHO. – fzwo Dec 12 '10 at 10:04
  • Edited my answer. Clearer/less offensive now? – fzwo Dec 12 '10 at 10:11
  • +1 for the first sentence, which I had actually concluded after getting the first few answers. – Larry Coleman Dec 14 '10 at 10:51
  • Yes, thank you for clarifying how clever is being used by stupid people in this context! – Derek Litz Sep 30 '13 at 5:04

Most folks are focusing on cleverness from an aspect of "The code requires too much deciphering to figure out what it is doing" and all the bad things that go along with that such as

  1. No one else can figure it out, let alone maintain it/debug it.
  2. The person who wrote doesn't even know what it does.
  3. It may actually be not all that brilliant to begin with
  4. etc....

All good points, but there's another negative aspect of cleverness and that is the old ego problem. This causes issues along the lines of

  1. Someone that is too "Smart" to use anyone else's solutions. Why look for what other people have done when you can invent your own way of skinning the same cat?
  2. Someone who thinks they've invented the coolest solution to a problem will often refuse to take any input.
  3. Won't let anyone modify "their" code even when there's obvious issues or a trivial change is needed.
  4. Somewhat conversely, they think they're smart and need to use the "latest" technique to prove how smart they are but fail to get a good handle on it in either personal projects or otherwise non-production code before rolling it into critical parts of the system.

We're all guilty of too much ego sometimes, but when it gets in the way of the team it's a problem.


Good Clever -- high ratio between clever lines of code vs lines of in a non-clever alternative. 20 lines of code that saves you from writing 20000 is Extremely Good Clever. Good Clever is about saving yourself work.

Bad Clever -- low ratio between lines of code written written vs. lines of code saved. One line of clever code that saves you from writing five lines of code is Bad Clever. Bad clever is about "syntactic masturbation".

Just to note: Bad Clever is almost never called "Bad Clever"; it will often travel under the aliases "beautiful", "elegant", "concise", or "succinct."

  • Interesting answer, but is code that you call "Bad Clever" actually referred to as "beautiful", etc., by anyone other than the person who wrote the code in question? – Larry Coleman Dec 14 '10 at 15:30
  • 2
    Depends. In Objective-C/C++/C, the phenomenon is usually limited to an individual. In Perl and Ruby, often the entire community will have a shared value about Bad Clever being "beautiful", "elegant", etc. – user8865 Dec 14 '10 at 17:11
  • 1
    @user8865: also, "Good Clever" code ends up being much easier to debug than the original since there's by your definition 3 orders of magnitude less of it. – Larry Coleman Dec 14 '10 at 18:14
  • 2
    Ah, so Perl programs are - now almost by definition - Extremely Good Clever :) Nice to know! – user1249 Jan 8 '11 at 19:39

I have to wonder about everyone's definition of clever.

Personally, I feel like I have been clever when I have taken a hard, complex problem, and implemented it in a very simple and straight forward way, while maintaining an acceptable level of efficiency.

tl;dr i feel clever when, during a code review, my reviewer says "wow, that was easier than i thought it was going to be", as opposed to "wtf is all this.."

  • 1
    LOL about the tl;dr, how slow do you think programmers read? Yes, I absolutely despise the misuse of clever here to mean the opposite of what it actually is. Dumb/Ignorant/Evil developers and managers actually use this to justify not hiring someone who they think may be "too smart". – Derek Litz Oct 1 '13 at 0:32

Aside from the theory answers listed, often this gets used in the context of too clever for everyone else.

Move between a top tier performance intensive team and a medium tier maintenance team sometime to see the real life differences in what is "too clever".

Leaving out the theory arguments, too clever is often based on what the least skilled team members can work with reasonably, so it is very relative to the environment.

  • Excellent: "too clever is often based on what the least skilled team members can work with reasonably" – Orbling Dec 10 '10 at 20:58
  • depending on your location this is somewhat less than "excellent" at times :-) – Bill Dec 11 '10 at 0:00
  • Who cares about the least skilled member of the team? Almost every team (though I'm sure there are a few exceptions) has at least one member who has absolutely no business calling him/herself a programmer. – dsimcha Dec 14 '10 at 13:47
  • 1
    Hopefully you are getting them to be better, but even when that is not successful you still have to deal with them as a team member and they need to be able to participate in some of the work. I am currently seeing this in lambda expressions. A lot of people I work with don't get them yet so they see them as too clever. This is unfortunate as they solve a lot of our problems quite efficiently and elegantly, but if none of the middle tier guys get them they will go to management for the software being unsupportable. – Bill Dec 14 '10 at 16:32
  • @Bill: Lambda functions??? Anyone who can't understand something that simple, even after explicitly being asked to go learn about them, has no business being a professional programmer. – dsimcha Dec 9 '11 at 23:55

Sometimes I've been so clever that I've been wrong.

  • 1
    That can happen. And sometimes, something's so wrong, its right. – bobobobo Jan 22 '11 at 5:42
  • They call those theories John. Theories can and should be wrong once and a while :), it doesn't mean we should stop being clever and striving to be as clever as possible. How else will we become leaders in this world! "Ah, but a man's reach should exceed his grasp -- or what's a heaven for?" – Derek Litz Oct 1 '13 at 0:50

Performant, maintainable, timely and cheap are the ways I measure a solution. I guess clever could also be part of a solution as long as it doesn't negatively affect those qualities.

  • +1 for using "cheap" as a positive in regards to development – Gary Rowe Dec 10 '10 at 17:55
  • I've seen too much 'clever' code that is not performant! – HLGEM Dec 14 '10 at 16:14
  • There are more valuable metrics, but those can be good ones depending on the project, and often they are at odds with each other so you have to emphasize one over the other in order to succeed. – Derek Litz Oct 1 '13 at 0:53

If clever code + the amount of comments required to make it understandable code <= simple code, then I say go for the clever code. Every time.

I think the problem arises when people who write "clever code" deliberately fail to comment it properly, because only by it being initially incomprehensible will future generations who come across it have to spend time "appreciating" how clever it is.

  • Well, or because they just don't think about the next guy, or whatever. I'm not sure I'd attribute to intellectual egotism what can adequately be explained by unthinking sloth and bad habit. But the fact is, if your code can't be comprehended at first glance, it needs comments, and if the code + comments is longer (in LOC or time) than another way, you're working harder than you need to. – Dan Ray Dec 10 '10 at 20:49
  • Good answer, (can't +1, none left, will later). If people spend no time writing clever code and others spend no time understanding it, preferring less complex simple code, even if less efficient. Then no advancement in skill will take place. – Orbling Dec 10 '10 at 21:04
  • Best answer. The mantra: write simple baseline, starter code that's braindead and slow as all get up...and then make it a comment when you boil it down to an unreadable one-liner. That's how you learn all the dirty tricks in your language! – Droogans Feb 10 '12 at 23:36
  • If I take your use of clever to mean convoluted, I have personally written some convoluted code that was made comprehensible through logging. While I didn't plan on writing convoluted code, at the time, it saved me some time, but I added a # TODO that it probably should be rewritten to be simple if we need to modify it significantly. – Derek Litz Oct 1 '13 at 0:55

I'm reminded of a quote I've seen attributed to many different people, as the good quotes often are.

To paraphrase:

Any intelligent person can make the simple complex, it takes a genius to make the complex simple.

Taking a complex idea and simplifying it so it's understandable shows the cleverness of the constructor but taking a simple idea and making it complex shows the constructor wants to be seen as clever.

  • Yes, it's the egocentric idea of wanting to be clever that makes your code base convoluted. You either are, or are not clever. Sadly, in initial learning stages people think they are more clever then they are. Later on they realize how not clever they are and actually then write clever code once they fill out the gaps in knowledge. – Derek Litz Oct 1 '13 at 0:41

If the 'clever' solution is difficult to figure out, then it shouldn't be used. For instance, if through side effects you can contract a complex calculation to one line, it's clever. But if it takes an hour for someone else to figure out what in the world you did, it's too clever.

  • 2
    Fair enough, but does your answer change if the person who can't figure out the code isn't familiar with all of the features of the language? – Larry Coleman Dec 10 '10 at 17:01
  • 2
    That's different, at least IMO. If a person isn't familiar with the features of a language, then they aren't in a position to judge what's clever or not. – Joe D Dec 10 '10 at 17:05
  • @Larry: Not necessarily. I would assume that the person reading it is at a basic/low advanced level of proficiency. And if it starts getting irretrievable complex, then it's time to put in a block comment explaining what the code is supposed to do, which will help establish a frame of reference for understanding what it's actually doing. The comment should be high-level, though - write out the calculation, explain the process; don't repeat the code. A person at should (ideally) be able to understand the code as he reads it. That's the goal, anyway. – Michael K Dec 10 '10 at 17:06

In my opinion, cleverness per se isn't a problem. Usually we can make confusions about "clever" (without sarcasm) and "insightfull" code. What I see as a problem, is the fact that usually the "clever" (with sarcasm) code contains implicit not-visible requirements, making it harder to debug and maintain along time.

There are several known algorithms that are clever. Quicksort is one, IMO.

"Clever" (with sarcasm) code usually make assumptions about variables being set and states of the system that are virtually disconnected from the "clever" code (as files opened previously, network connections, databases, etc...).

The amount of data you have to load on your brain to maintain correctly a "clever" code is usually to big to have a good cost-benefit ratio.


"Clever code" is any code for which the programmer had to think really hard or use some advanced skill to write it. The problem with that it disregards the need for a certain "cleverness margin", best expressed by Brian W. Kernighan:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."


Because what looks like cleverness to a developer in a burst of creativity can simply pass as mess and just be an unreadable, unmaintainable block of obscure riddles for others.

Still, a nice, clever, well-performing block of riddles, but if you have the experience, you'll often realize that it will cost your business (not you, the developer) at lot more to maintain that thing on the medium- or long-term. So you prefer to calm the ardor of your fellow developers when they get carried.

Except, of course, if there's a justification for the cleverness. And if there's a good documentation that comes along with the obfuscated thing you just wrote. You did comment that clever piece of code, right? Explain it's intent, why it needs to be like, and how it behaves?

If there's no justification, then it's probably just either premature optimization, over-engineering, or a YAGNI kind of problem. If it takes 15 levels of indirection to do something simple, then there's a good chance you fall under of the previous categories as well. And if it's not documented, then it's just trouble.

Great code shouldn't require the maintainer to be at 100% all the time to understand it. Good code is clever. Great code can be almost as efficient, but better in many other aspects. Great code shouldn't require an IDE with 15 views to follow your application's design.

Note: hey, I've written a few stuff I thought to be clever but that drew WTF? out of - if not my co-developers' - my manager's mouth. Have to look at it from their perspective.

  • Thanks for the answer. You seem to be agreeing with the others who say that "clever" doesn't mean what I thought it did. – Larry Coleman Dec 14 '10 at 10:46

I tend to be clever, but I strive to be elegant.

Develop code now that others will not try and avoid later.

  • 1
    Come on... clever is a synonym for elegant, your brain has been marketeered. Yes, I made that word up, it means you brain is influenced by marketing instead of truth. – Derek Litz Sep 30 '13 at 14:10
  • Elegant: simple and clever. @DerekLitz +1 for cromulent anything. – kevpie Sep 30 '13 at 23:59

This is my understanding of the issue, based on my experience and the other answers:

  1. Code that took cleverness to write, but comes out readable and maintainable is not considered harmful. However, most developers would not call that kind of code "clever"; they may use a different term like "elegant". There may or may not be some debate about whether such code exists.
  2. Production code that requires significant time and effort to understand even by a seasoned developer familiar with the language is "clever" and considered harmful by everyone.
  3. Production code that requires significant time and effort by inexperienced developers is considered harmful by some. I've seen answers either way, and I've worked with developers who've said explicitly that they would prefer to keep everything "lowest common denominator".
  • The entirety of modern western culture is LCD, I guess that means programming has to be too; not good. – Orbling Jan 20 '11 at 20:04
  • @Orbling: Yes, but don't forget instant gratification. – Larry Coleman Jan 21 '11 at 20:34
  • I like your points of experience. It's sad that people are not striving for iterative improvement and investing into each other by sharing knowledge and understanding. Instead they'd rather have us be cogs on a wheel so we can be easily replaced when the time comes. By doing this we are impeding progress. We are also selling ourselves short... – Derek Litz Sep 30 '13 at 14:14

I know a guy; he is probably the most brilliant person I have ever met. He is definitely an unbelievable coder, probably better than I will ever be in my entire life in terms of sheer programming chops. He writes code like he's typing a word document and can reverse a linked list like you wouldn't believe. If you want to talk about writing some seriously complex code, he's your man and if I run into an unbelievably hard problem I always turn to him. However, working on a project with him in a team setting is excruciating. He is unable to directly target the business problem and provide a logical, efficient, and concise solution to it. For him, a code listing of 1000 lines would be better than 100. Instead of using the tools provided to him via the IDE or framework, he will roll his own super-optimized tool. This is all well and good except for when other team members are waiting on him to finish something, or we have a deadline.

While I admire his ability to do these complex things, what I need is someone that can solve the problem and move on. Its not great to say, or admit, but sometimes in a business setting time is everything and you have to just solve the problem and get on with your life, you can always come back to it later and refactor the hell out of it to improve your code. There is a fine line between being clever and also being a pain in the butt. My motto for my team is always, what is the simplest possible thing that will work in this situation and then go from there. Sometimes simpler isn't always the answer but its a damn good place to start.

  • Sorry, despite the quality of this person you met to be able to code complex things, he is stupid. People can be and are stupid regardless of their other traits. Your statements of what you really want out of development are obvious to a talented person. If he is truly intelligent you should do him a favor and confront him instead of let him do stupid things with his talent. You are doing a disservice to him and everyone around him by being idle and complaining behind his back. If he is not intelligent you should fire him, then maybe he'll get it. – Derek Litz Sep 30 '13 at 14:31
  • I do have a relation to a primary resource who has dealt with intelligent people daily for decades and some of them are just missing a few pieces of knowledge to be productive in a team environment. They can figure it out on their own if you at least let them know about the problem. – Derek Litz Sep 30 '13 at 14:45

"Clever" in this context means "too clever for its own good", i.e. something that works now but will be a nightmare to understand and change later on.

Especially if it's a trick that exploits an obscure feature of the programming language, or makes use of weird side-effects, or is a really bizarre way of solving the problem in the target language.


I prefer Simple solutions, I really like the ruby way. When you want to for example sum first 2 elements on the list. first you cut the list to make it have size=2 and then you sum it.

I remember that once I used 1 list instead of 3 and create one big function that was very hard to maintain/change.

in todays world we don't have to sacrifice code clearness for performance(except c++, they don't have to, but they will).


Usually when you need to be 'clever' its to workaround a problem in code. Ifs a workaround and not very straightforward then you'll get a lot of confused faces or othertimes weird side effects when assuming certain conditions (which may be 100% correct at the time of writing the code)

Thus clever == confusing == bad :( But its also awesome as i used them for practical solutions to limited problems.


Re-quoting for context and and easier comprehension:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

What Brian Kernighan wrote here obviously refers to convolution, and he mistakenly used the word clever.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as [convoluted] as possible, you are, by definition, not smart enough to debug it."


A thing that is complex and difficult to follow.


Showing intelligence or skill; ingenious

Educated programmers know that simple code is ingenious. Code that is as clever as possible should be simple by definition. Educated programmers will also avoid working with and writing convoluted code like the plague. They will also turn convoluted code into clever code whenever they have the chance. Code usually starts out convoluted and approaches cleverness as knowledge about the domain and understanding of human cognitive ability in programming is better understood through experience and shared knowledge.

Because of the popularity of this quote and Brian Kernighan being quite popular in the industry this misuse of the word has a negative social impact and I'd honestly like to see that addressed by the man himself. Before writing this article I tried to see if I could simply e-mail him, but, I was unable to find any email contact information that I understood :(.

The negative social impact I have seen is other programmers ostracizing their more clever peers, because they now see cleverness as a problem. The real problem is the stupid peers who think they are being clever by doing things in a new unidiomatic way, and constantly inventing new things when there is no advantage instead of gaining and understanding of the greater community and reusing clever ideas as much as possible.

I do need to clarify though that often gaining an understanding is more difficult than inventing your own. Because of the common problem in industry for unrealistic deadlines inventing your own for your smaller niche problem will be used to save time. This is based on the observation that useful, reusable things usually target a larger niche, or provide a useful abstraction for invention. It is also based on the fact that people target large niches to make more money, when often this makes the tool extremely hard to use because of the complexity involved in making something usable for a wide area of applications.

The other negative social impact is this prevents progress and the desire to comprehend because in our egocentric world we will immediately be in denial of our own lack of understanding and write off the code of as being convoluted even if, once understood, the idea is actually quite clever.

TODO I'd like to cite some references but I'd also like the lack of references to not impede my ability to share information so I will quickly cite what I remember as the sources of my information and maybe I will find the actual info some day (or you can find it for me! :)

  • Guido Van Rossum's talk about event loops and how he came to understand them
  • A GitHub employee who stated that they avoid hiring clever people on Y-Combinator
  • Much of the discussion and learning that goes on in the Python community. The Python community is especially critical of new ideas, but does not dismiss new ideas they do not understand out of hand, and you can typically see features that were at first seen as convoluted see the light of day as a core language feature/package.
  • My own experience and professional opinion based on my 10000 foot observations. I can't really see the specifics to enlighten from all the way up there though :( Hopefully your experience and observation will tell you the same thing and someone else can comment below to give this answer some merit.

Feel free to add your own citations! Also, feel free to add commas to my text. I have not refreshed my knowledge of comma usage in English in quite some time...


Because often people don't know a language, idioms and patterns. They could take a book and learn it, but they don't. And because of those people you should write simple code.

It's not a cleverness. It's a knowledge.

  • 2
    I certainly don't agree with this (although not worth a -1). By this argument you could say that you wouldn't implement the Command pattern to handle a Undo/Redo transaction stack because the maintainers were fresh out of school and didn't understand what was going on. At some point you have to just say that if they don't know it they need to learn it. – Ken Henderson Dec 10 '10 at 23:13
  • @confusedGeek Quite right, where do you draw the line on ignorance? – Orbling Dec 11 '10 at 0:45
  • @Orbling, honestly that's the hard part and to some degree depends on the situation. The general guide I tend to use that is if a reasonably seasoned developer (knowledgeable in the technologies used) can grok it then it's probably ok. If they can't then it needs to be refactored (or review hiring practices). – Ken Henderson Dec 11 '10 at 2:01
  • @confusedGeek Aye, sounds sensible. The litmus test is probably, can a developer of the same calibre as yourself understand easily what you have done quickly enough. If not and there is an easier way, then it needs changing. Sometimes there is not an easier way. – Orbling Dec 11 '10 at 9:02
  • -1. Don't code for the lowest common denominator. Unnecessary complexity is bad, but if some cleverness makes the code substantially more DRY, etc. it may be worth it. – dsimcha Dec 9 '11 at 23:32

I couldn't find the word discipline mentioned anywhere around here, so I'll chip in. I do not want to post the answer, but to share a different insight on the matter, maybe one that the original question did not have in mind.

A clever developer is a good thing.

However, before cleverness come other traits. As you might have realized I will talk about discipline. A clever and undisciplined developer can be very bad for the long term maintainability of the system.

Suppose that a bug arises or a new requirement comes in. A clever developer might soon realize that a couple local fixes will get the job done in 2 minutes. If that developer is disciplined he will restrain from applying those fixes to the source code and will, instead, find a meaningful way to compose the desired behavior to the system. This way, the next time the need will arise to modify the particular pieces of code the maintainer will have an easy time to understand the code and implement the new changes without breaking anything. If not, well you get the picture.

  • "Beatings Will Continue until Morale Improves" – gnat Oct 1 '13 at 15:28
  • @gnat Meaning? To clear things up a bit; I do not take discipline as something being forced upon developers. It is a good personality trait. One that is usually developed by smart people after some time of maintaining software. The problem comes with clever people that have not been in the maintainer position enough and leave clever bombs everywhere for others to find. – dkateros Oct 1 '13 at 17:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.