The buzz cut

Ramblings from the barbershop

An Hour Here, an Hour There

| Comments

Before starting Barbershop Labs, I spent the majority of my career running engineering teams for early-stage companies in a wide variety of industries. Each company had its own unique DNA, with different products, technologies, people, organizational structure, funding, etc. However, one common theme was there always seemed to be a lack of analysis on the costs/rewards of everyday business activities.

There were sophisticated spreadsheets and software to calculate income, expenses, net revenue, contribution margins, blah, blah. The finance folks cranked out reports on customer acquisition costs, cash flow, funding, forecasts, churn rates, etc. However, when it came to how employees were spending their time, or how decisions were being made, or the net financial impact of small to medium decisions, these companies had no data.

A common scenario in the SMB “real world” is when the sales team is close to landing a new customer, but in order to close the deal, a new feature needs to be added to the product. This leads to a meeting with a bunch of department heads from Sales, Product, QA, Engineering, Customer Service, and the CEO. The sales team explains the new feature that’s required. The rest of the group nods their heads. They’ve been through this before. They explain how building that feature will impact their schedules, priorities, and department morale. Now the sales team nods their heads, and asks them to just investigate what it’d take to build the feature.

The various department heads go back to their respective teams and solicit feedback, draft estimates, schedules, specs/stories, etc. More meetings. Finally, the people from the original meeting regroup again with the CEO, and present their findings. The CEO nods her head, then says, “We need this customer, make it happen.”

The department heads accept this new direction, go back to their teams, redirect their resources, re-prioritize their plans, update their schedules, and ultimately, make it happen. When the dust settles, and (hopefully) the customer is landed, the return is clearly visible: the new customer will bring in X revenue. Let’s say that’s $100,000. But what about the investment that was required to get there? How do we calculate everything that it took to get that feature built? Unfortunately, this is where most SMBs fail. The CEO knows the cost of every employee (salary + benefits + taxes, etc), and has a sense of their performance, but nobody seems to think of that cost translated to an hourly rate.

Yet, calculating the cost of the example I provided is actually quite easy. First you have to throw out anything that’s unquantifiable. You can’t answer questions like ‘what if the work that was de-prioritized as a result of landing the customer would have led to 10x more revenue?’ Or ‘what if the new feature skews the vision of the product?’ Or ‘what if the new customer goes to your competitor a year later?’ Or, even something positive like ‘what if the new customer refers you to five new customers?’ Those are really important questions, but we don’t have concrete answers to them, so toss them aside.

Using my example, let’s assume that we tracked the hours of the entire effort, and we knew the hourly rate for all parties involved. Remember that first meeting with all of the department heads? There were six people in that meeting. Let’s say they each made $72/hr ($150k/year). That was a two hour meeting, so it cost $864. Then the team meetings each department head had with their respective teams, let’s say that ran a total of 250hrs at $45/hr: $11,250. The department heads then regrouped with the CEO – another $864. Planning work was done – another $5,000. Finally, the product design, visual design, development, testing, and deployment of the feature was completed. Let’s say that took eight weeks and required six full time employees, each averaging $45/hr: $86,400. Total it up: $104,378.

The return of the project was $100k, and the investment was $104k. A net loss.

Let’s look at a few more simple scenarios that happen every day. How about an hour long discussion between four people weighing the pros & cons of upgrading their hosting plan that will definitively improve service, but cost an additional $100/mo? Each of the four employees averages $125/hr, so that conversation cost $500, or FIVE months of the upgraded service. Make the damn decision in five minutes, and move on to more important things.

What about a weekly departmental meeting? What about the amount of hours spent fixing a bug? Or haggling over a contract? What are the costs? What are the returns? It doesn’t take a CFO to figure these things out, yet most companies operate blind to these metrics.

I’ve kept the business side of Barbershop Labs very simple. I want every dollar I spend to make me more than a dollar in return. I don’t spend money I don’t have, and any investment I make, I measure to determine whether it was successful. If I spend $1000 on Google Adwords, and it yields a contract worth $30,000, that’s a good investment! If I spend 5 hours automating a task that took me thirty minutes to complete every month, that’s a good investment. If I take on a project for $40k, and by the end, the development effort took $40,000, that’s a bad investment.

I measure everything by the hour, so when I sit down for a team meeting, I calculate the hourly rate for everyone in the meeting. If that meeting isn’t going to yield more than that sum, we’ve wasted our time. If I’m with a client and they spend 30 minutes asking why they should upgrade to a GitHub Organization account for $25/mo, I remind them how many months they would’ve paid for during the course of paying me for those thirty minutes.

I’m not adverse to spending money to make money, and not every investment is going to pan out, but if I don’t quantify my mistakes, then I can’t learn from them, and I’m bound to repeat them. That’s just not an option for me.

Screw TDD

| Comments

For those who know me, have worked with me, or have suffered through one of my rants, it will come as no surprise that I despise the notion of TDD. However, I’ve hesitated to blog about this subject until now for two reasons. Firstly, it’s an unpopular opinion, and I didn’t want my opinion to reflect poorly upon the company I run. Secondly, I have no desire to write provocative blog posts, and argue with random strangers who disagree. However, after watching DHH’s 2014 RailsConf keynote, I feel obligated (and inspired) to echo his sentiment.

I love Rails. I’m a Rails zealot. I’ve been building web software for over 15 years, have coded in tons of languages and frameworks, and I’ve never found a tool more comfortable and productive as Rails. But Rails is more than just a tool, right? Rails represents a collection of beliefs on how web software should be architected, built, configured, organized, and tested. Rails was a loud voice screaming “MVC” and “RESTful design” when those were unfamiliar to most. It screamed “Convention over configuration” to embarrass the Java folks. It took all the best ingredients of how web software should be built and maintained, and wove them together through years of aggressive evolution.

Rails will likely fade away some day, but I can guarantee you that whatever takes its place will borrow many of those some ingredients and core tenets. Your investment in its principles and ecosystem will never be a waste of time.

However, there’s always been one core tenet that I’ve resisted. One that didn’t feel right. Test Driven Development.

In the late 80s, G.E. Smith was the musical director for Saturday Night Live. I actually didn’t know his name until now when I googled him. He played the guitar and led the band. There was always a close-up of him before and after commercial breaks. I hated the guy. HATED. His facial expressions and weird hair drove me nuts. But I loved SNL. And so I spent years trying to convince myself that I liked him, so that I could enjoy the rest of the show. I lied to myself over and over and over again, hoping I’d start to believe it.

It never worked. I was ecstatic to see him leave in the 90s.

TDD was another G.E Smith moment. I tried to love it, because I felt like I couldn’t be a Rails guy without preaching it.

When I first learned about TDD, it seemed right. I struggled to adhere to it, but parroted it’s importance to the development teams I ran. I touted its benefits to executive management. I devoured books and blog posts on the it. However, the more I learned, and the more I tried it, the more I disliked it.

But I desperately wanted to like it. I remained hopeful that I was misunderstood or that I just wasn’t doing it right. I eventually took a TDD course by a highly respected group. I contained my skepticism for the first day, and did everything by the book. I even learned some new things. But by the second day, the instructor was demonstrating a test for a list view. First the test barked because there was no route. Then he created the route. Then it barked because there was no controller, so he created the controller. Then there was no index method, so he created that. Then there was no view, so he created that.

I interrupted and asked, “You’re just using this as a simple example, right? In reality, you wouldn’t intentionally skip all of those steps for things so obvious, right?”

He looked at me like I was crazy, and said, “No, I do this for everything.”

“Really? Isn’t that a waste of time?”

“No, you’d be surprised at how often you miss minor details, and the tests help you.”

That was it. I was done. I’d officially joined the Fuck TDD team.

Let me be clear, I believe in testing. I’ve inherited and built too many apps to not understand the value of regression testing. If you don’t write tests, you’re a fool. But I write tests after I write code, not before.

Here’s why:

  • I’m an expert developer; I know what I’m doing and don’t need to be led down a path by failing tests. I can get in the zone and crank out massive chunks of functionality in a short amount of time. Stopping to write or run tests is a distraction and stunts my progress. In a world where developers preach Vim because your fingers don’t leave the home row, how does running tests every ten minutes not impact your efficiency?

  • I hate starting with red. Red is bad. It makes me feel like I’ve done something wrong. There’s something so backward about intentionally starting with failure. That makes me feel like we’re creating a generation of passive developers. Do you walk out of the house naked everyday, and wait for your neighbor to scream at you to put clothes on. Or do you act like a big boy and dress yourself? (don’t answer that!)

  • I code because I like to create things. I build products with Rails. My job isn’t to write the world’s most comprehensive test coverage, it’s to solve problems with software. Tests are used to ensure that my software is stable, but they are a bi-product, not the product. It kills me when I see people using ugly design patterns in their code to make their tests run faster. That’s prioritizing tests over product. There’s no business value there. If you care more about the internals of the codebase, than the product itself, you’re doing it wrong.

