7 ms·

"“When asked, I would give people my opinion that maintainable code is more important than clever code,” he said. “If I encountered clever code that was particu

"“When asked, I would give people my opinion that maintainable code is more important than clever code,” he said. “If I encountered clever code that was particularly cryptic, and I had to do some maintenance on it, I would probably rewrite it. So I led by example, and also by talking to other people.”" This is very sage advice.

tyingq 7y ago
Interesting in the context of Dropbox, as they ship the client code as obfuscated and encrypted pyc files and a custom runtime that's pretty "clever": https://anvilventures.com/blog/looking-inside-the-box.html https://anvilventures.com/blog/looking-inside-the-box.html Edit. Yes I get the difference and the reasons they do this. The wordplay crossover (cryptic, clever, etc) was notable to me, and reminded me of the link I posted above.
- caseysoftware 7y ago
  We're not the intended audience for the code. We're just the consumers.
- _coveredInBees 7y ago
  That has zero bearing on the point Guido was making. He is talking about development practices. The client code is not being sent to users for them to develop code and contribute to the Dropbox codebase.
- jamestenglish 7y ago
  Just because the outcome of the code (i.e. obfuscated code) is "clever" doesn't mean that the code that does the obfuscation is clever
skellera 7y ago
You’d think it would be common sense when writing something that other people will read. We don’t see people writing books in acronyms or omitting words. How come so many people try to use code to show how smart they are?
- quaquaqua1 7y ago
  It's terrible. People use deliberate crypticness to flex on everyone who hasn't seen x subniche of programming style before. They designed it to be like this to be the gatekeeper at their organization.
- pdonis 7y ago
  > How come so many people try to use code to show how smart they are? Writing clever code doesn't mean it's being done for that reason. As the article notes, Guido himself agreed that in the early stages of developing a piece of software, such as in an early stage startup, it probably makes sense to write clever code, because you can get it done faster and therefore iterate faster on improving the code to meet user needs. At this stage very few people are working on the code (often just one), so communicating with other developers is not a big issue. The need for making it maintainable comes later, when the product is mature and many more people are working on the code, so the need for clear communication becomes much stronger.
- Cthulhu_ 7y ago
  You say that, but then there's more advanced writings like scientific papers which will freely use domain-specific terms and / or maths; I'm not saying that's bad, it's just that because I'm not at home with these terms and / or subjects I won't invest the time in trying to decipher it. Also because unlike with code, I don't actually have to of course.
- chipgap98 7y ago
  That metaphor doesn't hold up. Literature is full of allegories, figures of speech, allusion, and other forms of imagery. I agree that code should be as straightforward as possible, but I don't think books follow that rule.
- aksx 7y ago
  Sometimes it's not about show how smart they are, developers aren't clear about the code they are writing. when I write code for a concept i don't understand completely, it tends to be complex and cryptic. I'll go back to it after trying to understand the problem and the problem space more and be able to write simpler code.
vkat 7y ago
I think this is what experience teaches. Sometimes I have the itch to write clever code but then more often than not it ends up being cryptic to other developers. If you really have to write clever code, wrap it up in a well defined interface and write a bunch of tests.
- rstupek 7y ago
  I've found it also becomes cryptic to your future self who will have to figure out how to maintain it going forward
streetcat1 7y ago
probably would help if he added static typing from the get go.
Alex3917 7y ago
> This is very sage advice. I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to tell them to fix it. And many people don't like being told they need to rewrite their code because you can't understand it, so it leads to conflict and eventually you often need to fire people. So yes, it's good advice, but by cleaning up engineering debt you're often going to take on a lot of team debt.
- Aperocky 7y ago
  There's a delicate balance that often lies in hiring process. There are people who simply refuse to understand generics and/or stream APIs. Which are to (most) programmers more readable then the same logic being drawn out in a loop. Meanwhile some other programmer would just write code golf and brag about it. At the end of the day, it should be about enforcing a coding style that defines what you can or can't do. Adding final to all variable that can be final for instance is a great start.
