[bad_user]

I smell trolling, however considering this anecdote is genuine:

(1) interns should never be allowed to commit code in the master branch without a code review from a senior developer

(2) there are many competent developers in India, or around the world, so if your company needs to outsource, it can do so by being a little careful about who they employ

(3) if the above 2 are not possible, simply look for another job, because life is too short

[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.

[diego_moita]

No, I was not trolling. The key to understand the whole thing is that it was not a software company, but a construction company and I was there as a consultant.

For them, software is a cost, not a source of revenue. That's why they didn't implement rigorous practices such as code reviews. That's why they'd prefer the cheaper against the better coders. That's why I already followed your 3rd advice.

[jimbokun]

It's hard for me to think of a good reason why a construction company should be writing custom software, instead of buying something off the shelf.

[clavalle]

For the same reason any other large enterprise does...so many special cases in their organically grown 'systems' that it would be cheaper to get something custom coded than try to shoehorn their process into an off the shelf environment.

[xxpor]

(1) No one be allowed to commit code in the master branch without a code review from another developer

FTFY