The Truth About Side Projects

This a chapter of the book Get a Better Developer Job. It’s best to start at the beginning.

This chapter we get deep into side projects. Everyone has an opinion on them. Strong opinions. But this is what I learned when I started ignoring opinions and listened only to firsthand accounts form hiring managers, interviewers, and successful developers. I cover:

• What’s the deal with the GitHub résumé?
• Avoiding legal trouble
• Making money with side projects
• A shortcut to prestige
• What to work on when you’re out of work
• Switching tech stacks

Much has been said about the value of side projects, or the famous (notorious?) GitHub résumé. The first thing to realize is that it in no way replaces your professional experience. As one manager said, “If you’re not killing it at work, don’t think about side projects.” Get your house in order. Learn whatever skills and productivity hacks needed to improve your work performance.

If you are crushing it at work, and that job is keeping you marketable (current skills, interesting/challenging projects, a prestigious employer), you won’t need any side projects. Maybe learn to juggle chainsaws or catch flies with chopsticks. Or – gasp! – spend time with friends and family.

I say this because I’ve asked many managers and developers for clear examples where someone was hired because of a side project. I got a couple examples where it helped, but none where it was the main reason for hiring.¹ If this is confusing, you may have experienced what I have: an overwhelming number of opinions, based on a single anecdote (if that), and spoken as fact. As with everything in this book, I’m illustrating what is, not what should be.

While a side project won’t get you the job, it can get you an interview. If work is not keeping you super marketable (or super happy), it can help. Here are some guidelines to follow.

Visit HR

Almost every employment contract states that work you create on your own time, on your own equipment, still belongs to your employer. Joel Spolsky wrote a great piece on this. If it doesn’t compete with what your employer does, 99% of the time HR will grant you a waiver. A shockingly high number of people read that and think, “OK, then I’m sure it’s fine,” and proceed to work without a waiver. Don’t. This is one of those cases where it is much harder to receive forgiveness than get permission. You get permission from HR but must ask forgiveness from a legal department hell bent on “not setting a precedent.”

Speaking of your employer’s code, never show that to a prospective employer. Assuming it’s not open source, they don’t have a legal right to see it.² You may be violating a contract (or law!) by showing it to others, and whomever you’re showing it to will be worried you’ll do the same with their code after you leave.

Are you an entrepreneur?

I’m not a huge fan of working for free. Coding is a valuable skill set, so I want to see a return on my effort. If you have an entrepreneurial bent, build something that will make you money. This doesn’t (and shouldn’t) be anything big. Solve a problem you have with code, turn it into a product, and charge for it. If it’s something you can crank out in a weekend, even better. Entrepreneur Kurt Elster put up the (now defunct) Calming Manatee website in a weekend, tweeted it, slapped AdSense on it, and it became a cash sea-cow. It demonstrates knowledge of promotion, filling a need, analytics, and having a sense of humor. Does it prove you’re a great coder? No, but it demonstrates product-market fit.

Or you can make something a bit more complex. Look at Buffer. At the beginning, all it did was space out tweets for you. But it had user management, security, payment processing, web service integration (Twitter) and I’m sure things like admin and logging. There are also app marketplaces for various platforms like Salesforce, Google Apps, and other SaaS offerings. If it has a public API, it has potential.

Once you get it running, start polishing the code. Read the following to get you on the right path:

1. Clean Code, or Code Complete if you’re a Microsoftie.
2. Your language’s style guide. Some companies and open source projects publish their own, which could give you an edge if you interview with them. Google even has theirs on Github with config files for several editors.
3. The most popular book for your language. “What books have you read?” is a popular interview question in shops that value continual learning, and this can help establish rapport with your interviewer.

While reading, employ those best practices. Make it pretty. Use idioms and solid OO principles. That’s not a lot of effort for small projects, but looks really good to a prospective employer. And you’ll feel good to have created something of quality.

Even if you don’t have an idea yet, you can start. My company has a project called Launchpad that we use as a starting point for new apps. During down time, we keep it up to date with the latest framework and plugins, Bootstrap-styled templates, user management, etc.

If you’re interested in high scalability, you might make it a simple 12-factor app. You could even borrow an open source app (CMS, ecommerce, etc.) to learn cloud deployment, continuous integration/deployment, and other DevOps concepts.

Open Source Shortcut

If making and selling something isn’t your thing, you can still impress employers with an open source contribution. I don’t mean open sourcing something you wrote for school or as a personal project. Why?