- trilinearnz 7y ago
  We have reached a middle ground in our organisation (not a tech company, so there is less code and a slower pace). We don't require rewrites, but simply recommend that next time the code be written in a more lenient style. The education aspect is a good lens through which to view the issue also, sometimes resistance to an unfamiliar style is due to a fixed mindset around a known set of language functionality. It could be an opportunity to learn something new which is genuinely useful.
- deleted 7y ago
  [deleted]
doc_gunthrop 7y ago
That coincides with the following: > Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1] This is also noted in PEP8: > One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".[2] [1]: https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-code https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-cod... [2]: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds https://www.python.org/dev/peps/pep-0008/#a-foolish-consiste...
- RaiseProfits 7y ago
  Who would have thought the best argument against an 80 character cap in pep8 would come from guido himself?
  - icebraining 7y ago
    Anyone who charitably reads what he writes.
- hinkley 7y ago
  I’m finding that one of the biggest time sinks is code that looks like it’s doing something other than what it’s actually doing. Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature. One of the wisdoms of XP, I think. The code you touch the most should be the sanest.
- jodrellblank 7y ago
  > Code is read many more times than it is written I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable". And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on. I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard. But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?
huhtenberg 7y ago
The third option, of course, is to just comment your clever code to make it less cryptic. Yes, you can have your pie and eat it :)
- nomel 7y ago
  Unless there’s a real and needed benefit, why complicate it? I’ve seen clever code that was 300% faster, half the lines, completely unreadable, and called once per session, for a total the time of 10ms in a workflow that was minutes long. No amount of commenting could justify it.
- bagacrap 7y ago
  The compiler doesn't care about comments, so in my experience comments quickly go out of date as others change the code and ignore comments. There's nothing to say code can't be performant and legible. In fact I'm a bit confused what "clever" means here. Writing performant but illegible code does not take more cleverness than performant while legible.

tyingq 7y ago

Interesting in the context of Dropbox, as they ship the client code as obfuscated and encrypted pyc files and a custom runtime that's pretty "clever": https://anvilventures.com/blog/looking-inside-the-box.html https://anvilventures.com/blog/looking-inside-the-box.html Edit. Yes I get the difference and the reasons they do this. The wordplay crossover (cryptic, clever, etc) was notable to me, and reminded me of the link I posted above.

caseysoftware 7y ago
We're not the intended audience for the code. We're just the consumers.
_coveredInBees 7y ago
That has zero bearing on the point Guido was making. He is talking about development practices. The client code is not being sent to users for them to develop code and contribute to the Dropbox codebase.
jamestenglish 7y ago
Just because the outcome of the code (i.e. obfuscated code) is "clever" doesn't mean that the code that does the obfuscation is clever

skellera 7y ago

You’d think it would be common sense when writing something that other people will read. We don’t see people writing books in acronyms or omitting words. How come so many people try to use code to show how smart they are?

quaquaqua1 7y ago
It's terrible. People use deliberate crypticness to flex on everyone who hasn't seen x subniche of programming style before. They designed it to be like this to be the gatekeeper at their organization.
pdonis 7y ago
> How come so many people try to use code to show how smart they are? Writing clever code doesn't mean it's being done for that reason. As the article notes, Guido himself agreed that in the early stages of developing a piece of software, such as in an early stage startup, it probably makes sense to write clever code, because you can get it done faster and therefore iterate faster on improving the code to meet user needs. At this stage very few people are working on the code (often just one), so communicating with other developers is not a big issue. The need for making it maintainable comes later, when the product is mature and many more people are working on the code, so the need for clear communication becomes much stronger.
Cthulhu_ 7y ago
You say that, but then there's more advanced writings like scientific papers which will freely use domain-specific terms and / or maths; I'm not saying that's bad, it's just that because I'm not at home with these terms and / or subjects I won't invest the time in trying to decipher it. Also because unlike with code, I don't actually have to of course.
chipgap98 7y ago
That metaphor doesn't hold up. Literature is full of allegories, figures of speech, allusion, and other forms of imagery. I agree that code should be as straightforward as possible, but I don't think books follow that rule.
aksx 7y ago
Sometimes it's not about show how smart they are, developers aren't clear about the code they are writing. when I write code for a concept i don't understand completely, it tends to be complex and cryptic. I'll go back to it after trying to understand the problem and the problem space more and be able to write simpler code.

