7 ms·

>It is very common, especially among novice developers, to be proud of the number of line of code their application has. My experience has been the opposite. N

>It is very common, especially among novice developers, to be proud of the number of line of code their application has. My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't. In my career I found that maintaining unsexy, and maybe a little verbose code is never the problem. Usually that code tends to be more easily understandable to even junior developers and therefore is less prone to bugs being introduced because developer made the wrong assumptions on what the code was doing. Code that is too clever for its own good is where bugs tend to occur.

k__ 5y ago
Yes. Often even sacrificing everything to that tersness.
grp000 5y ago
Agreed. Some of my early code is near unreadable due to the complexity that I've since pared down on how much a single line should be doing.
galangalalgol 5y ago
Verbose code is one thing but multiple adjoining layers of abstraction, or excessive modularization can both make maintaining code very difficult as well. Both dense and bloated solutions had goals other than doing the simplest thing that might possibly solve the immediate problem. That is the only worthy goal, it ensures maintainability due to its simplicity and any extensibility loss is offset by that simplicity. Most of the designed in extensibility I've seen predicted the wrong sort of extension that would be needed anyway.
- me_me_me 5y ago
  This. Clearly defined purpose for each layer when doing abstraction. Verbosity and simplicity. And NEVER EVEN try to be smart. In two weeks you will forget how the 'smart' solution works and have to spend x2 time changing it.
- cactus2093 5y ago
  > Most of the designed in extensibility I've seen predicted the wrong sort of extension that would be needed anyway. I definitely agree with that, and I think a preference for more verbose code is actually very compatible with this idea. Verbosity is not the same as over-complicating or over-abstracting things. In my experience a lot of the time it's actually the drive to avoid verbose code that causes these problems in the first place. For instance, you have two functions that are similar but with some important difference, and the developer decides that anything that resembles duplication is bad and refactors them into a single abstraction. This type of thing can cause much more harm than just leaving in a little bit of verbosity by keeping the functions independent of each other.
  - gradys 5y ago
    One way to analyze the two similar function situation is to ask whether a future change in the logic to one would imply that a change should also made to the other. If so, then by keeping them separate, you introduce the risk that you would forget to update the other. Using a single function and calling it twice, even with different parameters, is a way communicating that it's important that the semantics be tied. If a change in one wouldn't imply a change in the other, then you really have two separate semantic roles being played that happened to resemble each other in implementation - harmless incidental duplication.
    - Wowfunhappy 5y ago
      What if a change to one would imply a change to the other, but also the block of code is needed in 20 places instead of two?
    - cactus2093 5y ago
      > to ask whether a future change in the logic to one would imply that a change should also made to the other. If there's a really obvious answer to that question, then great. But often the answer is "sometimes" or even "most of the time". We train most developers beginning even in intro-level programming classes to err on the side of deduplication and over-abstracting in these cases, but the longer I've been working as a developer the more I have come to think it's better to err on the side of allowing some duplication except in the most clear cut of cases.
corentin88 5y ago
Agreed. More-readable code is generally longer in my experience. And that’s not a problem AFAICT.
- dave_sid 5y ago
  Yes, Especially when there a compiler in between the ide and the cpu :-)
jayd16 5y ago
I think the author is referring to the mentality of "I wrote my way into this mess and dammit I'll write my way out!" That is to say, novices can tend to pile onto a solution with hacks and special cases instead of examining why their abstraction requires so much special casing. I think the code golf you're talking about is a different (but not exclusive) thing.
- Jtsummers 5y ago
  Yep. It's an interesting dichotomy with new hires. They can write some of the tersest code once they learn some new thing ("Wait, C# lets me use LINQ and lambdas. I can turn this entire thing into 3 lines of code!") and some of the most convoluted messes when they run into an issue. I call the latter the epicycle approach [0]. A simple model that doesn't quite work, but they can't let go of, is complicated by adding more and more "simple" extensions but it produces a convoluted mess that is nigh impossible to maintain or sustain. [0] https://en.wikipedia.org/wiki/Deferent_and_epicycle#/media/File:Cassini_apparent.jpg https://en.wikipedia.org/wiki/Deferent_and_epicycle#/media/F... : Demonstrating the complexity needed to maintain a geocentric model and account for the movement of celestial bodies.
