RTFM

Your github account is not your portfolio, but it’s a start

August 24, 2011 Job hunting, Open source 6 comments , , ,

Gina Trapani started a Google+ thread about using Github as a portfolio of your work to show potential employers. This in turn was prompted by a blog post by PyDanny titled “Github is my resume.” It’s a great idea, but it’s only a start. Your portfolio should be more curated than that to be effective.

I shouldn’t complain too much. Far too few job seekers consider the power of showing existing work products to hiring managers. That’s probably because so few employers ask to see any. In my book Land the Tech Job You Love, I cite Ilya Talman, one of the top tech recruiters in Chicago, estimating that only 15% of hiring managers ask to see samples of work.

Consider the manager looking to hire a computer programmer. She has hundred résumés from respondents, all claiming to know Ruby and Rails. She knows that anyone can put Ruby, Rails, or any other technologies into a résumé without knowing them. Even well-meaning candidates might think “I read a book on Ruby once, and Rails can’t be too tough, so I’ll put them on my résumé.” Looking at sample code is a great way to separate the good programmers from the fakers.

Since creating a repository of someone else’s good code is only slightly more involved than putting “Ruby on Rails” in a résumé document, a good hiring manager will ask in the interview about the code. When I interview candidates, I ask for printed code samples of their best work for us to discuss. Pointing at a given section on the paper, I’ll say “Tell me about your choice to write your own Perl function here instead of using a module from CPAN“, or “I see your variables seem to be named using a certain convention; why did you use that method?” In a few minutes, I can easily find out more about the candidate’s thought process and coding style than a mile-long résumé. This method also exposes potentially faked code.

So as much as I applaud candidates having a body of work to which they can point employers, simply saying “Here’s my Github repo” is not enough. The hiring manager doesn’t want to see everything you’ve written. Although everyone is different, she probably wants to see three things:

  • quality of work
  • breadth of work
  • applicability to her specific needs

Most important, she doesn’t want to go digging through all your code to find the answers to these questions.

Consider my github repository as an example. There are 28 repositories in it. Of these, nine are forks of other repos for me to modify, so clearly do not count as code I’ve written. Three repos are version control for websites I manage. Some are incubators of ideas for future projects that have yet to blossom. My scraps repository is a junk drawer where I put code I’ve written and might have use for later. How will an interested employer know what to look at? It’s arrogant and foolish to tell someone looking to hire you “here’s all my public code, you figure it out.” It’s the RTFM method of portfolio presentation, and it doesn’t put you in the best light possible.

For an effective portfolio, choose three to five projects that show your best work, and then provide a paragraph or two about each, describing the project in English and your involvement with it. There is literally no project or repository, on Github or elsewhere, about which I can say “This work is 100% mine.” Everything I’ve ever worked on has had work contributed from others, and the nature of those contributions needs to be disclosed upfront and honestly.

None of this is special to Github. There are plenty of online code repositories out there, such as Perl’s CPAN, which can act as a showcase for your work. Of course, you can also create your own online portfolio on your website as well. The keys are to highlight your best work and accurately describe your involvement.

A common complaint I hear when I discuss code portfolios goes like this: “Most of my work is private or under NDA, so I can’t have a portfolio.” Hogwash. You can go write your own code specifically to show your skills. If your area of expertise is with web apps, then go write a web app that does something fairly useful and publish that as your portfolio. Assign it an open source license so that others can take advantage of it, too. You’ll be helping your community while you help your job prospects.

Do you have an online code portfolio? Let me know in the comments, and include the URL for others to see.

Toward ending RTFM marketing in open source

July 20, 2011 Open source No comments , , ,

Too many times I’ve seen a conference announced once, and then never heard about it again. It’s what I call the RTFM method of marketing: Either you happen to know about the event, or you lose out. This year for YAPC::NA, the annual North American grassroots Perl conference, lead organizer JT Smith isn’t going to let that happen.

No sooner had the 2011 conference wrapped up when JT started daily postings about 2012’s event to the YAPC::NA blog. He plans to keep that pace going for the next year, until June 13th, 2012 when 2012’s event start. The goal is to keep people thinking about YAPC::NA in the next eleven months, and to keep everyone’s expectations high. “Everyone at YAPC 2011 laughed at me when I said I was going to do a blog post a day,” JT told me on Sunday, “but I’ve got the next 300 postings planned out.”

It’s not just frequency that’s different this time. JT’s writing about the details of the conference, and why you’d want to attend. His posts give tips about the best way to travel to Madison, and attract potential attendees with views of the conference location on the lake. A “spouse program” for the non-hacker members of the family is also high on his publicity list.

As JT and I ate lunch at the bar where he hopes to have a YAPC beer night, we discussed the mechanics of this ongoing communication campaign. JT has the next thirty postings written and posted to Tumblr with future publication dates, letting him create postings in batches, rather than every day. “I chose Tumblr for the blog because it has the best posting scheduling system,” he told me.

You can follow the YAPC::NA Twitter stream at @yapcna, or the blog itself at blog.yapcna.org.


I give “RTFM marketing” that name because it’s an extension of the geek notion of RTFM. “RTFM” comes from the rude geek response of “RTFM”, or “Read the F-ing Manual”. It’s used as a reply to a question that the geek thinks should not have been asked, because the information exists somewhere that the querent could have looked himself. It’s as if the rude geek is saying “The information exists in at least one place that I know of, and therefore you should know that information, too.”

The idea that one should just have known about a given piece of information applies to this sort of undermarketing as well. Project leaders seem to think that when information has been published once, everyone will know about it. The RTFM marketers expect that everyone know what they do, read the blogs they do, travel in the same online circles as they do. This is a recipe for failure.

This mindset can be crippling when it comes to publicizing projects and events. Organizers do their projects a disservice when they market their endeavors with the expectation that everyone will automatically know about something simply because they’re written one blog post about it.

RTFM marketers also don’t spread their messages wide enough. They advertise to the echo chamber of the circles in which they normally run. They’ll post to the standard blogs, post to the mailing lists they read, or discuss it in the IRC channels they frequent. This limits the potential audience for the project to the one with which the project leader is already familiar.

Tips for doing open source project marketing right:

  • Write & post frequently.
  • Write & post in many disparate locations.
  • Explain the benefits. Explicitly tell the reader why they would want to attend your event or use your software.
  • Change your messages. Don’t post the same thing twice.
  • Never assume that someone will have read your previous message. It’s OK to repeat something stated in a previous message.
  • You don’t know your potential audience as well as you think you do. Think big.

I’d love to hear stories and ideas about how you got the word out about your project.