The best IDE in the world

One of my most memorable experiences in software development occured to me eight years ago when I started working for Airbus. I was fresh out of college, all pumped up with my master’s degree in engineering. As a self-taught programmer, I had been swimming in code for 15 years prior but was still clueless about how to produce great, maintainable code. The main issue with someone that is overcome with pride is that it always finds itself faultless, rejecting any type of failure onto something or someone else. For me, 8 years ago, it was always Eclipse’s fault.

In an effort to reduce costs, Airbus started shifting their software development from Microsoft to the Java open source ecosystem. While familiar with C/C++ at the time, I only downloaded Eclipse for the very first time in 2006 at Airbus.

As an advocate of Microsoft products, Visual Studio was to me the pinacle of the IDEs, making the transition to Eclipse incredibly painful. It was slow: autocomplete would take multiple seconds, it would often freeze… The integration with Maven was never working. The layout was awkward. Spell-checking ON but line numbers OFF as defaults?! I was repulsed by it. Everything about it made me feel like it was created at the time when dinosaurs were still on the earth. I hated my job for having to use Eclipse. I was a miserable coder who knew deep inside that it was all Eclipse’s fault. I thought that things would get better with the days, but they didn’t. I kept dreaming about creating the site http://www.ihateeclipse.com/ three years before it was even born.

Two weeks had passed when a coworker passed by my desk and heard me curse at the IDE. He asked if he could help. I replied that nothing could be done: “Eclipse is just being a piece of *junk* once again.”, after which I engaged in a long 10 minutes rant about how awful Eclipse was, and how it diminished my abilities as a programmer.

He listened carefully and then asked if he could take a look. He picked up a chair and grabbed the keyboard. He started typing extremely fast, opening up the preferences, changing a bunch of options, tweaking memory usage, server settings, etc. His hands never left the keyboard. Everything on my computer, Eclipse included, seemed so fluid, so fast and so responsive. For each specific action, he knew the exact procedure, the right shortcut. The dialogs would open up and close within seconds. Within a few minutes, he had identified the issue, fixed it, tested it and commited the fix. As he left, he mentioned:

You know, Eclipse is just another tool… They are only as sharp as you decide them to be.

I was blown away. Back with my keyboard and mouse, Eclipse seemed slow again, but I knew that if I took the time to master it, it would become a powerful tool. Whenever I swang by my teammate’s desk, I noticed he was only using Emacs and a linux terminal. He had mastered these two tools to perfection and was faster at producing efficient code using them than through other tools.

With the years, I have come to master a small number of tools. I know all the shortcuts in Photoshop, I am pretty fluent in Visual Studio, I have completely customized Eclipse, I have my own Sublime Text plugins and use hand-crafted extensions in Chrome. Just like learning to play an instrument, mastering any tool is hard and requires dedication and a lot of time. I have modified/treasured the tools in a way that they have become a part of me as a coder. With the years, I have come to the conclusion that one of the best ways to become a better coder is to learn to master the tools of the craft.

Even today, I read the debates about Eclipse vs Netbeans vs IntelliJ, about .Net vs Java, Rails vs Django vs Laravel, Mac vs PC, etc. Seeing a title such as the best \[insert any word here\] in the world is usually devoid of real information. To those who seek which tool is the best, just pick one that you feel good with, and go master it. Make it your own. Make it the best tool in the world.

36 Comments

Akash Agrawal says (October 14, 2014 at 5:35 am):

Well said! I have been at honing my vim skills and though I still feel like a noob, I can definitely say now I do things lot faster compared to 6 months back.

zerr says (October 14, 2014 at 8:05 am):

Dude, you’re missing one main point – it is not about extensibility BUT usability.
i.e. I don’t want to spend months for fine tuning IDE – it should be mostly great out of the box. C++: MSVC + Visual Assist. C#: MSVC [+Resharper], etc..
So no, I don’t want to spend time writing my plugins for sublime, emacs, etc…

Nicolas Bize says (October 14, 2014 at 8:12 am):

Well, most famous tools today are pretty much great out of the box I think. I’ve worked with IntelliJ, Eclipse and Netbeans and I find all 3 great, customizable tools. I took a lot of time making Eclipse my home but I think I could have done the same with any other editor. For C#, there are not that many options: MonoDevelop and Visual Studio + Reshaper. But still, you could use Visual Studio + Reshaper out of the box and still be 5 times less efficient than someone who has mastered the tool inside out. So it’s not so much about the tool than about what you make of it.
You’re stating ST as an example. Aren’t you using any plugins? Have you ever opened the package explorer and installed custom things? Sure I’m efficient with an out-of-the-box Sublime. But I become a ninja with my own Sublime with all of its plugins, snippets, macros. 🙂
Thanks for reading!

zerr says (October 14, 2014 at 8:46 am):

