Comment by Bahamut | Hacker News Reader

Comment by Bahamut | Hacker News Reader

Parent Full thread

I've seen many negative consequences from poor software engineers being brought into companies first hand.

I saw a junior engineer try to add a patchwork of libraries just because he was not confident in his ability to do something correctly, leading to a lot of maintenance overhead that grew very quickly.

Many of the previous frontend engineers got fired from my current company because they did not produce at all - a direct result is a polluted codebase that needs to be scrapped asap because it has led directly to poor perception of product. It also is extremely difficult to iterate upon.

One company I was at had some very terrible legacy code from full stack engineers. The person who wrote the code was fired as well, but not before leaving damage that persisted for years - some triply JSON.stringified JS object, along with some other extra parentheses, was stored right into the database as a string! This meant every time the data had to be fetched, it had to be parsed by the server to fill certain other data, but the core answer object was still sent as it was due to the difficulty associated with sending a parsed form (the backend was Java), which meant that the frontend also had to parse it! Thankfully we were able to silo the damage to an easy to adapt modular service, but it was the cause of much sadness, especially when it was a core piece of data for our product.

First off, thanks for providing some concrete examples.

That said, those all fundamentally sound like process problems to me. They would not have been allowed to happen at either of the companies I have worked for or any of the companies I have worked with, at least not to a degree that they would harm products. Sure, we have shit code down in the bowels of our libraries, and some of it was put there by people who didn't know what they were doing. I would not characterize any of it as serious problems, though. Those tend to either not live long or not make it into the codebase in the first place.

I understand there is a tradeoff here, and that "process" is a dirty word to many people. A little process can go a long way, though. It can make problems like those you describe minor or non-existent. To me this seems like a small price to pay for opening up your hiring process and dealing with the poor choices.

On a slight tangent and speaking of costs, I get the impression that many people discount the cost of a false negative. You are trying to hire people for a reason. Your company is incurring costs from not having this person, be it the lost revenue from expanding or the actual costs of working your current engineers harder to meet deadlines. That needs to enter into the equation, along with the costs of false positives and the costs of mitigating same.

Even though process is intended to mitigate the damage an individual can cause, in practice it's hard to have a good process without good people. Everywhere I've felt that a poor hire had serious negative effects on a company, those employees were also obstacles to bringing in a better process.

I agree with you that the cost of a false negative must be considered. The kind of bad hire I'm thinking of here is a net negative producer that actively costs the company money (or even causes good employees to leave), even after they're gone (if you can manage to get rid of them).

I agree that good process is of vital importance. At one of the aforementioned companies, there was little process. At another, they appeared to have near mastered it (some issues, but overall exhibited excellent leadership & management). At one, the process is seriously broken.

I am starting to feel that if there is some bad code that does some longer term damage, the managers are at fault.

>I saw a junior engineer try to add a patchwork of libraries just because he was not confident in his ability to do something correctly, leading to a lot of maintenance overhead that grew very quickly.

That's why they're called junior and they get paid less. They're meant to be supervised to some extent. If the problem is only caught long after the damage is done then the issues run deeper than the capacities of a single junior engineer. Junior is just a nice way of saying inexperienced. Experienced != good, but inexperienced almost always means some degree of bad.

Why did the damage persist for years? Seems like that problem could be fixed fairly quickly.

It is too bad when someone writes less than optimal code, but on the other hand, did the software work? Did it make the company money? If so then it was a success, regardless of how bad the code looks. Often times in business you have to hack together something that works now, and worry about re-writing it later. It's easy with the benefit of hindsight to look back and say how things should've been done differently.

Reply on news.ycombinator.com