Why you should be proficient in a tool like vim or emacs

In my last post, I pointed out two little-discussed reasons why I think most engineers should spend most of their time in an IDE.

I knew I was venturing into the realm of religious wars to make such a claim. When I shared the post, the first comment I got was, “Do you have a death wish?” :-) I had to laugh.

Religious wars aren't pretty. "The Second Crusaders Encounter the Remains of the First Crusaders", by Gustav Dore (wikipaintings.org)

Religious wars: not so pretty. “The Second Crusaders Encounter the Remains of the First Crusaders”, by Gustav Dore (wikipaintings.org)

It turns out that my experience with the ensuing comments has been quite positive. Plenty of people disagreed with me, which is fine. I’ve heard good arguments from many different perspectives, which is part of the reason why I blog and post on social media in the first place; I need to be pushed. I hope my assertions about teamwork and gestalt were at least interesting.

Now, I promised that I’d write a follow-up post about the flip side of my advice. This isn’t because I can’t make up my mind; it’s because I see these two toolings as complements with some overlap rather than symmetrical alternatives.

So today, I’m going to try to convince all the IDE zealots in the world that they’re doing themselves and their teammates a disservice if they don’t take the time to become proficient in a powerful text editor.

Death wish part 2. :-) Continue reading

Why you should use an IDE instead of vim or emacs

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: Continue reading

// Comments on Comments

/*

We spend little or no time teaching programmers how to write good comments.

This is surprising, when you consider how often “total lack of comments” or “poor comments” are cited as evidence that certain modules (or the programmer who wrote them) are the worst thing that ever happened to the technoverse.

Comments shouldn’t leave you–or anybody else–mystified. :-) Image credit: xkcd

I happen to think that there are much yuckier tech things than poor or missing comments in code. But I still think our general level of comment proficiency is lower than it should be.

Here is my attempt to raise the bar a little.

Why We Comment

Sooner or later, most interesting programming problems require a sophisticated mental model of a problem. Building these models is hard work, and once we have them, we are paid to share with our team (or our future selves).

The best way to share mental models with other engineers is Continue reading