Hi everyone, I'm Chris Wanstrath, and I'm going to teach you how to become a famous Rails developer.
A Ruby rock star. A code ninja.
It's not hard, it just takes laser like focus and a bit of patience.
I should say up front that you don't need to worry about having any programming skills or ten thousand hours of practice. That doesn't matter - it's easy to fake.
So! The first thing you will need is a blog. But not just any blog. You need a blog with personality. It doesn't matter if the blog's personality matches your own.
The most important part of any blog is the name. Clearly. It can't be "John blogs." Or maybe it can - that might be retro cool at this point. But you understand my meaning. Don't settle on a name you're not happy with because if you do things right, you're never going to hear the end of it.
It's like choosing a band name. Or naming a child. Make sure it's something people will remember.
And try not to make it too Railsy. That's limiting - make it your own. It's your blog, after all.
I shouldn't have to say this next bit, I hate saying it, but I'm going to: never use a default blog template. You're shooting yourself in the foot.
Here's why: you'll eventually be posting quality content on this blog of yours. Not right away, don't get ahead of yourself. But you're going to write some really good posts. They'll get linked on Hacker News and Reddit, they'll get retweeted and delicious'd, and, if you're lucky, you'll get a mention in a podcast or two.
The first time someone visits your blog, if the content is good enough, they'll appreciate it. Maybe bookmark it. Then they'll move on to the next item in their feed reader.
The second time that same person visits your blog, if the design is unique and the personality shines through the content, they'll remember. "Hey. I was here before. It was good."
Now I don't know exactly how many quality posts you're gonna need because it's different depending on the individual. Some get hooked right away. They have no shame.
Others like to take it slow - they make you work for it. Three, four, maybe five stunning posts before they'll commit.
But they will commit.
The idea here is association - if your blog uses a faceless template, nobody is going to remember that they were there before. That they read a good post on it. You're fighting an uphill battle.
Spend time on the design. Maybe hire someone, do some favors for a designer friend, I don't know, you'll figure it out.
And once you do, you'll have a killer name and a sleek design. Good start.
Now for the customizations. The sidebar, the header. This stuff matters.
If you're going to put a list of blogs you like in the sidebar, and I wouldn't, you have to be very careful. If the blogs are too popular, people are going to think you're a wanna-be. If they're too obscure, they might think you hang out with the wrong crowd. It's better to be safe and ignore the whole thing completely.
In fact I'd just keep the sidebar sparse, very sparse. No tag clouds or recent comments or recent posts. Maybe just the archive, list it out by month. Listing projects you're interested in might be okay.
Oh, and your email address. People are going to want to email you.
But like I said, sparse. Don't distract from the content.
And never use Google Ads - you'll eventually want to join an ad network or get sponsored. Google Ads just cheapen the real estate.
The header is important because it's the first thing people see. A picture of you is probably best. Something fancy. But if you can't fit it in the header, the sidebar works equally well. Remember: people need to recognize you, know that you're the John from "John blogs."
As for the content, you need to decide on your tone. You should make a list of ten or so famous Rails developers, maybe in a spreadsheet, and pick one word adjectives to describe each of their tones.
Go through the list and figure out the combination that works for you. Zany and spontaneous? Professional and inspiring? Offensive and verbose? Pick two traits that you think you can pull off.
Write them down. This is now the tone of your blog.
The final step, before the actual blogging, is the rules. You need to set guidelines for your blog, rules about the content. If Hashrocket starts doing Scala, can you chime in on the controversy? Can you pen a post about the great new Twitter client you downloaded? What about your experiences with the Android SDK? Are you focused on code, the community, your observations, or esoteric tricks?
(I would stay away from esoteric tricks as a core competency but occasionally indulge in order to maintain your street cred. But that's just me.)
The important thing about the rules is they help establish consistency. You don't want to post about a neat oauth library once and never mention it again. That confuses people. They crave structure.
Give it to them.
Okay, with all that said we can start blogging. But we're not really blogging yet. We're just practicing.
Every day you need to write a post. It doesn't matter what about. No one is going to read 'em.
But you need to practice writing and perfect your tone. Give your blog a personality.
What to post? Anything. Instead of just making a Gist of your cool code snippet, post about it on your blog. Add a little anecdote about the background.
But don't drone on and on about it. Unless, of course, that's your tone.
The great thing about starting a new blog is you can go back and look at old Gists, old plugins you wrote, crazy rake tasks, and pretend they're brand new. Write them up. Make a post. It's new to everyone else.
Another neat trick is to look at what other bloggers are doing, popular libraries or techniques they've pioneered, and improve on them. That way they do most of the work, but because you made it a little bit better you can grab some of their spotlight.
Talk about testing. Lament the lack of something. Maybe even start trouble with another blogger's code. It didn't work for you, so it sucks.
After a few weeks of this we can start getting serious. But in the meantime, what are you going to do about your Twitter account?
You have one, right? Well you don't want to mindlessly tweet your blog posts - that's a huge turn off. And you don't want to tweet that you just started blogging, because there's nothing there and it's a missed opportunity.
Instead I would change your Twitter design (the background, link colors, all that stuff) to match your blog. Make them compliment each other. Dress for success. And be cool.
That way you're not just some random Rails developer, you're the author of "John blogs." You're that John. Make sure your avatar has your face in it, too.
In fact, why don't you dust off trusty Photoshop and make one of those social backgrounds for your Twitter account? You know the ones I'm talking about - with all the links you can barely read and certainly can't click. Those backgrounds let people know you mean business and how to conveniently find you.
Your tweets should probably follow the tone but, and this is the fun part, they can break the rules. Let people know the real you. Like a reality show.
Anyway, moving right along. You're set up, you're tweetin', you're bloggin', you're feeling good. Time to strike.
Your first post that you really think sings, put it out there. Tweet it, post it to the social news sites, get it on Rubyflow. Do it early in the morning on a week day, Eastern Standard Time, because people love refreshing Reddit at work.
But don't expect too much. There's no such thing as overnight success. We still have a lot of work to do.
One way to get eyeballs and readers is to release simple, useful code by way of terse, to the point blog posts. Show people the problem, show them the solution, tell them how to install it and provide them with a way to download it.
Another way is to rant. But you have to do that a lot.
As far as identifying and releasing simple, useful code, don't spend too much time thinking about it. Go about your day, your normal routine, but keep an eye out for things causing you pain. Things causing your coworkers pain.
An annoying kink in your deployment? Repetitive and error prone security practices? Bug in the authentication plugin you're using?
Keep your eyes open and, when you identify a pain point, something causing friction in your workflow, write it down. Store it somewhere.
Later that night you pour yourself a glass of wine, maybe some bourbon, sit down on the couch and write a solution.
Keep it simple and make sure you can complete the library or plugin in one night. Then write a blog post and release it.
Rinse and repeat.
If something's causing you pain, it's probably causing someone else pain as well. We're all Rails developers with pretty similar workflows. Well, most of us.
Eventually you'll hit the jackpot: something simple that a few people want to use. Maintain it, accept patches, and keep moving forward.
As you gain more confidence, you can start looking for bigger pain points and more ambitious solutions. You'll get better at spotting them.
Now you're ready for the conference circuit. Local RubyConfs, meetups in your city, and the holy grail, RailsConf. Get a serious pet project going and submit talks about it. Post progress updates. But be sure to maintain your tone and follow the rules. Go to the after parties and meet people. Let them know you're John from John blogs. Never take off your badge.
Continue posting with consistency. Most people don't know the difference between prolific and profound. Both words share a lot of letters. They just want something interesting to read, and a lot of it.
Keep track of what everyone is saying about your posts on Twitter, delicious, and FriendFeed. You don't have to respond, but I would frequently search for your posts on all these services. Check a few times a day.
If you contribute to Rails itself, that's huge. The other famous Rails developers will start to notice you. Same with commenting on blogs - especially the ten in your list. You kept that spreadsheet, right?
A few months of this and you'll be signing autographs, kissing babies, going to expensive nightclubs - living the good life.
Everyone will know your name. Publishers will be mailing you books, asking you to blog about them. You'll get invited to speak at conferences. Recognized on the street. Recruiters will haunt your inbox. Things you say will matter. Your blog will get sponsored. Maybe you'll even write your own book.
And, of course, you'll get to hang out with the cool kids. Now you're one of them, after all.
Congratulations.
The problem is that being a famous Rails developer isn't the same as being a good Rails developer. Anyone can become a famous Rails developer. Do all that stuff I just said. Boom, guaranteed to work.
Personally, I look up to the good developers. The people who don't care about their RSS subscription count, who blog as an afterthought. People who aren't concerned with how many Twitter followers they have and work on their pet project every week because they love it. Who've contributed to Rails for years because it's their passion and aren't overly concerned with their speaker's bio.
People who care about code, first and foremost.
There's always talk about putting IRC or Twitter nicknames on conference badges, so you can identify people you've met online but never in person. Why don't we just skip that and instead put your favorite project that you've contributed to on your badge?
"You've contributed to Rack? That's great, I love Rack. Maybe we can be friends."
"You worked on Webrat? Can you please explain it to me?"
Think about this - do you know the people involved on your favorite RubyGem? Your most used plugin?
They're probably people you'd get along with.
Code, I'm learning, is the common thread that brings developers together. It's not blogging or trolling or procrastinating, as much as we love those things.
It's reading, writing, and sharing code.
And as much as I blog, troll, and procrastinate, I think code has brought me the most good fortune. The biggest return on investment with the least risk.
After I dropped out of college, I worked at a PHP shop doing trucking logistics applications. We were a broker between independent truckers and big companies like KMart. Truckers would register on our website, say they're going to be in Delaware on the 3rd of May and that they're heading to Denver, then get information on shipments along their chosen route. They could then bid on shipments or accept them, all through us.
It was a fairly complex application and two things were missing: version control and constants. There was no version control, so you'd have things like main2.php and compute_radius_of_from_shipment7.php laying around. Along with versions 0 through 6 of that same file, in the same directory. Truly painful.
There were no constants and no configuration, so the source code was filled with magic numbers. If you wanted to tweak any of our algorithms, you had to find the code which did the computation and change some numbers by hand. Hopefully the correct numbers.
Naturally, the first thing I did was institutionalize Subversion. King of version control systems.
The second thing I did was start extracting the magic numbers into configuration files. At the time, it was a pretty common PHP idiom to use .ini files for configuration. Most of what you'd need was supported, and I'm pretty sure PHP came with a library that could understand .ini files.
This worked okay, but once I started tinkering with Rails I was blown away by YAML. So clean, so powerful. There was Syck, the C extension written by _why, but it was just that: a C extension. I didn't know much about loading C code in PHP, and even less about doing it on our production servers.
So I set out to write a YAML parser in PHP, on my own time. As a nod to Syck, I called it Spyc - S P Y C - a simple php yaml class. It was my first parser, was stateful, and I think did two passes for the reference / pointer stuff YAML supports. It didn't support all of YAML, but it supported most of it - both dumping and loading. The good parts.
I snuck it in and before long we were using YAML with great success at my company. Naturally, I put the code up on SourceForge. King of source code hosts. My designer friend made a page and in the first month Spyc was a huge hit. I swear it had at least 70 downloads. SEVENTY!
That was a big deal.
Fast forward about nine months: my telecommuting job turned into a real job and I agreed to move to New Jersey. I packed my car, said my goodbyes, drove eleven hours to Hackensack, worked one day in the office, realized all my co-workers were complete sleezeballs, got in my car and drove eleven hours back to Ohio.
And just like that, I was an unemployed college dropout.
It wasn't so bad - I spent a lot of time at the pool that summer. And I spent a lot of time learning Ruby and Rails.
I even started freelancing again. After all, I was fully qualified. I had 8 years of programming experience - I did some QBASIC when I was 12. I'm pretty sure that counts.
But summer ended and I needed to figure out what I was going to do with my life.
As luck would have it, around that time the video game website GameSpot was hiring. And I needed a job.
I had no idea where San Francisco was or what the guys at GameSpot were looking for, but I applied. I created a brand new resume and stayed up all night working on the cover letter. By the time I was finished, it was a page long and pretty convincing.
In it I promised to move to California the next day, bringing nothing but my guitar and Xbox with me. My family would miss me but I was ready to leave, and I was hungry to show the world what I could do. Ready to learn from the masters.
The phone interviews went well, they liked that I was into Macs and Ruby, and I obviously got the job. My first time ever stepping foot in California was when I flew out to find an apartment with my dad.
My work experience wasn't what got me the job. I'm sure my cover letter had something to do with it, but my short lived career in trucking logistics was less than glamorous. I really only had one thing to show GameSpot - Spyc. My code was freely available, had been used in production, and worked. They could download it and play with it, or check it out online. Regardless of whether or not they thought it was good, they could tell it was clean and well thought out. Well, maybe not, but I had a website and 70 downloads.
I got the job at GameSpot, in my mind the first big step in the path that brought me right here, thanks to code. Code I mostly wrote for fun, to scratch an itch.
So that was pretty cool, and I thought unique, until it happened again. While I was working on GameSpot, I was doing more and more Ruby on the side. I had an open source Rails tumblelog called Ozimodo, a crappy FTP server called ftpd.rb (which I used as a way to learn about threading), and a command line option parser DSL called Choice. For Choice, I had a full test suite (I wrote the thing to learn TDD) and an RDoc generated homepage on Rubyforge.
When CNET, GameSpot's parent company, acquired Chowhound, they decided to rewrite the site in Rails. From scratch. Classic. They brought on two Rails programmers from Wayfaring.com and were looking for another. They found me.
I later found out my RDoc site, RubyGem, and test suite proved to the Wayfaring guys I was a "real" Ruby programmer. They wanted someone excited about this stuff, and I certainly was.
Which was great timing, because it meant I got to expense my trip to the 2006 RailsConf.
Code talks.
If you don't have any projects going right now, you should spend some time here starting something new. Something you've been meaning to do but haven't got around to. An idea that's been floating around.
Or just find someone who's hacking and ask them what they're working on. Maybe it'll be interesting enough to jump in on.
If you want to run your own business, code is the perfect way to find cofounders and employees. I always feel bad for business types who post on forums wondering the best way to meet a cofounder or CTO. Not because they're business types - we all have to live with our decisions - but because I didn't realize this was an issue.
I met all the other GitHub people through code: PJ through Chowhound, Tom through his open source work, Scott through his almost annoying large array of Git based Ruby libraries, and Tekkub through his domination of the site's Lua section.
At CNET, we found really talented people through both open source and local meetups.
And everyone you met here that you didn't know before the conference, technically, you met through code.
GitHub didn't catch on because of Git. It may have helped, but it wasn't the primary catalyst.
GitHub caught on because it's about code. Sharing, finding, and contributing code.
Rubyforge and Sourceforge aren't about code. They never were.
In fact, just yesterday Sourceforge rolled out a redesign of their homepage. They have Twitter search and popular projects right there, front and center. Fancy. So I clicked around.
The first project I clicked on, Ares Galaxy, was number seven on the top ten list. The CVS browser said it didn't have any files. So I guess you can just download a tarball. Which is nice.
The second project I clicked on was number five on the list, 7-Zip. It didn't even have a link to a source code browser.
No code.
I realized I haven't created a project on Sourceforge in a long time, so I decided to do that next. I remember it being painful, but this is a fresh redesign.
The first page consists of five radio buttons, a Project Name field, a Unix Name field, a Public Description textarea, and an Additional Notes textarea. The Notes area is lovingly provided so you can justify to SourceForge's staff why you should be allowed to create a project. And, of course, you can't continue without giving them a reason that spans at least 200 characters.
Which I think is crazy - most days I have trouble with 140 characters.
Also, there's a warning at the top that says you need to be hosting open source software.
Once you've filled all that in you click 'next' and you're asked to choose an open source license. There are eight licenses listed, along with an "Other" option, and then a link to documentation about open source and choosing a license. I picked MIT.
On page three you are asked to assign your project at least five categories. Category options are things like, "Programming Language Ruby," "User Interface DirectX," or "Development Status Beta."
I picked four pretty easily but had legitimate trouble with the fifth, ending up with, "Topic Religion and Philosophy New Age."
Quite apt, if you think about it.
On the final registration page you're asked to read about what open source means, the site's terms of service, then submit the project for approval.
Upon submission you're thanked and told to wait one to three business days.
I obviously have an interest in lambasting a competing site, but this sign up form is one of the reasons we started GitHub. Once you have an account, creating a GitHub repository is, I think, simple:
We ask for the project's name, a short description, and the project's URL. Under those three fields are two radio buttons: is this project public or private? The only thing that's required is the project's name. You can change the any of the fields later. There's no approval process and you can instantly start sharing code.
Between deciding to share your code and actually sharing your code, SourceForge provides a four page registration form and a one to three day wait.
Yet their documentation on open source software states, "The essence of the Open Source development model is the rapid creation of solutions within an open, collaborative environment."
Right.
Here's my suggestion for SourceForge:
They should cut their registration process down to a single page, remove the 200 character "please host my project" plea, be more lenient on the categorization, suggest an open source license for you, then allow you to change any of these things after your project has been created.
They also should make project creation instant and run it through a spam filter or have the people they pay to manually read over and approve every single project submission instead look at a list of recently created projects and flag the ones that seem suspicious.
It seems to me all the steps and required forms are just ceremony, slowing you down and getting in the way of what you actually want to accomplish. Do they add value? Certainly not.
And if there's one thing I've learned from Rails, it's to get the hell out of the way and let people focus on the task at hand.
Reduce friction.
Newton's first law of motion, as commonly written, makes two statements: an object at rest tends to stay at rest and an object in motion tends to stay in motion. It's often referred to as the Law of Inertia.
And inertia, for those who don't remember or didn't take high school physics, is an object's tendency to resist changes in its state of motion.
If you kick a ball, it'll eventually slow to a stop. But it doesn't want to. Friction created by moving over the ground and through the air acts against the ball, conspiring to stop it at all costs.
The more friction you remove, the further the ball will go and the longer it will take to slow.
This idea of friction, it's a lot like the inverse of productivity. Being productive means getting things done efficiently and effectively. Friction keeps you from doing those things, slows you down, conspires against you, wastes energy.
And very often, friction costs you money.
A few months before the second RailsConf I left Chowhound and CNET to start a consulting company with PJ Hyett. We knew how to code, we thought we knew how to blog, but we didn't know anything about starting a business.
So, we did some research. Apparently there are companies you can pay to set up a business for you. Very officially. They'll even send you a leather binder with your company's name embroidered on it.
And there are people you can pay to do your accounting for you. We'll call them "accountants."
These are two of the most important investments you can make when starting a new business: having professionals file the paperwork and handle the numbers.
And not just because they know what they're doing.
Would you pay $100 an hour for an untrained accountant? Because if your consulting rate is $100 an hour and you do your own accounting, that's exactly what's happening.
Same thing for setting up a business. All the time you spend researching, filling out paperwork, mailing in forms, driving to Sacramento, finding a notary - it adds up and becomes expensive if you do it on your own.
Unless, of course, your time is worthless. But you're here, so it isn't.
And because your time isn't worthless, that means repetition, tedious grunt work, and excessive configuration all cost you money. Well, and time. Time is pretty important, too.
I think a key part of being a good developer is the ability to identify these pain points and remove them, to streamline a process.
Rack, for example, is great because it makes interfacing with web servers so easy.
Git's branching and merging are always touted as a selling point.
We all love Rails because it makes most of the tedious stuff go away.
And testing is famous because, well, bugs and bad design are the worst.
So let's follow these examples. Let's create more projects that scratch an itch or ease some pain. Let's stop obsessing about which test framework to use and start obsessing about building sites that solve problems. Let's stop arguing about languages and continue improving our favorite ones. Let's stop blogging lengthy tutorials to get RSS subscribers and start contributing to official documentation efforts.
Let's focus more on code and less on talk. More on the community and less on ourselves.
Actually, I think we're already on the right track. The Ruby Heroes awards are a great idea and are being given to the right people. Sites like Rubyflow and even Twitter make it easier than ever to find new, interesting projects. Calendar About Nothing makes it simple to find passionate developers and peek at what they're working on, while RailsCasts and DocRails are some of the finest documentation efforts in any community.
So, yeah. More of that.
After all, do we really want to be rock stars like Kid Rock or Axl Rose? People who are famously unreliable - who have reputations for degrading their fans and are renown for their planet sized egos?
I think I'd rather work with and be a good developer.
Thank you.
Great post :) Thanks