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?
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.
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.
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.
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.
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.
> 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.
I was going to go back and add "does he need any training" to my original comment then life got in the way and I promptly forgot!
Absolutely do run training; could for example set up a Pluralsight account, run through modules on GIT and any other stacks that are needed. If someone doesn't want to use version control in this day and age then I'd have to agree that'd be my number one priority to get fixed.
Understanding feature branches would be a very powerful change. Not sure exactly how applicable this is to your situation but on a general level I'd recommend making them as atomic / small as possible as a way of starting. I.e. by reducing the scope of an issue down to the MVP, then it becomes easier to just get that done - add additional features/requirements as following issues. And then get on to pull requests ASAP so that you can preferably sit together and review / discuss the changes. This would reduce the feedback cycle down to maybe a couple of days, which would greatly help the pace as well. Good luck.
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.
