I've had this on my mind for a while, but saw https://dev.to/madza/how-do-you-deal-with-half-finished-projects-3jcp and it insprired me to write it down;
For a long time I've had a ever building list of half-started projects. Always over-ambitious, always lacking direction and always getting stuck (since I always seemed use them as an excuse to try new tech too)
Nowadays I've promised myself not to get into them at all, because I've found that by myself I don't have all the tools needed to complete side projects and will always end up sinking so much time, effort and mental energy into something I'll sadly abandon.
I'm just a programmer, the only reason I finish anything professionally is because of good project managers, financial & time pressures from clients, and the fact that there's other projects waiting to start.
I think you need a minimum of three people. The obvious win with three people is a lot of self-indulgent ideas don't stand up to outside scrutiny, but as well I think we need three specific roles covered by three separate people:
💹💲🎁 The client/business owner/product owner role
Someone with a high level business & feature perspective.
They can spec out whats actually required/important & understand paths to profit.🕕🩺🤍 The Project manager/producer role
Someone who can manage time-frames & priorities & morale.
They understand that time, mental effort & emotional effort (if not directly financial) carry heavy costs.👷♀️👩💻 The Coder/Builder role
Someone to actually build the thing.
(You and me probably)
Even better if 1. & 2. are not technical.
This applies if you're spending a lot of time on it, or even if all three of you only commit a few hours a a week to it.
Programmers so often view themselves as entire islands capable of shifting the world on their own, but I think that it's a really uncomfortable weight to put on yourself and don't believe its setup to succeed.
Having these roles owned by separate people;
☑ Makes responsibilities so much clearer.
☑ Which allows for a more equal mind-share/ownership of different parts of the project.
☑ And It stops you feeling overwhelmed, overworked & stressed at all the different aspects you'd otherwise have to juggle yourself.
The next time I work on a side-project, it'll be after three of us think its a good idea and we can each fit into the roles above.
I'm pretty confident we'd have fun, complete it and make money on it.
What do you think?
Has anyone here completed substantial side projects on their own? How did you do it?
Top comments (5)
As a person who falls into the coder/builder role - I've found I've had better luck getting folks on board with projects if I toss together a REAL basic MVP of what I want to build before I start looking for other folks to jump into different roles.
Yeah for sure, a basic pitch or prototype that's solid definitely gets people interested.
I think I'd be trying to aim my pitch at people who are already a PM or run a relevant business in the sector. You know? I find it pretty easy to get other coders in on ideas, but I'm not sure that's enough.
If I may ask - have you had much success with getting people involved in side-projects? If so, how did they go?
Sounds like you're veering more into startup than side project then.
Having a PM from a technical background always helps to translate technical discussion and help with framing and managing estimates.
You know, I used to think this. But the best PM I've worked with actively tried to avoid technical detail. If you started to explain why a seemingly simple requirement actually eg. needed a SMTP server and multiple integrations etc he'd just stop you half way noting that an IT/devops department needed to be involved and that the task had hidden time sinks/complications.
Instead, he trusted you to figure out an estimate you were comfortable with and was compassionate when you spent 3x over on actual hours, cause everyone in this business knows how hard it is to quote when you don't know what you don't know yet.
I think your right though that translating technical discussion and framing are important, but I think it's the first role (the client/business owner) that's suited to it.
Imagine you were a client, tasking me & a PM to build you a front-end. You'd being able to provide specific technical requirements (eg 'the css needs to support x browser versions', or 'use bootstrap grid' rather than a less technical 'turn this PSD to HTML') would make my job building it so much clearer.
Might update the post to convey this. Thanks for the reply~