I think I often get rated poorer by management compared to others because I tend – by nature – to focus deeply on complex problems (Donald Knuth-style), whereas a lot of other developers communicate more, answer emails promptly, go to a lot of meetings and manage to cut 'n' paste together some code to show results the very next day. So you do get respect from fellow developers for your skills and experience, but managers don't really value you.
Nowadays there seems to be more and more focus on quick results ("profit") in development rather than an effort to have a more lasting solid base to build on; a lot of software is in eternal "prototype" phase, like the "under construction" state of web sites around 2000. I guess it echoes the general business mindset of quick short-term profit over lasting quality.
I think that pretty consistently the wrong people are chosen or promoted to lead or manage development projects; they are rarely the most knowledgeable of developers – if they know anything technical at all – and definitely even rarer do they possess the kind of personality that can actually stimulate and motivate others. I guess that's the curse of being more like an engineer as opposed to a business person; you tend to end up in a position where the people higher up don't necessary share the same motivations and goals, but have more control over your destiny than you'd like.
I used to be in the "correct but slow" camp. Now I better understand business I'm more aware of what needs the correct solution and what needs the timely solution, and this has greatly helped my career.
Yet I remember choosing a data structure too hastily and that killing a project a couple months later. By the time the error was realized, there wasn't time to reboot, project dead. You want a minimal viable product and both words create very difficult judgement calls.
It sounds like your assumptions about other developers copy and pasting is lumped in with a bunch of very positive things (asking for help, helping others, being a teammate, being invited to meetings about complex problems). My personal opinion is that software is nuanced and approaching every issue you run into with an assumption that it is important may be a misgiving.
The two second localization change shouldn't be "I have decided to rewrite localization." Similarly for new features, getting an MVP and releasing it internally is often better than writing the best XYZ from the start.
With that being said: there is a time for being very safe and cautious. Sometimes the work you're doing is the core piece of the business -- that deserves respect, lots of extra thought, a full suite of tests, etc.
In terms of engineering problems, make sure you aren't making things more complicated than strictly necessary. Most software gets rewritten because constraints/requirements/teams change over time, in unexpected ways. YAGNI.
Also, usually your job isn't to solve an engineering problem, it's to provide business value. It's easier to claim great engineering value (because all the requirements/constraints are in your head), rather than actually solving customer need where someone else gets to decide whether you are providing value.
Oh and of course people who are more visible to higher-ups get promoted more!
I think a huge problem with YAGNI as a principle is that it is - in itself - as subjective as most of the points in this whole discussion.
I've read my fair share of code authored by people who's definition of "done" seems to be "it compiles and doesn't fall over the first time I look at it", ignoring various obvious edge cases that could be triggered randomly. Cleaning up messes like this always costs more than the shoddy implementation saved in the first place. Usually those clean-up session start when some strange edge case occurs on a critical production system.
On the other side, the approach is fine, if the code only runs once or twice an is then discarded. In that case ironing out all possible bugs is clearly a waste of time.
So, YAGNI means different things in different contexts. So, I'd say that being aware of said context is a very crucial skill to have as a developer.
---
When it comes to business problem solving, I couldn't agree more, though. There are a lot of "solutions" that could have gotten so much better if someone tried to figure out the problem first.
People spend a lot of time demonstrating their sexual fitness for reproduction by displays of prowess. It's just what we do. Intellectuals and engineers aren't exceptions, they're often very naive about this tendency and the biological roots of it. I agree there. I've sometimes said that universities are very important because they teach people to meet the irrational demands of cloistered professors in order to succeed; thus preparing them for business. But there are times, you would probably agree, when you have to argue strenuously for engineering problems to be funded for engineering reasons, before they crash the business. Building a bomb because that's what management said they wanted isn't what you're paid for either.
The world is a social place. Who you know is much more important than what you know, a lot of times. Unfortunately I think this means that the personality types who seek management jobs are often gaining their position by personality, not qualifications. For someone who values competency and technical skill, the world is a frustrating place. Of course there are companies out there that make an effort to go against this paradigm but I feel like those are exceptions to the rule.
This can start at the top. If you're in a company that exists because the founder is a great actor and was able to bullshit, social engineer and gladhand a hapless angel or VC into funding them; then they'll likely hire similar shiny people for other management positions below them, too. Chances of success: poor.
Nowadays there seems to be more and more focus on quick results ("profit") in development rather than an effort to have a more lasting solid base to build on; a lot of software is in eternal "prototype" phase, like the "under construction" state of web sites around 2000. I guess it echoes the general business mindset of quick short-term profit over lasting quality.
I think that pretty consistently the wrong people are chosen or promoted to lead or manage development projects; they are rarely the most knowledgeable of developers – if they know anything technical at all – and definitely even rarer do they possess the kind of personality that can actually stimulate and motivate others. I guess that's the curse of being more like an engineer as opposed to a business person; you tend to end up in a position where the people higher up don't necessary share the same motivations and goals, but have more control over your destiny than you'd like.