Should I force a slower developer to change tool to try to increase their velocity?

Question

I have a developer on my team who, while delivers good quality code, is significantly slower than the other developers on my team. This is causing a pretty serious bottleneck that I'm trying to find a way to resolve. In the medium to long-term, making the team cross-functional will allow other team members to help get velocity up, but I'm looking at any option I can to increase the output of this particular developer (especially since the project is at risk of going over budget).

This particular developer still likes to code "old skool". That is, he uses a text editor for coding, command line for every possible situation, and if given the chance to remove his mouse and any visual aids, he'd do it. He's explicitly clear: they want to do nothing but code, preferably where they have zero exposure to other humans, and preferably at home. Absolutely no meetings, no discussion, he wants the tasks that need to be done and to complete them by himself. Trying to introduce agile is going to be a challenge. He doesn't have many other responsibilities, 95% of his work is code.

Now, I'm not against developers refusing to use interfaces, mouses and IDEs if they want to make their own lives difficult (personally, I think it's just a show-off move, and slows development time significantly IMO), but when velocity is under par, I'm looking at this as one of the options to increase output.

So, the question is, is it fair and within my remit to ask the developer to switch up to an IDE to improve velocity? In my experience, this has a drastic improvement in time to complete a task, but I feel like it would be forcing him into a corner and taking away something he really enjoys, which won't help with motivation.

For those who say "it gives more flexibility/power!", I understand this point, and command line is always there for the 2% of time you need it. For the rest of the time, IDEs and visual interfaces were designed for a reason: speed and ease of use. I don't buy into it.

Edit: For clarity, I'm a new member to the team, brought on as a project manager, but I'm also an ex-lead-developer who has a significant amount more experience than the other developers in the team. I've been given carte blanche to make architectural and development decisions in order to recover this particular project which is in serious trouble, and is vital to the company's success.

Edit2: A common suggestion here is to ask the developer what he thinks will help improve his velocity. I've done this already a few times, but no useful response is forthcoming: "I'll think about it" which doesn't happen. That's part of the reason why I'm looking down relatively unusual routes to see if I can boost productivity in other ways.

Edit3: It's clear that the whole IDE/CLI discussion is unresolvable; both sides have their points of view, and like OSX/Windows, or Python/PHP or...there's no right or wrong way. If you want to have you say on this, head over to this discussion to continue talking to brick walls. The question wasn't if IDEs are better than CLIs, it was if I can ask this developer to try something new to see if it affects velocity. Ultimately, developers can code with punch cards or in Minecraft if they like, as long as the velocity is there. Please be aware that to become efficient with CLI has a much longer and more difficult learning curve than IDEs do, and it's possible that's the situation here.

Answer 1

Management needs to set measurable goals.

They then need to confirm the developer is hitting those goals. If not, they need to take action.

If you are facing issues related to this and are not this employee's manager, focus on the velocity problems when you talk with your boss. If you are the manager you need to be more clear on expectations.

For the rest of the time, IDEs and visual interfaces were designed for a reason: speed and ease of use. I don't buy into it.

Do not argue on the "tools" approach like you've done here. It comes across as petty and ultimately is pointless - some of the best programmers I know love/swear by vim and are more productive using vim than I will ever be. The point isn't the tools, the point is the overall productivity.

Every time you mention this to a manager, you almost assuredly will make them less likely to take action.

Focusing on the tools will guarantee you cannot convince either this employee or management to take action, because it's a petty accusation and ultimately irrelevant. You need to focus on the results (or lack of results).

Answer 2

As an old school developer myself who uses text editors and the CLI, I can say that forcing someone to use different tools will not necessarily increase speed.

That said, if you're the team lead, it is generally unwise to micromanage down to the level of demanding he use certain tools over others.

Either he is doing his job or he is not.

If he is, leave him alone

If he is not, begin the process to terminate him.

The old saying that managing coders is like herding cats is not an understatement of the difficulty involved.

This part really stands out for me:

In my experience, this has a drastic improvement in time

Yes, in your experience. In his, it may have a terribly deleterious effect.

Don't ever make the argument based on a tool.

Remember, the point is either he's doing his job or he is not.

EDITED TO ADD::

Avoid micromanaging at all costs. All it does is set you up for failure, as the employee can react in three ways.

1. Resent it and drop their morale
2. "Reverse delegate" and put you in the position where most of your time is going to be spent on very low level things
3. Appear to comply, slow down, and then blame you for the performance hit. "I was doing fine with my text editor, then he forced me to use this tool I'm unfamiliar with.

