7 ms·

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and n

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if that's not possible) let them go. Whenever I hear a story like "this person did bad work for six months so we had to delete all his code changes and let him go" I immediately know that something is very wrong with the management of the software project in question, as in a good team structure it's just not possible that a single person does "negative work" for several months, let alone a year without being noticed. Also, whether a developer will do good or bad work does not only depend on his/her ability, but also on the circumstances under which he/she works. Some people need more oversight and a tighter feedback loop to be productive, while others can work in a more independent way. In any case, with a good team process it is really hard for a single person to do negative work, and if it happens it's usually the fault of at least several people (due to lack of clear standards, missing feedback cycles or lack of ownership). So if you're a senior developer or team lead, don't put the blame on other programmers, but instead ask yourself how you can build a process that makes it really hard for individual programmers to do bad work.

guitarbill 10y ago
> 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
kagamine 10y ago
Yes, I was reading that blog and trying to hear the voice of the frustrated junior dev who is blamed for everybody else's poor communication, who is not being supported and who is used as a scapegoat for the company's wider problems (structure, feedback, planning). Someone who spends their days wondering where it went wrong, why no-one is willing to work with them and thinking about how fast can they get out of there. This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.
erkaes 10y ago
You are right but I also can understand his 'influential developer' negativity effect. In my place there's this one influential developer (the Team Lead) that can veto every decisions even though the others juniors/seniors under him already have consensus. He doesn't want the existing process to be altered. Now he's alone as everyone is leaving.
- hash-set 10y ago
  Had that happen, too. Had two tech leads over me who didn't want to learn anything new. One guy was in love with Apache Camel, the other, was just a J2EE guy from like the early 2000s. Frustrating.
jondubois 10y ago
I think calling a developer 'awful' is rarely accurate. If that developer has only ever made two contributions to the project, then obviously that developer isn't in the right mindset to make useful contributions. I find that when I switch to part-time on a project, my performance degrades. Producing good code requires that you understand the existing code REALLY well (and that implies that you have to spend a lot of time just reading it) - If you don't understand the existing code really well, then you cannot produce good work. One of the worst things I keep witnessing is managers rushing new employees into finishing tasks quickly - This is really bad because new employees don't understand enough about the code to be productive; when you rush them, you essentially force them to implement dirty hacks which will end up costing way more in the medium and long term. Most managers don't like to pay engineers to lean/understand stuff - They want to pay for code that works. Engineers should be treated more like managers and less like office cattle. I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.
- user5994461 10y ago
  > I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers. Same. Been there, seen that. Seen good managers, seen bad managers, seen place without managers. I don't understand why there are managers in this industry.
  - larrik 10y ago
    A good manager minimizes the amount of time a developer has to spend on stuff that isn't developing. In the right situations, a good manager can make a team of a few devs far more productive than if you added another dev in place of that manager. Bad managers, of course, can be disastrous, though.
    - user5994461 10y ago
      Most stuff isn't developing. Designing, planning, architecturing, reviewing, developing, testing, delivering, maintaining, presenting... That's all a developer's jobs. I don't think that they should be strictly limited to "that guy who's got a special job title" (architect, managers, lead, whatever).
phereford 10y ago
I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment. 1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed. 2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle? Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.
- jakub_g 10y ago
  Bonus points if the senior/lead in scenario 2 really, really likes coding, and adds technical debt, bugs and ugly code at a rate faster than the other members can catch up with.
kelvin0 10y ago
Yes, and this book epitomizes your point: https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/1250067057 https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/12... I recommend the read to anyone working within teams of people.
Clubber 10y ago
You would think someone would be aware enough to do a code review of a newly hired junior developer pushing production code for the first time.
hash-set 10y ago
Have you ever had to deal with a bad worker, though? In one company where I was a tech lead we had a guy who did nothing. When I assigned him work, he turned in garbage that someone else had to re-do (often me, working at home). He would go out to his car after lunch and get stoned and then come back in and fall asleep at his desk! On paper, the team had four developers, in reality, there was only three. It was a huge headache trying to explain to PMs and other managers why our team didn't really have the bandwidth it appeared to have. I therefore complained to our manager about this guy. The response was long in coming and when it finally arrived, we were to place the non-worker on an "improvement plan" which was mandated by HR. That means I had to work even harder now because I had to put together said plan and basically try to micro-manage this guy while also re-doing all his code. The improvement plan didn't work. His output was just as bad as always. This went on and on for months. Mercifully, the guy was finally let go after almost a year of dicking around. All of this somehow reflected badly on me, however! My manager didn't like that I "made waves" in the company by requiring this guy to do work. He also didn't like having to smooth over all the ruffled feathers among the other teams who couldn't understand why we were always behind schedule. Stupid, bad management is to blame, not me.
chrisabrams 10y ago
> ask yourself how you can build a process that makes it really hard for individual programmers to do bad work That is a very constructive way at looking at things; I think I'll try this out with my team :)

