Everything you need to know if you decide to delete your Java IDE, and the top 5 reasons that made me delete my own Integrated Development Environment


About 3 years ago, I made a big change in the way that I write code. It occurred to me that in a lot of cases, my IDE was slowing me down more than it was helping me work. So, I made the drastic decision to delete it completely.

Of course, many people are shocked when they hear about this, and it’s definitely not recommended for every developer. In this post, I’ll share the motivations behind deleting the IDE in the first place, how I moved forward without it and who else may want to consider this as an option.


5 Reasons Why I Deleted My IDE

1. System Performance

I work with many programming languages at the same time: Java for our servers, C++ for some of our clients, JavaScript+CSS+HTML for our frontend, along with Groovy+Bash for some automated tasks. Running multiple IDEs for each language required too many resources (i.e. CPU/RAM) which led to issues running the actual program I was developing. Some of the IDEs froze from time to time while others just crashed. With all of this, it took too long to compile, link and publish the code.

Plus, it took it a long time to warm up everytime I would reboot my computer because it was trying to run so many IDEs. To avoid the long wait, I started to put my computer in sleep mode for months instead of shutting down which caused the OS to become slower over time.

2. System Reliability – “Voodoo”

As mentioned above, when you work with an IDE, you have to deal with it just crashing for no reason. It happened to me especially with Eclipse and XCode but also with other IDEs.

Other times, exceptions in your program cause bugs in the IDE or unexpected behavior. Most of the time either clean+build or clean+publish solves it, other times you have to close the IDE, clean its metadata and configure it from scratch.

For example, there were times I just couldn’t stop the server, probably because of a bug in my code, however it’s reasonable to expect the IDE to understand that I’m in the middle of development and allow me to kill the process if bugs occur.

3. Multiple Environments

My day-to-day work requires me to switch between building features, code reviews and bug fixing. I want the action of switching between tasks to be cheap (in time) and to be able to work on many things in parallel. With an IDE this is much harder to achieve. And there are two reasons why. First, because it uses a lot of CPU, RAM, etc.. And second, multiple instances of the same IDE might interfere with each other.

On top of that, when switching between branches during work, which happens a lot because I work on features and bugs at the same time, it took it forever to re-index the code and get ready for work.

4. Working on Remote Servers

For my work, I sometimes have to run multiple servers on multiple remote machines and run tests against them. I don’t like to build a package and install it just for the testing. I prefer to use these machines as if they were mine, and working without an IDE makes this task much easier.

Still, it’s more comfortable to edit the code using my favorite text editor (Sublime) instead of using vim or other command line-based editors. I overcome this issue by using a combination of rsync, git push/pull, sftp or even just copy/paste into vim.

5. Accessibility

Even when the IDE is fully configured with custom shortcuts, there are actions that require the use of the mouse. The problem with this is that even just moving your hand from the keyboard to the mouse for ordering, resizing views or moving the keyboard focus to a certain part of the IDE slows you down. This is a matter of personal preference, but I prefer to avoid this as much as possible.

Another important thing regarding the IDE is the amount of space it takes from the screen: one row for the window title, another one for menus and another for the toolbar. And that’s even before the tab switcher between open files starts. That causes the code itself to be limited to only part of the screen and uncomfortable to work on.

So, You Deleted Your IDE — What’s Next?

1. Learning About IDE Functions

First, you’ll have to learn about what the IDE does for you, how it compiles the code, how it publishes it to the servers, and how the files are organized in the file system. Luckily for me, OverOps uses standard build tools like Gradle, CMake, Bash and Groovy which can be run directly from the command line.

So, I run these tools from the command line and use a combination of Bash commands in order to publish and run OverOps. Basic file operation commands like cp, mv, rm to manipulate the files and less, nohup, kill, ps, htop, etc can then be used in order to monitor and control the program. Just like it is done in the production environment.

2. Building Your Own Tooling

After a while, you will start to realize which commands are used the most and you can start to create some aliases for them.

For my own work, I put those aliases in a ~/.bashrc file which is included automatically in every Bash session. Once the file got bigger and included more valuable aliases, I decided it was the right time to back it up. I created a new private git repository (used bitbucket for it) and put the file there. I cloned the repository into a local directory and used the `source` command to include it from the ~/.bashrc file.

At this point, I started to really enjoy this way of working, without an IDE. So, I decided it was time to put some extra effort into modularizing this file like I would for normal code. I created one main file to contain smaller files. Each file has a job, like `git.sh` contains all the aliases and functions related to working with git, while `docker.sh` contains the basic commands to work with docker. There are also some common files which contain aliases and functions unrelated to any specific program, and some families of files related to specific components in projects I work on, like moduleXXX.sh.

3. Discovering What You Can Do That Your IDE Couldn’t

One interesting thing about this work style, is that you have the power to create scripts that do complicated tasks that you could never imagine having as a part of the IDE. You can create functions which automate the process of building, running, calling some internal code, waiting for close and checking the error code in the end. All of this with one simple command. Of course, this can also be achieved from within the IDE by creating a plugin, but writing a plugin takes much more effort than just writing some Bash function.

A good example of this is one of the main projects I led in my company. We needed to do a port of our agent to the AIX platform, but at first we couldn’t find an easy way to run X Server with a GUI on it. Without the IDE, though, this wasn’t a problem. I just installed Bash on that machine and worked on it like it was my own development machine.

At that time, I realized the real power of working without an IDE was with the remote machines. I could run benchmarks on our product across many machines and test network issues like load balancing, firewalls etc. If an error comes up, no problem, I just add a few debug prints and start it over. The cycle of rebuild is reduced to less than a minute instead of rebuilding a debug version using the build machines.

Who Should Consider Working Without an IDE?

Working without an IDE is not an easy task. It requires a deep knowledge of the technology you are working with, plus you will need to be familiar with the shell environment of the OS you use.

The learning curve of working without an IDE is steeper than working with an IDE, so this isn’t recommended for beginners. Also, the benefits you get by working without an IDE won’t be worth the effort. Usually, there is no need for working on remote machines or jumping between tasks as a beginner.

This work style is more suitable for technical leads who jump between tasks frequently; the ones who need to run a Proof of Concept (POC) for some new feature, fix a bug in production and review a new developed feature all within a couple of hours. In these cases, the context switching between tasks is much cheaper if working in multiple environments.

It can also work well for developers who do Ops tasks like benchmarking, bug investigation in production, networking, or any tasks that need to run on remote machines.

Debugging in Development Without the IDE

Debugging is another story. Personally, I never was a big fan of IDE debuggers since debugging skills are very specific to the language, IDE and operating system. That’s why even when I worked with an IDE I rarely used the debugger. Instead I prefer to use debug prints. They work for every language, on every platform. The code should be modeled in a way that helps you to run parts of the code easily without needing to run the whole server for it. Some of the things that can help with this is to avoid shared states and to decouple components.

Luckily, deciding to work without an IDE won’t affect the way you debug in production or pre-production (staging). This will only change your backend development workflow, so all of your current monitoring tools will work as usual (that means you can still use OverOps! 😉 ).

Final Thoughts

**Edited** Concerning refactoring, I will say that code refactoring is definitely easier with an IDE since they have a built-in support for it. Without the IDE, I use regexp or some other small dedicated scripts, depending on the specific task. However, refactoring with regexp will make you an expert with them and it is quite a handy tool to master. Sublime, which is the primary text editor I use, can then index thousand of files very quickly and allows you to find/replace in less than a second. **

I won’t try to convince you that every developer should immediately delete their IDE and start working the way I do. Aside from the effort of configuring the environment for the first time (which may take weeks), from time to time you still need to stop for maintenance, add some aliases, remove others, add support for a new deployment mechanism, etc.

For any developer that works comfortably with the IDE, this isn’t recommended. But, for anyone that is often irritated by the performance and functionality of the IDE, you should know that there is a way forward without it.

David is a Backend Group Lead on OverOps’s R&D team, and the most laid back person you’ll ever meet. He also built Sam, OverOps’s internal build automation bot. When away from keyboard, David enjoys riding his motorcycle.
  • Lajos Incze

    i haven’t deleted, but use it only for refactoring, vim for editing, ide for refactoring. it is faster and more reliable with an ide.

    • David Levanon

      Code refactoring is definitely easier with an IDE since they have a built-in support for it. Without the IDE, I use regexp or some other small dedicated scripts, depending on the specific task. However, refactoring with regexp will make you an expert with them and it is quite a handy tool to master. Sublime, which is the primary text editor I use, can then index thousand of files very quickly and allows me to find/replace in less than a second.

      • Lajos Incze

        regexp is handy to spot targets to refactor but dangerous, and sometimes useless. e.g. you want to refactor a pretty common object property, e.g. “name”. you can imagine, how many “name” local varables, or properties of different objects can be found in a larger codebase. (in simple cases (of course) you can use a “grep -r”).

        refactorings can be more difficult when you restructure the code (e.g. extracting interfaces, etc.) a good ide is great at that.

        • David Levanon

          Indeed it is dangerous, that’s why I don’t recommend for everyone to do this. However, after years of working like this, and a lot of refactoring I have done, I can say that with little effort it can be safe and even fun.
          Luckily, in our company we give consistent and descriptive names which can easily be matched using regexp.

          Regarding refactors like extracting interfaces, creating delegators etc.. It is not a common task, but when I do need to do it, I just do it manually and it is not that big deal.

        • Giovanni Bianchi

          Refactoring is good, but I feel that people tend to rely too much on it, especially when IDE’s give you a lot of power to do it indiscriminately. If you work in a big team and refactor indiscriminately, you risk ending up with commits touching tens of files and it is a mess when merging.
          Best thing is to think ahead and design forward-looking software which will not need too much refactoring in the future. This, of course, sometimes, is a trade-off on KISS principles.

  • mikezx6r

    Interesting. I can see some advantages to this, especially the ‘getting to know your processes well’. Huge respect for taking the leap.

    I’ve settled on IntelliJ for my IDE, so I use it for front-end and back-end development. Minimizes the resources required as I have one window with all project files. And only one set of keyboard shortcuts. By using one IDE, I can do everything I require from the keyboard, and it provides good modes for reducing the clutter.

    Different approaches. Glad this one is working for you, and I appreciate you sharing it.

    • David Levanon

      Thanks for your comment! (Love your motorcycle too, by the way)

  • Henrik Martin

    Funny, I’ve gone the completely opposite way. Many years ago, I started off with tools like ksh/csh/tcsh, make, vi/emacs, awk/sed/perl, etc. Then I migrated over to Eclipse, and then after many years on Eclipse, I switched over to IntelliJ. I’m still very comfortable in the “low level” environment, but I can’t imagine doing a full day’s worth of work without my IDE. In fact, I look for solutions that will allow me to do more from within he IDE. I rarely experience IntelliJ crashing on me, and most of the plugins I use are real time savers. There’s great support for most of the languages/toolkits that I can think of, so the “one IDE for every language” comment sounds strange to me.

    • David Levanon

      Thanks for your comment. Agree to disagree? (:

  • malcolm davis

    I have multiple ide’s open up at a time. Many times different ide’s based on the code I’m writing. (I pick the right ide for the job).

    General things great about an ide, clicking through code, auto-complete, auto-importing, compiling as I type hence finding bugs as I work, and refactoring.

    My favorite is using the sample-driven approach that will auto-generate code.

    Your hardware/os/software configuration might be the core if the issue and not the ide.

    • David Levanon

      I’m using Dell XPS 15 9560 with Debian Stretch. One thing to remember is that efficiency also depends on the codebase that you’re working in, how many files/classes/etc. With the large codebase that I work with, the IDE was simply not optimal for my workflow.

      As for the features that you mentioned, although they are helpful and can make somethings easier, I find that I’m happier working without the IDE and I feel that deleting it was still worth it for me.

      • malcolm

        Large code bases are always a subject of debate.

        Intellij is a single solution-multi-module mindset. Due to intellij’s nature, the projects seem to be larger. (I’ve seen some 100K+ LOC).

        Eclipse has a workspace-multi-project mindset. From my experience, Eclipse projects are generally smaller in nature (less than 10K LOC).

        I’ve seen several huge projects over the years (100k+ LOC), but that is generally due to lack of ‘separation of concerns’ (SOC), rather than the characteristic of the problem space.

        It’s rare to see a project (concern) that needs to be more than 10K LOC. Tools like the modern IDE & Maven have made the management SOC much easier to do correctly.

        Compiling, testing, and running a 10K LOC project in Eclipse takes me a few seconds on my laptop. However, Eclipse+Java is heavily performance tuned.

        [Background: I’ve been doing dev since 1990. Java dev since 1998 and Java certified since 2000. I’ve been involved in several successful startups and consulted for numerous places including AT&T, Blue-Cross, and Motorola.]

  • Evgeny

    Very strange article. Maybe for some tasks is possible to work without IDE, e.g. scripts, small changes and etc. But I don’t understand how possible to work without refactoring and tooling. And in article there is no any mention about refactoring at all.
    Also I don’t understand how to work without debugger, printing some info is OK in some situation but debugger save a lot of time !

    • David Levanon

      Thanks for your comment, I added a small part about refactoring at the end of the post now. I agree that it shouldn’t be overlooked. As for debuggers, I included a full section on debugging in development including some ways that I found I can work without it more easily.

  • Balda

    You didn’t say what IDE(s) you used (and deleted), so I’m going to ask just question – did you tried the IntelliJ IDEA? I have a feeling (because this article exists) you somehow skipped it.

    • David Levanon

      Part of my job is to integrate Gradle with IntelliJ and Eclipse for other developers in the company. I used them both for years and just don’t like working with them personally.

      • Balda

        I share your frustration with Eclipse. However, I’m curious what exactly you don’t like in Intellij IDEA?

  • Mani Zaeim

    Strange and none-sense, I am using Linux and my ONLY desktop since 2001, so without doubt I love command lien, awk, sed, cut, tr, … BUT its more productive when it comes to coding and auto completion and importing packages and suggesting the code enhancement refactoing and integration with git svn , running app on the webservers and app servers and intergration with DB … WITH damn IDE such as IntelliJ or Eclipse! and not to mention to bunch of eclipse plugins, UML diagrams tools …
    core i5 and 16+ GB RAM should be enough for any coding. and its vey cheap now a days.
    100% im not agree with you, a professinal developer needs a professional tool for efficiency and productivity

  • Christopher Stura

    I suppose everyone finds their own happy. Personally I’m still in the mode where I use multiple IDEs. But a good multi purpose editor + IDE with nice tools is visual studio code. The thing I like about it is that it supports pretty much every language. Still for somethings like profiling or debugging the IDE is still king

  • Kamil Szabo

    I agree that IDE’s can slow down certain kinds of work – picking the most effective way of doing thigs is part of our jobs, weather it’s scripting, specialized tools, or whatever we are personally most effective in.

    But I have to strongly disagree with debugging approach. If I only take java and c# there is so much things (three biggest would be Conditional breakpoints, Expressions or live data manipulation) that just can’t be replaced by debug logs. Not to mention that in some cases changing log level means also different codepath. These tools are also vastly used for testing and tuning code For me, it would be all-in-all cheaper to buy a faster laptop that can handle IDE better, than “spare” time debugging without IDE.


  • yuraminsk

    You don’t need IDE if you are doing trivial work. Otherwise, it kills you.
    So my disclaimer for this article: never try it at home

  • Andrea De La Cruz

    Glad you found the best way for you to work as things are right now, however, I can’t shake the feeling that working on many things at the same time (features and bugs and different languages) is a little bit difficult (chaotic) for me.

  • Luiggi Mendoza

    I use the IDE for the code editing, refactor, file creation and such things that any IDE can handle without extensive usage of resources. For stuff like compiling, deploying artifacts and other things, I prefer to rely on terminal/bash tooling, using raw tools like maven (mvn) or writing my own scripts as you do. With this I can be as much as productive as I want and I define what I want the IDE to handle and what I want to handle on my own (and assume the risks/benefits of it).

  • nulloman

    so patch is handy. you can get diffs on any system pretty much. I find it better to work from shell if I’m cross compiling stuff.

  • Doug Reynolds

    If you delete your IDE, you using the wrong IDE. I am a fan of lightweight editors; I have used vim, sublime, atom, sublime, and VS Code. They work great for writing markdown, shell scripts, IaC, etc.

    I have used the debugger “print” statements, and they work. However, when you deal with complex frameworks and code that you haven’t personally written, print statements don’t always work. They can be swallowed by logging, io redirects, etc, and they lack the ability to dump entire objects (talking about you, Python pprint).

    I use Intellij for non-dotnet code, Visual Studio for dotnet, vim for scripts, and Visual Studio code for simple things. Intellij works great for remote debugging; it does have a learning curve, but it beats using pdb and can be forwarded over ssh.

    I don’t see a performance issue using docker, Vagrant, and Intellij with 16 gig of ram. So ymmv.

  • Greg Pasquariello

    So many of the reasons you gave for discarding your IDE are just plain incorrect…

    • Julian Klappenbach

      Serious. Not even wrong.

  • Michael Arthur Breton

    This is one of the most impressive explanations of what can go wrong during development and the shortfalls of using IDEs. Much of this can be avoided but at the expense of your savings account if you don’t have the support of a well funded corporate sponsor.

  • Memory Leak

    To me, the solution doesn’t befit the problems. Hope we are not seeing the beginnings of a ‘make vim great again’ movement.

  • James Holder

    This article just made me unsubscribe from the mailing list. Thanks!

  • mvadu

    your basic problem seems to stem from having to run many IDEs for each of the languages you use. Have you tried vscode? Its cross platform, supports almost all languages. I use it for go, python, C# and C++ (Arduino), and never have to sweat with performance issues.

  • Bryan Jacobs

    To me this is a very personal story about what works for a specific person. If it works and you love it great. However, I love the ability to refactor code easily, and that isn’t something that would easily part with.

    I can see value in learning to build a solid automation around daily work. That is a great insight.