ritchiea 5y ago
I believe the author would agree with you, his last bullet point is write for humans not for machines. When he says write less code, I believe he means favoring simpler architectures, saying no to features & tools until you absolutely need them & even finding no-code solutions. Not taking verbose code & making it less readable by shortening it.
- rightbyte 5y ago
  I note it is quite common with rule of thumbs in programming and that they are misused to sillyness. One way to write less code is to in practice code golf. To follow DRY add deeply nested abstractions. To not have to plan out what you do, use YAGNI or "no premature optimizations". Etc. Edit: My personal favourite is "code should be self-documenting", i.e. comments are a failure.
- rafaquintanilha 5y ago
  Author here. You summarized it better than me! Thanks.
drewcoo 5y ago
Part of learning any new technique is overusing it to see what its limits are. When people first start coding they're trying to get machines to do things. They have to learn the techniques of making code for other humans. To them it's making things verbose and adding tons of comments because that's better. Meanwhile, they're usually learning to plan for future code needs and make their code flexible. But part of learning to use those techniques is overuse. So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. Time to trim it back. Less is more. I think that's what the author meant.
- vagrantJin 5y ago
  > So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. I like the way you phrased that. Anecdotally I find code that is too clever annoying at times, when time is short and the PM Melissa has a bolt action rifle to my head on friday afternoon. I get that code that is too concise is also trying hard to be marvelled as genius-worthy.
mch82 5y ago
It seems the author agrees with you. The final “bad habit” calls people out for writing code for machines instead of humans. https://rafaelquintanilha.com/how-to-become-a-bad-developer/#write-for-machines-not-humans https://rafaelquintanilha.com/how-to-become-a-bad-developer/... The author lists the habits of *bad* developers as: (1) Never assume there is a bug in your code, (2) Write code without reasoning, (3) Lack assertiveness, (4) Take pleasure in writing more code, (5) Write for machines, not humans. So the author advocates for less code, but written to be used and maintained by other people.
stonemetal12 5y ago
My take on it is that all software developers novice or otherwise try to write simple, clear code. For some(especially novices) that means plodding, low abstraction code, so that all the details are visible. This makes for longer code. Others see high abstraction code as the cleaner simpler code because the abstractions hide what they see as irrelevant details, which makes for terse code. “the less, the better” “the more, the better” Tautologically both are incorrect when pursued farther than is prudent, and "the right amount, the better". Unfortunately no one really agrees on what "the right amount" is or we wouldn't have to discus different definitions and strategies to reach "the right amount".
- Osiris 5y ago
  And of course it depends on context. The interworking of a game engine may require some really obtuse code because it's focusing on performance and not on readability (in those cases, comments should be used to explain the code). In my experience the problem with juniors is more about thinking about the problem in a very linear fashion and not stepping back to see it as individual parts. For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand.
  - aYsY4dDQ2NrcNzA 5y ago
    “We must always think of the Way of strategy as being both a rat's head and an ox's neck. Whenever we have become preoccupied with small detail, we must suddenly change into a large spirit, interchanging large with small. This is one of the essences of strategy. It is necessary that the warrior think in this spirit in everyday life.” — Miyamoto Musashi, The Book of Five Rings
  - cardanome 5y ago
    > For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand. It is interesting that you think that code with more abstractions is easier to understand. From my experience the simple linear beginner code is the one that is quite easy to work with. It is easy to grasp the general intention and to slowly refactor parts of the code if need be. Now a mid level developer that thinks of themselves to be smart and tries their hardest to use some fancy abstractions and patterns? Yeah, put it in the trash. We will have to rewrite that code. The best code is from the senior that finds the right balance. Finding the right abstractions to use takes years of experience. The most important rule when programming is: Don't try to be smart. Keep it simple.
