3 ms·

I'm going to go out on a limb and guess that their "reason 1" was the sole source of the issue. This smells like an instance of the "nobody likes a know-it-all

I'm going to go out on a limb and guess that their "reason 1" was the sole source of the issue. This smells like an instance of the "nobody likes a know-it-all" problem that often arises with junior devs who haven't yet learned that their job isn't just between them and the computer, but them, the computer, and other people: the cleaner version likely would have replaced the dirty version had the author actually had a dialog with the author of the dirty code and mutually decided that there was a better way. The article likely would be better titled as "I learned a lesson about working on a team", not "goodbye, clean code".

Kiro 3y ago
I think the title is fine. It's a classic for good reasons and has been an eye-opener to a lot of devs falling into this exact trap, which you can do even if you're working alone. You overengineer a clean abstraction just to get bitten by it in the future.
watwut 3y ago
> This smells like an instance of the "nobody likes a know-it-all" problem that often arises with junior devs who haven't yet learned that their job isn't just between them and the computer, but them, the computer, and other people Meh, it is usually seniors on power trip who are guilty of this.
JonChesterfield 3y ago
> instance of the "nobody likes a know-it-all" problem Excellent insight. I think this exactly captures the dev environment. The more complicated code was viewed as a threat, the rival worth taking down a peg or two via management chain. For juniors reading this who have the same experience. "Nobody likes a know-it-all" is context dependent. It's absolutely true of lots of professional settings. Simplicity over flexibility, avoid confusing language constructs, preference for lots of time at the keyboard and languages that encourage this. The lifelong learning, software craftsman, reflect on the process philosophy advocated in various places is completely at odds with that setup. Trying to get better is unpopular with those who are not improving. Both are valid life choices. Software has been a comfortable place to put in your seven hours at the office and go home. It's also a world to explore bounded only by your imagination and intellect. Beware spending decades working with those who fear the unknown if you'd like to be one who discovers novelty. Or more concisely, if your incentives are misaligned with those of your colleagues, consider getting out of there.

Kiro 3y ago

I think the title is fine. It's a classic for good reasons and has been an eye-opener to a lot of devs falling into this exact trap, which you can do even if you're working alone. You overengineer a clean abstraction just to get bitten by it in the future.

watwut 3y ago

> This smells like an instance of the "nobody likes a know-it-all" problem that often arises with junior devs who haven't yet learned that their job isn't just between them and the computer, but them, the computer, and other people Meh, it is usually seniors on power trip who are guilty of this.

JonChesterfield 3y ago

> instance of the "nobody likes a know-it-all" problem Excellent insight. I think this exactly captures the dev environment. The more complicated code was viewed as a threat, the rival worth taking down a peg or two via management chain. For juniors reading this who have the same experience. "Nobody likes a know-it-all" is context dependent. It's absolutely true of lots of professional settings. Simplicity over flexibility, avoid confusing language constructs, preference for lots of time at the keyboard and languages that encourage this. The lifelong learning, software craftsman, reflect on the process philosophy advocated in various places is completely at odds with that setup. Trying to get better is unpopular with those who are not improving. Both are valid life choices. Software has been a comfortable place to put in your seven hours at the office and go home. It's also a world to explore bounded only by your imagination and intellect. Beware spending decades working with those who fear the unknown if you'd like to be one who discovers novelty. Or more concisely, if your incentives are misaligned with those of your colleagues, consider getting out of there.