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.
Ready?
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. (/Edited)
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.
Written by David Levanon. Originally published on The OverOps Blog
Top comments (36)
Meh...lame . Once you graduate to JetBrains you never go back.
PhpStorm and PyCharm are 💯🔥
PhpStorm and WebStorm happy daily user here, and I also converted some teammates!
When I do C# coding, ReShaper is my third hand along with VStudio.
When playing with Android coding, Eclipse is really a piece of crap, but then I moved to AndroidStudio and my world went to heaven!
JetBrains FTW.
Haha, pretty much what I was going to say - "Have to use too many different IDEs, it's too much effort" Mate, just spring for a JetBrains licence... ;)
Meh... Used JetBrains (Rubymine) for about 3 years. Then moved to Atom, then to Spacemacs and coding was never better than now.
Which IDE are we talking about? Because the things you mention that you are able to do that your IDE couldn’t (without needing to write your own plugin) are things that most of the IDEs I know about can do, either out of the box or with widely used plugins. And I cringe at the thought of writing your own syntax highlighting, let alone intellisense or advanced refactoring capabilities.
The question is often whether the IDE can work for me with all of the languages, frameworks, and tools I use. While it may be helpful in some, if it doesn't cover them all it ends up adding a mental burden as you need to know the tool's way plus the fallback manual way to unsupported features. Or you end up having multiple IDEs for different frameworks, which again increases memory overhead.
Quite right. If you work with a great many languages, which don't overlap well enough in IDE support, then the number+size of those IDEs becomes a factor (at least, if you want them all to be open at the same time). I'd however wager that there is sufficient variation between developer circumstances there, to make the above general dismissal of IDEs invalid/wrong.
Come on, Eclipse and XCode are utter pieces of shit, everybody ought to know that in 2018. I've never been able to use them more than 10 minutes without a crash.
Now it's like saying "I tried to drink water from the sewers and it ain't good so I'll only drink beer from now on". Although beer is good, you can drink much more water and all it takes is buying a decent bottle instead of crawling your way to the sewers.
Invest in a machine with a reasonable SSD and enough RAM, as well as JetBrains Toolbox, and you will never want to touch those awful piles of hacks that glorified text editors are.
JetBrains IDEs work with a very wide range of languages, have free plugins for many more on top, are definitely not unstable or terribly slow and heavy monsters (if you're not trying to run them on 10 years old hardware that was cheap even then).
Editing code on remote servers sounds like almost certainly you're just doing things wrong, however with a decent IDE (like JetBrains) you also have remote syncing features - edit the code locally, it will instantly sync it to your server over SSH.
No clue why you'd even have wanted to run X on your AIX machine if not running X was an option, normally people don't run their IDE on the server they deploy their code to, for a good reason.
A good IDE also includes support for remote debugging, which is much better than your debug prints. Similarly many of the things you would just add temporarily there are things many SaaS services (e.g. New Relic/DataDog/Sentry/...) would provide as things you could monitor all the time incl. in your production environment.
Having gone from literal plain text editors to "programmer text editors" to IDEs to text editors (because back then IDEs weren't very good) and and again to IDEs (because now they are) I can't really imagine seriously working in any non-IDE anymore. My time and sanity are worth the few extra euros it takes to buy a computer powerful enough to run my IDE.
I'm running IntelliJ on Linux and it's fantastic. If I'm pairing with people I sometimes have to use their Eclipse on Windows env and I seriously wonder how they stay sane.
That is so true:
"use Eclipse on Windows env and I seriously wonder how they stay sane."
aahahahahahaha
A timely article, as I've just submitted a set of two posts to my company's blog on the same subject. I guess they'll be published sometime in the next few weeks. Anyway, I decided to deal with the issues you listed by seeing how far I could go in the opposite direction.
I built a lean Linux VM with 512 MB memory and installed the packages and tooling to support 35 programming, scripting, and markup languages with just one editor - NeoVim. The purpose was to prove or disprove the hypothesis that a very lightweight setup could provide a satisfactory and productive developer experience.
The laptop I've been using has 25 IDEs installed on it, by the way. The best of them exhibit the behaviors you list in your article. It goes downhill from there.
One additional point you didn't mention. IDE support for version control systems tends to be flakey and incomplete. I find it much easier to interact with those tools from a command line even in cases when I'm using an IDE. Definitely agree with you regarding refactoring, though.
Of course, I don't need support for 35 languages. I wanted to stuff the VM full of tools and see if it would still work. It did. Not all those languages are well enough supported with NeoVim or Vim to make that environment suitable, but for most of them it's perfectly okay.
In some cases, I found the developer workflow was actually smoother and better than the equivalent activities with an IDE (for instance Scala, Clojure, Ruby, and COBOL). In others, a specialized IDE really is better even if it's possible to manage without one (for example, Java/Groovy, R, and specialized things like Arduino, Android, and iOS development). I also didn't have great luck with the Lisp-like languages using just NeoVim, but it wasn't a show-stopper. .NET development feels about the same as using VSCode. Markup languages like HTML and CSS and supersets like Haml and Sass feel about the same as Sublime Text (and I mean that in a good way).
I'm an oldtimer, so I didn't have to go through what you describe in the second half of your article, and as a TDD practitioner I rarely have to resort to a debugger. I can imagine people who learned to program with an IDE might not really know what's going on under the covers, and would have to backtrack a bit to pick up that info. I've noticed a lot of programmers aren't really sure which functions are part of the language and which are part of the IDE. But I'm sure they can learn that fairly quickly.
IDEs are perfectly good tools as long as we use them as conveniences and not as crutches. In many cases, they aren't really all that helpful.
Funny, I avoided IDEs for years because I typically don't like kitchen sink solutions. I normally prefer light and fast. But a few months ago I switched to VS Code after starting to work with TypeScript, Golang, and Webpack 4. And I've been thrilled with the setup and centralized tools like git, GitHub, terminals, multipane views, and much more. Not without it's occasional headache. But, overall, it's made me better and more productive.
But... VS Code is not an IDE.
True. I guess I was thinking about feature heavy editors. 🙂
Same here, moved from Intelij, to subline, to Atom and finally settled on VSCode. What i realized I was just using a small subset of features on Intelij and was going into feature overload trying to memorize hotkey combination. VScode come with a basic code editor tool and allows me to customize development enviroment. Beside, the majority of my work is done by the browser dev tools and npm/nodejs scripts.
I find the tendency to stick with an IDE relates most to the use of a single language or framework at a job. As you start mixing languages, environments, and tools, the IDE becomes more of a burden than a help.
Agree. In the academic context we worked only with one IDE when working with a language. Kept things fairly smooth going.
From my experience IDEs have previously slowed me down only because for the longest time I only used them as cumbersome, glorified text editors with intellisense. For anyone thinking about dropping their IDE because it slows them down, I'd recommend actually taking some time to learn about what your IDE can do for you if you use it to the fullest. They are the tools of our trade and learning their efficient use is absolutely worth investing some time in. For me the IDE I use is a time saver.
I like developing on lower-end machines, so IDEs are a no-go. I was a beginner and my first programming language was Java, while using Eclipse. Thing is, when I hit that 'play' button I never knew what was going behind the scenes. Once I dropped the IDE (and changing to linux might have helped for that matter) I had to read up about what was going on: compiling to bytecode / jar, call the command
javaon that jar... and that clarity was such a bliss to be honest. Unless I am developing for Android, I don't see why I'd use an IDE (I'm not prescribing to anyone, it's just my own case). I like writing setup scripts anyway 😊Why on earth do you like developing on lower-end machines?