When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job

This is one of the toughest situations for an employee to be in. He is forced to maintain the old system, but he does not get to architect the new one. It is claimed that he is slow at the new one. Well, how many of the people working on that are "slow" at the old one?

He probably thinks that he is being pushed aside. If he's smart, he will quit now and let you scramble to find a way to maintain the obsolescent system. If you're smart, you will start cross-breeding. Force the people who are so happy working on the new thing to start supporting the old one, and give Frank some real authority over some decisions on the new one.

Management problems usually come down to an imbalance between authority and responsibility. If someone has more R than A, then she is forced to try to steal it or sink, like Dee Dee Myers early in the Clinton administration. (Read her book.) If someone has more A than R, everybody becomes less efficient for one reason or another. When A and R balance, things get fixed fast. "Responsibility" means consequences. Make sure that people understand what they are responsible for, and what the consequences are. At that point, people will usually say either that they need more Authority, or that they cannot deliver what they are responsible for. Then, you negotiate.

To me, this is all a matter of respect. If you have to let Frank go, at least he will understand why and know that he was given a fair chance.

If a programmer can't adapt to new languages or platforms, then they obviously were never much of a programmer.

Some people are by nature more suited to doing maintenance work and we ought to be more thankful that these people exist. I had a friend who was getting some help through freelancer sites, and none of them were interested in maintenance work. All software projects involve ongoing development and maintenance. Being willing to work on old crufty badly commented code should be praised, not criticized.

He seems to be a bright fellow. The industry changes over time, and he'll start looking more and more obsolete as the months draw on. Certainly he'll be able to land on his feet somewhere else; it just won't be with you guys.

You are in the business of getting work done well and getting work done fast -- and, since the definition of 'work' changed, he's not doing his getting any work done. He's a fish out of water, so you have to send him someplace he can swim.

If he stays around, he'll only stink up the place.

One of the keys to software development is continually learning and wanting to learn.

Programming is a concept more than a language. Good programmers can code in any language, the rest is syntax. Communication and documenting is a huge bonus but if he had those project management might be possible.

Given my background is mostly in C#/C++ during my job i have learned and used .net, php, javascript, msbuild, nant, sql, and all newer versions of sql.

With google, a book, and a senior dev to bounce unobvious questions off of you should be able to learn anything. Sounds like he had those things.

If you do not keep up your skills you will become outdated in any job, it just happens that the technology world moves faster than the rest.

Good programmers love learning, and if he was given training and good faith time then he wont be a good fit. Its 100% obvious that replacing him will be good for the company even though it hurts you to let someone go who you like.

( just keep in mind you may be paying more for talent ).

Also note: I have seen this case several times and almost always you don't know how bad someone is until someone else comes along and replaces them.

Frank is stuck in one of those mid-career ruts. His primary skill, which once he was praised for and properly appreciated, is withering away as new technologies rise, and management has it in for him because they think he's outmoded. All he did was keep his head down and do the job he thought he was supposed to be doing... and all the sudden management is getting all bent out of shape about something, and Frank doesn't quite understand.

But, Frank's biggest problem isn't his lack of skill. The barrier to learning a new language is very low. So low that you should be immediately suspect why a talented engineer can't make the jump. The thing is, Frank ran completely off track somewhere in his career, and he feels it, but he doesn't understand why it feels that way. After all, he's still doing development work, right? Right? (hint: Wrong!)

I can tell you why; it's because he maintains code... other people's code. I am convinced that no intelligent creative type can stay sane just modifying existing works. They need to create new things. Get consultants to maintain your code for you, but let your own engineers create new things.

In addition to the core problem of never getting to make anything new (making things people want, creating value), Frank senses that management isn't being completely honest with him. They treat him as a pariah within the team instead of the very valuable asset he is. Frank is a senior (6 years) team member and they should be throwing VERY tough assignments his way to help him feel like he can contribute something, but they are instead leaving him with maintaining other people's code. At 6 years, most developers can fill the role of Architect if given half a chance. Come on, none of this is THAT hard. It's been years since Frank got a shot at making something from scratch. He would be rusty, but it would soon come to him.

Management, instead of looking for ways to inspire Frank, would rather write blog posts detailing a forced career death-spiral. Geez people, don't you know anything about dealing with your peers? Here's hoping you enter your own rut and experience all of this first hand.

I have seen this exact same story several times in my life. For what may be good (but are more often bad) reasons, management has decided to rewrite a system in a new platform.

You have a very skilled engineer on the old platform, and you assume that because he's a good programmer he can suddenly jump into the new system and he'll be just as productive as your team members who seem to love architecting.

