[gav]

I can give many examples where I've handed code over and later there was problems due to less-skilled developers.

One good example I have is being called by a client who had a bug they couldn't fix in some code I had written years before. After looking into it, I found something like this:

    // ABC 1/1/2001 removed this call as we don't understand why it was being called
    // x = performImportantCalculationABC();

There are lots of terrible programmers out there. The average level of programming skills on HN is considerably higher than you'll find at most companies.

I've seen so much bad code written by people with senior job titles; confusing, ugly, inflexible, but working code.

[veb]

You're forgetting that the smarter programmers realise all they need to do is fix something really fast, so their managers are like, "oh my goodness, you're excellent!" but if you get caught up on the details, spend several weeks "fixing" something that your manager won't even see or understand, you're a shit programmer.

So really, you gotta get your priorities straight.

[KirinDave]

If your priority is "ingratiate yourself to your manager" then yeah, it's best to pick small superficial problems or prefer patch-job fixes. These decisions tend to be informed by how much technical debt the "short" fix makes.

But if a problem genuinely will take 6 weeks to solve, then it's probably a worthwhile problem to solve. Those sorts of problems tend to have far-reaching implications for sites and their ability to scale. The big question is when to solve it. Competent engineers know when to do this.

Managers who can't see this? Bad managers. Bad managers can kill a startup just as effectively as 'rockstar' engineers.

[jshen]

Your code looks bad to me. Either x isn't used at all later, or you set x then for some reason set it again which is bad.