3 ms·
I hadn't seen that type of 'high' performer much for most of my career, but now I work at a place that appears to be plagued with them. I think some cultural pr
by hibikir 10y ago
I hadn't seen that type of 'high' performer much for most of my career, but now I work at a place that appears to be plagued with them. I think some cultural practices foster that bad behavior, common in places that move fast.
One of them is to value support and firefighting very highly. The best firefighter is often one that is also the most familiar with the code, so it's common to see amazing firefighters that are also your arsonists! But when you don't track where the bugs come from well, and have little code ownership, whoever writes the most code writes the most bugs, does more firefighting later, learns more about the system, and distances themselves from the rest of your developers that actually want the system to work. This also increases the amount of tribal knowledge (as systems get quirky and badly documented), making it harder for anyone else to seem like a high performer, as to make any changes to anything that isn't new, you have to learn how the rest of the snakepit works. And as you learn how it works, it gets bigger, because the "high performers" are creating debt far faster than anyone else can learn it.
If bugs are treated seriously, tests are treated seriously, and how easy people join a team is considered an evaluation criteria for the existing team members, not the new ones, things are different.
- radiowave 10y agoVery sharp summary. I definitely recognise this.
- pasquinelli 10y agoand then you end up with a company where one or two people are utterly indispensable.
- ArkyBeagle 10y agoSome organizations have that tendency no matter what is done. It's perceived as more efficient.
- ArkyBeagle 10y agoNobody has any idea of how to place a value on any of those things, so you're just making it up so far as they are concerned.
- CyberDildonics 10y agoI definitely been at places that regard firefighters as heroes and people who want to build houses that don't burn down in the first place as trouble makers and pessimists. It is a terrible culture to have and sometimes it is difficult to get away from, because to admit that you've built a fragile system is to point the finger at someone for work they did months ago or to point the finger at yourself.
- lisivka 10y agoYour development process is broken. How "high performer" can create technical debt in first place? I, personally, will not close ticket until it is well documented (i.e. code has comments, documentation is updated, ticket has resolution summary), and test cases are created (to be sure that nobody else will broke new code by incident), and code and test cases are properly peer reviewed by at least one member of the team (to allow information to spread across team), and all issues are addressed. Moreover, tickets are short, so they are easy to done and review.
- jakub_g 10y ago> whoever writes the most code writes the most bugs I'm experiencing this first-hand now. One colleague is writing lots of code very fast. Problem is, this code is far from perfect, and I spend a lot of time to understand it, and I find many bugs quite often. In the meantime while I'm reviewing, the guy writes even more code...
- fouc 10y agoHopefully you're not merging the feature branch until it passes code review. And if there are bugs, then you kick it back to him with all the comments you made.
- CaptSpify 10y agoIn my experience, these types of employees are "too busy for that". And they typically have the political clout that they can continue to get away with it. I'm not saying it should be that way, and YMMV, but it's how I've typically seen it play out.