3 ms·

You are not only paid to write your piece of code and be happy about it. You are also paid to be on stand by and do whatever you can to move the company forward

by Too 12y ago

You are not only paid to write your piece of code and be happy about it. You are also paid to be on stand by and do whatever you can to move the company forward which includes helping out other people at work. We have one employee who thinks he is a rock star (he is not), he finishes his assigned tasks in 4 days instead of 5 and then takes Friday off because he thinks he "deserved" it for being so damn creative and intellectual and he thinks about work at home anyway... Guess what happens on Fridays, people are still at work and need to contact this guy, questions about old code, plans for future, a new task came in, and surprise surprise, the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that? Its a tough balance, i am also very against pushing through when unispired and the sit on your chair and wait for the clock kind of job and I also need distraction free creative time. But this guy has thought me that many times the team needs you more than you need your oh so precious creativity and that is what you are being paid for, helping the team, the company, to move forward.

infinite8s 12y ago
Well then obviously your company should let him go. If not, then maybe he is as productive as you seem not to think.
barrkel 12y ago
he finishes his assigned tasks A team leader that uses people like this - cogs that munch through assigned tasks - is not operating at high efficiency. It's top-down directed, and is missing effective feedback from people who know most about the code, its architecture, what it can and can't do. People are treated as manual laborers rather than self-directed professionals. You're only using 40% - if that - of their capabilities. There are times when a team needs to operate like that - e.g. impending business-related deadlines - but they should be exceptional. The top-down model creates work politics, where the team members need to lobby and scheme to influence the team leader to make particular choices, and it leads to atrophy of initiative, and destroys most of the creativity that ought to be latent in a team. I'm extrapolating a lot from a single statement of yours, so it may not actually apply to your organization, but it definitely does apply to a lot of dysfunctional workplaces. the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that The person merging code should be the person reviewing the code, not the author of the code. If code breaks the build, the person reviewing it is at fault for merging it. And code isn't finished until it's reviewed and merged. Reviewing, at a minimum, means making sure it builds, the tests pass, and the tests have enough coverage, using code coverage tools if necessary. If the code is no good and accidentally got merged, the merge commit should be reverted. If the code is absolutely necessary (e.g. for Monday), that's a crunch, the guy shouldn't have left on Friday, and he's let the team down. You can't do that too often without needing to leave. But not for productivity reasons, for team reasons.

by Too 12y ago

infinite8s 12y ago

Well then obviously your company should let him go. If not, then maybe he is as productive as you seem not to think.

barrkel 12y ago

he finishes his assigned tasks A team leader that uses people like this - cogs that munch through assigned tasks - is not operating at high efficiency. It's top-down directed, and is missing effective feedback from people who know most about the code, its architecture, what it can and can't do. People are treated as manual laborers rather than self-directed professionals. You're only using 40% - if that - of their capabilities. There are times when a team needs to operate like that - e.g. impending business-related deadlines - but they should be exceptional. The top-down model creates work politics, where the team members need to lobby and scheme to influence the team leader to make particular choices, and it leads to atrophy of initiative, and destroys most of the creativity that ought to be latent in a team. I'm extrapolating a lot from a single statement of yours, so it may not actually apply to your organization, but it definitely does apply to a lot of dysfunctional workplaces. the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that The person merging code should be the person reviewing the code, not the author of the code. If code breaks the build, the person reviewing it is at fault for merging it. And code isn't finished until it's reviewed and merged. Reviewing, at a minimum, means making sure it builds, the tests pass, and the tests have enough coverage, using code coverage tools if necessary. If the code is no good and accidentally got merged, the merge commit should be reverted. If the code is absolutely necessary (e.g. for Monday), that's a crunch, the guy shouldn't have left on Friday, and he's let the team down. You can't do that too often without needing to leave. But not for productivity reasons, for team reasons.