Hacker News Reader

Comment by twblalock | Hacker News Reader

The people who get the most done are not the smartest, or the most skilled, but the ones who are most familiar with the organization they work in.

To outsiders it looks like they end up with compromised solutions, but to insiders it looks like they achieved the impossible.

View on HN

To me this has always been a management issue. Usually the business willingly allows for this to happen. Consequence is that you build an extreme dependency on this person. Knowledge needs to be built into the organisation through hard work, like documentation, processes and collaboration.

Yes the business allows this to happen because it is obviously in the self-interests in the existing employees: everyone tries to build their own little empires and to keep 'invaders' at bay.

In some companies, often when there is no growth, that leads to very claustrophobic atmospheres with a core group that has been there for 10+ years and gatekeeps everyone else.

Thing is that when knowledge is built into organisation you lose some agility, so there are definitely some tradeoffs.

My current workplace.

We have one diva who build the vast majority of the system. He is smart and likes algorithms, but doesn't write particularly easy code to follow (he values cleverness over simplicity). Any suggestion that it could be improved is met with a bit of an argument. And he isn't much of a team player compared to the other devs.

But he knows the system inside out....

In not the gut you talk about, but... I built many systems and was always a point of failure when it comes to dependency. I still know a lot of code, even when it's years ago. But I never kill an idea that has a better outcome as the current solution has, and if it's possible to implement, we'll do it. That's leadership.

this hits so close to home

And one day he leaves..

Sometimes, the people getting the most done, are either doing so based on proficiency (i.e. deep understanding of domain, system, language, stack etc) or are simply adept at finding the shortest path from a(requirements) -> b(code). These are the people I look out for, as essentially the root of tech debt. Hopefully, things like code-review will prevent people like this from pushing code that only they can understand, but that theory often proves false as these folks often out-rank you. Don't be afraid to call BS through any means available. At the very least, you need an explanation/comments/documentation explaining why simplicity was sacrificed.

I would change "familiar with the organization" with "good with people". It's all about getting others to help you reach your goals.

That’s what I see everyday. Insider produce crap, I criticized it as a new guy and became enemy number one very quickly. Isolated organizations enter the Lord of the Flies state. For them everything is normal while outsider has experienced more possible solutions. So it hurts seeing how bad and primitive device is made from 6 separate printed circuit boards soldered with random wires. Every amateur can do better with KiCad in a week. But in this organizations it’s state-of-art and author of this mess got promoted to senior.

I’m not saying this applies to your example, but the opposite happens too—the new guy comes in with all the answers but not knowing all the battles/design constraints that led to the current situation. It’s frustrating because the team gets to relive every design decision as the new guy brings up all the obvious stuff that surely none of the dummies on the original team thought of (but of course were the original designs before some business decision or other derailed things).

I am pretty sure, that “new guy” does not know all internals. But there some rules like not putting 2 screwdrivers into power outlet... It’s obviously should be done other way.

Running with that example for funsies. Turns out that slamming two screwdrivers into the outlet allowed you to tap the power source 6 inches away from the wall. Normally, this is a bad idea, but the alternative was tearing down the wall to extend the outlet, and the cost of that was too high at the time. The other cheap solution was a power strip, but there was no petty cash and no nearby store. Then several people tied power wires around the new screw driver power extenders (which was going to be a temp solution anyway until you could buy a power strip). Now, these critical power wires can't be disconnected because the attached servers can't go down.

Sometimes things organically grow in bad ways as cost optimizations that maybe (or maybe not) made sense back in the day. If you were to design it again, you obviously would not stick the screw drivers in the wall socket. But that was then, this is now. Instead of complaining about screw drivers, let's get a plan in place to get the mission critical services to be able to switch power sources.

Reply on news.ycombinator.com