vkat 7y ago

I think this is what experience teaches. Sometimes I have the itch to write clever code but then more often than not it ends up being cryptic to other developers. If you really have to write clever code, wrap it up in a well defined interface and write a bunch of tests.

rstupek 7y ago
I've found it also becomes cryptic to your future self who will have to figure out how to maintain it going forward

streetcat1 7y ago

probably would help if he added static typing from the get go.

Alex3917 7y ago

> This is very sage advice. I mean in real life (when you don't have Guido to do it for you), if people are writing code you can't understand then you need to tell them to fix it. And many people don't like being told they need to rewrite their code because you can't understand it, so it leads to conflict and eventually you often need to fire people. So yes, it's good advice, but by cleaning up engineering debt you're often going to take on a lot of team debt.

Aperocky 7y ago
There's a delicate balance that often lies in hiring process. There are people who simply refuse to understand generics and/or stream APIs. Which are to (most) programmers more readable then the same logic being drawn out in a loop. Meanwhile some other programmer would just write code golf and brag about it. At the end of the day, it should be about enforcing a coding style that defines what you can or can't do. Adding final to all variable that can be final for instance is a great start.
trilinearnz 7y ago
We have reached a middle ground in our organisation (not a tech company, so there is less code and a slower pace). We don't require rewrites, but simply recommend that next time the code be written in a more lenient style. The education aspect is a good lens through which to view the issue also, sometimes resistance to an unfamiliar style is due to a fixed mindset around a known set of language functionality. It could be an opportunity to learn something new which is genuinely useful.
deleted 7y ago
[deleted]

doc_gunthrop 7y ago

That coincides with the following: > Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.[1] This is also noted in PEP8: > One of Guido's key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, "Readability counts".[2] [1]: https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-code https://www.sandimetz.com/blog/2017/6/1/the-half-life-of-cod... [2]: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds https://www.python.org/dev/peps/pep-0008/#a-foolish-consiste...

RaiseProfits 7y ago
Who would have thought the best argument against an 80 character cap in pep8 would come from guido himself?
- icebraining 7y ago
  Anyone who charitably reads what he writes.
hinkley 7y ago
I’m finding that one of the biggest time sinks is code that looks like it’s doing something other than what it’s actually doing. Code smells draw the eye when debugging. Your brain wants the problem to be in the code that’s clearly “wrong”. So smelly code anywhere near common code paths has a huge cost compared to smelly code in some leaf function in an obscure feature. One of the wisdoms of XP, I think. The code you touch the most should be the sanest.
jodrellblank 7y ago
> Code is read many more times than it is written I'm really curious how true this is. Partly because, if it really was read more than it is written, people would optimize to /write less/ of it - if you have to pick up everything you put on the floor ten times over, it will incentivize you to put fewer things on the floor in future. And people would say things about code which people say about writing, such as "you have to write for your audience", instead of the more common "it's either boolean readable or unreadable". And partly because I suspect code is /skimmed over/ more than it is read; that is, people assume what it does, glance at its shape, then if there's no surprise triggered, move on. I would be interested to know if anyone has studied what it means for code to be read, but my suspicions are that most code which works is almost never read, and most code which is read, is read because it doesn't work and therefore it will be self-selected to be poor code in some regard. But then, I'm not a programmer working on a large codebase. Those of you who are, how much of it have you read in enough detail that you verified how it works - and no assuming that a method does what its name implies, or assuming that if it passes tests it must work, but actually verifying by studying it that it does what it should and that you understand it?

huhtenberg 7y ago

The third option, of course, is to just comment your clever code to make it less cryptic. Yes, you can have your pie and eat it :)

nomel 7y ago
Unless there’s a real and needed benefit, why complicate it? I’ve seen clever code that was 300% faster, half the lines, completely unreadable, and called once per session, for a total the time of 10ms in a workflow that was minutes long. No amount of commenting could justify it.
bagacrap 7y ago
The compiler doesn't care about comments, so in my experience comments quickly go out of date as others change the code and ignore comments. There's nothing to say code can't be performant and legible. In fact I'm a bit confused what "clever" means here. Writing performant but illegible code does not take more cleverness than performant while legible.