You goal is to present production quality code. Personal projects or homework assignments – even if they are big, like a graduate thesis – rarely need to be production quality code. They just need to satisfy your instructor or solve a problem for you alone and run on your personal machine. Security wasn’t a consideration, but it’s a huge part of being production ready. Writing code that safely handles multiple users, safeguards their PII,³ and processes payments is a big deal. An interviewer should be able to look at your work and think, “This is mature, well crafted, clean, secure. It would pass a code review and QA here.”

Now, you could create something from scratch and make it popular. That’s awesome and could get you a job on its own, but very unlikely to happen. It’s not too different from launching a startup.

It’s much easier to contribute to a well-known project and doing so is a really big deal. People take notice!⁴ Especially if it’s a bug or feature request with many votes. That may not be easy, but you’ll learn a lot and make good connections in the process. It passes the production-ready test because it was reviewed by team and is now running in production at many companies. It’s a path to consulting for that project, too, which could be lucrative.

Pick something you know well and is well known. It could be a small part of big framework (e.g., Rails, Spring, Grails, Angular, Zend, Node.js, Django, etc.), or a popular library like Bootstrap. Something relied upon by many companies and engineers. This may not be easy, and you may feel intimidated at the start. Shrink the problem. Maybe start by helping with documentation. Then understand and improve one small part of the code.

Another idea is to extend it via plugins or similar. You can take a popular plugin for one framework (say, Rails) and port it to another like Grails. Or write something to integrate a service. You might also look at abandoned plugins with a good user base and contact the creator about maintaining it. Abandonment happens often when prodigious contributors and/or early adopters switch ecosystems.

If you’re excited by consulting, consider applications instead of frameworks. If you’re a PHP hacker, you’ve got Magento, Drupal, and Mautic.⁵ Each language has some reasonably popular FOSS application you can master and extend. A guideline I learned from The Freelancer’s Show is if it has its own conference, it’s viable. And don’t forget, you can sell plugins and modules for these apps. In the enterprise world, these can go for thousands.

Before you contribute, ask maintainers about a project style guide and submission guidelines to make it easy on them.

Are you unemployed?

If you’re out of work and aren’t sure how long before you’re employed again, your first priority is following the advice in the other chapters. Fix your résumé and start preparing for interviews. I’d devote half your time to that. Rest assured, it’s not wasted effort, as it really will make you a better coder.

Pivoting

Do you have marketable skill set you’re not fond of? Maybe older tech with a shrinking job market. There are three ways to fix this.

The first is through gambling. Pick a technology that is new but looks like it will take off. You’re competing with very few people so if it does take off, you’ll stand out from the crowd. Think of the developers who used on Rails pre-1.0 or had an app in the Apple App store shortly after launch. Those people make bank. They’re sought after by companies and conferences. Yes, it’s a risky move. You’re trying to predict the future of tech, which is crazy. If you’re not plugged in, you can contact me and I’ll give you my personal predictions. I don’t have a crystal ball, so no guarantees, but I’ve got a reasonable track record. There’s a good chance in the early days you’ll have to move to get work, but not more than a year or two. Keep building authority and you’ll have nice gigs working from anywhere.

The second way is to do this on the job. It may seem hard to change what your team uses, but you won’t be the first to do Résumé-Driven Development™. Others on your team are interested as well. The easiest is to move one step away, like going from Java EE to Spring/Hibernate, or from that to Grails. Or to the latest framework version, especially if you’re a couple major revisions behind. You may first need to introduce unit and integration testing plus CI if you don’t have those already. But that’s good to have on the résumé, too.

If it has a big enough buzzword attached, management will approve. Look at big data. Every honest big data expert will tell you it’s stupid to build a Hadoop cluster for data that fits on a single machine. You could throw it in PostgreSQL or process it with Talend (or Excel!) and be done with it. Yet this happens all the time because management wants to pad their résumé, too.

In fact, with big data in particular, you have to do it at your current employer if you want to pivot without getting a masters or PhD. Nobody I know is hiring people based on Coursera classes and sample data sets. They want to see real world experience or a degree from a good school.

Third is to follow the entrepreneurship route as described above, but with a different technology. Getting into mobile now and standing out is tough, now that the iPhone is over a decade old. But if you have domain knowledge, even from a hobby, you can leverage that to scratch an itch, or build something easier to use. Could make you money, too, but check with legal first.

Help somebody's career:

Next chapter: Certifications