Hacker News Reader

Comment by hyperpape | Hacker News Reader

Funny that everyone leapt to the conclusion that it was a junior developer. I immediately thought of a senior developer who "gets things done" and gets rewarded for that, but leaves a flaming pile of rubble in their wake. I've seen bad bugs written by junior developers, but I've spent more time cleaning up issues introduced by experienced people for whom time had just reinforced bad habits. I don't know which is more common in general, that's just my personal history.

Who knows which it is. The article says they haven't touched the frontend servers yet, not that they haven't done anything substantial yet, so I don't think we can know unless Rachel decides to comment on that point.

View on HN

The worst experiences I ever had at a job were due to the most senior developer there. He was basically given this god-like status from management where he could do no wrong, and had free reign of all systems, because he'd been there for so long..

Yes, he was an incredibly capable software developer, but that had led to an ego issue where he thought he knew EVERYTHING, not just developing in his particular stack... so he'd find his way into various systems (software and hardware) he had no experience in, and assume he could just figure it out.

We had half a dozen full-on-disaster level situations in the couple years I was there thanks to this 1 person. Each time it was shrugged off as "an accident" because heaven forbid you actually upset him or hold him accountable.

I've observed that pattern with developers who are relatively senior, and have been in the same, smallish place since they graduated. Basically they had no technical feedback ever in their career.

Some developers put their crazy ideas and experiments on github; some developers put those in production.

This sounds a lot like my current situation at work. We're a decently-sized company of 100+ people. About a quarter of them are developers. Developers are divided into teams who are responsible for specific components of our system.

However, there are also a few "architects" who are basically free agents with god-like status. They don't architect anything. Rather, they do a lot of counter-productive things such as attending meetings for specific teams without those teams knowing. Then they make large decisions about the direction of a given feature without documenting anything, let alone letting those teams in on what's going on. It's always a fun surprise and works wonders for our ability to deliver a solution on time /s

Beyond that, they'll go off and develop whatever they feel like and force it through the system. We have a code review process, but if you bring up that problems are present in their code, they will often say that it doesn't matter and that the code just has to go through to meet some unspecified deadlines. They'll get management to skip code reviews if you try to hold them accountable. And of course, this results in things exploding. But then they can clean up those exploded bits, knowing what they were, and come out heroically since they "put out so many fires".

I'll stop ranting. But it really is frustrating, especially when you get shut down by management for bringing up any issues with this chaotic group.

Sounds like every startup ever.

> I've spent more time cleaning up issues introduced by experienced people for whom time had just reinforced bad habits

In my last job there was this guy who had more than 10 years of dev experience and:

- He tried to convince me it was better to write our own encryption algo instead of using https.

- His mySQL tables used no foreign keys, only int fields.

- He mixed all sorts of naming conventions in his code and databases: English, Spanish, camel case, snake case, kebab, etc.

- He spent 1-3 hours every day getting into the bank web apps, downloading some pdfs, copying and pasting stuff around, and finally producing a report by hand. Every single fucking day. So I developed a small service for extracting financial data from those pdfs into JSON. He only needed to read those JSONs and automate the reporting part. No, he kept making those reports by hand.

The guy was a friend and long time collaborator of the IT manager which was a complete ignorant in terms of dev.

> His mySQL tables used no foreign keys, only int fields.

This one is potentially justifiable if speed is a higher priority than data integrity.

Ok, but no, this was incompetence. The application he managed had around 10k users that used it a couple of times per year.

Most MySQL applications don't use FKs. The world keeps turning.

Besides performance issues, FKs cause ordering issues with restoring tables when necessary.

However, they're great for diagramming tools to show table relationships.

I'm more concerned when I don't see unique indexes on things that need to be unique (often caused by early versions of RoR.) In my experience, this is never a theoretical problem - it always becomes a major operational problem.

Source: MySQL DBA

Also, depending on how long ago this was, may not have been as bad as it sounds -- MyISAM doesn't support foreign keys, and it was the default all the way until MySQL 5.5 in 2010.

That last point kind of revokes his programming credentials. Something that takes that long, done that often, gets automated pretty quickly by most self respecting developers.

Yeah totally. I've never understood why he preferred copying and pasting over actually writing code.

job security and laziness. could be very meditative to do some copy-pasting over your morning coffee/tea

Note also that the developer said it would be a good long term solution to put the thing behind a service. Oftentimes the person isn't ignorant of better practices (though they may be out of practice in applying them). They just differ in which shortcuts they think are acceptable. Or perhaps they've been broken by an environment where doing the right thing has always been blocked by someone, until they no longer even try.

Replying to myself, since I can no longer edit.

Bad "senior" developers are worse than clueless junior developers: they cover their landmines better.

..and have juice with one or more managers

also, their ability to shift blame often is the reason they are a senior developer and not a fired developer.

That was my first assumption. These dangerous situations come up when a manager or developer think they have an asymmetric opportunity:

Ship this feature quickly and collect all the credit, or crash the website in the process and blame the website team.

Reply on news.ycombinator.com