The next Boston Vim Meetup

The first Boston Vim Meetup was awesome.

How awesome? This awesome:

Things went so well we’re going to do it again! The second meeting will be this Monday, December 5th. We’ll be meeting at the thoughtbot offices at 41 Winter St, 8th floor.

This time we’ll be having two talks: “Harmonizing your text editing and shell” by Darcy Parker, and a talk on vimscript by Gabe Berke-Williams.

Like last time, we’ll provide food and drinks. As such, we’d appreciate it if you’d RSVP here so we know how much to order.

See you there!

The vim learning curve is a myth

I’ve been speaking about and teaching people vim for several years now, and I’ve noticed a surprising pattern: people are literally afraid of learning the editor.

Over the years, the popular mythology around vim has become that it’s insanely difficult to learn; a task to be attempted by only those with the thickest of neck-beards. I’ve heard dozens of times from folks who are convinced it will take them months to reach proficiency.

These beliefs are false. Here’s what’s true:

You can learn to use vim in 30 minutes.

Go to your shell and type vimtutor. The tutorial that’s presented is excellent and you’ll be through it in no time. Once you’re done, you’ll have the rudiments needed to get your work done. You won’t be fast yet, no; but you’ll be competent. And even after those 30 minutes, you’re going to start grasping the ideas that make vim so amazing: the brilliant design decision that is modal editing, the composability of commands, the clever mnemonic naming of commands. These will be enough to make you want to learn more.

Learning vim is fun because it’s game-like.

No one ever says “I’d love to learn Street Fighter 2, but there are just so many combos!” People don’t say this because learning a game is enjoyable. You start off with just the basic kicks and punches, and those get you by. Later, you learn more advanced moves, maybe even by accident.

Learning vim is like this. At first, you do everything as simply as possible. Then you start to wonder if there are faster ways to get things done, and there are! If you chain those commands together they just work! You bump into things accidentally, or maybe you spend some time in the extensive help files. Over time, you burn a few advanced tricks into your muscle memory.

Soon, you realize there are many ways to accomplish your edits, and you strive to do them in as few keystrokes as possible. This can be incredibly satisfying, particularly to us technical-types that seem to have a higher-than-average appreciation for efficiency. It may be hard to believe that trimming one keystroke off a command will one day trigger a dopamine response, but I swear it’s true. Just ask these guys.

You’ll be faster than your old editor in two weeks.

