Learning from a Year Old Project, Part 1
Today marks a milestone that I didn’t quite expect to reach so fast. A little over a year ago, I made the first commit of a project that took both me and my friend Colin by surprise, and effectively led us to create our first ‘real-life’ webapp. Incidentally, it provided me a stepping-stone to become a fully-employed developer and to help a lot of very cool and passionate people with peakbagging.
It’s been amazing, and I have to thank Colin for making it a public commitment. As we discussed the timing for release, I thought back to a year ago and considered how far I’d come since - and I was surprised to see how much this little side project had helped me grow. I picked up a bunch of learnings: some of them in developing software, but also many more in regards to working as a team and managing a part-time project on a tight schedule, all the while balancing work and family.
Here’s a short list of what I picked up while working on a committed side project and being employed full time, both for my benefit and to hopefully encourage those who are considering a long-term project:
You and your team needs to care about the project. This one is key - if you have a side project that you know will be squeezed for time, you need to be very dilligent with it or it will ultimately fail. The less time you have for it, the more you need to care for its success. In our case, Colin and I wanted to have something to showcase, as well as have it for our own use. We wanted to eat our own dog food. Being actually passionate about what you’re building also sets you up for success in other ways, some of which are highlighted below:
Make it a public commitment. YMMV, but I’ve found this to work rather well. I think everyone in my close circle of friends and family was aware I was working on a “website”, and therefore kept asking me about it. You can also get your code-buddy, someone who keeps you straight over your work. GitHub contributors are fine, but friends and coworkers IRL are best. Especially if you’re working with them on the project.
Your project will eventually slip. Let it happen and figure out a recovery plan that works for you. We all have many things going on in our lives, and at some point or another your project will not be on the top of the totem pole. And that is perfectly fine. I’ve sometimes caught myself feeling anxious and guilty about not spending time on PeakBucket, and when that happens I remind myself that out of all the time alloted in my life, I would probably choose again to be with my wife over some non-essential piece of software. With that said, you need to continue working on your project if it’s ever going to see the light of day. Enjoy your day off, put time in the calendar for your project, and let someone know.
Challenging the opinions of your team and trusting them go hand in hand. There is a growth process as you collaborate on a project, where each of the members voice their opinion and tend to claim aspects of the project that they are comfortable with (though it is certainly possible that two or more people share the same domain and will go through the same process). Once people feel comfortable enough to question your solutions, you are on the fast track for full-on collaboration. It will be easy for teammates to zone in on code or design decisions they feel can be improved, while trusting each other on everything else.
Domain knowledge overlap is great - and you should develop it as much as possible.
Tests really are your friends, so write them. Your side projects are not exempt from good software practices, even more so if you are planning more people to use your project down the road. When you don’t have a lot of time to spend on changing things or tacking on new features, it is a godsend to not have to worry about changing things in a blink of an eye and hoping for the best.
Are you late? So what? A lot of people say that “if you are not unhappy with your 1.0 version, then you released too late”. However, it’s also better to release later than never. Don’t let your slips get you down – instead, think of what more you can do, and make an appointment with the project the same way you would with a dentist. General concentration techniques apply.
You have no obligations to anyone except yourself (this is your project, remember?), and it is in your best interest to be the most excellent boss you’ve ever had. Work when you feel the drive, rest when you don’t, and avoid the burnout. If you keep a sustainable pace (and your project scope allows for it), you will definitely reach the year-mark and feel awesome about it. I certainly do.