3 ms·

> let them go Erm, that isn't how corporations work. First, team lead doesn't mean manager, and even then in some companies, first and second line have very li

> let them go Erm, that isn't how corporations work. First, team lead doesn't mean manager, and even then in some companies, first and second line have very little to say. HR needs to be involved, etc. Which creates more work. There are the people who simply don't care. Contractors on a gravy train or outsourced people. I've been there, there is nothing you can do in this case. I think it's fair to say from your resume/LinkedIn that you have been shielded from such effects for most of your career. Consider that a blessing, but don't assume you always have so much control over your environment. A lot of us are more like mercenaries, making good money out of bad situations while we can.

ThePhysicist 10y ago
That's a valid point of course, thanks for pointing this out! I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case. But even if you're not in a position to do hiring/firing decisions there is still a lot you can do to make it harder for other people to do bad work. One of the easiest things is to agree on a standard for your codebase with the other developers, and create a process through which you monitor this standard (e.g. through code reviews). If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.
- guitarbill 10y ago
  I agree. Funny story with the code review, we had that. But several devs kept submitting broken/bad code, so they could tell their manager "oh, I'm waiting on a code review". The loss of productivity due to other devs trying to do constructive code reviews was staggering. One guy was asked to leave a project after he submitted 17 updates to the same commit, and all of them failed basic (and luckily automated) linting. Another contractor titled all his commit messages a single word: "update". I've even worked on a project where the build system was "maintained" by contractors - talk about a conflict of interest. You can imagine how transparent it was.
  - Normal_gaussian 10y ago
    In the bad/broken code it again sounds like poor management - instituting the 'bums in seat' checklist of was present for a code review, versus the qualitative check of 'had done work that was worth reviewing'.
    - guitarbill 10y ago
      Sure, but any metric or process put in place is vulnerable to be gamed. In some way, I respect individuals who do this. Just don't bother my team. But managers aren't intrinsically bad people, they just have different motivations. And they have their own problems caused by politics. Ideally devs would have tools to combat this problem directly. But life isn't always fair.
  - ptero 10y ago
    Of course there are developers who bring problems to projects. However, many of the problems are organizational: I have seen some projects place sizeable incentives on any bug fixes (e.g., highly value number of such submissions / week), which encourages people to do quick fixes for simple things, not important ones and does not penalize for poor performing software and convoluted code. If one finds itself in this environment, IMO it is best to run away. I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it.
    - guitarbill 10y ago
      > I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it. It's a good question. I think it's often a hard sell, that the change, while more work in the short run is less effort in the long run. Why should I care? I'm still getting paid the same. Of course, that's a facile argument and easy to refute: professional development. In my experience organisational behaviour has a root cause. You have to find that and understand it to change it, you can't just change the organisational behaviour but leave the root cause. To an outsider, the root cause probably isn't obvious. Heck, sometimes by the time you understand it yourself, you've been there so long you might as well move on. But often, it's also the devs who refuse to get political. Who understands the system better, and why should somebody else fix it? But then the obvious excuses happen. "Too busy", "Not my problem", "Nothing I can do". Devs start leaving the project or the company. Now, it's never going to get changed. Apathy is the worst symptom.
- cookiecaper 10y ago
  >I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case. I would say this is quite rarely the case. It's amazing how many companies are able to slog through with completely braindead personnel practices. It seems most places are either far too reluctant or far too quick to terminate employees. I know of a company that refused to fire someone who not only destroyed a production database but, on a separate occasion, accidentally facilitated an ongoing leak of the source code of all web applications (which was only discovered when it was revealed to the CEO by a script kiddie with a guilty conscience). Because this guy is well-connected, he lives to imperil the company another day (usually in slightly less dramatic ways). I also know of a company that fires otherwise good programmers for not being at their desks by 9:05 a few times per year. Those people are terrible. It seems that a company that is actually reasonable about its personnel practices is very rare indeed. >If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix. You're right that often you can't fire someone for legal or political reasons, which is unfortunately all too common. However, I must oppose your proposal to just leave the org. As discussed above, there are not many sanely-run companies out there. In my career, I used to take the "just leave" advice, but I've found this really stunts your ability to grow, personally and professionally, along multiple axes. Unreasonable people are, unfortunately, a fact of life. I used to think a smart company could mostly avoid having them in the ranks. I still believe a smart one could more or less do this, and that damage from the stragglers can be mitigated, but I now just believe smart companies are unicorns and you should never expect to be working at one. This is a safe/important assumption because "smart companies" can turn dumb real quick, especially when/as visionary leadership is replaced by conventional business school cogs. One must become a politician, which will enable one to flourish in the chaos, especially if passable political craft is combined with actual technical skill and good judgment. If you're stuck with bad talent that can't be fired, you should redirect them into a side channel where the amount of damage they do is mitigated. There's actually a lot of bad employees who are perfectly OK with this. Most of them are primarily interested in security, since they know it's difficult to find new employers with their limited skillsets. Giving them their own little irrelevant kingdom will help with that and also keep the high-level bosses happy because they don't have to fire their cousin and make Thanksgiving awkward for the rest of eternity, or deal with a lawsuit from an employee who has already threatened to take the company to the cleaners.
user5994461 10y ago
> I've been there, there is nothing you can do in this case. You can leave. You can become the contractor that doesn't care but racks in €1000 a day. There are always options.
- guitarbill 10y ago
  These are all long term solutions, and good ones. But life isn't always that simple. Why let one bad dev ruin it for everybody else? It's a bit like one person being rude. Would you leave for that? I meant it more in a "accept it and move on" way. To be honest, if you're in a similar situation at MegaCorp Inc, you already have to put up with many things out of your control. But should we as professionals an answer to this problem? Or is it a management problem? (Although that's a cop-out, because that's still part of our profession). Is it human nature? Do other professions suffer from similar situations? These are interesting questions, to which I have no answer yet.

ThePhysicist 10y ago

That's a valid point of course, thanks for pointing this out! I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case. But even if you're not in a position to do hiring/firing decisions there is still a lot you can do to make it harder for other people to do bad work. One of the easiest things is to agree on a standard for your codebase with the other developers, and create a process through which you monitor this standard (e.g. through code reviews). If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.

guitarbill 10y ago
I agree. Funny story with the code review, we had that. But several devs kept submitting broken/bad code, so they could tell their manager "oh, I'm waiting on a code review". The loss of productivity due to other devs trying to do constructive code reviews was staggering. One guy was asked to leave a project after he submitted 17 updates to the same commit, and all of them failed basic (and luckily automated) linting. Another contractor titled all his commit messages a single word: "update". I've even worked on a project where the build system was "maintained" by contractors - talk about a conflict of interest. You can imagine how transparent it was.
- Normal_gaussian 10y ago
  In the bad/broken code it again sounds like poor management - instituting the 'bums in seat' checklist of was present for a code review, versus the qualitative check of 'had done work that was worth reviewing'.
  - guitarbill 10y ago
    Sure, but any metric or process put in place is vulnerable to be gamed. In some way, I respect individuals who do this. Just don't bother my team. But managers aren't intrinsically bad people, they just have different motivations. And they have their own problems caused by politics. Ideally devs would have tools to combat this problem directly. But life isn't always fair.
- ptero 10y ago
  Of course there are developers who bring problems to projects. However, many of the problems are organizational: I have seen some projects place sizeable incentives on any bug fixes (e.g., highly value number of such submissions / week), which encourages people to do quick fixes for simple things, not important ones and does not penalize for poor performing software and convoluted code. If one finds itself in this environment, IMO it is best to run away. I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it.
  - guitarbill 10y ago
    > I wonder why such organizational behavior is very difficult to change -- I have seen, twice, smart people brought in to clean up a project stuck in this state. They were given freedom to run it the way they saw fit (upper management knew the project is failing) and both times they failed to change it. It's a good question. I think it's often a hard sell, that the change, while more work in the short run is less effort in the long run. Why should I care? I'm still getting paid the same. Of course, that's a facile argument and easy to refute: professional development. In my experience organisational behaviour has a root cause. You have to find that and understand it to change it, you can't just change the organisational behaviour but leave the root cause. To an outsider, the root cause probably isn't obvious. Heck, sometimes by the time you understand it yourself, you've been there so long you might as well move on. But often, it's also the devs who refuse to get political. Who understands the system better, and why should somebody else fix it? But then the obvious excuses happen. "Too busy", "Not my problem", "Nothing I can do". Devs start leaving the project or the company. Now, it's never going to get changed. Apathy is the worst symptom.
cookiecaper 10y ago
>I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case. I would say this is quite rarely the case. It's amazing how many companies are able to slog through with completely braindead personnel practices. It seems most places are either far too reluctant or far too quick to terminate employees. I know of a company that refused to fire someone who not only destroyed a production database but, on a separate occasion, accidentally facilitated an ongoing leak of the source code of all web applications (which was only discovered when it was revealed to the CEO by a script kiddie with a guilty conscience). Because this guy is well-connected, he lives to imperil the company another day (usually in slightly less dramatic ways). I also know of a company that fires otherwise good programmers for not being at their desks by 9:05 a few times per year. Those people are terrible. It seems that a company that is actually reasonable about its personnel practices is very rare indeed. >If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix. You're right that often you can't fire someone for legal or political reasons, which is unfortunately all too common. However, I must oppose your proposal to just leave the org. As discussed above, there are not many sanely-run companies out there. In my career, I used to take the "just leave" advice, but I've found this really stunts your ability to grow, personally and professionally, along multiple axes. Unreasonable people are, unfortunately, a fact of life. I used to think a smart company could mostly avoid having them in the ranks. I still believe a smart one could more or less do this, and that damage from the stragglers can be mitigated, but I now just believe smart companies are unicorns and you should never expect to be working at one. This is a safe/important assumption because "smart companies" can turn dumb real quick, especially when/as visionary leadership is replaced by conventional business school cogs. One must become a politician, which will enable one to flourish in the chaos, especially if passable political craft is combined with actual technical skill and good judgment. If you're stuck with bad talent that can't be fired, you should redirect them into a side channel where the amount of damage they do is mitigated. There's actually a lot of bad employees who are perfectly OK with this. Most of them are primarily interested in security, since they know it's difficult to find new employers with their limited skillsets. Giving them their own little irrelevant kingdom will help with that and also keep the high-level bosses happy because they don't have to fire their cousin and make Thanksgiving awkward for the rest of eternity, or deal with a lawsuit from an employee who has already threatened to take the company to the cleaners.

user5994461 10y ago

> I've been there, there is nothing you can do in this case. You can leave. You can become the contractor that doesn't care but racks in €1000 a day. There are always options.

guitarbill 10y ago
These are all long term solutions, and good ones. But life isn't always that simple. Why let one bad dev ruin it for everybody else? It's a bit like one person being rude. Would you leave for that? I meant it more in a "accept it and move on" way. To be honest, if you're in a similar situation at MegaCorp Inc, you already have to put up with many things out of your control. But should we as professionals an answer to this problem? Or is it a management problem? (Although that's a cop-out, because that's still part of our profession). Is it human nature? Do other professions suffer from similar situations? These are interesting questions, to which I have no answer yet.