bena 5y ago
Write as little code as needed to complete the task and as much code as needed to be understood. At the same time. Both incredibly dense and incredibly verbose code can become maintenance headaches. You want it short enough that it can be contained in your head, but long enough that the steps are obvious. I liken it to the scene in Return of the Jedi where Han is instructing Chewie to fly close, but not too close.
austincheney 5y ago
My experience is somewhere in between. Many novice developers are proud of how few lines of code their solution is although it’s really just 2 lines of glue code masking 300mb of dependencies. When you point this out they come back with some bullshit like: * any original code is NIH * vetted by the community * original code can fail
genezeta 5y ago
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I would agree with that. But then again, it isn't entirely incompatible with the cited quote. That is, at different times in their careers, developers may tend to do different things. In any case, I think I understand the original quote as something I have indeed seen somewhat frequently in large projects. It seems somewhat common, from my experience at least, that people -particularly "not-so-good developers"- involved in large projects tend to assert how large/important the project in fact is, by mentioning LOCs. "This is a very large project... It's about 5.5MLOCs or so. It will have grown a bit since we last counted."
BitwiseFool 5y ago
My friends and I used to joke about how verbose variable and object names can be in an enterprise setting. But the longer I have worked as a professional developer the more I appreciate the long and 'exactly what it says on the tin' names. In almost every circumstance developer time is more valuable to the company than some clever code that 'saves' CPU time.
dgb23 5y ago
I know where you are coming from and I agree on a certain level, but I think this is too specific to your case (large teams, high fluctuation, lots of juniors) The more general approach would be to write code with coworkers/audience in mind. In some environments or projects it might be more effective to write in a way that is harder to grok (requires more work to understand) but is ultimately more tailored to a specific outcome, may that be performance, extensibility, security or what ever.
ChrisRR 5y ago
Oh god, I used to work with the guy like this. Incredibly clever graduate, blew some of my knowledge out of the water. But every day was a game of code golf to him. His code was absolutely illegible
- jackcviers3 5y ago
  To be fair, bugs are highly correlated with line count, and all code is inscrutable in the absence of knowledge. I do like vocabulary-based metrics for legibility/difficulty; Halstead metrics can't tell you how good a piece of code is, but they can tell you how difficult it is for others to read, empirically. The old 7 +- 2 rule applies, if you are using more than 9 functions/methods and arguments, the vocabulary of a function is difficult. f compose g is 0.5. It has 3 elements. It's not hard to understand. def compose (f: B=> C, g: A => B): A => C = x => f(g(x)) Is 2.5, counting all the definition parts and type level stuff. It has 14 distinct elements. If you don't know the pieces, it's really difficult to read if you don't know any of the parts. If your language doesn't care about types, def compose(f, g) = (x) => f(g(x)) Comes to 2.1 by my count, but you have to look up fewer things at 7, so it's easy to read for new people. Now, the types make it easier once you advance beyond a pure beginner- the constrain the function to only one possible implementation. But if you're totally unfamiliar with things, they make stuff unreadable. Even in tiny functions.
toomuchredbull 5y ago
Yup... I find this with swift developers they love to write code that is just a series of : ? ! type symbols to do what should be 3 or 4 lines of readable code into one line of unreadable code.
marcus_holmes 5y ago
Agreed. The author should change it to "write complex code". Novice developers are frequently proud of the complexity of their code. Experienced developers write simple, easily understood, code.
teucris 5y ago
The principles in this article seem paradoxically conflicting, especially this one (“[don’t] Take pleasure in writing more code”) and “[don’t] Write for machines, not humans” Inherently, more code means more chances to explain what it’s doing to other humans, so shouldn’t more code be better? Obviously not, so I take these two principles in tandem as “write as much code as is needed to accomplish the task effectively and explain how it works, but no more than that.” Squishy, but I think this article as a whole does a decent job of addressing your concerns.
kbenson 5y ago
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I think it's both. There's a sense of accomplishment that goes along with both accomplishing some small task with minimal code, and also for having written a somewhat large chunk of code for a project. Both have their place, as succinctness has it's place, and it's natural to look back and feel proud of a lot of work. It's just when they aren't tempered by the experience to ask whether that terseness came at a cost that wasn't worth it or whether that project is much larger than it needs to be for the task accomplished that it ends up being detrimental.
systemvoltage 5y ago
“the less, the better” Could mean: 1) As you said, terse clever code and agree 100%. 2) Or avoid writing factories that produce factories, abstractions upon abstractions that never get the payoff since the abstraction only gets used for a single (or a handful) of cases ever. When you write abstractions, make sure that in next 10-20 years its going to get its money's worth by taking advantage of it. There are always some exceptions but most of the time I've seen code that has no defense for all the bloat. 3) The best code is the code that you don't write. In this case "the less, the better" indeed. So I can see multiple meanings of "less, the better". Also, my experience matches the author - new developers are mostly proud of number of lines than cleverness.
jt2190 5y ago
> I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't. This is one piece of developer lore that’s actually backed by some research. [1] Like it or not, there is a correlation between lines of code and bug count. [1] I’ll link to this research when I have a little more time. Edit: Here's a great resource on this: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/
AceJohnny2 5y ago
I agree, and it reminds me of an analogy... I discovered IRC as a teenager in the 90s, and soon learned SMS-speak for rapid messaging. I was proud of how quickly I could write if I just wrote "u r" instead of "you are"... This was cool! In chatroom arguments, being able to belt out more sentences faster was better! But as my typing improved, I realized the above was a childish optimization. Real skill was able to write out correctly-spelled sentences just as fast. I then saw the SMS-speak as immature shortcuts. This realization carried over into code: good code is the clear, adequately verbose (but appropriately concise) kind. Code that tries to be overly-clever (of the "code golf" kind), was to be viewed with suspicion.
- AceJohnny2 5y ago
  (I'll admit this tainted my view of Perl for a long time, as I perceived its community tending to more vocally celebrate such "clever" code)
mcguire 5y ago
Have you ever dealt with seriously verbose code? One 10,000 line file with maybe three functions or methods? Setting and resetting the same variables; perhaps introducing new ones kind of randomly? From a programmer who uses essentially one control structure, a while(true) loop with a test and break somewhere in the middle of the body? (Actually, the last is a separate issue, but things like that always add to the fun.)
fifticon 5y ago
Maybe I misread him, but I read it as "it is better to have just the right, critical set of features", instead of "adding more bells and whistles will always makes it better!" I know from my own code, that whenever I introduce too much flexibility, I invariably end up with fragile complexity, and using it to shoot my feet from various angles. And I have also met a colleague or two who so far haven't reached the same conclusion, only the fragile complexity part (i.e. they still see it as a positive thing.)
joshwcomeau 5y ago
+1, came here to say this. The comprehensibility of the code matters way more than the length. It’s not like the bugs sneak in once every 50 characters typed. As I’ve gotten more experienced, my code has gotten less fancy and more verbose. A single terse expression is broken out into 3 or 4 statements, defining variables that capture and name fragments. But yeah, otherwise really enjoyed the article!
h1fra 5y ago
Funny that point 4 and 5 both make sense alone but are fairly contradictory when applied together. Juniors can barely understand why they are both very important. It's with experience that you learn to write less small dumb code, and write more longer smart/debuggable code. In my short career, the worst code was always the one made by the overly experienced CTO that insist on doing everything in a one liner.
908B64B197 5y ago
> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. Depends on the culture. A lot of offshored programmers will report their "performance" as number of lines written. With the expected results...
slumdev 5y ago
> Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I've never seen a senior write nested ternary expressions with side effects...
rafaquintanilha 5y ago
"Simply put, it means “the less, the better”" was referring to the principle of "via negativa", not necessarily to code. Maybe I conveyed the wrong meaning on this sentence. I don't think that less code is better. I believe that the more code you have, the more potentially breaking parts you get. However, the right amount of code is a function of your deadline, team, goals, budget and whatnot. In any case, it's nice to have principles as a beacon during your development, so you don't get lazy and fool yourself. But by no means they are written in stone and every attempt to summarize an absolute truth will be shallow.
johnalbertearle 5y ago
Quite so.

k__ 5y ago

Yes. Often even sacrificing everything to that tersness.

grp000 5y ago

Agreed. Some of my early code is near unreadable due to the complexity that I've since pared down on how much a single line should be doing.

galangalalgol 5y ago

Verbose code is one thing but multiple adjoining layers of abstraction, or excessive modularization can both make maintaining code very difficult as well. Both dense and bloated solutions had goals other than doing the simplest thing that might possibly solve the immediate problem. That is the only worthy goal, it ensures maintainability due to its simplicity and any extensibility loss is offset by that simplicity. Most of the designed in extensibility I've seen predicted the wrong sort of extension that would be needed anyway.

me_me_me 5y ago
This. Clearly defined purpose for each layer when doing abstraction. Verbosity and simplicity. And NEVER EVEN try to be smart. In two weeks you will forget how the 'smart' solution works and have to spend x2 time changing it.
cactus2093 5y ago
> Most of the designed in extensibility I've seen predicted the wrong sort of extension that would be needed anyway. I definitely agree with that, and I think a preference for more verbose code is actually very compatible with this idea. Verbosity is not the same as over-complicating or over-abstracting things. In my experience a lot of the time it's actually the drive to avoid verbose code that causes these problems in the first place. For instance, you have two functions that are similar but with some important difference, and the developer decides that anything that resembles duplication is bad and refactors them into a single abstraction. This type of thing can cause much more harm than just leaving in a little bit of verbosity by keeping the functions independent of each other.
- gradys 5y ago
  One way to analyze the two similar function situation is to ask whether a future change in the logic to one would imply that a change should also made to the other. If so, then by keeping them separate, you introduce the risk that you would forget to update the other. Using a single function and calling it twice, even with different parameters, is a way communicating that it's important that the semantics be tied. If a change in one wouldn't imply a change in the other, then you really have two separate semantic roles being played that happened to resemble each other in implementation - harmless incidental duplication.
  - Wowfunhappy 5y ago
    What if a change to one would imply a change to the other, but also the block of code is needed in 20 places instead of two?
  - cactus2093 5y ago
    > to ask whether a future change in the logic to one would imply that a change should also made to the other. If there's a really obvious answer to that question, then great. But often the answer is "sometimes" or even "most of the time". We train most developers beginning even in intro-level programming classes to err on the side of deduplication and over-abstracting in these cases, but the longer I've been working as a developer the more I have come to think it's better to err on the side of allowing some duplication except in the most clear cut of cases.

corentin88 5y ago

Agreed. More-readable code is generally longer in my experience. And that’s not a problem AFAICT.

dave_sid 5y ago
Yes, Especially when there a compiler in between the ide and the cpu :-)

