5 ms·
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
by makach 7y ago
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.
- mytailorisrich 7y agoYes 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.
- antupis 7y agoThing is that when knowledge is built into organisation you lose some agility, so there are definitely some tradeoffs.
- collyw 7y agoMy 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....
- SeriousM 7y agoIn 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.
- wesleyjconnor 7y agothis hits so close to home
- sbarre 7y agoAnd one day he leaves..
- ezzzzz 7y agoSometimes, 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.