I mentioned Sublime as an example of highly customizable editor, but you’re right. It is mostly a good editor with more or less good enough existing plugins.

zerr says (October 14, 2014 at 8:48 am):

EDIT: But SlickEdit seems much polished to me 😉

Paul Davis says (October 14, 2014 at 12:21 pm):

I work in Aero at BAE (Mostly Boeing Commercial) and I was showing a college some regex magic to do a complicated replace in Sublime Text 3 just yesterday and it blew her mind. I did not use anything but Cnt-H with an out of the box setup (some downloaded packages). I have not come across another editor I like that can do multiline regular expression block replacements. I use multiple editors depending on what I am doing but I find I reach for Sublime more and more. I have been doing development for 10 years and I am amazed at the power of Sublime to do “text” editing.

Nicolas Bize says (October 14, 2014 at 1:54 pm):

Such a great and simple example of taking things one step further with sublime!! Thanks 🙂

Stephen Johnston says (October 14, 2014 at 11:46 pm):

Which is great, and you will do this once every two years or you have some other really weird stuff going on with your code. I’m always amazed when people talk about how awesome an IDE based on some esoteric aspect. I have awesome command line tools that can easily do one off search and replaces in a code base. I recently started using PHPStorm for PHP development and I was amazed at the number of features it had related to things I do every day even simple things like highlighting unused variables.

Jake says (October 14, 2014 at 8:18 pm):

“Lots of options” is not a good thing on itself, if all the options suck.
The 3 Java IDEs suck equally, when compared to Visual Studio.

Mikael says (October 14, 2014 at 9:41 am):

This is such a terrible view.
The problem with “mastering the tool” is that the lifetime of the tool is unknown and translatability of the knowledge is equally uncertain. Becoming an expert of tools essentially means that you have invested excessive amounts of time learning this tool rather than learning some deeper knowledge (i.e. better software design principles).
This is of course more a matter of shades of grey rather than black or white. For example, programming languages disappear as well but you have to use at least one. The difference is that a solid computer science education enables you to learn any programming language, and it should not take more than a month of full time programming until you are productive in a new language.
Knowledge of emacs does however not translate to neither vim nor eclipse and vice versa. The same can be said of photoshop, paint and maya. Latex and Word are thoroughly different.
Overinvesting time in learning these tools is a real personal risk. Yes, of course it makes perfect sense to become better at the tools we use to produce but to go from that statement to claiming we should just accept any tool and “master” it. The advice should be to reject any tool that requires you to master it in order to be productive.

Marten says (October 14, 2014 at 3:13 pm):

I so disagree. How can you be productive without hotkeys?
Answer: you can’t. And learning like 20-30 hotkeys makes ALL the difference. And that; unfortunately takes time.
The good news? You make all that time back once you master it. I knew this already, but I got it confirmed to myself when I picked up VIM, and used a few months to become fairly accomplished in it.

Marten says (October 14, 2014 at 3:15 pm):

PS: For Java Developers who need Eclipse’s refactor tools AND want Vim bindings, there is a nice plugin for eclipse called VRapper.
It boosted my productivity by at least 25%

Mike S. says (October 14, 2014 at 6:23 pm):

“Becoming an expert of tools essentially means that you have invested excessive amounts of time learning this tool rather than learning some deeper knowledge (i.e. better software design principles).”
In my experience, it takes a few hours a day for less than a week to become pretty fast with most tools. The productivity boost pays for itself within two months. So even if everything I learn about Vim/Eclipse/NetBeans/gEdit becomes useless within a year, it’s still worth my time.

Hasen el Judy says (October 14, 2014 at 7:36 pm):

@Mikael: you’re expressing a very limited view. You can’t be a great craftsman without mastering your tools. Good tools are extensible, and timeless. Vim is what now, 30 years old? People still use it, and still learn it! I learned vim about 5 years ago, and have been using it (very happily) as my main text editor ever since.
If your tools change every 4 months, you’re doing something wrong.
You might as well refuse to learn any programming language deeply because languages “keep changing” and “new languages keep popping up”.

Taylor says (October 14, 2014 at 2:41 pm):
I will share your story with the world, my friend. This should be read in every introductory Programming / Computer Science course IMO. In hindsight, the level of technological bigotry that exists in the software realm is unbelievable. We should master what we like, and appreciate others expertise instead of criticizing their choices.
Though, it already seems that the frenetic people that you are referring to have already jumped on the opportunity to tell you why you are wrong.

Alec Larson says (October 14, 2014 at 3:00 pm):

What a bullshit excuse for shitty software.

Nitin Dahyabhai says (October 14, 2014 at 3:26 pm):

If that were the case, simply reconfiguring it wouldn’t make a positive difference.

Hasen el Judy says (October 15, 2014 at 10:54 am):