Heroku Fork Tutorial

| Comments

Heroku introduced the fork command back in June. There are some good blog posts about it already, but I ran into some first-timer obstacles, so I figured I’d share the basics here.

Let’s say you have an existing app named foo. It’s already setup on Heroku (with the name foo), and you want to create a staging environment for this app. Using Heroku’s CLI, it’s easy.

$ heroku fork foo-staging

That will create a Heroku fork of your app, database and all. It should even duplicate your add-ons, but there are some exceptions there; notably: Heroku Scheduler.

Now, you have to tell git that you have a new remote named ‘staging’

$ git remote add staging

By default, heroku will still think this new app uses the ‘production’ environment (when I say ‘environment’, think config/environments), so you have to change this:

$ heroku config:set RACK_ENV=staging RAILS_ENV=staging —app foo-staging

That will require you to create an environments/staging.rb file and add a db config for staging.

That’s pretty much it, but now that you have two heroku apps tied to the same codebase, you can’t run heroku commands without specifying the app’s name:

$ heroku run rails console -a foo-staging

And to do a push to the staging environment:

git push staging master

Celebrating One Year in Business: Part II

| Comments

In my last post, I explained how I started Barbershop Labs. In this post, I’m going to cover what I’ve learned in the past year while running a small software development shop.

There’s no halfway.
Over the years, I’d tested the waters of contracting full time by pinging my network to see if anyone had any projects. I mistook the lack of responses as a lack of opportunity.

What I’ve learned since doing this for real is that your network is much more likely to approach you if you’re doing it for real. Nobody wants to take a risk on someone who is “considering” starting a company. If they’re going to send business your way, whether it be directly or as a referral, they want the confidence that you’re all in.

It’s not that hard.
Hard is a relative term, but in my experience, keeping Barbershop Labs running hasn’t been nearly as hard as I’d expected. I’ve had a steady stream of business from day one, and have had very few surprises. I work long days, but I’ve always worked long days. I’ve had uncertainty at times, but I’ve always had to deal with uncertainty.

The most difficult thing for me has been planning for the future, while taking care of the now. A single hour spent on fostering the pipeline means an hour away from current projects. Yet, ignoring either will quickly get you into trouble. The only real solution is to hire away that problem, which brings me to my next learning…

Growth is frightening.
Early on, I found myself with more work than I could handle by myself. That’s a good problem to have, right? Time to grow the company!

I started the company with the full intention of growing it, but as soon as I was faced with the opportunity, I froze. Running a business gets exponentially harder with two people.

First, there’s the financial risk. I knew that if I ever hit a dry spell, my family would be OK. I could go home and tell my wife that we’d need to dip into savings for a few weeks. However, I couldn’t say that to someone else’s family. Hiring someone is making a commitment to their entire family.

Then there’s the matter of setting up payroll, finding suitable office space, and distributing work. It’s amazing how quickly things becoming complicated when you’re forced to make sure everyone has a full plate. You may hire someone because you just won a six month contract, then two months into the project, there’s a need to hit the pause button. It doesn’t happen frequently, but it happens.

Maybe more sophisticated shops handle this situation via a contractual clause, but in my case, the pauses have been short enough, and the clients good enough, that I was willing to work around their issue. However that forced me to reallocate resources quickly. Maybe that means that you start another project sooner than expected, maybe it means putting in 40-hours/week for another three month project, when initially you’d planned to do 20-hours/week on that for six months. Every change has a domino effect, and keeping everything in order takes a lot of time and energy.

Finally, there’s management. I spent my entire career managing people in one capacity or another, but I started Barbershop Labs because I wanted to focus all of my attention on building good software. I was tired of office politics, unproductive meetings, and all of the other minutiae that often gets in the way of building good products. I’ve always preferred to hire great people, rather than worry about being a great manager, but no matter how great the people, growing a company requires some management energy. There’s no way around it, and the more your skirt your duties, the more your company will suffer.

I avoided growth until it was absolutely necessary, and even now struggle with the decision to bring on more people; especially non-billable folks like biz dev. This is an issue that I expect to persist for at least another year.

It’s not for everyone
I’m having an absolute blast with Barbershop Labs. I’ve met so many great people, worked on some cool projects, have been exposed to tons of new technology, and have made good money along the way.

I love switching gears between projects. I enjoy building products from scratch as much as the challenge of rescuing a project. And I enjoy collaborating with customers and in-house development teams.

Not everyone likes, or is good at, all of that. Some people prefer putting all of their passion and energy into a single product. I get that. Some hate dealing with clients. I get that too. The point here is: when hiring, make sure you find not only a good developer, but one that will flourish in the world of client-services as well.

You gain perspective
When I was running technology departments in-house, for tiny startups and established companies, I’d often push for more resources, or to better compensate the people we had. Even when I had full knowledge of the company’s financials, and I knew money was tight, I’d push for those things as an “investment.” If we bring in one more developer, we’ll be better positioned to keep up with the market, support our customers, bring in new customers, etc.

I still believe in strategic investments, but managing the finances of my own company has brought a new perspective. The purpose of a business is to make money. If you have $100, and you spend $100 to make $101, you’re heading in the right direction (although, you may want to reconsider your business model!). If you spend $100 to make $99, you’re heading in the wrong direction. It’s really that simple. Every dollar I spend, needs to make me more money, and I can’t spend money that I don’t have.

There are many successful companies that were in the red for years before they turned a profit. A software development shop should not be one of those companies. Every hour that you spend while working, whether billable or not, should have a direct path to increasing your revenue.

I suspect that if I ever go back to an in-house position, I’ll carry this mentality forward.

Note: This post could go on forever. I’ve decided to stop it here and write separate blog posts throughout the year with more learnings.

Celebrating One Year in Business: Part I

| Comments

A year ago, I made an outrageous proposal to the CEO at the company I’d only been working at for three months: let me quit, start my own company, and be my first customer. Maybe that doesn’t sound that outrageous. People do things like that every day, right? But for me, at that time, it was the biggest, riskiest move of my life.

By most measures, I’d enjoyed a successful career as a technology leader. I’d run development groups, technology teams, and did a tour as a CTO. I had a great track record for crafting good software, building awesome teams, and holding my own in executive circles. I’d worked for a lot of startups, some that had done well, and if you looked at my resume, you’d think I was successful. And I suppose I was, but I wasn’t happy.

Since I was a kid, I wanted to be an entrepreneur. My father embodies the very definition of an entrepreneur. He grew up poor, couldn’t afford to go to college, and began his career as an electrician. He went on to start several companies, reinventing himself countless times, until he had provided the life for his family that he’d always dreamed of. My brother is a successful entrepreneur in his own right, having started a company right out of college and building his own little empire.

When i was in my early 20s, I was a finalist in a worldwide entrepreneurial contest sponsored by IBM. Ultimately, I didn’t pursue that company because I was in a great situation professionally. I’d always assumed I’d start my own company someday, but as the years went on, life got more complicated. I got married, bought a house, and had kids. Suddenly there were mortgage payments, life insurance, healthcare costs, retirement savings, college savings, etc. We’ve all heard that story before. It seems cliche at this point, but damn is it true.

Even though I’d spent my entire career taking risks by predominantly working at startups, starting my own company had become an unacceptable risk. I began telling myself that being a good dad was more important than being an entrepreneur. When I’d talk about my career with my wife, she’d ask if I still wanted to start a company someday. I’d tell her that my priorities had changed. She’d press harder, and I’d get defensive. She’d eventually drop it, but we both knew that I was hiding from the truth.

In 2012, after a few years of less-than-ideal work situations, I found myself working for a new company. I was happy. I was spending my days doing things I loved, building a great team, improving the culture of the company, and working on some interesting software. And then three months in, the CEO pulled me aside and told me he was selling the company. I went home that night with a very heavy heart. I wasn’t worried about my job security, or the change in leadership — I was jealous. I’d become fast friends with the CEO, and looked up to him as an entrepreneur. He had taken nothing but an idea, and through blood, sweat, and tears, built a successful company. He put in the hard work, made the right decisions, and now he was being rewarded. He deserved it, and I wanted the same.

