3 ms·

Junior developers who make a mistake? Cut them some slack and teach them. Senior developers who make the same mistakes over and over and never learn? I've kind

Junior developers who make a mistake? Cut them some slack and teach them. Senior developers who make the same mistakes over and over and never learn? I've kindly pointed out the mistake and invited them to avoid it in future. After a few more failures, I sometimes talk to them sternly, but the sad thing is that they won't learn from either kindness or harshness. I'm not in a position to fire them. Does anyone have an idea better than "Just suck it up?"

DanBC 10y ago
Aren't you interested to find out why they're making those mistakes?
- justin_oaks 10y ago
  Of course. I guess I can give some examples. One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else". Another developer constantly forgets to terminate servers that he started in our cloud hosting provider. This costs the company money and thus should be avoided. When its noticed that they're still running, he gets asked to terminate them but he doesn't do it right away and forgets again. Someone else ends up doing it. He's been asked repeatedly to make sure to terminate the servers. Suggestions to help include setting a timer, writing a script that will check for unused servers, etc. Those suggestions aren't heeded or I guess he forgets to remember to set the timer. Another developer says in a meeting that he'll perform a task, but forgets before he gets out of the meeting. When he's asked to write it down, he does so, but never looks at the paper later. There are more cases, but it seems to boil down to people not learning. You need to learn how to structure your code, you need to learn how to manage your time, you need to learn how to remember to do something. But maybe I'm the slow learner and I'm missing something. Thus I'm open to suggestions. So far my strategy is to accept that these other developers behave this way, and setup ways to protect myself from their failures.
  - lotyrin 10y ago
    Teams are made of people, and people are made of animals stretched to purposes far beyond any resemblance to the environment they were designed for / by. Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign people tickets, tag machines with their desired longevity and kill machines past their designated life span (or a default minimum), hold code reviews for new highly conditional methods and include drawing out truth tables and checking the desired behavior for each row. Lots of teams either expect everyone to be be an ideal spherical engineer and stumble when that proves not to be, or expect nothing of anyone and are doomed to achieve that expectation. The middle path of expecting excellence but tolerating failure is a lot of work but has plentiful advantages. How much failure you have to tolerate and how complex the systems designed to provide that tolerance are depend on the makeup of your team and its size (the larger your team the closer to the mean you'll have to be, and with more individuals a wider variety of behaviors will be represented).
    - justin_oaks 10y ago
      Well put. I prefer enforcing things by technical means when possible and via policy and process at other times. Sadly I see a lot of policy and process that isn't enforced, thus it might as well not be there. Nevertheless, I'll just attempt to improve that which is within my sphere of influence. I suppose I'll just have to do my best to expect excellence and tolerate failure. I appreciate the insight.
Bahamut 10y ago
Talk to your manager. That is their job to make sure they are doing what they're supposed to in a more formal setting if informal coaching does not work.
- justin_oaks 10y ago
  Yes, I suppose this is the "correct" way. If my manager doesn't have a problem with my coworkers failures, then I'll just have to tolerate it too.

DanBC 10y ago

Aren't you interested to find out why they're making those mistakes?

justin_oaks 10y ago
Of course. I guess I can give some examples. One developer writes huge methods or functions with a tangled mass of if-else. The inevitable result is that an else case missed and the whole thing fails spectacularly in some situations. Discussions with the developer are basically "That's how I've always done it and I don't want to change. I'll just add that missing else". Another developer constantly forgets to terminate servers that he started in our cloud hosting provider. This costs the company money and thus should be avoided. When its noticed that they're still running, he gets asked to terminate them but he doesn't do it right away and forgets again. Someone else ends up doing it. He's been asked repeatedly to make sure to terminate the servers. Suggestions to help include setting a timer, writing a script that will check for unused servers, etc. Those suggestions aren't heeded or I guess he forgets to remember to set the timer. Another developer says in a meeting that he'll perform a task, but forgets before he gets out of the meeting. When he's asked to write it down, he does so, but never looks at the paper later. There are more cases, but it seems to boil down to people not learning. You need to learn how to structure your code, you need to learn how to manage your time, you need to learn how to remember to do something. But maybe I'm the slow learner and I'm missing something. Thus I'm open to suggestions. So far my strategy is to accept that these other developers behave this way, and setup ways to protect myself from their failures.
- lotyrin 10y ago
  Teams are made of people, and people are made of animals stretched to purposes far beyond any resemblance to the environment they were designed for / by. Animals will have ingrained habits, many of these will be maladaptive. People though can create systems and systems can adapt for those habits. Do some cost/benefit analysis to enacting policies within the system that is your software development lifecycle. Assign people tickets, tag machines with their desired longevity and kill machines past their designated life span (or a default minimum), hold code reviews for new highly conditional methods and include drawing out truth tables and checking the desired behavior for each row. Lots of teams either expect everyone to be be an ideal spherical engineer and stumble when that proves not to be, or expect nothing of anyone and are doomed to achieve that expectation. The middle path of expecting excellence but tolerating failure is a lot of work but has plentiful advantages. How much failure you have to tolerate and how complex the systems designed to provide that tolerance are depend on the makeup of your team and its size (the larger your team the closer to the mean you'll have to be, and with more individuals a wider variety of behaviors will be represented).
  - justin_oaks 10y ago
    Well put. I prefer enforcing things by technical means when possible and via policy and process at other times. Sadly I see a lot of policy and process that isn't enforced, thus it might as well not be there. Nevertheless, I'll just attempt to improve that which is within my sphere of influence. I suppose I'll just have to do my best to expect excellence and tolerate failure. I appreciate the insight.

Bahamut 10y ago

Talk to your manager. That is their job to make sure they are doing what they're supposed to in a more formal setting if informal coaching does not work.

justin_oaks 10y ago
Yes, I suppose this is the "correct" way. If my manager doesn't have a problem with my coworkers failures, then I'll just have to tolerate it too.