Why You Shouldn’t Always Use an IDE
IDEs make your life much easier — until they don’t
An integrated development environment, or IDE for short, is a tool that helps you write code. They support many features like debugging, code completion, syntax highlighting, build automation, refactoring, version control, and much more. However, using an IDE during development might not always be the best choice — especially if you’re just starting out.
Before we dive into the reasons not to use an IDE, let me get one thing straight. I love IDEs (especially the ones from JetBrains), pay a lot of money for them, and use them on a daily basis. They make my life much easier and help me code faster.
However, when I started coding over a decade ago, I started doing so in very basic text editors (after really struggling with some IDEs). This really helped me become the developer I am today. So, let’s dive into the reasons why you shouldn’t be using an IDE!
Language and Framework Understanding
IDEs are amazing at supporting you while you write code. However, if you’re working in a programming language or framework that you’re not that familiar with, an IDE might autocomplete your code before you even know what you’re writing. This way, you won’t completely understand what you’re doing, perhaps only the result you’re achieving.
If you don’t have the autocomplete functionality of an IDE, you are forced to read documentation, inspect logs and error messages, and thus, gain a thorough understanding of the programming language or framework you’re working in. This massively helps you understand how a language or framework operates, and how you can use it to your advantage — instead of fighting against the language or framework with an IDE as your sword.
Too Much, Too Soon
If you’re embarking on the journey of learning to develop in a new language or framework, you first have to start with the basics. However, an IDE offers a lot of complex options like code snippets, autocompletion, smart refactoring, and other options that take over your control of the code. By utilizing all these complex features, you might dive into the deep end of the pool before you’ve learned how to properly swim by using complex features you’d see much later otherwise.
Instead, focus on learning the basics of the language or framework you’re working in and build on that knowledge. When I tried to create one of my very first websites in HTML, I started out by drag-and-dropping some elements in Dreamweaver. However, after some time, I struggled with aligning an image. As I was only using the visual editor, I lacked the proper knowledge about the underlying HTML to fix this issue, and I was completely baffled by the generated code.
Defeated, I started the same project again, but this time writing the HTML code myself. Not only did I learn much more this time around, but I was also able to completely avoid the issues I was having before. So, don’t rely on an IDE to help you out with the features of a language when you’re starting out. First, try it yourself, and only after you’ve explored the depths of the language, rely on an IDE to take care of the heavy lifting.
IDEs Are Fat Cats
IDEs are incredibly extensive tools: they analyze your code while you’re writing it, they are able to know about every class, function, and variable in your codebase, they help out by running a debugger, and they keep track of changed files and much more. As you might expect, this can consume a lot of resources.
If you’re working on a system with limited resources, your precious resources are probably already being consumed by the dozens of browser tabs you opened to research the language or framework you’re exploring. This might leave little resources for the backend processes that are powering your IDE, leading to sluggish performance and a lot of irritation during your first steps into a new world. Exploring a new language or framework can be daunting enough. Having to struggle with a slow work environment might be the straw that breaks the camel's back, making you turn your back on developing.
A Hidden Build Process
Building an application from source code can be a complex process. An IDE can take care of this complex process for you, giving you the time to focus on the development of your application. However, if you’re planning on deploying your application to some kind of server or application store, you’re probably going to have to take some steps that your editor cannot take for you.
Therefore, knowing how to take the steps required to build your application is a very powerful tool in your toolbox of knowledge. Learn about dependencies, build chains, Makefiles, compilers, optimizations, flags, and whatever else is required to build the application in the language or framework you’ve chosen to dive into. This way you’ll learn about the complex series of steps the IDE takes for you, and you have a better understanding of what to do when your IDE lets you down.
IDEs Can Direct You Down the Wrong Path
Quick fixes aren’t always the right fixes. Just because your IDE might advise or urge you to fix a problem by renaming a variable, moving code around, or placing a class in a new namespace, doesn’t mean that this is the right solution for the problems you’re seeing in your project.
When you apply the simple fixes as suggested by your IDE, it might even break your application further. The issue in your project might be related to your business logic or data storage, and your IDE might have no knowledge of this.
If you rely on your IDE to fix errors in your code for you, you might be led to believe that a simple fix in your code will solve your issues, even though greater problems might be parting your codebase. Before relying on your IDE to fix your issues, you should understand what could be the cause of them and know how to fix them yourself.
Your IDE Might Not Understand Your Project
IDEs do an amazing job at understanding your codebase — as long as you’re somewhat adhering to the standards of the language or framework. If you’re coding a simple application, and you just want to try out some features, an IDE might annoy you by not understanding the structure of the project you’re setting up.
Of course, you should adhere to coding standards moving forward. But when you’re just starting out with a new language or framework, it’s hard enough already to keep all requirements in mind without having to deal with an IDE that’s continuously shouting at you to restructure your code.
And even if you’re aware of all industry standards, you might have some reasons not to adhere to them.
At my previous employer, I was presented with a codebase that wasn’t really up to industry standards. Therefore, trying to use an IDE on this codebase caused more irritation than it did good: it was continuously telling me called functions did not exist, autocomplete did not work, and it tried to fix code that was up to standards of the company. Using an IDE on this codebase was like rowing against the tide and made my job much harder than it had to be.
Conclusion
Let’s conclude by being honest. If you’re writing code semi-professionally, you probably have more reasons to use an IDE than reasons not to. As I said before, I use one every single day, and I’d probably go insane if I was only allowed to use regular text editors.
But if you take anything away from this story, it should be that you should be aware of all the complex tasks that an IDE handles for you — not only so you know what to do when your IDE fails or is not available, but also to be thankful that you don’t have to worry about these complex tasks day in and day out, so you can focus on staying sane.
Happy coding!