guitarbill 10y ago

> 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

kagamine 10y ago

Yes, I was reading that blog and trying to hear the voice of the frustrated junior dev who is blamed for everybody else's poor communication, who is not being supported and who is used as a scapegoat for the company's wider problems (structure, feedback, planning). Someone who spends their days wondering where it went wrong, why no-one is willing to work with them and thinking about how fast can they get out of there. This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.

erkaes 10y ago

You are right but I also can understand his 'influential developer' negativity effect. In my place there's this one influential developer (the Team Lead) that can veto every decisions even though the others juniors/seniors under him already have consensus. He doesn't want the existing process to be altered. Now he's alone as everyone is leaving.

hash-set 10y ago
Had that happen, too. Had two tech leads over me who didn't want to learn anything new. One guy was in love with Apache Camel, the other, was just a J2EE guy from like the early 2000s. Frustrating.

jondubois 10y ago

I think calling a developer 'awful' is rarely accurate. If that developer has only ever made two contributions to the project, then obviously that developer isn't in the right mindset to make useful contributions. I find that when I switch to part-time on a project, my performance degrades. Producing good code requires that you understand the existing code REALLY well (and that implies that you have to spend a lot of time just reading it) - If you don't understand the existing code really well, then you cannot produce good work. One of the worst things I keep witnessing is managers rushing new employees into finishing tasks quickly - This is really bad because new employees don't understand enough about the code to be productive; when you rush them, you essentially force them to implement dirty hacks which will end up costing way more in the medium and long term. Most managers don't like to pay engineers to lean/understand stuff - They want to pay for code that works. Engineers should be treated more like managers and less like office cattle. I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.

user5994461 10y ago
> I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers. Same. Been there, seen that. Seen good managers, seen bad managers, seen place without managers. I don't understand why there are managers in this industry.
- larrik 10y ago
  A good manager minimizes the amount of time a developer has to spend on stuff that isn't developing. In the right situations, a good manager can make a team of a few devs far more productive than if you added another dev in place of that manager. Bad managers, of course, can be disastrous, though.
  - user5994461 10y ago
    Most stuff isn't developing. Designing, planning, architecturing, reviewing, developing, testing, delivering, maintaining, presenting... That's all a developer's jobs. I don't think that they should be strictly limited to "that guy who's got a special job title" (architect, managers, lead, whatever).

phereford 10y ago

I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment. 1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed. 2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle? Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.

jakub_g 10y ago
Bonus points if the senior/lead in scenario 2 really, really likes coding, and adds technical debt, bugs and ugly code at a rate faster than the other members can catch up with.

kelvin0 10y ago

Yes, and this book epitomizes your point: https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/1250067057 https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/12... I recommend the read to anyone working within teams of people.

Clubber 10y ago

You would think someone would be aware enough to do a code review of a newly hired junior developer pushing production code for the first time.

hash-set 10y ago

Have you ever had to deal with a bad worker, though? In one company where I was a tech lead we had a guy who did nothing. When I assigned him work, he turned in garbage that someone else had to re-do (often me, working at home). He would go out to his car after lunch and get stoned and then come back in and fall asleep at his desk! On paper, the team had four developers, in reality, there was only three. It was a huge headache trying to explain to PMs and other managers why our team didn't really have the bandwidth it appeared to have. I therefore complained to our manager about this guy. The response was long in coming and when it finally arrived, we were to place the non-worker on an "improvement plan" which was mandated by HR. That means I had to work even harder now because I had to put together said plan and basically try to micro-manage this guy while also re-doing all his code. The improvement plan didn't work. His output was just as bad as always. This went on and on for months. Mercifully, the guy was finally let go after almost a year of dicking around. All of this somehow reflected badly on me, however! My manager didn't like that I "made waves" in the company by requiring this guy to do work. He also didn't like having to smooth over all the ruffled feathers among the other teams who couldn't understand why we were always behind schedule. Stupid, bad management is to blame, not me.

chrisabrams 10y ago

> ask yourself how you can build a process that makes it really hard for individual programmers to do bad work That is a very constructive way at looking at things; I think I'll try this out with my team :)