With a title like the one above, you may be expecting a rant from an IDE bigot. I know there are plenty of flame wars on this topic, on both sides, and if I raised your hackles (or whet your appetite), I’m sorry.

This is not that kind of post. For one thing, I don’t take myself so seriously:

There’s a keystroke for that! Image credit: xkcd.com

What I’m hoping to do here is point out some subtleties to this debate that don’t get a lot of airtime, and explain to my supercharged-text-editor friends why I work the way I do. However, I also plan to write a companion to this post, explaining why you need to learn a tool in the vim/emacs category, and I’ll have plenty to say on that topic as well. Hopefully that buys me a few minutes of an open mind. :-)

From a distance

If you step back from the debate over IDEs vs. supercharged text editors, and squint to suppress the details, you’ll see that most exchanges on this topic look like this:

Variant 1

Variant 2

I tend to roll my eyes at conversational threads like these, because:

Those who are really proficient in one of these environments, but not the other, usually overestimate the feature disparity.

This cuts both ways. All you vim experts, did you know that IDE black-belts slice and dice text as quickly as you, that they compile and debug with the keyboard, and that they have very powerful macro capabilities like the ones you love? All you IDE lovers, did you know vim and emacs can do tabs and outline collapsing and go-to-declaration and cross-project refactoring? If it’s a question of power, and if we’re talking about what’s possible rather than what’s standard, then I think it’s six of one, half dozen of the other.

The shared assumption–that feature richness is the right yardstick for comparison–is wrong.

Theoretical power isn’t very interesting. Most of us use only 10% of what either toolset offers.

But more importantly…

Observation 1: It’s not about you.

As I plan to discuss at length in a different post, software engineering is a team sport. Yet if you look at the argument templates above, you won’t see much focus on teamwork.

We probably don’t notice this misalignment because we assume that what’s best for individual team members is best for the team as a whole. Often, this is true–but there are important counterexamples. John Stockton scored less points than he might have, because he was superb at dishing out assists to Karl Malone. Would a higher-scoring John Stockton have been better for the Utah Jazz? I think not. It was team points, not individual points, that Stockton optimized.

In programming, optimizing your own work while disregarding the habits, expectations, skills, and needs of others on your team might be a bad tradeoff. If you pick a coding standard that’s vim-friendly, but half the team is using an editor that can’t emulate it well, have you been smart? If your IntelliJ wizardry leaves your buddy in the dust during pair programming, have you transferred knowledge as effectively as you should? If you despise doc comments because you have no use for hover text in emacs, but half your team uses eclipse, are you playing nice? If you use a refactor wizard all the time, but it drastically bloats the diffs on a maintenance branch, are you really boosting team productivity as much as you think?

I think that this observation weakens arguments on both sides of the debate, but on balance, it undermines the supercharged text editor crowd more. No two emacs gurus configure their environment the same way, and souping up the out-of-the-box editor is usually a labor of love for the fan. Go read all the web pages that discuss how to customize vim or emacs, and then tell me I’m wrong. Unless your whole team is cut from identical cloth, you’re more likely to have more in common, and to have a higher level of out-of-the-box functionality, with an IDE.

Don’t forget the impact of the broader community in your calculations about team value. You can absolutely write java code efficiently in emacs or vim–but the vast majority of java developers use Eclipse or NetBeans or IntelliJ. Why? What does this buy them? Well, their IDEs are constantly educating them about the latest and greatest thinking in the community. When Java 7 or 8 comes out, their IDE nags them to update. Help topics get refreshed. New samples, new project templates, new static code analysis features just show up. And the programmers learn, just by the nature of their toolset. Plus, their skillsets are more likely to transfer, to generate useful help for others on StackOverflow, and to be honed by others, if they’re in the mainstream.

A programmer who’s continually learning, and who’s plugged in to community best practice, is likely to contribute more value to his or her team, over time, than one who’s learned an efficient way to work and isn’t interested in newfangled ideas. All other things being equal, of course.