I didn’t sleep that night. Partly because we had a two month old baby, but mostly because my gears were cranking. The notion of starting my own company, which I’d shoved so far down, had come bursting out. I thought about the financial risk. I was making good money at the time, but hadn’t achieved the level of financial security for my family that I longed for. We had some savings, but our expenses were high. I thought about the logistics. How would I get customers? Where would I work? How would I handle health insurance? Most importantly, I thought about the notion of controlling my own destiny. No matter how well I’d performed in my career, or how much influence I had, I was always just a cog in the machine. On one hand, that was comforting; if things went wrong, I could blame someone else, right? I could hide behind the failures of others. It couldn’t have been my fault — I’m the smart technology leader who does no wrong. On the other hand, I was leaving my fate to chance. I was trusting others to make me their number one priority, and to make decisions with the best interest of my family in mind; and that just wasn’t realistic. I’ve worked with some amazing people who have gone out of their way to do right by me, but ultimately their responsibility was to themselves and their families.

By the morning, I told my wife that I was thinking about starting my own company. She heard me out, and expressed some concern, but told me that she trusted me, and knew how important it was that I take a crack at entrepreneurship at least once in my life. Yes, I married up.

I spent a couple of weeks thinking everything through. I really didn’t want to start a business without any revenue, so I decided that I’d at least try asking my current company if they’d like to be my first customer. Giving notice and asking the same company to be a customer is slightly ludicrous. Some companies would be so mad, or hurt, that you were leaving, the last thing they’d want to do was help you. I had two things working in my favor though: first, I had a feeling that my CEO would understand my desire to start my own company; second, one of my favorite pieces of advice I’ve ever received was “always give someone the opportunity to say no.”

I made the pitch and they accepted. Three weeks later, on September 1st, 2012, Barbershop Labs was born. My entrepreneurial journey had begun!

In part two of this series, I’ll share what I’ve learned in the first year.

Finding Available OmniAuth Providers

| Comments

I’m working on a project that uses OmniAuth to connect a user’s account to LinkedIn, Twitter, and Google Plus. Easy enough, right? On one screen in my app, I needed to display the services that a user had already connected, and the ones that were still available to connect.

The former is easy:

<%= render %>

But what about displaying services that the user hadn’t connected yet? I didn’t want to store a constant of available providers, as that’d just be one more place I’d have to edit when adding a new provider. So, I dug around a bit and found this:


That returns an array of providers, with one caveat: it adds Developer, OAuth2, and Oauth to the list by default. I didn’t want those exposed to the end user, so I added a method in my Service.rb class:

def self.available_providers
  OmniAuth::Strategies.constants.reject {|item| item =~ /Developer|OAuth2|Oauth/i }

Then, to display the services that the user hadn’t connected yet, I used:

Service.available_providers.each do |service|

This works great, but it doesn’t feel 100% right. Any suggestions on how to do it better?


Matt Brand reminded me that you can subtract arrays in ruby. While looking at that part of the code, I realized I’d sinned and had this logic within the loop. While rails would’ve cached that query, it’s still bad form. I started to rewrite that block with:

(Service.available_providers - do |service| %>

But that’s just too much logic for an erb, so I added a method to my User.rb model:

  def remaining_services
    Service.available_providers - services.pluck(:provider)

And now my code for displaying the available services looks like this:

current_user.remaining_services.each do |service|

Now, I just need someone to recommend a better way to get available providers from OmniAuth, as OmniAuth::Strategies.constants still feels wrong.

A Month With Vim: Weeks 3 & 4

| Comments

My third and fourth weeks with Vim brought clarity. I broke through the learning curve of Vim, stopped tinkering with my environment, and had developed muscle memory for things like switching between insert and normal mode. I no longer needed the Vim cheat sheet in my bookmarks toolbar, and I completed all the levels in Vim Adventures. I was finally ready to see if my productivity was any better. And you know what? It wasn’t. I wish it had been, but the reality was, there was no measurable improvement to my productivity.

Vim is a very good text editor. It provides endless customization, some really cool plugins, and tremendous control over moving through files. Using Vim has given me a new appreciation of split paneling, using keystrokes for EVERYTHING, and never leaving the editor. If you’re coming from TextMate, or Pico/Nano, or another archaic editor, you’re certain to become more productive in Vim in due time, but if you’re coming from SublimeText, you probably won’t notice a massive improvement. Ultimately, it’s just another flavor of great editors, and you have to decide which flavor you prefer.

In my case, I can now say that prefer SublimeText. I code 100% of the time on my MBPr, and I never use peripherals. I use a lot of key mappings to get around, but if I need to use the mouse or the arrow keys, my hands don’t move far away from the home row to make a significant different. I’ve never felt slow, and Vim didn’t make me noticeably faster.

I spent my first two weeks trying to make Vim look and feel like SublimeText, but no matter what plugins were available, they never quite mimicked the experience. NerdTree and CommandT just never felt right. Vim Rails annoyed me that I had to have a “rails” file open in order for it to work. I never found a project-wide search that I loved. I never got around to looking for a plugin to mimic SublimeText’s “Quick Add Next” feature. I spent the final two weeks letting Vim be Vim; working more with buffers, named registers, and panels. Ultimately I decided that there was no use in tinkering with Vim to make it more like SublimeText, and the “pure Vim” experience wasn’t as good as the pure SublimeText experience.

All is not lost though. Firstly, I like to make educated decisions. Secondly, my experiment with Vim has inspired me to improve how I use SublimeText. I now use RubyTest to run tests directly within SublimeText, Origami to manage split paneling, and I’m beginning to learn the keyboard shortcuts that weren’t already in my repertoire.

Thanks to everyone who helped make this experiment worthwhile. I hope that this series of posts helps others navigate their own experiment, and decide which flavor they prefer. If you have any questions along the way, feel free to reach out to me.

A Month With Vim: Week 2

| Comments

Week two of my Vim experiment began and ended with me doubting whether Vim was really a better editor than Sublime Text. However, in the middle of all that doubt something interesting happened: I became reliant on Vim. Yes, you read that right. While I was doubting Vim, I was unknowingly becoming addicted to it. It’s almost as if Vim was cackling in the corner, saying “it’s so cute that you think you have a choice.”

Honestly, at the beginning of the week, I really wanted to abandon the entire experiment. I was losing productivity, tripping over simple things, and really starting to think that Vim was more about a nerd badge than anything else. I started to bounce questions off a few people who swear by Vim, and even sat and watched one of them code for fifteen minutes. He flew through some routine refactoring, which was certainly encouraging. I shared with him what I’d learned so far and he told me that I was close, and to keep at it.

Sometime during the week, I encountered the Yank command while playing Vim Adventures. I sat down to code that day and quickly ran into a situation where I needed to Yank something. Unfortunately, in my mind, “Yank” meant “deleting and copying.” Yes, that’s what the delete command does, however at the time, I thought the delete command simply deleted it (without copying). So, I tried to “Yank” some text, and nothing happened — nothing was deleted. This began two hours of misery. I googled and googled, but found nothing useful. I tried reverting my .vimrc, thinking maybe there was a conflict with one of my configs. I tried visual mode. I tried Y and y{motion} a hundred times, hoping that suddenly it would start working. Then I posted to Stack Overflow. Within ten minutes, someone had explained that Yank simply copies. Whoever named that command Yank, instead of Copy, deserves a kick in the ribs.

I share that story for two reasons. Firstly because annoyances like that seem to pile up quickly with Vim. Even the obvious things can be difficult at first. Secondly, it’s those frustraing moments where I tend to learn the most. While I was hacking away, trying to solve my problem, I stopped thinking about “using Vim.” I just used it. It was during those two hours where I really began to develop some muscle memory around the Vim commands and motions.

By mid-week, I spent some more time beautifying things. I switched to the solarized theme, and installed an awesome status line utility called powerline. Powerline changes the color of the status line depending on which mode you’re in, which I found super helpful. It was also around this time that I noticed I was starting to move quickly and make fewer mistakes. Switching between normal mode and insert mode was becoming more and more natural, I was moving around files faster, and getting a hang of the commands and motions. It wasn’t life-changing, but it did feel like I was interacting with my computer on a more intimate level. Like, I had gone from writing code using the same keystrokes that I’d use in MS Word, to writing code with keystrokes that felt more approrpiate to a programmer.

Feeling good about things, I started to experiment more with Vim plugins. I found this Quora question to be the most succinct list of the most popular Vim plugins. The more I played with the plugins though, the more I thought that what took plugins and configurations with Vim, came out-of-the-box with Sublime Text. Should we really be high fiving each other because we can change ‘foo’ to “foo” with the Surround plugin? And do I really have to remember to type cs'“ to do that, when in Sublime Text, I just highlight the word and type ?

Late in the week, I ran into a situation where I needed to quickly answer something for a client. I broke down and opened up Sublime Text 3 (shh, don’t tell anyone). After answering the question, I looked lovingly at my beautiful, familiar text editor, and began to… CHEAT. I was ready to go back to Sublime Text. I was happy that I’d learned Vim, but ready to declare Sublime Text the victor. And then my world got turned upside down. I couldn’t move around Sublime Text. Not because I couldn’t remember the key commands, but because the ones I wanted weren’t there. My mind was telling me that I liked Sublime Text, but my fingers were telling me that I liked Vim. Fan-fucking-tastic.

I discovered that Sublime Text has a “vintage mode” where you can enable a lot of the Vim commands and motions. I thought maybe that’d be a happy medium. But happy mediums are never really happy, are they? Nothing felt right about vintage mode. The solution was either full Vim, or full Sublime Text.

So, here I am, at the end of week two, a bit confused. I’m in no man’s land — no longer in love with Sublime Text, but not ready to declare my love for Vim. Let’s hope Week 3 provides some clarity!

A Month With Vim: Week 1

| Comments

In my last post I explained that I was going to immerse myself in Vim for a month to see if I found it a suitable replacement for Sublime Text. Here’s what I learned in my first week:

Being an absolute Vim noob, I had to start at the beginning. I googled Vim and clicked through to My first reaction was “oh, crap, this looks like an Apache project website.” Apache has some great projects, but those sites are all sterile, assume you’re an expert, and lack useful documentation. That’s what felt like. I mean, compare Sublime Text’s site with Vim’s. SublimeText’s site is all “Hey, look at this beautiful piece of software,” while Vim’s site is all “eep opp ork ah ah.”

I think that’s relevant. There was once a time in my life where I enjoyed tinkering with complicated software. I did several tours of running linux on old laptops. I built my own machines, recompiled binaries, and found crazy hacks to get things working the way I wanted them to. I’m past those days. I have a mac. I don’t want to tinker any more. I expect things to work. So, when I saw the Vim site, I got a little nervous. Was Vim going to make me more productive, or was it just going to earn me a nerd badge?

I clicked the “download” link on and was immediately faced with a decision: which mac client to use? I’ll make it easy for you, if you’re on a mac, use MacVim:
brew install macvim

With MacVim installed, I spent my first week familiarizing myself with the configuration options, plugins, and keyboard shortcuts. Here’s an overview of what I learned:


If you’re using MacVim and not using Janus (see the plugins section below), your configs will live in ~/.vimrc and ~/.gvimrc. The latter is used to store configs specific to the GUI version of Vim. The former is for general configurations.

One of the first configuration changes I made was to the color scheme. Hey, if you’re going to be staring at the same screen all day, it should be pretty, right? I’d been using the Monokai scheme for Sublime Text, so I was happy to find a version for Vim. I grabbed the Monaki.vim file and put it in ~/.vim/colors/ (create those directories if they don’t exist yet). Then I added the following config in ~/.vimrc: colorscheme monokai. Note: after making changes to .vimrc and restarting MacVim enough times, I finally figured out how to reload changes without restarting. With .vimrc in the current buffer, do the following: %so ~

With my colorscheme set, I added some standard configs which I’d gathered from a variety of sample .vimrc files:

syntax on
filetype plugin indent on       " Enable filetype-specific indenting and plugins

set nocompatible
set backspace=indent,eol,start  " allow backspacing over everything in insert mode
set history=400                     " keep 400 lines of command line history
set ruler                         " show the cursor position all the time
set showcmd                         " display incomplete commands
set showmatch

"set nowrap
set wrap
set linebreak
set nolist                      " list disables linebreak

set autoread
set guioptions-=T
set ignorecase smartcase
set laststatus=2                " Always show status line.
set relativenumber
set sidescroll=5
set listchars+=precedes:<,extends:>
set scrolloff=3                 " Show 3 lines of context around the cursor.
set tabstop=2                   " Global tab width.
"set autoindent                 " always set autoindenting on
set shiftwidth=2                " And again, related.
set expandtab                   " Use spaces instead of tabs
set nobackup                    " Don't make a backup before overwriting a file.
set nowritebackup               " And again.
set backupdir=~/.vim/_backup    " where to put backup files.
set directory=~/.vim/_temp      " where to put swap files.
"set spell

It’s worth noting that most people use set nowrap. I’d prefer that option, but when editing files with long lines, I found Vim to get super slow. The last thing I expected to have a problem with was Vim being slow. That alone would’ve been a show stopper. I googled a bit and found that one option was to turn off syntax highlighting. I tested that, and it worked, but I can’t live without syntax highlighting. The other option was to turn wrapping on, thus preventing long lines. Not ideal, but that resolved the problem for now. The set spell config turned on spellchecker, which was nice while writing this blog post in Vim, but it too seemed to degrade performance, so I turned it off for now.

I’ve just started to play with customized key mappings, but I’ll hold off on discussing those until a later post.


There’s a large contingent of Vim users who recommend using the Janus to provide a basic foundation for the most common mappings. I played with Janus, and went back and forth on it several times. Ultimately, I decided against it. As a new user, I want to learn vanilla Vim. I want to experience the problems that Janus solves in order to understand why Janus exists.

There seems to be multiple ways to install plugins. The two most common appear to be Vundle and Pathogen. At this point, I’ve activated both, but I’m really only using Vundle.

The plugins that I’ve found must-have’s so far for a Ruby developer are: Vim Rails, Command T, SuperTab, Vim Ruby, Vim Endwise, NerdTree, Vim RVM, and SnipMate

Key mappings

Commands can be executed by single key presses (e.g., j to move down), control + key presses (e.g., Ctl + w + w to switch between splits), Cmd + key presses (e.g., Cmd + z to undo, and Leader + key presses. The “leader” is like adding an additional “Cmd” key to your keyboard. The default leader is /, but it seems common to change that to the comma with the following configuration: let mapleader = ‘,’

There are a ton of commands. Very few of them felt natural to me, and one week in, I’m still way slower than I want to be. I started my learning process by typing in :help. Somewhere along the way, I found this cheatsheet, which has proven to be helpful on multiplate occasions. The absolutely best thing that I’ve done so far to learn the basic commands was to play Vim Adventures. If you’re serious about learning Vim, buy a license to this. I can’t recommend it enough.

Week one thoughts

I’m far from making a final decision, but with one week down, I’m not ready to declare Vim the winner. I do enjoy the key mappings, but I still can’t see a clear advantage over Sublime Text. Things that just work in Sublime Text, take a lot of tinkering in Vim. I was also REALLY surprised at some of the performance issues that I ran into with Vim. I never would’ve expected that.

Three weeks to go. Time will tell…

A Month With Vim: Introduction

| Comments

For years, I coded in Perl, PHP, and Java using Pico/Nano. I was pretty damn productive in those days, but simple refactoring was tedious and time consuming. When I shifted to Ruby, I started using TextMate, and eventually Sublime Text. Both provided huge improvements to my programming happiness and overall productivity. Fast forward 5-6 years and now, I consider myself a fairly advanced Sublime Text user. I know the majority of the shortcuts, leverage plenty of plugins, and can move around with ease. I don’t NEED it — I could still go back to Nano, if necessary — but it has certainly made me a better programmer.

Lately, the Vim community has been conspiring against me. Everywhere I turn, there’s another developer I respect gushing over Vim. I see daily references to it in screencasts, conference talks, and blog posts. What’s all the hype about? Will keeping my fingers on the home row, pecking at a new key combinations, provide me similar productivity gains to my Nano –> SublimeText shift?

It’s time to find out.

Vim has a steep enough learning curve that it’s impossible to do a fair assessment in a week, so I’ve decided to commit myself to it, as my only text editor, for the month of July. I’m documenting the experience for others who are starting at zero.

Read more about my first week with Vim