3 ms·
I'd say clever is defined by your audience. If you're writing something that others on your team would consider clever, then you're responsible for making sure
by rapind 16y ago
I'd say clever is defined by your audience. If you're writing something that others on your team would consider clever, then you're responsible for making sure they understand it. Even if that means losing whatever time you saved by writing something clever (the advantage is still creating a smarter team though).
Responsible developers write a lot less clever code because it means they feel obliged to comment the crap out of it and find the time to go through it with other team members.
Unfortunately there's a lot more clever code that only one person really gets. If you're too clever for your team, then quit slumming it and find a smarter team. You're going to be toxic to a team that isn't as clever as you are unless you assume the role of mentor and all of the responsibility that comes with it... and the required patience.
- raganwald 16y agoYour response assumes that clever code exists to save time writing programs, and that for any problem there are a wide range of equally good solutions possible from "takes a long time to write but is easily readable and maintainable" to "quick to write but impossible to read and maintain by those who don't have doctorates in functional programming idioms." I don't dispute the existence of code that is unnecessarily clever, but I suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies.
- rapind 16y agoI can agree with that. I'd add that if something seems clever you might want to make sure others on your team are aware of it too. At least that way you won't get blamed for being too clever, and more people will understand what's going on.
- raganwald 16y ago// Here be gryphons and scabrous wyrms
- stcredzero 16y agoI suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies. If "clever" is often necessary to avoid things like conflating concerns or introducing dependencies, I think this points us in the direction we need to take in improving programming languages. (Off the top of my head, this applies to both Ruby and Smalltalk.) Though, I've also observed that bolt-ons to programming languages to address these issues are often a bit too "clever" themselves. (Example: The original implementation of Objects in Perl.)
- raganwald 16y agoIf "clever" is often necessary to avoid things like conflating concerns or introducing dependencies, I think this points us in the direction we need to take in improving programming languages. I agree!!!! As a rough rule of thumb, "horizontal" or "general purpose" libraries are a potential source of inspiration for language improvements. In my own case, I think #andand is a terrible kludge. But if I were designing a new programming language, one question I would ask myself is, "How do I make this go away?" I might add support for monads, Or maybe I would decide that null is a bad idea. I don't know, but I would certainly give it some thought.