Your job is simply to expedite. Make sure your team has the tools they need, and remove any obstacles to success. If your goal with this employee is speed, then sit down with him and discuss speed, not the tools. Ask him how he could produce more in a shorter period of time.

Mention that you think the new tools might be useful, but ask for his input. If it's his decision, he may use the tools willingly without the morale hit. He may know of other tools that would allow him to come up to speed without the IDE or tools you are using now. Remember: The goal is increased performance, not "Use these tools or else"

Answer 3

As others noted, forcing a change of tool in and out of itself may not always be the best approach or work. However, convincing them that it's in their best interest to change a tool, will.

This takes a two-pronged approach:

1. demonstrate to them, tangibly, that changing the tool will help them improve their productivity

2. use your management levers to impress them that they must improve their productivity, so they are motivated to find an answer as to how.

   #2 is a standard management question that's somewhat outside the scope of what your asking (this is standard management 101).

   The rest of my answer will revolve around how to achieved prong #1, convincing them that if they are interested in improving productivity, changing the tool will help them.

---

A following approach might work better than "forcing", at least with some developers: produce evidence. Which specific flavor you can use depends on individual developer's personality and your+his dynamics. Some of these approaches can (and probably should) be mixed and matched.

• Approach 1: Demo

  Request him to view a demo (by yourself or another developer they respect) of how a specific set of tasks is done faster using IDE/new tool.

  If they are a good developer, they would be at least somewhat swayed by evidence and logic. They are still meatbag with bugs in software (aka human) so this may not always work as well as desired due to peculiarities of behavioral psychology, so set your expectations accordingly.

  You may want to do this either in obvious way (framing it as "I know you dislike IDEs, I'd like to demonstrate how they can help you"); or less obvious ("Here's a demo for entire team, watch me do XYZ in 15 mins so you can all be as cool as myself" - after he himself took a day to do the same thing).

• Approach 2: Challenge

  This won't work with all personalities; and may backfire; but some people are intensely competitive.

  Challenge them to see whose approach is faster; either as a dare; or as a competition.

  As incentive; you can promise them "if you win the challenge, I'll NEVER bring up the topic again and buy you free pizza for a week; if you lose, you commit to learning and trying the IDE for a month"

• Approach 3: Overwhelm them with benefits of new tool

  Personally, I'm much like the developer you described. I won't use the mouse unless I must; I do things in command line (with high efficiency) that most people aren't aware can be done; I taught CLI skills to my fellow teammates in a formal setting. I used to hate Eclipse and other IDEs.

  What changed things for me was my manager literally (or is that figuratively? :) carroting me to death with "Oh, look at THAT cool thing I can do in Eclipse!" (Easy refactoring. Easy debugging. "Jump to definition". "Where is this identifier used" search. etc...)

  I still use CLI when warranted; but I made an effort to climb the learning curve for Eclipse and to make peace with its shortcomings, simply because the manager objectively proved that it will make my life better/easier as a developer.

• Approach 4: IMPORTANT: Offer them help with learning curve

  Part of the resistance is likely the combination of people liking comfort zones and objective difficulty of learning to use modern IDEs with any degree of proficiency.

  Your job as a manager is to eliminate barriers that affect your team; as such you are in a position to deal with the latter.

  Offer them any resources they need - training materials; classes etc... However, in my many years of experience, the one that is most helpful, and most enticing, is help from yourself or respected team members.

  If they know they can ask questions on the IDE to someone who won't be judging them "eh that's a n00b thing, you low-rep idiot" way; they will be less resistant.

  If they experience the joy of someone helping them out with a weird IDE problem, they would feel far less apprehensive.

Answer 4

Simply put, you're on the wrong track. The choice of tools will not make a developer more productive. In fact, if you force someone to use the tools they do not enjoy working with, it will negatively affect their morale and make them less productive. I use an excellent IDE when coding on Windows, and command line tools when coding on Linux and there is absolutely no difference in my productivity between the environments - but that's because I enjoy both.

To make the developer more productive, talk to them and ask what would make them more motivated. It's really an HR issue, not a technical one.

Answer 5

You are way overconfident in your judgement here.

I've often observed that people who aren't fluent with keyboard interfaces tend to vastly underestimate how effectively a good keyboard interface can be used by someone who is. Doubly so when the interface is extensible and being used by someone who is well-versed in how to configure it.

You very much sound like such a person.

To make matters worse, your posting comes off as being quite prejudicial.

Consequently, I think it extremely unwise to try and force this issue.

---

That said, you clearly believe in this, and are interested in making a convert. The thing you have to remember is that changing the tools you use can be a rather bumpy ride, especially when the new tool is very different from what you're used to.

In my opinion, the best way to approach this is to remove the obstacles to smooth over the transition. The answer by DVK goes over this well.

But you have to remember that this developer has different experiences than you.

For example, you might not think it's a big deal to start a new project in your favorite IDE. The new user, however, will be faced with a bewildering array of options they don't understand the ramifications of. And probably be constantly comparing the process to simply hitting a keyboard shortcut to open a new file in their old tool and wondering why the new tool has to make things so complicated.

---

Note that you have other potential options to achieve greater productivity. You've judged his work as being of greater quality, so assign him to tasks for which quality is of greater importance. You'll get your productivity gains by allowing your rapid developers to complete other tasks and move on more quickly, rather than getting them mired in a task that has to go through several iterations to polish up their code.

Answer 6

Make sure this person isn't a better coder for the long-run. He may get features out slower, but if they are of higher-quality, it's difficult to have an argument against that.

Not getting things done fast enough to stay within budget is part of his job. Someone who is responsible, needs to step in and work towards a correction. Maybe he needs to be help accountable. Hopefully, someone would be willing to work with him to solve this problem before drastic measures are taken. Maybe it is the use of other tools. Don't be surprised if you force him to make a switch that his productivity declines. These things take time and are worse if the person doesn't believe it will help and isn't motivated.

Apparently someone in charge is now aware of this problem or they're doing nothing about it. Maybe they feel the rest of the team will pick up the slack? I would let this person know that you have no intentions of doing that especially if he won't compromise and use other tools.

Answer 7

There are different schools of management:

• People should do things management tells them to do, and do them the way management tells them to do them.

• People should do things that help the company, and figure out on their own how to do them, because they are professionals.

Most developers are usually managed the second way, and respond somewhat poorly to the first one. Ok, I vastly oversimplified and there are way more then 2 schools of management, but you should get the point. If you want a developer or other highly skilled worker to do something, you usually do the following:

• Tell them where the goal is, and help them figure out where they stand.
• Let them work out a solution.
• Provide assistance wherever they need it.

As a manager, the tools your team uses do not matter to you. What should matter is if the team has access to the tools they need, is adequately trained in the tools they use, and if there are tools that cause unnecessary friction in the team's processes. Remember: They are the experts, they know how to work, that's why you pay them.

What you can do is raise awareness of tools. Some ways to raise awareness and familiarity with a broader range of tools are to have teammembers review each others code on check in, have some pair programming sessions, have different team compositions on special occasions (e.g. on "yearly bug week", or "special project Friday"), and many more.

---

Advice specific to the IDE vs text editor part of the question:

If a developer who worked with a text editor for years is significantly slower than other developers who work with an IDE, that developer will not suddenly get to the same speed as the other developers by switching to an IDE. The speed difference is nowhere near the region of "significantly slower".

Answer 8

I really disagree with many of these answers suggesting that it is always bad to force a developer to use a certain tool when developing. For example what if you are coding in Java and you need to do debugging, but you have a developer who only uses a text editor and the command line. I have met people who were in the industry for years, who did not know that you can change the code in eclipse whilst debugging and your changes will take effect immediately... I mean take a look at this question about debugging Java in VIM, https://stackoverflow.com/questions/545056/how-to-debug-java-application-using-vim-gvim. The accepted answer has a link to something called JavaKit, which was last updated in 2008. If I am the boss, and I have a developer who is taking hours debugging Java in Vim to find a bug, what I would do is show them how I can do this task in 5 minutes in an IDE. After which I will let them know they can play that game on their own time, and I expect them to use the IDE in the mean time. But again I would need to demonstrate the benefit or business need for that tool to ensure I wasn't micro managing, however I wouldn't indulge a debate about whether or not a developer is more efficient debugging with or without an IDE. If the developer really was some magician with text editors and the command line then you wouldn't see them perform slower...

Answer 9

If the only concern is his own personal velocity, then I agree with the broad consensus: manage that. Let him know he might have options for increasing productivity by using modern tools, but otherwise that's up to him.

However, if the way your team works requires some of these tools - whether you work with projects that require at least opening up Visual Studio to set up process flows, or you standardized the team on a code analyzer that doesn't have an CLI - then using that tool is a job requirement, and you should make that clear. He's working on a team, and should not harm the productivity of the team generally by his own personal working style.

Anything that is inside the programmer black box is up to him, so long as he meets or exceeds expectations in productivity and quality. Anything that crosses outside to the team and has impact on others or the team as a whole, he follows your requirements or he is cut loose. That's a reasonable expectation, and a reasonable division of responsibilities for a professional.

As for how, if you do decide some of this is a requirement in order for the team to function properly: simply make it clear, in a team meeting, that the use of the tool is a requirement (to everyone). If he continues not using it, and won't change after being directly asked to, then escalate with management as needed. Personally I would make some effort to "sell" him on it, but not too much, if it's a requirement - particularly if the rest of the team is sold on it already.

Answer 10

I recently tried using the Xcode IDE with a very large project we work on right now on an 4 year old Mac: total disaster! To run the current state-of-the-art IDEs you also need a state-of-the-art machine, otherwise you just watch the IDE draw its fancy windows, or even worse loading indicators, instead of coding. And that's usually where the CLI comes in handy, because it always works at very high speed, no matter what your machine performance is.

So maybe you can bribe him? Get him the fastest machine you can find and he can use it to learn working with the IDE. If he switches back to the CLI immediately, give him the old machine and the new one to someone who can use it. Not as punishment, but to use the resource effictive. If he really tries it for a long time, maybe let him keep it. Depends all on your budget.

Also as others have mentioned, he needs to see the IDE fly, just let some developers call him over and help debug some problem. They will automatically use the IDE as intended and do all the cool stuff and he will be in the first row and just watch and ingest it because he is probably too busy looking for the bug. You get a lot of oh-I-didn't-know-you-can-do-that moments when watching someone else code in a different editor. Often even in the same one, so let the developers share their favorite IDE features in quick presentations.

Answer 11

The tools they are using are not the limiting factor.

He's explicitly clear: they want to do nothing but code, preferably where they have zero exposure to other humans, and preferably at home. Absolutely no meetings, no discussion, he wants the tasks that need to be done and to complete them by himself. Trying to introduce agile is going to be a challenge. He doesn't have many other responsibilities, 95% of his work is code.

They aren't engaging with other members of the team. Not getting feedback. Not doing code reviews (which are one of the best ways to improve developer productivity, code quality, and skill).

Continue to allow them to work remotely, but not 100% of the time (our office does 10%).

Institute mandatory in-person code reviews with the entire team. Let them see the other members' tools and techniques. Code that has not been reviewed and signed off on by another team member doesn't get committed to Master. Maybe you'll all switch to Vim, I don't know, but you'll all get better.

Answer 12

This is a management issue. The point is that the developer is not performing quickly enough for the project needs. His/Her slow performance needs to be called out by the manager and then he/she needs to correct it. If he/she has questions to the rest of the team for how that is a different story, but the base issue here is the developer is not performing quickly enough for the job he/she is doing. Management needs to work the situation with the developer and maybe a PIP to get things back on track.

Edit based on Comments: I have had a similar situation. I recommend team "training" activities on tooling and other things that are making the rest of the developers "successful". If you don't want to scare the person with then you have to train the team as a whole to follow certain practices and tooling to better uniform the approach of the team. This will likely be cumbersome for the entire team for the sake of 1 person, but if you don't want to call them out specifically then you have to make it generic for everyone. You can dictate the required tooling once you figure out the best way, but again this addresses the whole team with forced behaviors instead of just the individual. You can have a talk with them without having a PIP, but I don't see a way around telling them that they aren't as fast as the other developers, which then gets into the same sound you mentioned wanting to avoid in the first place. Yes tooling may help speed things up, but the point is the developer likes the way he/she is doing things, which is not using the tooling, which then gets back to a personal issue. Perhaps training will help them want to utilize newer tools?

Answer 13

If there is a useful tool that his not using point him to it.

I am certainly biased to text editors, and tried to write scala in vim, but I was quickly pointed to IntelliJ, and even though, it has different mindset, and somewhat of a learning curve; I am much more productive with it.

Therefore, point him to the best tools you think he misses. Don't force him to use it, just suggest him to try it. If he refuses to even try, that's a red flag to me, looks like a hard person to work with. If he tries it, but is not more productive with it, then you will at least understand why he is so "old skool", some people get confused by easy to use interfaces, I am a bit like that. Maybe you can put him on tasks where there is user interface to work with?

Answer 14

Person who can quickly write a script for any task and touch-types faster than you speak may be way more productive with command line than with some quirky IDE, regardless how professionally pushed into your team by they sales department. Do not assume this is related to performance in any way.

Also, I disagree with general approach of somebody else deciding about the tools, unless they recommend a new tool I do not know about. The person who is using the tool daily is more competent than some "decision maker" higher in the hierarchy, who just quickly evaluated it, or maybe even simply watched the well prepared demo without corner cases.