Where to find me online

October 4, 2011 Internet, Social No comments , , , , , , , , , , ,

Although I mostly write to my blog and my Twitter feed, here’s a dump of most of my online presences.
My blog is where I post about technology and job hunting and careers.
@petdance on Twitter
My main outlet for posting short thoughts and links to interesting stuff. (I try not to engage in conversation on Twitter, because I think it’s annoying for everyone but the two people involved in the conversation.) If you were following @theworkinggeek or @techworklove on Twitter, switch to @petdance.
Perl news and the occasional original article. Most of the blog traffic is a weekly recap of the news bits posted to the @perlbuzz Twitter feed.
I’ve whittled down my Facebook friend roster to mostly friends and family and people I know in day-to-day life. I’ve found that I’m not interested in the day-to-day lives of people I only know from the world of open source. Therefore, most of the friend requests I get from people I only know online get ignored.
I’m not sure how I’m going to wind up using Google+. Mostly I’ve been posting longer-form blurbs or embedding media.
Slideshare and Speakerdeck
I’ve always been posting slides of my talks on Slideshare, but Speakerdeck has just popped up and I like their interface much more, so I’ve put some content there, too. Look for Speakerdeck to gain more traction in the programming community.
I have yet to have anything useful come out of LinkedIn, but I maintain a network there as well. My rule for adding someone as a contact on LinkedIn is that it has to be someone with whom I’ve actually worked on a project.
Github is where I host most of my open source projects. Love love love.
Flickr and twitpic
I’m not at all a photographer, but there you go.

Did I forget one? Leave me a comment.

“Building and Managing a Project Community with Github”, St. Louis, MO, 2011-09-03

August 31, 2011 Open source 2 comments , ,

On Saturday, September 3rd I’ll be presenting “Building and Managing a Project Community with Github” at ArchReactor, a hackerspace in St. Louis, MO.

Jefferson Underground Building
2400 South Jefferson Avenue
St. Louis, MO 63104

There will be a social hour from 4:00-5:00pm, and my presentation starts at 5pm sharp. I hope to see you there!

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.

“Building and Maintaining a Project Community with Github”, my talk at OSCON 2011

July 16, 2011 Open source No comments ,

Here’s the OSCON page link to add to your schedules. has taken open source by storm, but it’s more than just a code repository with the latest hot source control system. It’s a new way of working with open source projects.

The web-based social aspects of github can change the human and technical dynamics of working on open source projects. Some of the issues I’ll discuss include:

  • Easier access to code means lower barrier to entry means more people submitting patches. This is a boon, and brings challenges.
  • People seem to expect patches to be accepted because of the ease with which change sets are created. These expectations may clash with project goals.
  • Watching the github fork network lets you see what other people are doing with their forks. It allows me as a project admin to see what people are doing with the code.
  • New workflows are required. A branch and merge strategy for development is crucial.
  • Projects need a guidemap to tell people what to do, because people may think it’s just a simple matter of creating a fork, making a change, and saying “Here’s my work, now integrate it.”
  • Project branches can easily become large, hard-to-handle change sets. Less care and thought is put into change sent back to the project because merging is so easy. Contributors still must work together to coordinate work.
  • Discussion of patches has moved from the mailing list to the change request itself. This can diminish visibility and discussion.

I’ll discuss these and other aspects of community and project management and give examples from my own experiences migrating existing projects to github.