The philosophy of IDEs

Back when I was your age, things were different. That is, of course, unless we are the same age, in which case everything was the same. We didn’t have the internet. When we wanted to learn new coding languages and techniques or understand the history of our craft, we were required to take a sacred pilgrimage. One year, I smuggled in a Polaroid. You can see the pictures I took in Figure 1.3. You should understand that all of what I am about to tell you is both true and a closely guarded industry secret. Just so we’re clear, you didn’t hear this from me.

Hidden somewhere in a mystic range of mountains, seekers of great coding wisdom would ascend the 10,000 stairs by the light of the full moon in search of the Master. The journey was not easy, and the wisdom imparted had to be hard-earned. It was on one such crusade that I learned why good IDEs are so important. The Master said, “If you know the language, and you know the IDE, you need not fear the result of a hundred deployments.”

Figure 1.3: High in the sacred mountains, up the 10,000 stairs, lies the monastery where I learned to code

The Master often speaks in riddles, so let me explain. Deployment refers to a published iteration or an increment of your software. In most professional circumstances, the objective is to publish your software. If our objective is to publish, the next sticking point is that we must know a programming language. I assume you have at least a tacit understanding of programming in Python. That just leaves the Master’s reference to the IDE.

There are several classes of tools a developer might use to develop Python code. The Python language can be considered an interpreted language. We could argue that when it runs, some of the code is optimized into C code and cached, but at this stage, we aren’t worried about that level of detail. The point is that a Python program exists as simple plain text files and can be executed in that form. Contrast this with statically compiled languages such as C, C++, C#, Java, or Go. Those and many other languages require the code in the text files to undergo a compilation phase where a new executable file is produced. In C#, you can’t simply execute a .cs file. You need to compile it into a binary, then execute the binary. Since Python executes its code directly via the Python interpreter, the level of tooling needed to work on Python can be very simple. Essentially, any text editor will do. There are three levels of editor capability to choose from.

The first is a simple text editor. Simple text editors are generally limited to opening, editing, and saving text. They are generic tools designed to work with any kind of text file, from grocery lists to systemd configurations. In Windows, you might know it as Notepad. On a Mac, you might use TextPad, and if you are rocking a Linux desktop such as Ubuntu, you’ll easily find Text Editor. If you are not a fan of GUIs on your OS, then you have no doubt heard of editors such as vi, vim (vi improved), Emacs, and nano. All these programs fall into the category of simple text editors. If you’re not sure what a systemd configuration is, don’t sweat it; it’s a system administration file on Linux. I just needed something that sounded complicated to characterize the more complex end of the text file gamut.

The second evolution of programming editors is called enhanced editors. These editors are purposefully designed to work with technical files. Some popular examples include the following:

• Visual Studio Code
• Atom
• Notepad++
• UltraEdit
• Sublime Text
• JetBrains Fleet
• Bluefish Editor
• IDLE (the editor that ships with Python)

These tools are designed to work with a wide range of programming languages and can generally be easily customized to add support for emerging languages. Enhanced editors offer some common features that make a developer’s life a little nicer, such as these:

• Syntax highlighting, which color codes keywords and other semantic elements in your code.
• Macros, which allow the developer to record and play back common keystrokes
• Project and file organization to allow easy switching between multiple files that make up a project
• Rudimentary code completion to reduce the amount of typing needed to write your code
• Plugin support for other niceties such as linters, spell checkers, file previews for your code, and more

Over time, some of these enhanced editors have become very robust because you can customize and expand their capabilities. When you consider these tools as they are right out of the box, they are more useful and specialized than general text editors, but they fall short of qualifying as IDEs.

At the top of the code editor food chain is the IDE. If you were to look inside the cockpit of a fighter plane from the World War I era, you’d see a few simple controls and nothing more. If that’s a text editor, the IDE is the cockpit of a Boeing 747 aircraft. Every tool a developer could ever desire or need is crammed into a comparably complex UI. IDEs contain all the features of an enhanced text editor, but usually offer the following additional enhancements:

• Some easy ways to run your code right from the editor.
• Tooling to help manage your source code repository, such as Git or Subversion.
• An integrated, easy-to-use debugger, which allows you to pause the execution of a running program and inspect or alter its current state.
• Tools to help you write automated tests such as unit tests and run and visualize the results.
• Complex code completion is based on the introspection or indexing of the code in your project. In modern IDEs, this is enhanced using artificial intelligence (AI).
• Profiling tools to help you find execution bottlenecks.
• Integrated tooling to help with supplementary systems, such as databases.
• Tools for deploying your code to a server or cloud environment right from the IDE.

