4 ms·

Have you tried communicating these concerns to him? Break down the expectations, e.g. that everything must be committed in the repo, with covering tests etc? I

Have you tried communicating these concerns to him? Break down the expectations, e.g. that everything must be committed in the repo, with covering tests etc? If he takes it on board, win! If he ignores it and takes offense, well at least you tried?

teekert 8y ago
I tried setting dead lines "Ok, lets make sure this is finished next week". But there is always an excuse, but it boils down to him being a poor programmer, he gets stuck and then he works on the other project he is employed in. The poorness is understandable in our circumstance and sort of ok (we were driven into this kind of work and I happen to love it, he happens to have no talent for it what so ever). I did offer other work (back to the lab in stead of doing the bioinformatics) but he does somehow seem to enjoy it. I know, time to be hard and honest indeed.
- jrockway 8y ago
  Arbitrary deadlines rarely work. Psychologically they just encourage "student syndrome" where people feel like they can slack off until the deadline actually seems threatening. Then the deadline is missed. That is the nature of human psychology, not your particular employee. Avery talks it about a bit here (read the section where "student syndrome" starts showing up): https://apenwarr.ca/log/?m=201712#13 https://apenwarr.ca/log/?m=201712#13 Ultimately, your job as a manager is to keep your team unstuck. People get fired all the time because their manager is bad at management, as it's certainly a supervisor's privilege to fire people they don't like. But always remember that your assessment "this guy is lazy and doesn't like the field" could be completely wrong and you're just bad at management.
  - teekert 8y ago
    Thanks, this could certainly be it, the next conversation will be along the lines of "what do you need to finish things faster?" Don't misunderstand, this guy has sometimes been working on something for weeks, and then I decide to take it from him to do it from the ground up in 2 days. He seems to be allergic to git and complains about errors of others that don't even affect him. Still he seems unaware so a respectful inquiry seems best indeed.
    - watwut 8y ago
      Always be respectful. But, the complains about errors of others that don't even affect him might be just strategy to cover up (maybe even from himself) his own under-performance and insecurity. Good luck. He sounds like some people I worked with in the past, not as a boss but as a colleague, and it was no pleasure. Down to being sociable and nice at beer. Btw, the complaining about other people errors from someone like that whose own larger errors are seemingly never addressed can overtime turn the team culture pretty toxic.
    - jrockway 8y ago
      I don't think it's possible to have an actual allergy to git, so some training in that area would probably help their productivity. Make sure he knows how to use git, and that he knows your organization's policy in regards to commits. You can set a policy like "just commit everything at the end of the day" and provide a shell script to do that. Don't make git the wedge that isolates you from your employee; make it a productivity tool. > take it from him to do it from the ground up in 2 days People that you employ to work for you will ALWAYS do things differently and probably more slowly than you. I have never had someone working for me, asked them to do X, and then gotten a changelist to review that was exactly what I would have done myself. Your employee is not a clone of you, he's an independently-thinking person with different assumptions and experience. (Certainly, if something is WRONG, don't accept it, but it's different... that's the reality of having more that one person working on a project.) Also... there is no really good way to estimate how productive someone is, including yourself. You could be way above average and nobody that works for you will ever be as fast as you. You also have to expect that someone with less experience than you is going to be slower. For you, 2 days is applying the sum of your domain expertise and X years of a software engineering career to a cookie-cutter problem. For someone that works for you, that could be a month of acquiring career skills necessary to solve problems in the future and some subset of your problem domain experience, and then 2 days of applying those skills. You do enough of those "my boss could do this in 2 days" projects over many months, and then you're the guy that does it in 2 days. That's what experience is. > complains about errors of others that don't even affect him Probably worth having a discussion about. I will point out that you're kind of doing this here and in a public forum, hoping that your employee never finds out.

teekert 8y ago

I tried setting dead lines "Ok, lets make sure this is finished next week". But there is always an excuse, but it boils down to him being a poor programmer, he gets stuck and then he works on the other project he is employed in. The poorness is understandable in our circumstance and sort of ok (we were driven into this kind of work and I happen to love it, he happens to have no talent for it what so ever). I did offer other work (back to the lab in stead of doing the bioinformatics) but he does somehow seem to enjoy it. I know, time to be hard and honest indeed.

jrockway 8y ago
Arbitrary deadlines rarely work. Psychologically they just encourage "student syndrome" where people feel like they can slack off until the deadline actually seems threatening. Then the deadline is missed. That is the nature of human psychology, not your particular employee. Avery talks it about a bit here (read the section where "student syndrome" starts showing up): https://apenwarr.ca/log/?m=201712#13 https://apenwarr.ca/log/?m=201712#13 Ultimately, your job as a manager is to keep your team unstuck. People get fired all the time because their manager is bad at management, as it's certainly a supervisor's privilege to fire people they don't like. But always remember that your assessment "this guy is lazy and doesn't like the field" could be completely wrong and you're just bad at management.
- teekert 8y ago
  Thanks, this could certainly be it, the next conversation will be along the lines of "what do you need to finish things faster?" Don't misunderstand, this guy has sometimes been working on something for weeks, and then I decide to take it from him to do it from the ground up in 2 days. He seems to be allergic to git and complains about errors of others that don't even affect him. Still he seems unaware so a respectful inquiry seems best indeed.
  - watwut 8y ago
    Always be respectful. But, the complains about errors of others that don't even affect him might be just strategy to cover up (maybe even from himself) his own under-performance and insecurity. Good luck. He sounds like some people I worked with in the past, not as a boss but as a colleague, and it was no pleasure. Down to being sociable and nice at beer. Btw, the complaining about other people errors from someone like that whose own larger errors are seemingly never addressed can overtime turn the team culture pretty toxic.
  - jrockway 8y ago
    I don't think it's possible to have an actual allergy to git, so some training in that area would probably help their productivity. Make sure he knows how to use git, and that he knows your organization's policy in regards to commits. You can set a policy like "just commit everything at the end of the day" and provide a shell script to do that. Don't make git the wedge that isolates you from your employee; make it a productivity tool. > take it from him to do it from the ground up in 2 days People that you employ to work for you will ALWAYS do things differently and probably more slowly than you. I have never had someone working for me, asked them to do X, and then gotten a changelist to review that was exactly what I would have done myself. Your employee is not a clone of you, he's an independently-thinking person with different assumptions and experience. (Certainly, if something is WRONG, don't accept it, but it's different... that's the reality of having more that one person working on a project.) Also... there is no really good way to estimate how productive someone is, including yourself. You could be way above average and nobody that works for you will ever be as fast as you. You also have to expect that someone with less experience than you is going to be slower. For you, 2 days is applying the sum of your domain expertise and X years of a software engineering career to a cookie-cutter problem. For someone that works for you, that could be a month of acquiring career skills necessary to solve problems in the future and some subset of your problem domain experience, and then 2 days of applying those skills. You do enough of those "my boss could do this in 2 days" projects over many months, and then you're the guy that does it in 2 days. That's what experience is. > complains about errors of others that don't even affect him Probably worth having a discussion about. I will point out that you're kind of doing this here and in a public forum, hoping that your employee never finds out.