A final thought about teamwork: consider the rising generation. In my experience, most young programmers leave school with more comfort in IDEs than in text editors. Since young programmers are continuously arriving, the value of working within their world view is worth pondering.

Observation 2: Software engineering ain’t just coding

Besides reading, writing, and debugging code, what do you have to do to release software? If your world is like mine, you have to:

• make install scripts
• configure continuous integration, build promotion, and deployment mechanisms
• model people and their behaviors
• create and update database and XSD schemas
• design multimedia collateral like icons, sound, color palettes, and video
• encrypt and decrypt license files
• write, run, and re-run unit and integration tests
• generate and consume XML, JSON, and YAML
• tweak CSS and XSLT transforms
• fire up virtual machines in private or public clouds
• feed content to tech writers
• create animations and other visual behaviors
• interface with translation memories and localizers
• react to bug reports from static code analysis tools
• push bugs and enhancement requests through their lifecycle in a ticketing system
• update a wiki

… and on and on.

You can certainly live and thrive in that complex world if you’re a fan of a powerful text editor. However, I’ve come to believe that a text-editor-centric worldview is a little too comfortable thinking of every problem as a series of discrete editing tasks. Integration details fall through the cracks; mental models remain simplistic. After all, the tool you’re using bills itself as an editor, not an “integrated development environment.” Isn’t that suggestive?

The greatest advocates of unit testing, continuous integration, refactoring, and best practice that I have known in my career have all been IDE proponents. Most (but not all) of the best system thinkers I know are IDE-centric, as well.

I don’t think this is an accident.

IDEs show you a gestalt; they encourage you to think holistically about what you’re doing. If you write a method, and you don’t like the hover text that pops up to coach you when you call it later, then you are incented to change the doc comment for it, then and there–because the IDE integrates the whole experience. If you rename a method, and 7 red regions suddenly appear along the scrollbar for your file, you learn immediately how much you’ve broken. If you tweak the model in an MVC architecture, and the IDE is displaying the ER diagram and the table layout from the backing DB in a callout below your edit window, you are more likely to remember to make a complementary edit in that other layer at the same time. You are more likely to care about test coverage if your tool of choice tells you how you’re doing, constantly.

Where I’m at

If you peruse my archives, you’ll see that I’m a pragmatist. I use IDEs as often as I can, but I’m willing to drop into vim when it makes sense. I speak passable vim, but it’s not my first language.

I have no doubt that some of the folks who read this post will be awesome team players, great gestalters, and hard-core text editor gurus, all at the same time. That’s a cool combination of skill/personality, and I know it’s possible to achieve. And if you’re there, and you’re well into your career, maybe staying there makes sense.

However, what I’m suggesting is that on balance, for most engineers, the usual tool of choice ought to be an IDE instead–specifically, an IDE that other team members and the larger community use and like. This choice will pay off in enhanced teamwork benefits, and it will encourage the sort of broad, integrated thinking that characterizes the best software efforts.

Right now, I actively participate in half a dozen codebases. Some consist of venerable, unix-style C; one is cutting-edge C++11; others are in java or python. The teams that maintain the older code cut their teeth on vim and gdb, and they still mostly live there. I wish I could convince them to try out IDE-land for a while; I think they’d find it easier to generate momentum on unit tests, to eliminate fear of ambitious refactors, and to see their way past nagging tech debt. However, bigger concerns have kept me from pushing them hard in that direction.

Maybe this blog post will move the needle. :-)

As I’ve worked on developing my new programming language, I’ve given a lot of thought to how I can add value to the user experience of a software engineer. I’ve got some exciting ideas that I’m eager to share. Much of what’s possible is more likely to be realized in an IDE; where I’m headed, text editors won’t be enough.

My next blog post will be for the folks who live in the other codebases, and who may think that an IDE is all they’ll ever need. They have something to learn from the other worldview, as well…