Some popular examples of IDEs include the following:

• Visual Studio (this is different from Visual Studio Code)
• PyCharm
• IntelliJ IDEA
• NetBeans
• Apple Xcode
• Xamarin Studio
• Eclipse

As you can see, the IDE is the most powerful weapon in your coding arsenal. It is important to use the best one available to you. If you are new to software development, or maybe even not-so-new, you might wonder why the enhanced editors are so popular. At the time of writing, roughly 50% of developers use Visual Studio Code, which is not on my list of IDEs.

Many developers prefer a more “lightweight” development environment. This is especially true of frontend web developers who swear by Sublime Text and Visual Studio Code. In truth, they need all the features of the IDE, and they use them, but they are spread out across different tools they use throughout the day. A frontend developer relies on profilers and debuggers that run in web browsers and they don’t need those tools in an IDE. Instead, they can get a simpler editor that downloads quickly, installs simply, and runs instantly when they click the icon in their OS.

I submit that if you are doing full stack web development or mobile development, or you need to work servers or containers, an IDE is a better choice.

There exists a certain class of software developer who swears you should never use anything other than the simplest possible tools. They believe that reliance on a tool to do coding and related hard work diminishes the overall mastery and accomplishment needed to be considered proficient. I couldn’t disagree more. One year, while at the monastery, the Master told me a story of a great swordsman from Japan named Miyamoto Musashi. In his day, every samurai knew of Musashi as the greatest living swordsman and all the samurai wanted to take a shot at defeating him. Back then, duels were usually fought to the death. One day, a dueling challenger met Musashi as he was getting off a boat. Musashi was unarmed. The challenger waited until Musashi could fashion a wooden sword, called a bokken, from one of the boat’s oars, which he intended to use in the dual. Legend has it Musashi made a fool of that challenger and left him alive, much to the challenger’s disgrace. Musashi, the Master said, was the finest warrior who ever lived, and his skill with a sword has never since been matched. However, if the objective were simply to defeat him, I could have easily done so with a machine gun.

In my opinion, limiting the tools you use owing to a sense of pride in your capability, or lack thereof, is foolish. The objective of a software developer is to ship software, usually on an unforgiving deadline. It isn’t to waste time trying to prove yourself to someone else’s standards, unless, of course, you’re a degree-seeking student. I’m sure there are a few of you reading this book. Play the game and do what your professors say. You should realize that once you graduate, everything changes. You will be expected to produce code quickly, accurately, and consistently. This is best achieved via the automation available in a good IDE. You should choose the best tool for the job at hand. I found PyCharm helped me to become productive while I was learning the Python language. When you start, and you’re not using an editor that corrects your line spacing and indents, you’re going to make a lot of silly mistakes. It’s frustrating. I’d think to myself, “If I were using C#, I’d be done by now.” I was even tempted to abandon Python and PyCharm for something more comfortable. However, that’s not what I wanted to do.

PyCharm will underline all those silly mistakes for you and correct them with the touch of a button! I learned, after seeing those mistakes underlined over and over, what to do when I’m using an editor without code inspection. Today, when I am working in other languages, I still use Python rules. Having learned Python with the help of PyCharm, I was able to ship faster, learn faster, and improve my code in other languages and tools. Do me a favor and never let anybody tell you you’re not a real developer because you didn’t do something their way. If they persist, tell them nano is better than vi or Emacs, and just walk away. Such a statement will probably cause their head to explode.

I’d like to make one more comment about Visual Studio Code. This editor has evolved through plugins to the point where it can compete with a fully featured IDE. However, this comes at a cost compared to a professionally developed IDE such as PyCharm. To get the identical features you’d find in PyCharm in Visual Studio Code, you’d need to install a large number of plugins. These plugins are all written by the community, which means they are all independent development efforts. These plugins will never work as cohesively as the base features you will find in an IDE such as PyCharm. This is also true when comparing Visual Studio with Visual Studio Code. Try creating a C# project in Visual Studio versus Visual Studio Code and you’ll find the process is dreamy and smooth in Visual Studio. Visual Studio Code, on the other hand, requires a lot of command-line work and lots of weird plugin installations. The experience just isn’t the same. The same observation holds with other editors such as vim, which can be heavily customized. You’ll spend a week messing with plugins and open source scripts to achieve, at best, partial parity with an IDE’s out-of-the-box functionality.