If you use vim all day and make an effort to use it well, you’ll be editing code faster than you did in your old editor within two weeks. A couple tips to help you on your way: keep a cheat sheet of commands you’re trying to commit to memory, find a friend that’s an experienced vim user for the many questions that you’ll have in the beginning (ask in #vim if you have no such friend), and pay attention to things you do that feel inefficient (there’s almost definitely a better way). If none of that works, reach out to me on twitter and I’ll try to help you out.

It’s effing worth it

There’s a reason everyone at thoughtbot is using a 20-year-old text editor. There’s a reason I’ve flown to other countries to try to convert more vim users. There’s a reason people love this editor. Maybe you should find out why.

Good luck! And happy vimming.

Climbing back up the mountain

Today is the end of my fourth week as a Design Apprentice here at thoughtbot and it’s been pretty crazy so far. Before I got started I was excited to start filling in all the minor gaps in my knowledge. My first week was spent looking at documentation and demos for new tools and languages and running through tutorials. It was exciting stuff, and all seemed pretty straightforward. All I had to do was jump onto a project and I’d be contributing in no time. I was confident that I could go from Photoshop jockey to front-end guru in a matter of days.

Then I started writing code that was actually intended for release to a client’s product. The panic set in pretty quickly. The “minor gaps” were quickly revealed to be “huge gaping chasms of inexperience.” I had worked with HTML and CSS plenty of times before, but the pace was leisurely, the deadlines few and far between, the complexity very low. Now I would go from discussing a new feature in the morning to the expectation of having it complete by lunch. 

This was a pretty big wake up call for me. At my previous job I was considered the design team’s authoritative source of development knowledge. Questions came to me first and my answers were accepted as absolute truth. On the rare occasion that the designers were expected to write code (the horror!) the task would be assigned to me. I was pretty comfortable on the top of my mountain, so to be body-slammed off of it so effortlessly was a serious bruise to my ego.

It’s been two more weeks since then. Things have gotten better. I’m not blazing fast, and I don’t always do things perfectly the first time, but my confidence is back (tempered with a good dose of humility). I’ve learned a few important things about tools and process during this time. If you’re an apprentice, or a designer that’s new to the expectation of delivering front-end code, hopefully this will be of some benefit to you.

Vim

Vim will look clunky to you if you come from a background similar to mine. A few years of Dreamweaver, the eventual move to a better piece of software like Coda or Espresso, and then this? You want me to work in a text-based interface with a complete lack of familiar keyboard commands? It will seem insane, but there are some huge benefits and you should stick it out. Once you start to become familiar with it, the potential for amazing speed will become apparent. The hard part is making your hands learn all the new movements and commands. Once your muscle memory starts to kick in things will become faster. I wouldn’t say I’m great with Vim yet, but I’m at least as fast as I was in Espresso, and working hard to improve.

It’s important to note that I work in an office of Vim users. It makes sense for me to use it and I have a great support and learning network. If everyone in your office uses TextMate, or Espresso, or something else, you should probably use that too so that everyone’s on the same page.

Sass

Sass is amazing. If you know anything about CSS, just reading their documentation ought to get your blood rushing. My favorite part is the ability to nest selectors, which makes it incredibly easy to target elements correctly. Add in variables and mixins and you’ve got a very powerful extension to CSS.

If you want a set of great mixins, allow me to humbly suggest thoughtbot’s Bourbon.

Ruby on Rails

This was the hardest part for me to adapt to. I’m used to working on static sites, so finding where everything was located in the Rails framework was intimidating at first. Luckily, I get to attend workshops (for free, it’s a great perk) at thoughtbot and our Intro to Ruby on Rails workshop was incredibly helpful in teaching me to navigate an application.

Code/Design Reviews

Have someone else look at your work. A lot. More experienced people will be able to point out what you’re doing wrong and what you could be doing better. It’s important to correct these behaviors before they become habits. Don’t be timid about offering your own feedback either. Design is often a collaborative process, and talking about your ideas usually results in better work.

But what if you’re the only designer at your job, or a freelancer? Start by posting your work on Twitter or Facebook and asking other designers for some feedback. I’ve found that many people are willing to take the time to send you a short review. Dribbble can be another great place to get input.

Google

You can almost always find answers to your problems by searching for them online. The odds of encountering an issue that somebody else hasn’t run into and solved before are incredibly low. And in our industry we’re lucky to have a lot of knowledgeable peers who enjoy writing about their solutions. 

You will improve

Most importantly, try to stay positive. You’ll have ups and downs, successes and failures, but as long as you’re moving forward you’ll be ok. I’m lucky to have people at thoughtbot who are committed to making me a better designer and a better front-end developer. Try to find people like that for yourself, either in your workplace or online. We’ve got a great community full of intelligent, helpful people. Take advantage of it.

Boston Vim Meetup

Calling all vimmers!

Mark your calendars, clear your registers, and follow the leader to the first Boston Vim Meetup.

On October 24th at 7pm, passersby of the thoughtbot office (41 Winter St #8, 02108) will wonder aloud at the audible “Om”ing of programmers in vim nirvana. This enlightened evening will feature talks by Mike Burns, Ben Orenstein, and Gabe Berke-Williams. Attendees will see useful vim techniques revealed, emacs users sassed, and food and drink provided.

Come to learn, or bring your own lighting talk (which must adhere to our strict “no slides” rule. Yes, really.) No registration required. Neckbeards optional.

Questions? Hit the comments.

:qa!