Let’s stop telling programming newbies to learn Vim (or Emacs)

As readers of this blog know, I am a proud user of the third most baffling editor in existence. (Why third? well, I feel confident placing Vim as the 2nd, because while inscrutable, hand-twisting keybindings are difficult, in my observation modal editing is a slightly bigger mental leap for the programming newbie. The most serenely baffling editor of all is, of course, ed.)

I also spend quite a lot of time tutoring newbie programmers. One thing I do not advise them to do is to learn Emacs. Not right away, anyway. I have been guilty doing of that in the past; consider this my statement of repentance.

Here’s the thing: as I said, I pair with novice programmers pretty much every week. And I’ve come to realize that as a group, they are faced with a bewildering array of tools to learn. My typical tutoring student is trying to simultaneously master:

  • Ruby
  • Ruby on Rails
  • Assorted language mutts and DSLs like YAML, ERB, HAML, and SASS.
  • Git (the most powerful DVCS available, but also easily the most baffling from a UI point of view).
  • Z shell
  • RVM/RBenv
  • Homebrew
  • Vim

They are trying to learn all of these at once because they’ve picked up on the consensus opinion that these are all part of the best-in-class Ruby on Rails development toolchain. And they are right. But what they don’t see is that most of the people touting that toolchain learned it one piece at a time. In particular, most of the current crop of Vim users came to it after learning Ruby and Rails. Either that or long, long before.

I spend a lot of time watching novices trying to understand some core Ruby concept, and then get sidetracked by the fact that the editor just deleted five lines instead of inserting two characters. It’s hard enough learning a new (or first) programming language. It’s incredibly frustrating not being able to get the code that they think might be right onto the screen in a reliable fashion. It kills their forward momentum, and makes learning a new language a lot more of a drag than it should be.

By contrast, lately I’ve also seen a number of newbies using Sublime Text 2, often the free nag-ware version. They are much less hampered by the combined programming language / editor learning curve. While Sublime Text is a powerful editor in its own right, you can use it like Notepad and still get by just fine.  Typing characters makes them appear on the screen, cut-copy-paste has the keybindings you’re familiar with, and if you can’t remember the keybinding for re-indenting text you can mouse to it in the menus.

As of now, my recommendation for someone new to Ruby and Rails is to start out with a basic, GUI-based text editor with traditional CUA keybindings. Examples include:

Note that while I also use RubyMine occasionally, I do not include it or any other IDEs in my list. IDEs pose their own barriers to understanding, by hiding a lot of the command-line invocation and directory navigation without which much of the development process remains “magic”.

Once a novice achieves a modicum of comfort and fluency with the language and framework, then I do recommend they learn at least one of the “big two” editors well. A good programmable editor will grow with you for the rest of your career, multiplying your effectiveness as a developer. Yehuda Katz has a good article on making the transition to Vim without completely losing productivity; a similar approach is possible with Emacs.

But please, let’s stop telling total novices they should immediately learn (Emacs|Vim) because it’s oh so powerful and superior. It’s just one new tool too many.


  1. I’ve stopped telling other programmers at work to try Vim, even the experienced ones. I realized that it was a personal preference that I was trying to push on them. Taking somebody out of their comfort zone is often a productivity drain until they’ve advanced past a few stumbling blocks.

    My new approach is to let them use whatever editor they like until they’re ready to transition, if ever. Productivity over peer pressure.
    Thanks for the post.

  2. Couldn’t agree more, although they need something that respects code better than notepad.

    I spent a fair amount of my youth as a musician. I played percussion instruments, mainly drum set, timpani, vibraphone, and marimba. Of course I knew kids that played trumpets, oboes, flutes, violins, and so on. When I went to college and majored in music, everyone was expected to take piano classes so that we all had a ‘common reference’ when we collaborated in our classes.

    This is how I view vim. the common reference everyone should have – available everywhere. Of course, some people play it as their main instrument, but most people know enough to be functional, playing something else most of the time.

  3. Hear hear!

    I’m sometimes challenged by the question: “So why should I learn Vim?” I never give the hard sell. If you have to ask, then you’re probably not ready.

  4. Personally, I would approach this slightly differently. First, I routinely let others pick the tools they like to use. I do my best to adapt to [what I feel are the useful and important parts of] their requirements rather than the other way around.

    But, also, I feel that if a person is going to be in an environment that provides ed, vim, emacs, or whatever, that there’s certain things they should know.

    First, it’s critically important that a person know how to exit the editor. In a unix terminal environment, this might be control-Z and then using kill to shut it down. In a windowing environment this might be knowing how to close the window. But, also, each editor has its own way to reliably exit it (ed: control-C Q Return usually works, vim: Escape : q ! Return usually works, emacs Control-G Control-G Control-X Control-C usually works). And, second there’s finding decent documentation on the editor (nowadays, google usually works plausibly well).

    After that, all a person needs to learn to use the editor is how to move within the document (for vim and emacs you are positioning the cursor, for ed you are selecting a line). how to change the file you are editing, and how to save your changes.

    That’s all a person needs to learn to start using an editor. Yes, there are many useful things an editor can do, but a person can learn those things over time, in any of a variety of ways.

    (Setting up a key (or whatever) to efficiently merge your current git branch so that it’s up-to-date, build/test the result and position the cursor on the location in the source that triggered the first failing test can be nice, but there’s a variety of ways of doing that and except for positioning the cursor none of that absolutely needs to involve the editor.)

    So, anyways, if a person wants to use an editor, and they express frustration, I usually try to make sure they have a basic reference sheet so that they can edit.

    But I feel that you should not turn capabilities into an obstacle. If you focus on what’s important it does not need to be hard.

    But, of course, this cuts both ways, and like you say there are a lot of editors out there that a person might want to use for any of a wide variety of reasons.

  5. The problem with that is this: software development is about exposure to new thinking. A Visually Studio guy at work was watching over my shoulder as I edited some code. He told me that he has never seen anything like it. Told him emacs is made for editing. He had never heard of it; that right never heard of emacs.

    I was lucky back in the day that I had to learn VI in order to do my labs assignments. And while I was bitching at my professor about how I just didn’t really get VI, he told me to try emacs. He printed out a reference card and said go!

    So while I agree that trying to learn emacs while learning a language while learning a framework is death, learning emacs/vim/textmate/ is a good investment.

    I would show each newbie both emacs and Vim, and show them why they are good programming editors. While they both take an investment in time, your newbie will be exposed other views of computing.

  6. Thanks for writing this post. I have not learned lisp because every time I tried to do it, I had to wrestle with emacs first. This last time I just gave up on emacs and wrote code in my usual text editor, and suddenly it was easy and pleasurable to learn lisp.

    The text editor with syntax highlighting and auto indentation is all what the beginner needs. Those two actually do make learning the language easier.

  7. Does your typical novice student really attempt to learn/master that many concepts? Do you ever try to steer them to Sinatra or express.js?

    If I’m looking to cut down on concepts to learn, that’s where I would start, not the editor. I wouldn’t necessarily steer people to a power editor (your points about copy/paste are very valid), but I wouldn’t discourage it either. I would discourage a novice starting with Rails.

  8. I remember being a total beginner decades ago and being forced to use vi to write a simple program. It was truly traumatizing. It was not the right time or context in which to learn this editor. Later, I did learn vi (and even had a fancy .exrc file with macros), but then switched to emacs. That was a big switch, but I’ve used emacs since. I still use vi(m) in various contexts now. But for someone new to programming, mastering a complex text editor should not be the first step.

  9. YES. A newbie needs syntax highlighting and some form of automatic indentation (whether they know it or not). They need to be able to type code, edit code, and see it run. Beyond that, they need their editor to get out of their way. All other features of the editor are certainly less important than the getting a handle on the language(s) they are learning. At some point, after they’re comfortable with the basics of a useful set of languages, THEN it’s worth learning how to make their editor (and the rest of their toolset) more powerful.

  10. How do you do the trick in your screencasts of typing some code and then executing it with the output appearing as “# => …” comments at the end?

      1. The question is not related to the post, but I was wondering that as well. I know that “:r !ruby file.rb” will print the output in the current file, but not right next to the method alongside the comment.

  11. I agree with your post but your examples are vim-oriented. Emacs now comes with CUA shortcuts by default, you can use the mouse and there is a menu bar. You don’t have to use tricky key combinations if you don’t want to.

    1. I’m quite familiar with modern Emacs features, since I use Emacs 24 in GUI mode every day. CUA mode is bundled with Emacs, but it is not the default. And I hesitate to recommend it to newbies in any case. CUA bindings clash so fundamentally with standard Emacs bindings that there’s a lot of opportunity for confusion and surprise.

    1. It looks promising, but the playground wasn’t that exciting (maybe it would have been more exciting with a language I use) – the ui was non-standard (that’s ok, if it isn’t just new, but solves a problem), but otherwise I didn’t really see the benefits of it (I use PyCharm, and that has a “scratch” editor (aka the python interpreter) — it just has that drab, enterprise IDE appearance.

      I thought this guy had some good critique of the LT demos:


      1. Sorry, but Java is not Clojure.

        You cannot compare both, they are designed to have different usages.

        Must I remind you that is alpha?

        Eclipse is in 4.2 stable too.

        PyCharm it’s pretty amazing piece of work, but you cannot forget that it’s a change of concept, Chris is not saying: “HEY MY IDE ILL CRUSH YOU ALL” and just, try it, if you like it, keep it.

        It may be pretty easier than Eclipse + multiple plugins and stuff.

  12. “Text is a powerful editor in it’s own right,” => “Text is a powerful editor in it is own right,”

    Errors like this make an author look like a fool. So true.You are better.

  13. YES! Thank you for writing this! I’m currently learning C++, git, vim AND bioinformatics all at once! The freedom to not use vim would be so welcoming!

  14. Right. Because people should be building products which run on servers they don’t understand, and should become “productive” more quickly. Bullshit.

  15. Agreed.

    Now, what’s your stance on learning unix utilities / shell usage? I cut me teeth on csh over 20 years ago when I was a very young novice, at the time it was essential because that was your dialup Internet connection (ie. before PPP). These days you can get by without the shell, but I still find it to be one of the most powerful and essential tools. I think it’s more approachable than vim/emacs as well, but of course it still takes an extended effort over the course of years to really unlock the power. And once you start deploying serious production apps, I feel a lack of shell-fu seriously hampers the ability to deal with server-side issues.

    1. I’m 100% sure that the author is an Emacs user! because he knows that Vim has more users, so he is trying make both side users leave their editor and hence, more Vim users will leave! Victory is with us! Death to Emacs! #editor_wars, #kidding

  16. As a complete novice to programming I have to agree. Learning a foreign
    language is difficult enough and dealing with all the complexities of
    vim is a daunting task to grasp for a beginner such as myself. One can argue about
    practicing drills from say, https://www.shortcutfoo.com/ but all this
    just get’s in the way of actually understanding the concepts and
    intricacies of code. I’ve made the switch to ST2 not so long ago and
    honestly I don’t feel the pressure of remembering keystrokes as much
    because I’m not locked in by the learning curve of the tool. Because at the end of the day, a text editor is just a tool. Maybe I will learn to sharpen my tool skills with more serious editors such as vim or emacs down the stretch but for now I will stick to what is more important, “code.”

  17. I agree. Vim is a very practical tool. Problem is that it’s just not for everyone. I had a low skill protege beg me to teach him vim, but it just wasn’t working and he wouldn’t give up. I had to explicitly tell him to quit Vim and use something he was productive with, but would catch him struggling with it at his desk… he got fired eventually, but it was because he just didn’t have any practical skills. On the other hand, I had a very highly skilled protege learn vim simply because I made it look cool to him. Just make it look attractive, but never force the issue, and those who have it inside them to use it productively will just start using it. Sublime or whatever for the rest. 🙂

  18. Absolutely agree… just mentored a newbie today, and when asked “Should I learn Vim?” I told her absolutely not right now. And really, that was a reoccurring theme throughout the day. “Should I learn RSpec?” “Should I use FactoryGirl?” “Should I use a presenter?” I stressed that the more she can limit the amount of different things she is learning at one time, the better.

    There is an obsession (and I’m guilty of it from time to time, ok, often) with learning the best way to do something, and that includes tools. But we all need to walk before we can run. Take an hour max each day to learn a new best practice, and the rest of the day just focus on doing it anyway you can!

  19. The only essential Vim to learn as a newbie is how to open, edit, save, and quit in the context of a basic text file. The reason I say this is because Vim is probably going to be an available editor if a *nix install gets hosed up.

    1. No, ed will be available, and work if the terminal is messed up. vi (and i’m talking about The One True “vi” from Bill Joy here, not this sissy vim crap that allows arrow keys in insert mode) won’t.

      If you are responsible for a Real Computer, learn ed.
      If you want to be productive, learn an editor that you can grow with. Emacs and vi work once you’ve gotten over the initial issues.

      And, computer systems and users supplying and advocating “nano” or “pico” should be percussively educated.

  20. I just can’t believe that after years of being laughed at for preferring vi over IDEs, it is suddenly “cool” to use vim. How the world turns…

  21. I’ve been using vi/vim for 25 years and it kicks butt! Yes this “dates” me, but I remember when vi was the only editor that could open some of the files I worked on because of the size.

  22. As a newbie myself, I totally agree. I recently ventured into a Scala enthusiasts meet-up (while already being a junior-level Java developer, so not all that sage there either 😉 ) and was bombarded from every direction by totally unrelated issues, the most memorable being a 15 minute one-on-one presentation of “The One True Way.” I left with about 5 sites and 3 tutorials that my new, self-appointed guru insisted I complete (all on how to use Emacs) in order to even get started with scala… erm… sorry, maybe next year.

  23. I think it depends on how much frequent contact the newcomer is expected to have with an experienced developer and/or how much time the teacher is expecting to dedicate to the student. Vim is something I think is best taught in person over the course of days, not hours.

    In http://apprentice.io, most of our students learn vim once they arrive. They have likely come from a few months of Sublime Text or TextMate usage, Michael Hartl’s “Rails Tutorial” under their belt, and Google skills that include “[something] StackOverflow” and “[something] Railscast” and “[something] Github.”

    After a day or two of pairing, they have basic vim commands down, can enter and exit normal/insert/visual mode and get things done slowly. After a week or two, they’re just as productive as the ceiling they would have reached in Sublime Text or TextMate. After a month, they have built muscle memory in a lifelong skill that will outlast Rails and its family of tools we use today.

    That is a good fit for our goals. When the teacher knows they’re spending enough time in person with someone that they will be able to pick up best-in-class practices and tools (pretty much the list you mentioned plus Postgres), I’d heartily recommend using vim, and thereby learning it in the process.

  24. Honestly I think you probably should learn an editor before you learn various methodologies of text editing.. I.e. Programming, be it ruby, c, or html.

    In my opinion, if you like the feature set of Emacs or Vim, you should go ahead and start learning them.. It’s not like you need to learn 200 commands to get around in Emacs. If you spend 30 minutes learning the basics you’ll be fine and can learn the rest as curiousity strikes your fancy.. Your article makes it seem like a person needs to become a Emacs/Vim guru in order to use it. Much of the point of picking emacs, or perhaps to a slightly lesser degree Vim, is that ONE tool is all you really need for a variety of tasks.. Ultimately that means less to learn, not more. You might as well get started learning the one tool you will continue to use throughout your career for a variety of tasks. 30 minutes, that’s all it takes and you can edit with the same efficiency of Kate, Gedit, or notepad++.

    1. Yes, exactly. Good point! “30 minutes, that’s all it takes and you can edit with the same efficiency of Kate, Gedit, or notepad++.” and plus you have a lot more!

  25. I’ve used all of the aforementioned editors beyond the novice level, and although I’m currently a vim user, for beginners I have two recommendations that didn’t make the list. On Windows, Programmer’s Notepad strikes a beautiful balance between power and simplicity, with plenty of room to grow before you attack modal or quasi-modal editing.

    On Unix, I like Geany. Again, very simple to use from the start (although the menu structure isn’t quite up to PN’s), but with a lot of power to tap into as you grow.

    I agree with the sentiment of your post…learning this stuff from scratch all at once would be enough to put me off!

  26. I don’t know if I agree. I understand what you are trying to say, but what if you were working with something setup like the .NET platform where you almost certainly will end up using something gargantuan like Visual Studio? The point shouldn’t be to use a given editor; it should be to advise people to find a good workflow that helps them be more productive.

  27. The learning curve is steep, but once you get them to overcome the learning curve things will be better.I think the earlier you begin the better.

  28. What about ErgoEmacs? Common keyboard shortcuts are supported, so you don’t have to change your mindset.

  29. Once you start using Vim you will never come back to the light side of the force, Vim is extremely adictive. I really try to use Sublime Text 2 but I always get back to Vim.

  30. I’m 100% sure that the author is an Emacs user! because he knows that Vim has more users, so he is trying make both side users leave their editor and hence, more Vim users will leave! Victory is with us! Death to Emacs! #editor_wars #kidding

  31. Newbie programmers have to learn paths of Vim.
    Because one day these will become descendants of honored ancient tradition of blazing fast, pure console, context-aware text editing.
    The spice must flow.

  32. Vim is really awesome for those occasions when you want to edit stuff on a remote machine over SSH. Many things are faster to do in Vim (if you have the experience and typing skills).

    But from my personal experience, I find that Vim pros often tend jump into code implementation too quickly and produce sub-par solutions in the long term (they often neglect the big picture in favor of fast implementation – It’s the mindset).

    Once you understand that initial implementation costs are nothing compared to long-term maintenance costs, you will understand that your choice of development tool is insignificant. People should focus their learning towards planning, not implementing.

    I guess I like Vim, but I don’t like the Vim mindset – And the unhealthy obsession some developers have with it.

  33. Hello. I’m a beginner and I want to learn ruby and html5. What do you think about brackets (it’s from adobe and open source)?. It would be agood choice to start?

  34. I’m 71 years old and haven’t learned a text editor. I use sublime text. For all else nano. I’ve learned and forgotten a few emacs and vi keystrokes numerous times.

  35. While I can sympathize with what the OP is saying, you can configure both Emacs and Vim to work relatively sanely for a new user. That was the only way for me to effectively learn Vim. I always had stuff that I needed to edit. What I ended up doing was finding an example .vimrc that was n00b friendly.

    You can make vim behave more consistently with lesser editors with some configuration options which will be enough to get work done without taking the editor completely away from you. You will still need to know how to get into insert-mode when you first start the editor (type i), and how to get back into command mode when you want to save and/or quit (ESC is the easiest to remember), as well as the necessary commands to save (: w ENTER) and quit (: q ! ENTER); or better yet, save and quit (: w q ENTER). Otherwise, you can go ahead and use it like a stupid Notepad editor: arrow keys, backspace, delete, etc. If you use gVim you can probably get the mouse behaving more or less like you’d expect too (maybe even the terminal vim can, but I disable mouse support..).

    If users are at least using Vim (or Emacs) then there will be opportunities for them to learn new tricks to save them time, while otherwise just fumbling around like a Notepad user would. The first step is getting them to use it. Learning to use it properly or well comes after (the proper way to use Vim is to remain in command mode 99% of the time, but a newbie is not going to be able to do that).

    It really doesn’t take much to match the efficiency of clumsily using Notepad-equivalent editing functions. When I decided I was going to learn Vim I started by forcing myself to edit everything with Vim, combined with a newbie-friendly .vimrc. Sure, I was clumsy at first, but eventually that became comfortable to me, and I began Googling for tutorials on how to do things better. It’s really not that hard. Just as with everything else, it does require you to take the time to do it. Too much at once will certainly overwhelm a beginner, but learning to use an editor well is just as important, if not more so, than learning a programming language. Learning to write good programs takes years anyway. There is no shortcut. Learning to use a powerful editor is just one of many required skills.

  36. Hey, don’t discount IDEs. IntelliJ is a particularly powerful IDE where Refactoring is everything. You simply can’t do all of these other powerful things in editors like emacs / vi.

    Always take a pragmatic view of these things and go at your own pace but push yourself to learn at least one of these editors when you get a breather – you’ll be glad you did as a good developer doesn’t just write code 🙂

  37. Good read…Why in this world where we stress new languages that have “fewer keystrokes” are we still accepting tools like VIM for editing code?? IMO, It’s just programmer/geek machismo. VIM comes from a line of editors that were originally developed for environments that had no monitor but a printer output only. It’s just crazy to me that we can’t move on….Does anyone still prefer punch cards??

    1. Dan> Why in this world where we stress new languages that
      Dan> have “fewer keystrokes” are we still accepting tools
      Dan> like VIM for editing code??”

      Simple answer: Vim is an excellent tool. Nobody using it is doing so by force.

      1. The problem comes from social pressure and the feeling of inadequacy that can come from not knowing how to use these editors which can cause real tangible harm to people. They might be excellent coders but simply can’t tolerate using Vim/Emacs, e.g. due to lack of discoverability in the interface.

    2. When you spend a ton of time coding, one of the things you realize quickly is how beneficial it is to keep your hands on the main part of the keyboard.

      And be clear here: if you don’t see this as an issue, then it’s only because you’ve never used an editor that allows you to keep your fingers on the keyboard.

      Every time I have to life my hand up to grab my mouse or move to the arrow keys I find myself slowing down. People like you seem to believe that because vi came from an era of older systems that the precepts it uses (modal editing—not always in insert mode, etc) have anything to do with being on a terminal. IT DOES NOT.

      Emacs allows non-modal editing, and is a tower of features, but the over-reliance on CTRL is bothersome to me. You’ll see old-timers complaining of “emacs pinky” as a result of that concept.

      And anything requiring a mouse is by itself a horrendous struggle. I spent years using Visual Cafe for Java and after I got really adept at using a mouse for editing, I still couldn’t come close to what I could do with vi, let alone vim. Using an editor for creating code brings with it a different mandate and charter than a word processor. Simple as that.

      1. Yes, but we also need to stress that this applies to you and not everyone else is the same. Just like with anything in life, we all have different likes and dislikes. Something which might work wonders for one particular individual could be a nightmare for someone else.

        So the social pressure / groupthink regarding these editors needs to stop and new users must be aware that it’s absolutely fine to use Eclipse, gedit, kedit, kate, etc… And that does not mean you are a bad programmer.

  38. Thank you for this article, it describes the problems I had when I was much younger and started trying out Linux. This Unix editor nonsense in fact damaged my self confidence and I thought I wasn’t good enough and a bad Linux developer, when in fact it was Vim that sucked due to it’s incredibly poor interface, and not me. It’s like a cult or religion, and it causes real harm to new users.

    Now I use Eclipse for pretty much everything I do and it’s fine.

Leave a Reply

Your email address will not be published. Required fields are marked *