3 ms·

A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promot

A) Short-term mindset developer: - Tech debt is for others to fix. While others cleanup after me, I will be completing my next task and paving my way to promotion. - If it works, it's good enough. It does not matter if I can't explain why it works. - Everything is an obstacle. Documentation? obstacle. Coding standards? obstacle. I just want to complete tasks. - I do exactly what I am asked for. It does not matter if it is insecure, it does not scale, or if the entire system crashes. All of that will be someone else's problem later. - Code does not have to make sense, as long as it runs it is good enough. - I worship project management. B) Sustainable mindset developer: - The cost of tech debt compounds over time. I should fix tech debt before more code depends on it and becomes more expensive to fix. - I need to understand how and why things work. Is this really working? Do I really understand what I am doing? - Reviewing relevant documentation for the technologies I use is a good idea. Making sure I understand and follow coding standards is a good idea. Well crafted coding standards can save work. - I understand that not all stakeholders are technical. I need to understand the technical implications of what I am asked to do, and push back if necessary. - Code is written once, read many times. Readability makes everyone more productive. - I acknowledge that project management documentation and tools are a form of documentation, and as such, it is not a source of truth. When it comes to things to do, the implementation is the source of truth, not tickets. Bad companies promote A), good companies promote B).

xyzelement 6y ago
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
- lxe 6y ago
  Spot on. An experienced developer understands that incurring tech debt and paying it down is a balancing act.

xyzelement 6y ago

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
lxe 6y ago
Spot on. An experienced developer understands that incurring tech debt and paying it down is a balancing act.