4 ms·

> But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap cod

> But in my experience, some people also have code impurity complex such that they think somehow they're better because they're capable of dealing with crap code without complaining. You better believe that I complain loud and hard about crap code. I complain about how crap other people's code is, and I have the self-awareness to complain about my code that is crap. What I have a problem with is the attitude some people have that developers "suck" because they write crap code. For example, some people write method names that aren't descriptive. It happens. I personally don't think they should be forced to write "I suck" 30 times on their school blackboard because of this. What would that actually achieve? > You say "code purity is a self-limiting decision" without realizing writing code with correctness as an afterthought is often a more significant self-limiting decision because it increases the cost of the software in terms of maintenance and refactor cost. No, actually, I do realize this. But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost. From the VB6 example I used before - the runtime will actually be out of all versions of Windows from 2024. But that's a problem for Another Project. You may think that writing "incorrect" code is a self-limiting decision but I can assure you that I am doing fine and my clients/managers/colleagues have generally enjoyed working with me.

gnulinux 4y ago
Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, some people write method names that aren't descriptive. It happens. I agree, and I would actually argue names don't matter. Well, they do, we should still pick good enough names, and never pick adversarially confusing names. But ultimately, code should be clear regardless of the name. Take a look at this Haskell talk for better arguments than I can write here: [1] Part of the reason why designing software that by definition cannot include bad behavior is such a powerful concept is because even when we inevitably name things terribly, the harm is contained. [1] https://www.youtube.com/watch?v=ZSNg6KNzydQ https://www.youtube.com/watch?v=ZSNg6KNzydQ > But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost Sure, but this part of the problem. As engineers, it's also our duty to explain to business people the implications of these. If ultimately the business decision is that "this thing won't matter in X years" then there is nothing we can do, but the limitations must be known and clearly communicated. Which, I don't think you disagree, but I didn't think this came out in your original post.
- tomlockwood 4y ago
  > As engineers, it's also our duty to explain to business people the implications of these. I agree wholeheartedly! It is always a disappointment for me when I'm unable to adequately explain to people why we need to minimize technical debt, or write good tests, or use linting, etc, but I think many developers also struggle with this, and so I don't think it would be fair to say a developer "sucks" for having to drop those to write code that works in the amount of time they managed to negotiate. But, some of the best developers (technically) I know also have pretty bad communication skills!

gnulinux 4y ago

Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, some people write method names that aren't descriptive. It happens. I agree, and I would actually argue names don't matter. Well, they do, we should still pick good enough names, and never pick adversarially confusing names. But ultimately, code should be clear regardless of the name. Take a look at this Haskell talk for better arguments than I can write here: [1] Part of the reason why designing software that by definition cannot include bad behavior is such a powerful concept is because even when we inevitably name things terribly, the harm is contained. [1] https://www.youtube.com/watch?v=ZSNg6KNzydQ https://www.youtube.com/watch?v=ZSNg6KNzydQ > But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost Sure, but this part of the problem. As engineers, it's also our duty to explain to business people the implications of these. If ultimately the business decision is that "this thing won't matter in X years" then there is nothing we can do, but the limitations must be known and clearly communicated. Which, I don't think you disagree, but I didn't think this came out in your original post.

tomlockwood 4y ago
> As engineers, it's also our duty to explain to business people the implications of these. I agree wholeheartedly! It is always a disappointment for me when I'm unable to adequately explain to people why we need to minimize technical debt, or write good tests, or use linting, etc, but I think many developers also struggle with this, and so I don't think it would be fair to say a developer "sucks" for having to drop those to write code that works in the amount of time they managed to negotiate. But, some of the best developers (technically) I know also have pretty bad communication skills!