jayd16 5y ago

I think the author is referring to the mentality of "I wrote my way into this mess and dammit I'll write my way out!" That is to say, novices can tend to pile onto a solution with hacks and special cases instead of examining why their abstraction requires so much special casing. I think the code golf you're talking about is a different (but not exclusive) thing.

Jtsummers 5y ago
Yep. It's an interesting dichotomy with new hires. They can write some of the tersest code once they learn some new thing ("Wait, C# lets me use LINQ and lambdas. I can turn this entire thing into 3 lines of code!") and some of the most convoluted messes when they run into an issue. I call the latter the epicycle approach [0]. A simple model that doesn't quite work, but they can't let go of, is complicated by adding more and more "simple" extensions but it produces a convoluted mess that is nigh impossible to maintain or sustain. [0] https://en.wikipedia.org/wiki/Deferent_and_epicycle#/media/File:Cassini_apparent.jpg https://en.wikipedia.org/wiki/Deferent_and_epicycle#/media/F... : Demonstrating the complexity needed to maintain a geocentric model and account for the movement of celestial bodies.

ritchiea 5y ago

I believe the author would agree with you, his last bullet point is write for humans not for machines. When he says write less code, I believe he means favoring simpler architectures, saying no to features & tools until you absolutely need them & even finding no-code solutions. Not taking verbose code & making it less readable by shortening it.

rightbyte 5y ago
I note it is quite common with rule of thumbs in programming and that they are misused to sillyness. One way to write less code is to in practice code golf. To follow DRY add deeply nested abstractions. To not have to plan out what you do, use YAGNI or "no premature optimizations". Etc. Edit: My personal favourite is "code should be self-documenting", i.e. comments are a failure.
rafaquintanilha 5y ago
Author here. You summarized it better than me! Thanks.

drewcoo 5y ago

Part of learning any new technique is overusing it to see what its limits are. When people first start coding they're trying to get machines to do things. They have to learn the techniques of making code for other humans. To them it's making things verbose and adding tons of comments because that's better. Meanwhile, they're usually learning to plan for future code needs and make their code flexible. But part of learning to use those techniques is overuse. So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. Time to trim it back. Less is more. I think that's what the author meant.

vagrantJin 5y ago
> So that means code gets gold-plated, baroque, byzantine, and needs a novella of comments to explain its magnificence to future developers so that they use it right. I like the way you phrased that. Anecdotally I find code that is too clever annoying at times, when time is short and the PM Melissa has a bolt action rifle to my head on friday afternoon. I get that code that is too concise is also trying hard to be marvelled as genius-worthy.

mch82 5y ago

It seems the author agrees with you. The final “bad habit” calls people out for writing code for machines instead of humans. https://rafaelquintanilha.com/how-to-become-a-bad-developer/#write-for-machines-not-humans https://rafaelquintanilha.com/how-to-become-a-bad-developer/... The author lists the habits of *bad* developers as: (1) Never assume there is a bug in your code, (2) Write code without reasoning, (3) Lack assertiveness, (4) Take pleasure in writing more code, (5) Write for machines, not humans. So the author advocates for less code, but written to be used and maintained by other people.

stonemetal12 5y ago

My take on it is that all software developers novice or otherwise try to write simple, clear code. For some(especially novices) that means plodding, low abstraction code, so that all the details are visible. This makes for longer code. Others see high abstraction code as the cleaner simpler code because the abstractions hide what they see as irrelevant details, which makes for terse code. “the less, the better” “the more, the better” Tautologically both are incorrect when pursued farther than is prudent, and "the right amount, the better". Unfortunately no one really agrees on what "the right amount" is or we wouldn't have to discus different definitions and strategies to reach "the right amount".

Osiris 5y ago
And of course it depends on context. The interworking of a game engine may require some really obtuse code because it's focusing on performance and not on readability (in those cases, comments should be used to explain the code). In my experience the problem with juniors is more about thinking about the problem in a very linear fashion and not stepping back to see it as individual parts. For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand.
- aYsY4dDQ2NrcNzA 5y ago
  “We must always think of the Way of strategy as being both a rat's head and an ox's neck. Whenever we have become preoccupied with small detail, we must suddenly change into a large spirit, interchanging large with small. This is one of the essences of strategy. It is necessary that the warrior think in this spirit in everyday life.” — Miyamoto Musashi, The Book of Five Rings
- cardanome 5y ago
  > For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand. It is interesting that you think that code with more abstractions is easier to understand. From my experience the simple linear beginner code is the one that is quite easy to work with. It is easy to grasp the general intention and to slowly refactor parts of the code if need be. Now a mid level developer that thinks of themselves to be smart and tries their hardest to use some fancy abstractions and patterns? Yeah, put it in the trash. We will have to rewrite that code. The best code is from the senior that finds the right balance. Finding the right abstractions to use takes years of experience. The most important rule when programming is: Don't try to be smart. Keep it simple.

bena 5y ago

Write as little code as needed to complete the task and as much code as needed to be understood. At the same time. Both incredibly dense and incredibly verbose code can become maintenance headaches. You want it short enough that it can be contained in your head, but long enough that the steps are obvious. I liken it to the scene in Return of the Jedi where Han is instructing Chewie to fly close, but not too close.

austincheney 5y ago

My experience is somewhere in between. Many novice developers are proud of how few lines of code their solution is although it’s really just 2 lines of glue code masking 300mb of dependencies. When you point this out they come back with some bullshit like: * any original code is NIH * vetted by the community * original code can fail

genezeta 5y ago

> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I would agree with that. But then again, it isn't entirely incompatible with the cited quote. That is, at different times in their careers, developers may tend to do different things. In any case, I think I understand the original quote as something I have indeed seen somewhat frequently in large projects. It seems somewhat common, from my experience at least, that people -particularly "not-so-good developers"- involved in large projects tend to assert how large/important the project in fact is, by mentioning LOCs. "This is a very large project... It's about 5.5MLOCs or so. It will have grown a bit since we last counted."

BitwiseFool 5y ago

My friends and I used to joke about how verbose variable and object names can be in an enterprise setting. But the longer I have worked as a professional developer the more I appreciate the long and 'exactly what it says on the tin' names. In almost every circumstance developer time is more valuable to the company than some clever code that 'saves' CPU time.

dgb23 5y ago

I know where you are coming from and I agree on a certain level, but I think this is too specific to your case (large teams, high fluctuation, lots of juniors) The more general approach would be to write code with coworkers/audience in mind. In some environments or projects it might be more effective to write in a way that is harder to grok (requires more work to understand) but is ultimately more tailored to a specific outcome, may that be performance, extensibility, security or what ever.

ChrisRR 5y ago

Oh god, I used to work with the guy like this. Incredibly clever graduate, blew some of my knowledge out of the water. But every day was a game of code golf to him. His code was absolutely illegible

jackcviers3 5y ago
To be fair, bugs are highly correlated with line count, and all code is inscrutable in the absence of knowledge. I do like vocabulary-based metrics for legibility/difficulty; Halstead metrics can't tell you how good a piece of code is, but they can tell you how difficult it is for others to read, empirically. The old 7 +- 2 rule applies, if you are using more than 9 functions/methods and arguments, the vocabulary of a function is difficult. f compose g is 0.5. It has 3 elements. It's not hard to understand. def compose (f: B=> C, g: A => B): A => C = x => f(g(x)) Is 2.5, counting all the definition parts and type level stuff. It has 14 distinct elements. If you don't know the pieces, it's really difficult to read if you don't know any of the parts. If your language doesn't care about types, def compose(f, g) = (x) => f(g(x)) Comes to 2.1 by my count, but you have to look up fewer things at 7, so it's easy to read for new people. Now, the types make it easier once you advance beyond a pure beginner- the constrain the function to only one possible implementation. But if you're totally unfamiliar with things, they make stuff unreadable. Even in tiny functions.

toomuchredbull 5y ago

Yup... I find this with swift developers they love to write code that is just a series of : ? ! type symbols to do what should be 3 or 4 lines of readable code into one line of unreadable code.

marcus_holmes 5y ago

Agreed. The author should change it to "write complex code". Novice developers are frequently proud of the complexity of their code. Experienced developers write simple, easily understood, code.

teucris 5y ago

The principles in this article seem paradoxically conflicting, especially this one (“[don’t] Take pleasure in writing more code”) and “[don’t] Write for machines, not humans” Inherently, more code means more chances to explain what it’s doing to other humans, so shouldn’t more code be better? Obviously not, so I take these two principles in tandem as “write as much code as is needed to accomplish the task effectively and explain how it works, but no more than that.” Squishy, but I think this article as a whole does a decent job of addressing your concerns.

kbenson 5y ago

> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I think it's both. There's a sense of accomplishment that goes along with both accomplishing some small task with minimal code, and also for having written a somewhat large chunk of code for a project. Both have their place, as succinctness has it's place, and it's natural to look back and feel proud of a lot of work. It's just when they aren't tempered by the experience to ask whether that terseness came at a cost that wasn't worth it or whether that project is much larger than it needs to be for the task accomplished that it ends up being detrimental.

systemvoltage 5y ago

“the less, the better” Could mean: 1) As you said, terse clever code and agree 100%. 2) Or avoid writing factories that produce factories, abstractions upon abstractions that never get the payoff since the abstraction only gets used for a single (or a handful) of cases ever. When you write abstractions, make sure that in next 10-20 years its going to get its money's worth by taking advantage of it. There are always some exceptions but most of the time I've seen code that has no defense for all the bloat. 3) The best code is the code that you don't write. In this case "the less, the better" indeed. So I can see multiple meanings of "less, the better". Also, my experience matches the author - new developers are mostly proud of number of lines than cleverness.

jt2190 5y ago

> I also disagree with that author's views on this point. For example: "Simply put, it means “the less, the better”" - No, it isn't. This is one piece of developer lore that’s actually backed by some research. [1] Like it or not, there is a correlation between lines of code and bug count. [1] I’ll link to this research when I have a little more time. Edit: Here's a great resource on this: https://www.hillelwayne.com/talks/what-we-know-we-dont-know/ https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

AceJohnny2 5y ago

I agree, and it reminds me of an analogy... I discovered IRC as a teenager in the 90s, and soon learned SMS-speak for rapid messaging. I was proud of how quickly I could write if I just wrote "u r" instead of "you are"... This was cool! In chatroom arguments, being able to belt out more sentences faster was better! But as my typing improved, I realized the above was a childish optimization. Real skill was able to write out correctly-spelled sentences just as fast. I then saw the SMS-speak as immature shortcuts. This realization carried over into code: good code is the clear, adequately verbose (but appropriately concise) kind. Code that tries to be overly-clever (of the "code golf" kind), was to be viewed with suspicion.

AceJohnny2 5y ago
(I'll admit this tainted my view of Perl for a long time, as I perceived its community tending to more vocally celebrate such "clever" code)

mcguire 5y ago

Have you ever dealt with seriously verbose code? One 10,000 line file with maybe three functions or methods? Setting and resetting the same variables; perhaps introducing new ones kind of randomly? From a programmer who uses essentially one control structure, a while(true) loop with a test and break somewhere in the middle of the body? (Actually, the last is a separate issue, but things like that always add to the fun.)

fifticon 5y ago

Maybe I misread him, but I read it as "it is better to have just the right, critical set of features", instead of "adding more bells and whistles will always makes it better!" I know from my own code, that whenever I introduce too much flexibility, I invariably end up with fragile complexity, and using it to shoot my feet from various angles. And I have also met a colleague or two who so far haven't reached the same conclusion, only the fragile complexity part (i.e. they still see it as a positive thing.)

joshwcomeau 5y ago

+1, came here to say this. The comprehensibility of the code matters way more than the length. It’s not like the bugs sneak in once every 50 characters typed. As I’ve gotten more experienced, my code has gotten less fancy and more verbose. A single terse expression is broken out into 3 or 4 statements, defining variables that capture and name fragments. But yeah, otherwise really enjoyed the article!

h1fra 5y ago

Funny that point 4 and 5 both make sense alone but are fairly contradictory when applied together. Juniors can barely understand why they are both very important. It's with experience that you learn to write less small dumb code, and write more longer smart/debuggable code. In my short career, the worst code was always the one made by the overly experienced CTO that insist on doing everything in a one liner.

908B64B197 5y ago

> My experience has been the opposite. Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. Depends on the culture. A lot of offshored programmers will report their "performance" as number of lines written. With the expected results...

slumdev 5y ago

> Novice developers tend to be proud of how terse and dense their code is, and optimize for minimizing line count. I've never seen a senior write nested ternary expressions with side effects...

rafaquintanilha 5y ago

"Simply put, it means “the less, the better”" was referring to the principle of "via negativa", not necessarily to code. Maybe I conveyed the wrong meaning on this sentence. I don't think that less code is better. I believe that the more code you have, the more potentially breaking parts you get. However, the right amount of code is a function of your deadline, team, goals, budget and whatnot. In any case, it's nice to have principles as a beacon during your development, so you don't get lazy and fool yourself. But by no means they are written in stone and every attempt to summarize an absolute truth will be shallow.

johnalbertearle 5y ago

Quite so.