So basically, you failed to correctly determine an upgrade path for Frank, probably assuming that "programmers can do anything." This is almost complete nonsense. After years of maintenance work, which Frank was apparently doing well without complaining, you're expecting him to do new development with team members who probably speak near jibberish to his ear (I'm assuming you're in Java, and non-Java developers listening to "skilled" Java engineers is a very frustrating experience because Java kids are constantly obsessed with idiotic fads -- I wouldn't be surprised if Frank's personal evaluation of your teams programming ability is much lower than your current evaluation of his).

To use a newspaper analogy, you've effectively put a copy editor on the editorial board of a magazine and you can't figure out why he's sinking. He's sinking because he doesn't have the first idea how to be an editor, and he's only pretending he does to please you (and not get fired). If you want a copy editor, get him back in a proper job. If you want to have no copy editor and have to waste tons of money training a new one, fire him for not filling his new role.

What you should have done when you started this upgrade path is figure out how Frank will transition from maintenance of the old system to maintenance of the new system. This means your hot-shot engineers should be writing documentation at a level that Frank can maintain their code now (because, lets be honest, you're going to lose them the moment new development is done anyway). If Frank can't figure out their code, well, the problem is not with Frank.

I agree with the person who posted that programming is about concepts, not the language. While different languages and frameworks offer different things, it shouldn't be THAT difficult for a good programmer to pick up a new language and/or framework.

Frank has been working with the existing codebase for what, 6 years? What's 6 months compared to that? Maybe he didn't learn the existing codebase in 6 months, either.

Not everyone makes a good programmer, but a team needs testers, maintenance folks, and debuggers as well if they have large applications. Does his need him for any of that work? He can learn at a slower pace, perhaps in a way that is more natural and comfortable for him. He may not get a lead architect position, but he will be valued and have a job.

Can he work on smaller, already written chunks, either through testing or debugging? Some people learn far faster with actual real-world examples.

I hesitate to form a concrete opinion on what I'd do with him, because I haven't talked to him or worked with him to see how he learns, how he communicates, and what his REAL strengths are. I doubt my first option would be to ditch him, though.

I ended up leaving my company after 7 years (and in this bad economy, too). I had a similar type of bind, but flipped around. I was one of the original developers of our legacy systems, which was done in COM. In the 7 years, we transitioned into .NET. Within the last year, I was actively involved in moving to the next generation of our system, using some hybrid SOA. Unlike Frank, I have adjusted well to transitions into new technology.

However, the old technology never dies. New hires were .NET only. As time passed, I ended up being one of the last people knowing the in-and-outs of the older technologies used. In fact, by the time I finally left, I found out that I was the only one who has actually created a COM object from scratch. But, the production site has major active code paths that still used COM. So, I ended up being the "COM" guy, even though I was also the "Services" guy, too.

As problems surfaced, the maintenance portion of my work became overcome my newer, fun work, which ends up limiting my productivity. I became overly frustrated and people started to notice. I had many discussions with management with the problem, but nothing was done. I was obviously not happy with the situation, and with no help from management, I decided to leave. For me, it was the best thing I could have done.

What I learned: there is a reason why a legacy system exists. It is the system that is making money. Because the team flocks to a newer tech, the existing system MUST be maintained. It is everyone's responsibility to maintain. Management redefined Frank's job from his primary expertise, so they assumed that he would be OK with that 100%. Not all programmers fit the same mold, eh? On top of that, once other members start to typecast you as something you may not appreciate ("slow", "maintenance guy", etc), then it's hard to break that cast. So, the management has more issues with soft skills, teamwork and planning rather than simply dealing with Frank's lack of Ruby skills, IMO.

Frank's story rings very similar to mine. Frank and I had a similar issues with alignment of goals and interests versus the needs of management or the team. Once those goals no longer align, it is best to try to fix it as quickly as possible. Otherwise, I think it is best for Frank to find new opportunities in something that he'd like to do.

It's now several weeks since my friend, a coworker of "Frank," told me about the frustrations he and his teammates have been having. Although the situation isn't fully resolved, I thought I'd let you know a bit of what has transpired as well as fill in the blanks on a few queries that people had commented on.

First, I can't tell you what Frank actually thinks or feels, because I don't know. I heard the tale from the coworker, not from Frank, and Frank presumably doesn't know that he's being discussed. Mind you, as Frank's coworker you wouldn't know what he's thinking either.

Also, the company is already Agile-friendly -- there are daily scrums, for instance. Not everyone on the team is especially interested in pairing, but they're open to it.

Although Frank has been saying that he's on board with the new program, my friend tells me that he's been more than a little obnoxious. Mostly, "He tries to act like he's really smart, but then it turns out he doesn't know what he's doing." He insists that he knows what he's doing, but his code doesn't work.

The guy is lost, and apparently doesn't want to admit it -- maybe even to himself. He wasn't asking questions; he just kept trying stuff, some of it that pissed off other team members (such as checking into production the code that didn't work). And despite knowing that he had a whole new system to learn, Frank regularly goes home earlier than does anyone else on the team.

However, in the last couple of weeks, someone in management must have had a serious talk with Frank, because he suddenly started asking for questions and making an effort to listen to the answer. He was also assigned to work with someone -- my friend, as it turns out -- on one of his projects. My friend asked lots of questions aimed, he said, to find out whether Frank had a hole in his knowledge or a gaping chasm. "So far it looks like the Grand Canyon," he said. "He's missing so many of the fundamentals." Which does back up the premise of those who opined, "We don't even know what is going on with Frank until we watch him do it."

The story isn't over. But it's not looking good for Frank. It's one thing to need to learn a lot -- ignorance is curable -- but he isn't demonstrating the activities to indicate he's serious about doing so.

I wonder whether the history of this transition might explain
matters a little more diagnostically. Right now, what's been
described is already difficult. We're later in the game and the
problem has had time to fester . . . Since we're given that this
chap has done good work in the past, how ever did we get here?

What were the first indications of an issue?
Who noted them?
How were they characterized?
In particular, how, and when, would Frank have become aware
that things weren't going well?

What lessons are there for getting ALL members of a group
from here to there, that could be applied from the beginning?
What, if anything, would have prevented this?

If this is truly an agile team, my first impression is that it sounds like a failure of the team rather than the individual. Though the particular skill set of the team might emphasize a different root cause.

In light of Esther's recent update about Frank's "gaping chasm" of ignorance in the new technology stack, I wonder: If the whole team started from the same point, how did Frank get left so far behind? He may have alienated the rest of the team along the way, but otherwise I'd say it's the team's fault for not helping him along.

If the whole team is new to agile in addition to the technology, then it may be more of a failure of management. Why haven't retrospectives addressed Frank's areas of weakness? Haven't people offered to help with specific roadblocks during daily standups? Why has Frank been afraid to ask for help along the way? It sounds like he needs some serious prodding, but someone should have been able to fulfill that role on the team before six sprints had gone by.

My biggest question when reading this is: why doesn't Frank trust the team? That could be his own doing, it could be the composition of the team, or other factors may be involved. It could be as simple as that Frank doesn't trust the agile process itself. If he's had to "learn" a new method of working along with this new technology, he may just be so far out of his comfort zone that he can't assimilate anything.

why did they switches frameworks at all?
if they allready had a good team with skilled guys, there would have been no need to switch.
-management fail

why did that guy didnt adapt to the new system?
as a dev by myself id say: if you know one language, you know them all. the fundamentals are in most cases identical and not depending on the language at all.
- dev fail

Forget Frank as a programmer on the new platform (Ruby). Given Frank's attitude - "He tries to act like he's really smart, but then it turns out he doesn't know what he's doing" - Frank is beyond help. People who are not prepared to admit that they don't understand, or can't do what is asked of them will never learn. I've seen the same pattern in various places I've worked in the past.

One of my current collegues has an attitude very similiar to Frank's. He likes to project the image of a talented programmer who knows his stuff. The reality is that he is pretty much clueless. Not such a big deal right? Every programmer with any experience goes through clueless periods. But the key to progressing from clueless to compentent is openly admitting that you don't understand and taking steps learn. My collegue's ego, like Frank I suspect, doesn't what to admit that he is a fish out of water, therefore he is not receptive to learning. He also becomes very defensive/antagonist when there is any sort of implication that there maybe any sort of problem with his work. I've worked with this guy for a few years now, and several training courses and fair amount of pair programming hasn't made any difference. You may be wondering why this guy is still on the team after under performing for so long. Well, he's my boss. He also is highly skilled at covering his own ass!

To all the respondents who are say that a good programmer will naturally pick up new technologies I think you are slightly off track. I suspect that such statements come from younger programmers who were taugh such things as OOP and OOD in school. Many years ago, when J2EE was considered bleeding edge I worked for a company that was transitioning a legacy mainframe system to Java. At the time most of the team were mainframe (Cobol) programmers. Very talented, experienced guys (on the mainframe). Throw these same guys at Java and suddenly their talents were being over shadowed by some 'snotty nosed' kid. Some guys didn't take this too well and promptly left. Others just never really groked OO programming and subsequently moved on to become business analysts/project managers, where there business knowledge and experience could be better utilised. Some, although generally the exception rather than the rule, also become compentant Java programmers.

Frank certainly seems to be somewhere in the first two categories. None too happy about the changes that are occurring around him and unable to keep up with the changes. Dealing with the Franks for this world there are really only two options - get rid of him or move him on to another job that matches his abilities.