Software developers don't agree on a lot of things. You have infinite fertile ground for debate around programming languages, IDEs, frameworks, operative systems, libraries, patterns, best practices, or counter variable names. What we all agree on is that we hate wasting time on some piece of code that will not bring any measurable benefit, or worse, it will be deleted in 2 weeks. With experience, we become pretty good at sniffing that out from a distance, and, it's our responsibility to always steer the work we do into meaningful territory.
When we tackle our programming side projects we tend to have a higher degree of control than when developing software for others, and since I believe no programmer ever started a side project with the idea to get the least out of it as possible, I'm going on a limb here and say that, even if only deep down, we always have great ambitions for the software we craft.
We always want to get the most out of side projects we build. Even finish them, if we allow ourselves to go a little crazy.
This is part three, of my Side Projects Trilogy. In part one, I talked about How to Choose your Next Side Project, so that chances of getting the best out of them mount on your favor. In part two, I listed 12 Great Ideas for Programming Projects That People Will Use. And here, I'll be sharing my favorite strategies to make your side project journeys as enriching as possible.
Find a partner
“If you want to go fast, go alone. If you want to go far, go together.” - African Proverb
Working with a partner might not be the best solution for all projects and everyone. However, there's always a time where I wished I could brainstorm with someone as invested in the problem as me. Asking for help in a forum or Twitter wouldn't have the same impact. A partner would mean fewer blind spots, and fewer surprises sneaking up on you.
Your ideas get more chances to be refined into something great. Your tech stack knowledge hopefully is not a complete overlap, opening doors to leverage the best languages and frameworks for each type of problem.
The best thing about working with a partner is not tech-related though. There will be moments when life outside happens. When it will be difficult to keep advancing, where there won't even be a clear path to progress to. When one's output into the project suffers, the other can use that as motivation to keep going, knowing that a switch in roles will probably happen in the future.
The rule of thirds
“Hell, there are no rules here - we're trying to accomplish something.” - Thomas Edison
Named after the most famous photography cheat code, this is a framework to help you chose the most engaging tech stack for your project. You get the best technologies to get the work done, but with a little spice to keep things interesting.
Pick 3 main technologies for your project according to the following characteristics:
- One where you consider yourself an expert
- One you have been experiment with
- One new to you
This distribution provides some benefits, even adds some fun to the experience. First, as software developers, we are always experimenting or wanting to. This allows us to accommodate that while mixing in other technologies where our expertise level guarantees us some reasonable level of productivity from the get-go. Also, the importance of including another technology we have been experimenting with can help us complete the picture on it, letting us know it's a tool we want to keep on our arsenal or not.
Second, this is also a way to escape the boring. When you are stuck or tired of working with one, perhaps you also use it on your daily job, you can jump into any of the other two.
Know your purpose
“Never doubt that a small group of thoughtful, committed, citizens can change the world. Indeed, it is the only thing that ever has.” - Margaret Mead
This is the platform that supports any success of our side projects. The more you know why you are doing it, the easier it will be to weather all the challenges. When things get hard, it's the quality of the picture in your head of your purpose that will keep you on your path. No solid foundation, no inner reason moving you, and abandoning the journey will be the most likely outcome.
Know why you are building a side project before knowing how or what.
Try some daily affirmations and surprise yourself. Open your note-taking app every morning and write in detail why are you working on the current side project. Do this every day and don't check previous entries. After 2 weeks, check all the notes and compare them. When you zeroed in on the same entry every single time you'll notice the difference.
Small milestones into big targets
“The process of delving into the black abyss is to me the keenest form of fascination.” - H. P. Lovecraft
The pursuit of a goal gives meaning to what we do. The pursuit, not necessarily the goal. Those goals we set for ourselves can be more or less within our reach and in that balance lies some of the reasons for success in side projects.
Set small milestones along the way in your project. Group a few features, and as long as you can release them alone while still adding value you are good to go. This gives you room to breathe. You can stop at any time you want, and chances are your project is stable and doing what it's supposed to do.
Several milestones strung together can lead you into your target objective. Make this target as big as possible, allowing for deviations along the way. You might experience technological impediments, obtain new user feedback, get improved designs, etc. Some features might disappear or be developed from scratch and it will be decisive how you handle the difference between what you envision in the beginning and what you might be getting a few weeks, or months, down the line.
In darkness, deploy motivators
“We are all in the gutter, but some of us are looking at the stars.” - Oscar Wilde
I already mentioned sometimes in this article how predictable dark times are when tackling a side project. You probably know what I'm talking about. We know they will come and so better be prepared for them. Most of the ideas I explain here are already preventive medicine for this problem, however, it's only appropriate if we reserve a special Big Gun for a special Big Boss.
When I feel less motivated to start, or continue, a project there are two kinds of motivators I call upfront. Podcasts and communities of other makers.
Hearing the struggles other founders go through when working on their products from podcasts like The Indie Hackers Podcast, or How I Built This with Guy Raz has always the positive effect of getting me pumped to pick up where I left off.
Communities like Indie Hackers, Product Hunt, or Starter Story, work differently. They make me realize that different products, more or less original, with different degrees of polish, target users, and technologies employed can enjoy the same level of success.
Place rewards on your roadmap and reap them
“Don't judge each day by the harvest you reap but by the seeds that you plant.” - Robert Louis Stevenson
I already mentioned milestones and here I want to emphasize the impact of rewards. Maybe you set a reward for each completed milestone, maybe for two or three milestones completed before X days. The rule is not as important as the object. It's really powerful when I can see that behind those small goals I'll get something that I won't have in any other way.
Be careful though with feedback loops. You don't want to set milestones with random features just so you can eat those extra fries. And rewards don't always have to be things. Maybe it's only more time to binge on a TV show. Use rewards wisely, but use them, and most importantly, go all the way in taking advantage of them.
Stop when you feel unstoppable
Wait, wait, not that kind of "quitting" stop. I'm talking about the Hemingway "stop".
“Always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.” - Ernest Hemingway
This magnificent advice from Ernest Hemingway applies to writing as it applies to programming. Both are creative endeavors, where fluctuating levels of inspiration are to be expected. Sometimes is not where you want it, others you don't know what to do with so much of it.
Inspiration is not always unpredictable though. We can create the best conditions for it. A white screen with a cursor blinking is probably not it. Getting in the office and face a piece of code that doesn't even compile is, you guessed it, probably not it. On the other hand, the moments where you are in total flow are just as powerful, everything feels like magic coming out of your fingers.
I'm not saying to waste that precious, most productive, section of your schedule and stop it short. What you can do is aim for a finish when an interesting development is going to happen next; when you already know what you'll do and how it will play out. This works best if you don't have a fixed schedule, of course.
If you have a tidy time slot where to play inside, maybe it's time to use the rule of thirds: stop when it becomes clear what will happen next with one of the technologies. If you still have 40 minutes available, jump into another area of your project and get to a cliffhanger development there.
Do it in public
“I am always doing that which I cannot do, in order that I may learn how to do it.” - Pablo Picasso
One of my favorite reasons to build side projects is to Learn. Learning anything related to shipping a software product and have it being used (preferably by not just you), of course. With the growing trend of learning in public, describing the lessons you are going through while developing software is not just a way of increasing your accountability (people start expecting content from you) and authority (people start recognizing you as competent in the topic).
There's another layer of learning we can aim for. Learning guru, Scott Young, came up with a different style of project: a benchmark project.
Instead of going deep into some new web framework, seeing all the videos, reading all the tutorials and doing all the sample projects, which might feel good and provide us with a sense of nice practice, we should start by defining a clear benchmark that defines success.
Notice the difference between a clear benchmark like "Make 10 contributions to open source projects using the web framework X" and "Learn how to use web framework X".
Which one is propelling you further into action?
You can't hide inside 'tutorial zone' and pass it as learning with a benchmark like that. They work like quests on RPGs. You have to put in the work into something that will be measurable and impactful for others. There's only a better version of you on the other side of that quest.
Wrap up
We sometimes get lost along the way in our side projects. We lose sight of what made us start in the first place. We may even reach the destination we set for ourselves, but because it doesn't look like a finish line, with fanfare, confetti, and excitement, we stall or wander in the 80% that produces 20% of the results.
That is not the way it's supposed to be. Your side project is finished when you got the most out of it, and not necessarily at the finish line. These 8 strategies aim to help you get more out of the projects you start, and if that makes you faster to the finish line or the route more scenic I would say that is awesome. Give them a try, see what works for you, and let me know about it. Enjoy the views.
Top comments (0)