OverOpsAbout 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
