Note: Besides being inspiring, this post is very enlightening. It reminds us to put our feet back where they belong: on the ground. It also shows that we can accomplish many great things by making the right choices and doing the one beneficial, sustainable thing in the programming world: reading, writing, and sharing code. If any part of the translation could be improved, feel free to suggest a change. You can find the original text here. And now, here's the translated text:
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 programming ninja. It’s not hard: just focus like a laser and have a little patience.
Let me say upfront that you don’t need to worry about any programming skills or ten thousand hours of practice. That doesn’t matter—it’s easy to fake.
So! The first thing you need is a blog. But not just any blog. You need a blog with personality. It doesn’t matter whether the blog’s personality matches your own.
The most important part of any blog is its name. Obviously. It can’t be “John’s Blog.” Or maybe it can—it might be retro by now. But you know what I mean. Don’t choose a name you’re unhappy with, because if you make the right choice, you’ll never hear the end of it. (The name might be good, but if you don’t like it, you’ll end up abandoning it.) It’s like naming a band. Or a child. Make sure it’s something people will remember.
And try not to be too Railsy. That’s limiting—make it your own. It is your blog, after all.
I shouldn’t have to say this next part. I hate to say it, but I have to: never use a default blog template. That’s shooting yourself in the foot.
Here’s why: eventually you’ll publish quality content on your blog. Not right away; don’t rush. But you’ll write some really good posts. They’ll be linked on Hacker News and Reddit, “tweeted” and saved on Delicious, and, if you’re lucky, you’ll get a mention on a podcast or two.
The first time someone visits your blog, if the content is good enough, they’ll appreciate it. Maybe they’ll 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’ve been here before. This was good!”
I don’t know exactly how many quality posts you’ll need, because it depends on the individual. Some people connect immediately. They don’t hold back. Others are slower—they make you work for it. Three, four, maybe five wonderful posts before they connect. But they’ll connect.
The idea here is association: if your blog uses a template with no identity, nobody will remember that they’ve been there before or read a good post there. You’re fighting an uphill battle.
Spend time on the design. Maybe hire someone, do a few favors for a designer friend—I don’t know, you’ll figure it out.
And when you do, you’ll have a killer name and an elegant design. A good start.
Now for the customizations: the sidebar, the header. Those essentials.
If you’re going to put a list of blogs you like in the sidebar—and I wouldn’t—you have to be careful. If the blogs are very popular, people will think you’re a follower. If they’re too obscure, people might think you keep bad company. Better to play it safe and leave the whole thing out.
In fact, I keep my sidebar sparse. Very sparse. No tag clouds, recent comments, or recent posts. Maybe just an archive that creates a monthly list. Listing interesting projects can be good.
Oh, and your email address. People will want to email you.
But, as I said, keep it sparse. Don’t distract people from your content.
And never use Google ads—you’ll eventually want to join a sponsored-ad network. Google ads just devalue the product (your blog).
The header is important because it’s the first thing people see. A photo of you is probably best. Something distinctive. But if you can’t fit it in the header, the sidebar works just as well. Remember: people have to recognize you, to know you’re John from “John’s Blog.”
As for the content, you need to decide on your persona. Make a list of ten or more famous Rails developers, maybe in a spreadsheet, and choose an adjective that describes each one’s persona. Go through the list and choose the combination that works for you. Playful and spontaneous? Professional and inspiring? Offensive and long-winded? Pick two traits you think you can pull off. Write them down. That is now your blog’s persona.
The final step before blogging is setting rules. You need to establish guidelines for your blog—rules about the content. If Hashrocket starts talking about Scala, can you join the discussion? Can you 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’d avoid making esoteric tricks your core competency, but indulge the urge occasionally to maintain your credibility. That’s just me, though.)
The important thing about rules is that they help establish consistency. You don’t want to post about a great library once and never mention it again. That confuses people. They want something structured.
Give it to them.
Okay, with all that said, we can start blogging. But we aren’t really blogging yet. We’re just practicing. Every day, you need to write a post. It doesn’t matter what it’s about. Nobody will read them. But you need to practice writing and refine your tone. Give your blog a personality.
What should you post? Anything. Instead of just making a Gist out of your beautiful piece of code, write about it on your blog. Add a little backstory. But don’t go on and on about it—unless, of course, that’s your tone, your persona.
The great thing about starting a new blog is that you can go back and look at old Gists, old plugins you’ve written, crazy rake tasks, and pretend they’re brand new. Write it up. Make a post. It’s new to everyone else.
Another good trick is to look at what other bloggers are doing, and improve popular libraries or techniques they’ve pioneered. That way, they’ve done most of the work, but because you’ve made it a little better, you might get some attention from them.
Talk about testing. Complain about something that’s missing. Maybe even start an issue about another blogger’s code. It doesn’t work for you, so it’s crap.
After a few weeks, we can start doing something 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 thoughtlessly “tweet” your blog posts—that’s a huge turnoff. And you don’t want to “tweet” that you’ve just started a blog, because there’s nothing there yet and it’s a wasted opportunity.
Instead, you could change your Twitter design (the background, link colors, all of that) to match your blog. Make them greet each other. Dress it up for success. And be nice.
That way you’re not just some random Rails developer; you’re the author of “John’s Blog.” You’re John. Make sure your avatar has your face, too.
Actually, why not fire up Photoshop and make one of those social-media backgrounds for your Twitter account? You know what I mean—all those links that people can read and, of course, might not click. Those backgrounds let people learn about your business and find you conveniently.
Your tweets will probably follow the tone of your blog, but—and this is the fun part—you can break the rules here. Let people know something about you. Like a reality show.
Anyway, let’s move on. You’re up and running, you’re “tweeting,” you’re “blogging,” you’re feeling good. Time to attack.
Put out the first post that you really think is good. “Tweet” about it, post it on social-news sites, and fight to get a link on Rubyflow. Do it early on a weekday morning, Eastern Standard Time (USA and Canada), because people love to refresh 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 visitors and readers is to release small, useful pieces of code directly in a blog post. Show people the problem, show them the solution, tell them how to install it, and provide a way to download it.
Another way is to rant. But you have to do it a lot.
When it comes to identifying and releasing useful, simple code, don’t spend too much time thinking about it. Go about your day and your normal routine, but keep an eye out for things that frustrate you—things that frustrate your coworkers.
Did an idiot mess with your production code? Are repetition and errors considered safe practices? Is there a bug in the authentication for a plugin you’re using?
Keep your eyes open, and when you spot a pain point—something that creates friction in your workflow—write it down. Save it somewhere.
Later that night, pour yourself a glass of wine, maybe a glass of whiskey, sit on the couch, and write a solution. Keep it simple, and make sure you can finish the library or plugin in one night. Then write a blog post and publish it.
Rinse and repeat.
If something causes you pain, it probably causes someone else pain too. We’re all Rails developers with very similar tasks. Well, most of us.
Eventually, you’ll hit the jackpot: something simple that few people want to use. Maintain it, accept patches, and move on.
As you gain confidence, you can start looking for more ambitious problems and solutions. You’ll get more recognition.
Now you’re ready for the conference circuit: local RubyConf events, meetups in your city, and the Holy Grail, RailsConf (in Brazil: Rails Summit Latin America). Take on a serious project and talk about it. Post updates on your progress. But don’t forget to maintain your tone and follow your rules. Go to the coffee breaks and meet people. Let them know you’re John from John’s Blog. Never take off your name badge.
Keep posting consistently. 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 lots of it.
Keep track of what everyone is saying about your posts on Twitter, Delicious, and FriendFeed. You don’t have to reply, but I’d check for your posts on all these services frequently. Check a few times a day.
If you contribute to Rails itself, that’s huge. Other famous Rails developers will start to notice you. The same goes for blog comments—especially on the ten blogs on 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 send you books and ask you to blog about them. You’ll be invited to speak at conferences. You’ll be recognized on the street. Recruiters will fill your inbox. The things you say will matter. Your blog will be sponsored. Maybe you’ll even write your own book.
And, of course, you’ll have to hang out with the famous people. You’re one of them now, 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 everything I said. Boom, I guarantee it’ll work.
Personally, I look up to good programmers. They don’t worry about their RSS subscriber count; blogging is secondary for them. They aren’t worried about how many Twitter followers they have, and they work on their projects every week because they love doing it. They’ve contributed to Rails for years out of passion and aren’t overly concerned with publicizing their lives.
People who care about code, first and foremost.
There’s always talk about putting IRC or Twitter handles on conference badges so you can identify people you’ve met online but never in person. Why don’t we just skip that and put the favorite project you’ve contributed to there instead?
“You contributed to Rack? That’s great; I love Rack. Maybe we can be friends.”
“You worked on Webrat? Could you explain it to me?”
Think about it—do you know the people involved in your favorite RubyGem? Your most-used plugin?
They’re probably the people you want to spend time with.
Code, I realize, is the common thread that connects developers. Not blogging, trolling, or procrastinating, but the fact that we love code.
It’s about reading, writing, and sharing code.
And the more I blog, troll, and procrastinate, the more I think code has brought me the greatest fortune. The greatest return on investment with the lowest risk.
After I left college, I worked with PHP at a company building delivery-logistics applications. We were the middlemen between independent carriers and big companies like Kmart. Carriers would register on our site, say they would be in Delaware on May 3 and were heading to Denver, and then get information about shipments along their chosen route. They could then bid a higher price for a shipment or accept the stated amount, all through us.
It was a pretty complex application, and it was missing two things: version control and constants. There was no version control, so you had things like main2.php and compute_radius_of_from_shipment7.php scattered around, along with versions 0 through 6 of the same file in the same directory. Truly painful.
There were no constants or configuration, so the source code was full of magic numbers. If you wanted to adjust one of our algorithms, you had to find the code doing the processing and manually change some numbers. We just hoped the numbers were right.
Naturally, the first thing I did was institutionalize Subversion. King of version control systems.
The second thing I did was extract the magic numbers and put them in configuration files. At the time, we wrote PHP code that accessed .ini configuration files. It supported most of what we needed, and I was delighted that PHP came with a library for accessing and parsing .ini files.
This system worked well, but when I started working with Rails, I fell in love with YAML. So clean, so powerful. There was Syck, a C extension written by _why, but that was all it was: a C extension. I didn’t know much about loading C code into PHP, and even less about doing it on our production servers.
So I started writing a YAML parser in PHP in my spare time. As a tribute to Syck, I called it Spyc—SPYC, a Simple PHP YAML Class. It was my first parser; it was stateful (it kept state as it ran). I didn’t support all of YAML, but it supported the main features—dumping and loading. The good parts.
I threw myself into it, and before long we were using YAML successfully at my company. Naturally, I uploaded the code to SourceForge. King of source-code hosts. My designer friend made a website, and in its first month Spyc was a huge success. 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 goodbye, drove eleven hours to Hackensack, worked one day at the office, realized all my coworkers were complete suck-ups, got back 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 totally qualified. I had eight years of programming experience—I did some QBasic when I was 12. I was sure that counted.
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 people at GameSpot were looking for, but I applied. I put together a new résumé and stayed up all night working on the cover letter. By the time I was done, it was a full page and pretty convincing.
In it, I promised to move to California the next day, taking nothing but my guitar and Xbox. My family would lose me, but I was ready to leave, and I was eager to show the world what I could do. Ready to learn from the masters.
The phone interview went well. They liked that I was familiar with Macs and Ruby, and I obviously got the job. The first time I set foot in California was when I flew out with my dad to look for an apartment.
My work experience wasn’t what got me the job. I’m sure my cover letter had something to do with it, but my brief career in transportation logistics wasn’t very glamorous. I had only 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 browse it online. Whether or not they thought it was good, they could see that it was clean and well organized. Well, maybe not—but I had a website and 70 downloads.
I got the job at GameSpot. In my opinion, the first major step on the path that brought me here was thanks to code—code I wrote mainly for fun, to scratch my own itch.
That was pretty cool, and I thought it was a one-off, until it happened again. While I was working at GameSpot, I kept doing more and more Ruby on the side. I had an open-source Rails project called Ozimodo, a terrible FTP server called ftpd.rb (which I used to learn about threading), and a command-line DSL parser called Choice. For Choice, I had a complete test suite (I wrote the suite to learn TDD) and a homepage generated by RDoc on RubyForge.
When CNET, GameSpot’s parent company, acquired Chowhound, they decided to rewrite the site in Rails. From scratch. Classic. They brought in two Rails programmers from Wayfaring.com and went looking for another. Then they found me.
Later I found out that my RDoc site, RubyGem, and test suite had convinced the Wayfaring guys that I was a “real” Ruby programmer. They wanted someone who was excited about this stuff, and I certainly was.
That was a big moment, because I got to go to RailsConf 2006.
Conversations About Code
If you don’t have any projects right now, spend some time here starting something new. Something that makes sense to you, but that you don’t already have around you. An idea that’s been floating around.
Or just find someone who’s hacking on something and ask what they’re working on. Maybe it’s interesting enough for you to jump in.
If you want to start your own company, code is the perfect way to find co-founders and employees. I always feel bad for the business types who post in forums asking the best way to find a co-founder or CTO. Not because of the kind of business they’re in—we all have to live with our decisions—but because I don’t think it should be a problem.
I met everyone else at GitHub through code: PJ through Chowhound, Tom through his open-source work, Scott because of his almost annoyingly large collection of Ruby-based Git libraries, and Tekkub because he knew the Lua section of the site inside out.
At CNET, we found some really talented people through both open-source and local projects.
And everyone you’ve met here whom you didn’t know before the conference, technically, you met through code.
GitHub didn’t become popular because of Git. That may have helped, but it wasn’t the main catalyst.
GitHub became popular because it deals with code. Sharing code, finding code, and contributing code.
RubyForge and SourceForge aren’t focused on code. They never were.
In fact, just yesterday SourceForge redesigned its homepage. It has Twitter search and popular projects front and center. Slick. So I clicked around.
The first project I clicked, Ares Galaxy, is number seven on the top-ten list. The CVS viewer said it had no files. So I guess you can just download a tarball. Which is fine.
The second project I clicked was number five on the list, 7-Zip. It doesn’t even have a link to a source-code viewer.
No code.
I realized it had been a long time since I’d created a project on SourceForge, so I decided to do that. I remember it being painful, but this was a new 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 field is thoughtfully provided so you can explain to the SourceForge staff why you should be allowed to create a project. And, of course, you can’t continue without giving them a reason of at least 200 characters.
I think that’s crazy—most days I have trouble with 140 characters.
There’s also a notice at the top saying you need to host open-source software.
After you’ve filled out all the fields and clicked “Next,” you’re asked to choose an open-source license. Eight licenses are listed, along with an “other” option and a link to documentation about open source and choosing a license. I chose MIT.
On page three, you can assign at least five categories to your project. The category options include things like “Programming Language Ruby,” “User Interface DirectX,” and “Development Status Beta.”
I chose four very easily, but I had trouble with the fifth. I ended up with “Religion and Philosophy Theme: New Age.”
Very appropriate, if you think about it.
On the last page, you’re asked to read about what open source means and the site’s terms of service, then submit the project for approval.
After submission, a thank-you screen appears and asks you to wait one to three business days.
I obviously have an interest in disparaging a competing site, but this signup 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 a project name, a short description, and the project’s URL. Below those three fields are two radio buttons: Is this project public or private? Only the project name is required. You can change any of the fields later. There’s no approval process, and you can start sharing code immediately.
Between deciding to share your code and actually sharing it, SourceForge puts a four-page signup form and a one-to-three-day wait.
But its open-source software documentation says: “The essence of the Open Source development model is the rapid creation of solutions within an open process, collaborative environment.”
Exactly.
Here’s my suggestion to SourceForge:
Cut the signup process down to one page, remove the 200-character “please host my project” requirement, be more flexible about categorization, suggest an open-source license, and let people change any of these things after the project is created.
They should also make project creation instant and run it through a spam filter—or have paid staff manually review and approve each project—instead of looking at the list of recently created projects and flagging the suspicious ones.
It seems to me that all these required steps and forms are just ceremony, slowing you down and making you waste time on something other than 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 out of the way and let people focus on the task at hand.
Reduce friction.
Newton’s first law of motion makes two claims: an object at rest tends to stay at rest, and an object in motion tends to stay in motion. It’s often called the law of inertia.
And inertia, for those who don’t remember or never took physics, is an object’s tendency to resist changes in its state of motion.
If you kick a ball, it gradually slows down until it stops. But it doesn’t want to stop. Friction created by its movement along the ground and through the air acts against the ball, conspiring to stop it at all costs.
The more friction you remove, the farther the ball will travel and the longer it will take to stop.
This idea of friction is much like the inverse of productivity. Being productive means getting things done efficiently and effectively. Friction keeps you from getting those things done; it slows you down, works against you, and wastes energy.
And 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 and thought we knew how to blog, but we knew nothing 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 even send you a leather document folder with your company name embroidered on it.
And there are people you can pay to do your bookkeeping. We’ll call them “accountants.”
These are two of the most important investments you can make when starting a new business: professionals who handle the paperwork and people who handle the numbers.
And not only because they know what they’re doing.
Would you want to pay an inexperienced accountant $100 an hour? Because if your consulting rate is $100 an hour and you do your own bookkeeping, that’s exactly what’s happening.
The same goes for setting up a business. All the time you spend researching, filling out paperwork and forms, and driving to Sacramento to find a notary adds up—and gets expensive—if you do everything yourself.
Unless, of course, your time doesn’t matter. But you’re here, so that’s not true.
Since your time isn’t worthless, that means repetitive, boring, hard work, and all the excessive setup costs, are costing you money. Well, and your time. Time matters a lot, too.
I think an essential part of being a good programmer is the ability to identify these pain points and remove them, to streamline the process.
Rack, for example, is great because it makes interfacing with web servers so easy.
Git branching and merging are always cited as the reason people choose it.
We all love Rails because it makes most of the tedious stuff go away.
And testing is famous because, well, bugs and bad designs are awful.
So let’s follow those examples. Let’s create more projects that scratch an itch or relieve some pain. Let’s stop obsessing over which testing framework to use and start obsessing over building sites that solve problems. Let’s stop arguing about languages and keep improving our favorite one. Let’s stop writing long tutorials to get RSS subscribers and start contributing to the official documentation.
Let’s focus more on code and less on chatter. More on information about 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 they’re 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 easy to find passionate programmers and take a look at what they’re working on, while RailsCasts and DocRails are among the best documentation efforts in any community.
So, yes. We want more of that.
After all, do we really want to be rock stars like Kid Rock or Axl Rose? People who are famously irresponsible, with reputations for mistreating their fans and egos as big as the planet?
I think I’d rather work with and be a good developer.
Thank you.