Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




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.


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.


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.)


Never meant to imply otherwise :)


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.


Let us say "clever" is problematic when "hard to understand": complex and unintuitive. (The best "clever" is simple and obvious).

The issue is whether it is sufficiently general to become a standard technique.

If so, you're right. Familiarity with it makes you "cleverer", as it becomes intuitive, and less complex (as you push details down into long-term memory).

But, in that case, IMHO, it's even cleverer to "turn over the detail to the machine", i.e. create an abstraction, to hide the detail.

> There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself. https://wikiquote.org/wiki/Alan_Turing


> If so, you're right.

I'm not making any claim regarding the relation between clever and clear/understandable code. Just that writing clever code, however defined, doesn't expend much of a cleverness resource - if anything, it strengthens it.

That is, looking at each piece of clever code in isolation. If the original claim was meant more that a code base has a limit to how many clever tricks it can contain before it becomes unmaintainable, I'd be more inclined to agree.


Just that writing clever code, however defined, doesn't expend much of a cleverness resource - if anything, it strengthens it.

Walking strengthens the legs and increases endurance. However, no Roman Legionnaire would command his men, as if more marching would only increase capability, and they could therefore march forever and as much as they want. Instead, it's best to reserve the fast marches for when a goal is attainable which gives a tactical or strategic advantage.

There's only 24 hours a day to be clever, and there's only a limited number of hours per day a given person can muster the concentration to be clever.

That is, looking at each piece of clever code in isolation.

Which only applies to an isolated problem, as in a coding interview. In a programming project or a startup, it's more like a military campaign, where there will be many, many interrelated problems over many years.


I see, you're addressing whether cleverness is a limited resource.

Perhaps you're right, that practicing cleverness will make you cleverer.

But it still takes time and effort - perhaps those are the resources that are limited?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: