3 ms·

There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that

There's also a C) Pseudo-sustainable developer, who thinks he's doing B but really over-investing in optimizing and overcomplicating (and over documenting) that which isn't critical and thus wasting a ton of time.

beandgaethje 6y ago
This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.
- xyzelement 6y ago
  I am less optimistic. A good developer documents the right parts because he has the understanding that this is helpful. An under-documenter doesn't get why that's helpful. An over-documenter doesn't get why it's helpful either, that's why he does it all over the place.
  - glouwbug 6y ago
    Good on them for puttin in the effort, at least. Some of us just show up for the paycheque
29athrowaway 6y ago
It takes more time and dedication to become effective at B). And at first, you may get things wrong, but the approach does pay off. Someone that follows approach B learns more in a shorter amount of time. Because learning (advancing the frontier of your knowledge) happens when you encounter that limit, recognize it and try to move forward. Rather than dismissing it, which is what A) does. B) always thinks: what is a better way of doing this? A) never does. Therefore, over time, B) becomes more effective than A). In mind sports it's the same. You learn more in slow games when you take longer to think your moves. Every pro will recommend you to prefer slow games over fast games.
- xyzelement 6y ago
  This doesn't really match my experience with people. You can be dogmatic about, for example, code comments - and dogmatics are not thinkers. I used to work with a guy who was representative of this dogma. He'd give people a hard time if they didn't comment every line of code, and his own comments would be shit like: if (country == "Japan) // If the country is Japan total_cost = price // set total_cost equal to price else total_cost = price + tax // Otherwise, set total_cost to price+tax He thought this was great, and was upset when I'd tell him this is completely useless (comments don't provide any information over the code) and it's missing the one thing that would be good to actually document: why is Japan different? People like this heard somewhere that comments are good, and thus good people write comments, and if I am a good person then by gosh I am writing comments. They don't think about utility at all.
  - 29athrowaway 6y ago
    Your code example doesn't represent approach B). You are conflating verbosity with readability. A better example of B) in this context would be understanding that IEEE 754 floating point numbers cannot be used for currency, and perhaps adding a comment about that. Meaning, really understanding what you are doing all the way, and understanding when it works and when it doesn't.
    - Gibbon1 6y ago
      I've come around to commenting as if I was Statler and Waldorf.
lxe 6y ago
Spot on. An experienced developer understands that incurring tech debt and paying it down is a balancing act.

beandgaethje 6y ago

This sounds like a junior dev on the path to B). I think the desire to do the right thing says a lot and finding that right thing takes time.

xyzelement 6y ago
I am less optimistic. A good developer documents the right parts because he has the understanding that this is helpful. An under-documenter doesn't get why that's helpful. An over-documenter doesn't get why it's helpful either, that's why he does it all over the place.
- glouwbug 6y ago
  Good on them for puttin in the effort, at least. Some of us just show up for the paycheque

29athrowaway 6y ago

It takes more time and dedication to become effective at B). And at first, you may get things wrong, but the approach does pay off. Someone that follows approach B learns more in a shorter amount of time. Because learning (advancing the frontier of your knowledge) happens when you encounter that limit, recognize it and try to move forward. Rather than dismissing it, which is what A) does. B) always thinks: what is a better way of doing this? A) never does. Therefore, over time, B) becomes more effective than A). In mind sports it's the same. You learn more in slow games when you take longer to think your moves. Every pro will recommend you to prefer slow games over fast games.

xyzelement 6y ago
This doesn't really match my experience with people. You can be dogmatic about, for example, code comments - and dogmatics are not thinkers. I used to work with a guy who was representative of this dogma. He'd give people a hard time if they didn't comment every line of code, and his own comments would be shit like: if (country == "Japan) // If the country is Japan total_cost = price // set total_cost equal to price else total_cost = price + tax // Otherwise, set total_cost to price+tax He thought this was great, and was upset when I'd tell him this is completely useless (comments don't provide any information over the code) and it's missing the one thing that would be good to actually document: why is Japan different? People like this heard somewhere that comments are good, and thus good people write comments, and if I am a good person then by gosh I am writing comments. They don't think about utility at all.
- 29athrowaway 6y ago
  Your code example doesn't represent approach B). You are conflating verbosity with readability. A better example of B) in this context would be understanding that IEEE 754 floating point numbers cannot be used for currency, and perhaps adding a comment about that. Meaning, really understanding what you are doing all the way, and understanding when it works and when it doesn't.
  - Gibbon1 6y ago
    I've come around to commenting as if I was Statler and Waldorf.

lxe 6y ago

Spot on. An experienced developer understands that incurring tech debt and paying it down is a balancing act.