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.

  • 39
    How often do you need to revisit his code due to quality issues compared to other members of the team? Is it less?
    – hookenz
    Apr 3, 2017 at 23:52
  • 10
    Dozens of comments have already been moved to chat. If you're not asking for clarification from the OP please comment there or join the site-wide The Workplace Chat. OP: please edit answers to useful comments into your question instead of keeping the discussion going.
    – Lilienthal
    Apr 4, 2017 at 8:25
  • 23
    Switching tools also has a cost. If you DO get the dev to switch, remember that it will likely hurt his productivity in the short term, whatever the long term outcome. Apr 4, 2017 at 14:03
  • 35
    Do note that you are assuming a relationship between the development environment and the velocity. This might be the case, but it might also not be the case.
    – Jasper
    Apr 4, 2017 at 14:40
  • 22
    "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." - No, look again at the title of the question. "Force" and "ask" carry two quite different connotations.
    – Brandin
    Apr 4, 2017 at 17:50

14 Answers 14


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).

  • 54
    @dKen that's probably even more important to present clear goals rather than tools based arguments. Your peers are going to find you incredibly petty if you try to argue for either a PIP or even firing an employee based primarily based on what tools they use.
    – enderland
    Apr 3, 2017 at 15:45
  • 17
    I think you're right. The rest of the team are thriving with the "self-managed" approach that has come from agile, but this one developer might be struggling with it (in fact, he's already said he prefers the pressure of tasks and deadlines over picking what he does himself). I think the next step is to perhaps make and assign clear goals which he may find easier to adhere to. Thanks again for your input (and yep, I think blaming the tools is out of the question for the time being).
    – dKen
    Apr 3, 2017 at 15:50
  • 24
    @dKen From your description, he might have self-management and time-management issues, and some people prefer more structure while others thrive with less. It's possible it's a "work expanding to fill it's space" issue - especially if they are consistent. You might need to work with them on tighter deadlines with more regular reporting than your other employees use - individual strategies like 15-minute end of day reporting, morning goal-setting, etc. You'll need to experiment to find the right tack that works for them, but none of this will work if you aren't clearly communicating the issue.
    – BrianH
    Apr 3, 2017 at 16:37
  • 9
    As a novel idea, after articulating your concerns and expectations, why not ask the developer what they think would improve their speed? Apr 3, 2017 at 21:57
  • 9
    @dKen if the person claims they'd do better with a personal task list instead of being free to pick/choose from all the teams work in the scrum (or etc); would it be possible to put that claim to the test and slice of a reasonably self contained chunk of work representing his 'fair share' of the total for a few weeks to see what happens? Apr 3, 2017 at 23:28

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.


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"

  • 5
    Thanks for the response Richard. He's doing his job but at a significantly slower velocity than is sustainable at the moment. I'm pushing some changes in the way we work that has had a very positive outcome for the rest of the team, but he's resisting because it's a change to his usual process. Generally unwise to micromanage: I'm sometimes called out for micromanaging, but in situations where the project is behind schedule and tasks need strict prioritisation for maximum benefit, isn't it sometimes necessary?
    – dKen
    Apr 3, 2017 at 15:17
  • 84
    I think everybody is being too cautious. I say that changing the environment is guaranteed performance hit. Best case scenario is that after some time, the performance will increase enough to make up for the initial loses. But those will be heavy - if the project deadline is near, that's the best way to miss it. It's a simple matter of investment and the return from it.
    – Agent_L
    Apr 3, 2017 at 17:28
  • 27
    @dKen But is your micromanagement objectively helping? Or is it just giving you a peace of mind that you're doing something? Most people follow the rule "If you can't fix what's broken, start fixing something you can" without ever realizing it. I'm not saying that this is the case here, but this is what gives micromanagement its bad name.
    – Agent_L
    Apr 3, 2017 at 17:34
  • 5
    @Agent_L, you're right about the performance hit. Tool change is out of the question now. About MicroManaging, it's something I do suffer from occasionally, but in this instance, that MM has turned the project around. Most people don't like being MMed, but if it means the difference between a failed project or a successful one that keeps their job secure, then there's no choice. My MM has been effective according to all measurable stats, although has had a bit of a negative effect on morale, as expected. Now isn't the time for sentiment though.
    – dKen
    Apr 4, 2017 at 3:47
  • 7
    Or number 4. quit because he doesn't feel comfortable any more and @dken just lost a high quality (even if not the fastest) coder.
    – ecc
    Apr 4, 2017 at 7:36

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.

  • 8
    This is brilliant. I don't think any of the other answers gave different ways to encourage the dev to try alternative IDEs, and I like the approaches (actually, they made me laugh with their cleverness). Nice work.
    – dKen
    Apr 3, 2017 at 16:08
  • It also helps if everybody on the team uses the same IDE because then they can all help each other and it's also easier to temporarily switch to pair programming when you hit a difficulty, because your partner will already know how to navigate your IDE. Apr 3, 2017 at 19:50
  • @Sumyrda This works both ways. Being cross-functional could also include the concept of IDEs; there's no reason a developer can't be comfortable in more than one (I use different IDEs for different coding languages, for instance). Of course, there's an impact on velocity as the learning increases, but if the medium-long term goal is more flexible, more valuable and happier employees, then this is part of the investment needed.
    – dKen
    Apr 5, 2017 at 5:14
  • Just a little addition to the "challenge" approach: it is a good idea to introduce the pair programming in the team. I.e. let people work together at one machine once in a while. This will let the knowledge about tools and techniques propagate on peer-to-peer level without active participation of management. Apr 5, 2017 at 17:40
  • 15 minutes with an IDE, a day with other tools; what do you think this developer is using, edlin?
    – user
    Apr 6, 2017 at 15:31

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.

  • 9
    I too use command line and text editor on Linux, and IDE on Windows. Partly because I haven't found an IDE I like for Linux. But there is another major effect I notice of not using an IDE (although this may not match your situation) - I need to understand many things on a much lower and more specific level. I need to hand-write the build files, and design the projects so that they make sense and are easy to work with without an IDE. Meanwhile, my Windows projects using IDE are organized how the IDE wants, have major opaque/automated/dependent areas, and feel vulnerable to weird IDE issues.
    – Dronz
    Apr 3, 2017 at 17:23
  • 14
    Using better tools absolutelly improves productivity. To say it doesn't is comical.
    – Davor
    Apr 4, 2017 at 9:38
  • 5
    "The choice of tools will not make a developer more productive." - presumably you would readily agree that the choice of tools can make a developer less productive? In which case your assertion starts to look a little shaky, doesn't it?
    – AakashM
    Apr 4, 2017 at 9:47
  • 5
    @Davor. "Better" is an opinion, not a fact. Some tools are better for some people in some environments. I am absolutely certain that forcing a developer who is familiar with command line tools to use an IDE will not improve his productivity. Apr 4, 2017 at 13:14
  • 6
    @Davor: I don't think anyone disagrees that using better tools improves productivity, what we're disagreeing about is the definition of "better". To take an edge case, most of us would agree that a 24" high-resolution display is better than a 14" CRT, no? But if you happen to have a blind programmer working for you, is upgrading their display going to help productivity?
    – jamesqf
    Apr 4, 2017 at 19:43

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.

  • 4
    The keyboard-mouse issue is something that this answer touches on (and others don't) that's important. Some people think bets on the home keys, and break their train of thought switching between keyboard and mouse while for others it doesn't matter. I don;t write much code these days (and use a text editor) but found the IDEs that require me to use the mouse a right pain. A well designed IDE with good keyboard shortcuts will only cost you the penalty of learning a load of new shortcuts compared to the editor, force an unsuitable IDE on this person and you'll never ge the productivity back.
    – Chris H
    Apr 5, 2017 at 8:07
  • The person using the keyboard interface may not be fluent either. There are good devs that primarily rely on the keyboard, but just because someone shuns an IDE, doesn't mean they're some sort of old school ninja.
    – user8365
    Apr 5, 2017 at 11:47
  • @Chris H: A good editor or IDE should not force you to learn shortcuts, it should allow you to DEFINE your shortcuts. And allow those shortcuts to be as complex as desired, as e.g. my shortcut key that runs make if I happen to be doing C/C++ coding, or LaTeX if I'm working on a tex file...
    – jamesqf
    Apr 5, 2017 at 17:24
  • You've judged his work as being of greater quality - the original answer called it "good", which reads as adequate. It's not mentioned as superior. Apr 7, 2017 at 13:16
  • "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" I can say I've seen the opposite. I've had the experience of people telling me how fast their mouse-free style is and then watching the excruciatingly long time it takes for them to do the most basic things.
    – JimmyJames
    Apr 7, 2017 at 15:39

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.

  • Thanks @JeffO. I'm the manager here so it lies squarely on my shoulders to figure out how to make it work. I appreciate you said the tool "may be the problem", instead of others who have ruled it out as not being possible at all, which in my experience just doesn't stack up. I've a lot to think about.
    – dKen
    Apr 3, 2017 at 14:56
  • 4
    If you feel this strongly about it, you should sit next to him in sort of a paired-programming situation and watch him work. If he feels like his is a better way, it's the only way I see either him changing your mind and for you to rule this out.
    – user8365
    Apr 3, 2017 at 19:42
  • Your first sentence is a very important point, I think: "Make sure this person isn't a better coder for the long-run.". Most very good coders I know are not necessarily fast (and sloppy) coders. They are coders where you do not have to refactor as soon as they finish. Compare that to someone who produces new bugs right and left or does not think things through.
    – kedavle
    Feb 17, 2022 at 21:22

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".

  • 4
    Ultimately, what matters is whether devs are hitting goals in a timely fashion and to a high (but reasonable) standard of quality. The environment shouldn't matter even if they're using butterflies so long as they hit that goal :). Aside from constraints on things like cost and security, they should have autonomy over their environment, and should not be able to shift responsibility onto the tooling when things go wrong because they chose it. If there's a performance problem, it's on the dev. Micromanaging the dev's tooling won't solve it, and the dev will resent you for it.
    – Michael B
    Apr 5, 2017 at 2:35
  • In my experience most managers claim to use the second way but the moment someone does something he's not explicitly told to do, even if it's a direct benefit to the company, they show their real colours and get angry with you for doing something you weren't told to do. And yes, that's IT managers.
    – jwenting
    Apr 6, 2017 at 10:40
  • As to my own preferences, I like them somewhere in between. Be given clear goals, but allowed leeway to do other things as well that provide benefit when I see them (which I'll then generally present to my managers first depending on the impact they'd have).
    – jwenting
    Apr 6, 2017 at 10:42

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...


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.


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.

  • I have a 6-7 years old HP Z400 Workstation, and no IDE ever comes even close to using more than what, 5% of CPU? I have a hard time believing that a 4 year old Mac would stall from an IDE when I have latest XCode running on a Mac from 2010 I believe.
    – Davor
    Apr 4, 2017 at 14:22
  • 2
    Apple has a history of selling bloated software for underpowered hardware at a premium cost. Apr 4, 2017 at 14:37
  • 1
    We're running the latest MacBooks with 16gb of RAM. My computer is identical and I'm running two IDEs for two languages, plus Photoshop and other hogs surprisingly quickly. Specs aren't the problem. As I mentioned, the developer is dedicated to "old skool"; there's little rationale except he wants to be edgy and do things the difficult way to learn more (which is great, as long as it doesn't affect velocity). He's aware of what other IDEs are capable of doing.
    – dKen
    Apr 4, 2017 at 19:53
  • 1
    @MatthewWhited: Do you have personal experience? From my personal full time iOS / MacOS experience, what you say is just an uneducated rant.
    – gnasher729
    Apr 5, 2017 at 0:55
  • 2
    If speed is important enough at this company that the slow velocity of one developer is a big deal, you honestly don't have time for this. Swapping machines, setting up new IDEs, waiting for the dev to come back up to full productivity in the new environment if he ever does, etc. all take time. Lots of time. Time that it sounds like you don't have.
    – Michael B
    Apr 5, 2017 at 2:29

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.


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?

  • 10
    a PIP will just get him to leave. As a general rule, a PIP is nothing more than preparation for termination, it's a terrible demotivator Apr 3, 2017 at 14:41
  • 1
    I'm the manager here, so it's on me. I don't want to get too drastic too quickly. I'm new(ish) to the team, but I'm looking at a few things to try before I take it to the next level. I'm confident there will be something I can do to help lift velocity.
    – dKen
    Apr 3, 2017 at 14:58
  • @RichardU Agree with PIP being a demotivator however, your answer suggests "begin the process of termination". Not sure how that's a ding on mine when you suggest the same approach without mentioning any plan for improvement...
    – mutt
    Apr 3, 2017 at 15:44
  • 1
    @mutt Wasn't made to be a ding on your answer, just that if you want improved performance/retraining, don't call it a PIP, far too much negative connotation. Sorry, I should have phrased that more clearly. Apr 3, 2017 at 15:54
  • 1
    @dKen If you were to PIP him, would others back you up in your assessment? That is, does the slow velocity of the developer also appear to his coworkers? It's always a good idea to ensure that the problem is objectively visible to others who work with the person. There may also be mitigating factors that you discover this way: for example, is that person working on a harder problem than the other developers on the team?
    – Michael B
    Apr 5, 2017 at 2:18

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?


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.

  • 1
    The fruitless and ultimately meaningless discussion on CLI vs. IDE can be found here. The question was: am I right to try an IDE to see if it changes velocity. I'm not asking peoples' preferences on development tools.
    – dKen
    Apr 4, 2017 at 19:47
  • The only environment worth evaluating a developer on is the tooling that he or she is most comfortable with (within the company's constraints on cost, security, etc.). Forcing an external one will not make the developer faster, and it's the developer's responsibility to learn an optimal environment at the end of the day anyway.
    – Michael B
    Apr 5, 2017 at 2:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .