4 ms·

A rule in life: ruthlessly stomp on the maladaptive tendency of our brains to try to expand the scope of our responsibilities beyond the scope of our power. If

A rule in life: ruthlessly stomp on the maladaptive tendency of our brains to try to expand the scope of our responsibilities beyond the scope of our power. If you were the boss of this company, it would be your job to do something about an incompetent programmer. But you're not. You're a freelance programmer. It's your job to write code. You've raised the issue with the boss. He has decided to keep things the way they are, as is his right, even if he's mistaken; he's the one signing the paychecks. That's all that was up to you to do about it. Having done that, your job is to write your code and let the other guy write his code.

tra3 11y ago
That's shortsighted. Eventually this bad code will be the responsibility of the freelancer (who at 3 years in is more permanent than most of the other devs it seems). Another reason to take care of this now and be a "team player": making the company more successful ensures a renewed contract.
- moron4hire 11y ago
  That's been my big hold-up. I've always believed "I succeed when my client succeeds". It's hard to think of leaving. Leaving--when I know they don't have anyone to replace me and their hiring process won't likely winnow out a suitable replacement--feels like abandoning them.
  - philjr 11y ago
    Have you communicated to the boss in a rational way that this is such a big deal to you it would cause you to leave? Or have you just told them the other guy isn't good. This is how I typically approach these types of problems.... Ask yourself if you're ready to see this through and by that I mean every possible outcome including leaving or getting fired or potentially getting the other guy fired. That means assessing your financial situation, possibility of getting more work etc. to me the logic goes that if this is such an important thing then I should be willing to accept all outcomes as this is the Right Thing To Do. It might seem a little melodramatic but it forces you to ask yourself hard questions. Then, approach the boss. Tell him that you heard what he said before but the quality of your colleagues work is such that you can't stand over it and it's affecting everyone working on the project. If you end up having double standards for the code it brings everything down to the lowest common denominator. My next option would be to bring a _solution_ to the table as opposed to just a problem. Let's bring in code reviews and I'll work with MrProblemCoder directly on his reviews one on one for a few months to try and bring his standard up. However, you need management backup for this. Maybe you don't even want to single him out, maybe you sit down collectively once or twice a week to do group reviews and breakouts afterwards. Maybe Friday afternoons are review the review days. The big thing here is that you want to make clear to the boss that there is a Significant Problem in a clear, rational way and have him understand the impact of it. Try leave your emotion at the door. Then present a solution which involves the group taking collective responsibility for the code quality with you leading the charge, but that management must back up and present. If the outcome of that conversation isn't positive, then you have a management who doesn't care about quality and more importantly doesn't trust what you're saying about the impact. That would make it much easier for me to walk away as I now understand they've chosen the next path for themselves. If you're not ok with that path then you could still try "influencing" these types of initiatives over a longer period of time instead of entering in to brinksmanship. Institutionalise code reviews for a portion of the team and show less bugs/rework and show the cost of crappy code. It's a softer approach and may take months and months of collecting data and influencing your colleagues. These situations are not easy unless you're actually in a position to institute change directly!
- rwallace 11y ago
  You're missing the point. He has no authority to take care of this now. Continuing to nag the boss after he's already been told 'no' in no uncertain terms not only won't make the company more successful, it will make him unhappy, get him a reputation as a troublemaker and not a team player, and possibly end up getting him fired.

tra3 11y ago

That's shortsighted. Eventually this bad code will be the responsibility of the freelancer (who at 3 years in is more permanent than most of the other devs it seems). Another reason to take care of this now and be a "team player": making the company more successful ensures a renewed contract.

moron4hire 11y ago
That's been my big hold-up. I've always believed "I succeed when my client succeeds". It's hard to think of leaving. Leaving--when I know they don't have anyone to replace me and their hiring process won't likely winnow out a suitable replacement--feels like abandoning them.
- philjr 11y ago
  Have you communicated to the boss in a rational way that this is such a big deal to you it would cause you to leave? Or have you just told them the other guy isn't good. This is how I typically approach these types of problems.... Ask yourself if you're ready to see this through and by that I mean every possible outcome including leaving or getting fired or potentially getting the other guy fired. That means assessing your financial situation, possibility of getting more work etc. to me the logic goes that if this is such an important thing then I should be willing to accept all outcomes as this is the Right Thing To Do. It might seem a little melodramatic but it forces you to ask yourself hard questions. Then, approach the boss. Tell him that you heard what he said before but the quality of your colleagues work is such that you can't stand over it and it's affecting everyone working on the project. If you end up having double standards for the code it brings everything down to the lowest common denominator. My next option would be to bring a _solution_ to the table as opposed to just a problem. Let's bring in code reviews and I'll work with MrProblemCoder directly on his reviews one on one for a few months to try and bring his standard up. However, you need management backup for this. Maybe you don't even want to single him out, maybe you sit down collectively once or twice a week to do group reviews and breakouts afterwards. Maybe Friday afternoons are review the review days. The big thing here is that you want to make clear to the boss that there is a Significant Problem in a clear, rational way and have him understand the impact of it. Try leave your emotion at the door. Then present a solution which involves the group taking collective responsibility for the code quality with you leading the charge, but that management must back up and present. If the outcome of that conversation isn't positive, then you have a management who doesn't care about quality and more importantly doesn't trust what you're saying about the impact. That would make it much easier for me to walk away as I now understand they've chosen the next path for themselves. If you're not ok with that path then you could still try "influencing" these types of initiatives over a longer period of time instead of entering in to brinksmanship. Institutionalise code reviews for a portion of the team and show less bugs/rework and show the cost of crappy code. It's a softer approach and may take months and months of collecting data and influencing your colleagues. These situations are not easy unless you're actually in a position to institute change directly!
rwallace 11y ago
You're missing the point. He has no authority to take care of this now. Continuing to nag the boss after he's already been told 'no' in no uncertain terms not only won't make the company more successful, it will make him unhappy, get him a reputation as a troublemaker and not a team player, and possibly end up getting him fired.