@Alec: it’s actually quite the opposite: it’s about stopping to make excuses (e.g. “crappy software”) and learning to use what you have to the utmost.

R Madala says (October 14, 2014 at 3:47 pm):

It’s surprising to note that even large companies such as Airbus are thinking about cost reduction and favoring, open-source software, which can have potential vulnerabilities, which a malicious user can easily exploit.

michael says (October 14, 2014 at 5:46 pm):

Are you aware of the phrase, “security through obscurity” and why its not an effective form of security?

Monsto says (October 14, 2014 at 5:55 pm):

This is exactly right.
On reddit, when someone re-asks the regular question “what’s the best text editor?” I invariably answer “the one that doesn’t get in your way”.
If you can code like a demon on crack in notepad, then notepad is the best text editor for you.
Conversely, if you assigned an editor, then you better make it work for you.I mean if you have no choice and you’re stuck rowing a boat in the rain, then you better figure out how to row that boat the best you can. Complaining about the rain doesn’t get the rowing done.

A_person says (October 14, 2014 at 6:06 pm):

I suppose, with enough effort, you can learn to make a VW bug drive like a Ferrari.
It would probably be easier to start out with a Ferrari.

Hasen el Judy says (October 15, 2014 at 10:55 am):

Is the “Ferrari” actually easy to drive?

Jake says (October 14, 2014 at 8:23 pm):

Guess what, you can write an IDE from scratch, and even design a programming language from scratch, “to make it your own”.
I guess no one has the means to do that, so a logical person will seek the best tool already available at the market.
You don’t grow your own wheat, right? You don’t have your own power station, correct?
Software tools are no different. Chose the already best, and further customize it to your needs.
But guess what, there is a best, given certain needs and prerequisites. There are tools which are better than others for any given task.

Guido Contreras Woda says (October 14, 2014 at 10:51 pm):

I’ll adhere to the grey area described in some comments.
I understand that most of us SHOULD be familiar with shortcuts and productivity “boosters” like macros and boilerplate generators. But most of the time, this repetitive work should let us know that we’re missing some key refactoring to lower our copy-paste activity.
I worry about programmers that feel productivity is typing fast. Usually problems take 80% of thinking time and 20% of typing time.
I’d rather follow Pareto’s rule on this one.

Lee Hanxue says (October 15, 2014 at 3:47 am):

Thanks for taking the time and sharing this gem, Nicolas. You are quite right, there will never be a perfect OS/IDE/programming language, and it is down to each of us to make it as effective as possible.

Amit Chootiya says (October 15, 2014 at 10:05 am):

Interesting point.

some r says (October 15, 2014 at 3:32 pm):

I came here expexting something like… Best browser is… But found a conclusion i could agree with 🙂
Lovely post, enjoyed reading it !

Henry Sampson says (October 16, 2014 at 9:02 am):

Totally agree! This summarized the debate on tools well.

Vishal says (February 11, 2015 at 3:39 pm):

Very well said.
I totally agree, that instead of spending more time on which tool is better, I should spend more time improving my skills with the tool that I use.
Thank you very much. 😀

B.A says (March 25, 2015 at 4:02 pm):

A Fool with a Tool is Still a Fool

Rick Cogley says (March 24, 2016 at 4:35 am):

Good article. I agree with the idea of focus on specific tools. It does not take too long to learn a set of keyboard shortcuts, and, I’ve got a ton of scripts I created a long, long time ago, which are still useful today.
Sometimes it’s indeed irritating when a tool goes out of fashion or dies from lack of developer support, or perhaps due to the company selling it going bankrupt.

A.Smirnov says (April 22, 2016 at 5:02 am):

All I read is the coAll I read was comparison between hammering a nail with a Rock and a Hammer. While stating that you can achieve the same result with rock. Indeed you can, but regardless you will have higher failure state with it, then with hammer.

Patrick Günther says (January 4, 2017 at 1:33 pm):

So how does one teach eclipse not to validate the contents of node_modules folders. There are like 5 different places in the preferences where you can exclude these but eclipse still gets stuck parsing and validating the contents of node_modules.

Nicolas Bize says (January 4, 2017 at 6:08 pm):

@Patrick try to mark the folder as derived. (I think it’s PackageExplorer>Select Folder, ⌘+I to bring up properties, check Derived attribute)

ikk says (December 8, 2017 at 1:26 pm):

Why don’t you tell us what are those magic settings that make Eclipse good?
Where is the setting for “Stop freezing ramdomly”?
Where is the setting for “Stop giving errors when importing projects that I know for sure that Maven accepts”?
Where is the setting for “Scroll wheel scrolls the pane under it”?
Where is the setting for “Don’t show errors until you are damn sure they really exist”? I’m tired of trying to fix things that magically work after a clean rebuild or in a clean workspace.

Comments are now closed

dark
sans