I have a coworker who's struggling with some of our newly adopted technologies. In the area of this technology I would regard him as "gets things done" but not "smart". He is really trying and really not getting it. He's extremely valuable in other areas of our technology stack so getting rid of him would not only be cruel but detrimental and yet this deficiency is really starting to hurt our overall productivity. After peer programming with him several times and seeing him continue to struggle, I can't help but wonder what an optimal solution is? Is letting him twist in the wind a good motivator? Am I coddling him or am I just beginning to scratch the surface of helping him get up to speed? What are some middle ground solutions others have implemented with this problem?
Have him do more of the things he/she is productive at. This might free someone else's time to take his/her slack. If they are valuable, don't hold their hand as much as leading.
I think you should help as much as possible without giving the solution to him. IMHO, the best way to learn is by doing it yourself, with guidance from others.
You should probably identify the specific problem areas and ask him to spend some time with them on his own. It sounds like it might be a situation where the person only cares to work with the technology during business hours, and therefor might be in a perpetual 'catching up' mode.
Our profession is one which requires moderate to significant outside research. Toying with various technologies outside of the workplace is something that everyone needs to do, and this is how to improve. Having a hobby type of passion for new technologies is the optimal path here.
Every developer has struggled at one point or another. Let him figure things out on his own, each time he figures something it's a personal reward. It will build his confidence as well.
Has he had a chance to use the newly adopted technologies in a ground-up, fresh-start situation, or has he been maintaining existing systems while someone else (who you'd call "smart") has adopted the new technology and built something non-trivial?
If he has had to try and comprehend the new stuff when a substantial bit has already been written, and hasn't seen it grow from the ground-up, you've put him at a disadvantage. Oftentimes the only way to "get it" with a new technology is to start with a blank page. This happens a lot--some whiz engineer generates a new codebase/framework/whatever, and only the original author gets the benefit of doing it from scratch, and understanding it inside out. In that case, give the guy new to the technology a chance to do a small project in said technology from scratch, and see if it improves the comprehension.
If he is good at some things it may just be that he takes a bit longer than average to pick things up. Have you asked him how he skilled himself in those other areas - he might need some classroom training or even something as simple as a budget to buy a few books and a chance to spend some work time leaning the ropes.
I'm not sure about the policy of your company, but where I work we have a 6 months trial period. If you can't show any interest or if you fail to grasp really basic stuff that "everybody else" did grasp during that time, you're out.
It might be cruel, but also fair to that person. Better than to let that person stay for years and have people complain about him/her. That's not productive for any part. The company is not hiring people for charity.
With that said. Perhaps there are other things this person can do and that he/she also is very good at. I suggest your bring this up in a nice way. Just have a nice chat and be frank. My opinion is that most people appreciate people being honest with them.
Don't wait too long until you make your choice :)
Cheers
I was going to put this into a comment, but I think it deserves to be an answer of its own.
I am with Rik Garner on this one. Actually, I am very surprised that people keep pointing out that he should do it on his own time. While that's great when it happens and should ALWAYS happen, in theory, the reality is much sadder. People have other things going on in their lives besides catching up with a newly introduced framework/technology/process, etc.
I strongly believe that it would be a company's responsibility to at least encourage the learning process by providing the necessary means (as Rik has suggested), such as books, classes, and workshops. If the company is of a size where that's not economically possible, a simple 1-hour meeting a week, where programmers are encouraged to share their gotchas as well as problem-areas, would go a long way.
If you see that the person is not putting in enough effort or is simply not interested - that's a completely different problem.
It seems to me that developers tend to have their "niche" areas or specialties that they grow into over time. Some people are better at injecting specific kinds of services, others are better at searching algorithms, and some may be better at front end coding. Most of this specializing really comes from how a developer thinks.
I've found that when developers flounder with new technologies it's because they can't seem to find ways to apply what they already know to these newer concepts. It may be helpful when explaining things to tie in examples and references to what the developer already knows or is strong in and then relate the newer technology to it. Sometimes random links to video walk throughs, tutorials and books help too, accompanied by a 'hey this is kind of cool or I thought this was useful'. At the very least, the person will understand that someone thinks that they aren't as good as they should be and will either get crackin' or get lost.
Peer code reviews have been pretty useful at our work place in getting people up to speed on areas of code, not to mention that people tend to commit less crappy code when they know someone is going to look at it.
A few questions come to mind here that some other answers point to but a summary may be nice:
- Does the struggling developer know how he learns? This is HUGE to my mind as while some can just follow directions and pick up something, others may need a totally different approach or format and this is worth seeing if he sees this or not.
- Has he gone through this before? If so, ask how that went for him, how long it took and how similar is the current situation. Sometimes one can look at the past and use that to make for a better future.
While one can suggest that he pick it up on his own time, there is something to be said for a team lead or manager calling this person on where they struggle and ask if he needs help, wants to continue struggling or move onto other things that aren't so difficult for him.
I'm currently in tech support, supporting a piece of middleware written in Java. Well, I'm pretty good at Java, and cut my teeth on C++, so development isn't a problem for me. But learning the ins and outs of the J2EE stack + Websphere, Weblogic, COBOL, JMS, how our middleware integrates with them, SOAP/WSDL and ESB was quite the hammer dropped on me. It took me about six months to feel really comfortable with supporting the product, and I am getting to the point where I can diagnose bugs without having to go to development. So I have skill, but not the experience. If my boss had given up in those first six months, he wouldn't have the relatively skilled guy he does today. If he had instead picked a more senior J2EE guy, that curve might have been alleviated, but maybe it would have been transferred to some other part of the stack. Maybe they'd have to learn clustering, Oracle and SQL Server and a myriad of other things I'm already damned good at.
You're best served with trying to understand why THIS particular thing is vexing him so. Maybe he needs to take this technology and go and creat skeleton projects, something he can fuck up to no end without impacting your project. I wrote a lot of webservices when I first started learning J2EE (since my product is aimed at the SOA market). Dealing with SOAP/WSDL issues is almost second nature to me now, when before it was a frustration.