When you have a vision, how do you work toward it for long spurts? Or is it more of a "micro-visions" approach? Not sure if I'm asking the right questions, so feel free to reframe them if I'm not being clear enough.
It beats every kind of "system" and "rational" framework.
Think of the people you love. Think of how your project will help them in some small way, even if that is just making you a happier, wealthier person who can give more to them.
Think of the people you dislike, whose values you detest, who will gain and triumph in some way by your failure.
Picture a fantasy vision of a better world, where your contribution, however small, brings value to many.
If none of that stirs anything in you, and gives you a burst of energy to redouble your efforts, then two unfortunate things may be the case:
You may be incapable of emotion. About 5% of us are, in which case ignore all of the above and find a system. Stop looking for ways to "motivate yourself" because "motive" is connected to "emotion" (same root).
What you're doing may not be at all worthwhile. That isn't a reason to give up. The road to a project that's genuinely fulfilling and is "emotionally self-powered" passes through many mediocre and failed "learning" projects along the way. Completing it many be all you need to do to move on.
I think a nice pairing to the "emotion" angle here, and along similar lines, is thinking about "meaning". What does it mean to you, deep down, to get this project finished? What need does it fulfil for you? Is it independence? Is it a burning need to create something, irrespective of the outcome? Is it the enjoyment from sharing what you've built? Is it financial freedom?
It boils down to having a clear idea of the why behind something you're working on. If you know why you're doing something, and you're really clear about it, I think that can really help motivation over the long haul.
Not everything needs a clear "why", but it can help.
Edit: on a bit of tangent related to thinking about the "why"; as a technologist/developer, when I first get involved in a technical project and a company asks for a specific technical solution, I find it really helpful to ask "why" and to keep asking that until I break through the layers and get to the root need that the business is trying to fulfil.
Many technology projects can go off track due to a lack of clarity about what actual business need those projects are trying to address. Often this is due to a bit of a disconnect between commercial/business people and technical teams, so it can be really useful to make sure that the business intent is communicated clearly before getting lost in the technical implementation details.
Absolutely. Hard to find out sometimes. As a bit of an amateur psychologist, I'd say the "deep down" part presents the challenge. We're mostly too busy cutting code to do the "inner work". And as you say, the "Why?" doesn't always come first. Sometimes we are involved in projects and business as a way to work things through and discover something. What starts out as "I don't want to be poor like my parents" ends up as "I could do something about preventable disease X and save many lives". That's why I think that the ethics behind the hacking is more important than we realise and there's no such thing as "technological determinism".
So on that basis, maybe the why does always come first? You may just not be intellectually aware of what that why is? BTW I guess I'm taking quite a broad definition of "why". The "why" could be, because you learned early on that behaviour X makes you feel safe, due to some childhood trauma - but this is a deeply embedded instinct rather than a conscious process of decision making. And things like that can be very difficult to pin down.
I suppose you could discuss this point at a number of different levels...
Definitely agree that the "why" can change over time. I've 100% seen this happen with my own motivations!
There's a type of "API-ization" of all existence. 15 people can do the exact same thing with nearly opposite objectives and all be a "team" (such as what we see large-scale in politics) or have the exact same "why" with 15 ways to do it and be "disunified" (i.e., the Linux community).
The secret to staying motivated, which nonrandomstring pointed to, is finding a way to bundle all those fluctuating "why's" together toward 1 purpose. It makes you manic and obsessive, but determined and implacable on a death march to a glorious prize. My discouragement was likely because I needed sleep and wasn't de-stressing correctly, then applying it wrongly to what I love doing.
What you're saying about finding an emotional outlet is absolutely true. I spend so much time building, and probably need to spend more time advertising it! Things like HN are great places to express my passion (i.e., state assertions of fact in as few words as possible), and there are likely more niches once I slowly build out my dev ambitions later.
1. Consistency instead of Intensity - steady progress in small chunks help instead of all-nighters which lead to burn out
2. Fall in love with the process - ignore the outcome and keep working on your steps instead, it stops the worry about what's going to happen in the future
3. Ship an initial version before talking about it - talking about a project before you've released something makes you think that you've already achieved it.
Aside: I think there is a typo in your link
Thanks for the heads-up, fixed.
Break it down into shorter milestones. Get some small achievements, then take a break and do something else for a while. Don’t let it become a burden.
Also, you need to be willing to quit if it no longer makes sense to continue. If you were doing a project for fun and it stopped being fun, it isn’t serving it’s purpose any more. Abandoning it could be the right choice if you get to this point.
Second thing that helps is, defining "huge" within the right context. Your project looks large from a self-centered point of view. Think about human flight - took 2000 years, multiple generations to figure out. Go into the history of various inventions, they all took lots and lots effort. Once this context is understood, you'll find that whatever you're doing is not necessarily such a "huge" task. Such perspective helps too.
Third, the characteristic of good goals is this:
Good goal = Difficult + Specific
The whole point of good goal is it helps you extract more effort from yourself. In a way, you set goals so that you can do more. If your goal demands more of you, it means the goal is doing its magic! So why'd you become discouraged when a goal demands more of yourself? By stretching yourself, you'll become more capable.
I thought it's conscience and compassion. Animals can learn capabilities & skills, but they don't have the concept of good and evil.
The key idea is that we can "develop" various attributes to a degree which is orders of magnitude larger than the next animal. To me, doing that is meaningful.
I'd call it "honest" rather than shallow!
Cool project BTW
It’s an infinite series of stacked physical exertions that reminds me that I can’t think my way out of putting in the work.
It’s a great metaphor for how most really incredible projects are actually built (with a lot of grind). It also helps build the mental muscle of ok I gotta hit my targets today so I can hit my new targets tomorrow
I wrote a long form essay about the concept here if you’re interested.
1) Break it into smaller chunks
2) Prioritize all those smaller chunks by impact, difficulty, and dependency
3) Break them again into smaller pieces based only on difficulty
4) Work based on priorities, get lower diff and high impact first
This way you will start to get a good feeling about your work/project.
Take breaks and make sure you don't burnout.
Good luck!
Just create a section in your to-do for future upgrades where you move huge topics until only your core idea is left again. In reality things may turn out different anyway, so find the MVP in your idea and bring it to market.
This is easier said than done, but reality is there is only so much one developer can do, and there is only so much motivation before you even bring it to market (feedback & cashflow help for motivation later)
I break down the project to its minimum shippable product (since I build web apps, that's relatively doable). Having ridiculously fast CI/CD helps a lot here.
Once the first cut is released, I tend to iterate on it in two hour bursts (since that's all I have before work starts).
I wrote about applying this to build a SaaS, been running it for over a year and a half now: https://onlineornot.com/building-saas-in-one-week-how-built-...
Results come in their own right time. Software project: think of implemented functions (step by step); all-at-once results project (e.g. lightbulb): think of the "method" of Edison.
Quiet perseverance.
If it is a hobby project that you intend to make into a commercial product, stay focused, get to MVP and make sure you aren't burning effort on something that people don't want to pay for.
If it is to learn something, e.g. how to write a game, make the goals really small. Once I have learned how to move the player a bit, do I really need to perfect it?
Is it just the fun of programming? Use coding sites to compare different languages/frameworks.
You can introduce hardware to make it more fun, e.g. programming a small robot via a RaspPi or a microcontroller.
Don't beat yourself up, maybe the journey is OK but it sounds like you have a destination in-mind so focus on the outcome and chat with others to find out if there is a quicker way to at least get to the first staging post/MVP.
As others have said, if it is for no particular reason and you've stopped enjoying it, just stop it. No harm, no foul!
The idea that all projects must push through all struggles and succeed is exactly what causes frustration. There can be other goals in life.
Of course life gets in the way. People who rearrange meetings at the last minute or worse, call me out of the blue or set up meetings with 10 minutes notice really boil my piss (if you'll excuse the expression) as it forces me to rearrange my day. But generally speaking this approach has worked for me for years.
I'm blessed with a project that is essentially a fractal of moderately difficult and very diverse CS problems. Goes a long way to help me keep going. There is literally always something fun to do. The outcome was more of a "huh, I guess I've built an internet search engine now, neat, but about that crawler resource optimization I was thinking about..."
Donations and letters of appreciation are encouraging as well, now that it's a working product, but they didn't get me to the point it was working.
There are a few tactics I use to help:
* Prepare myself mentally for the task and understand that the task is going to take as long as it's going to take. This means being more "result oriented" than adhering to a "time box" approach and giving myself permission to take a lot longer than I might have anticipated. It means I'm not looking at the clock and stressing myself out about how "unproductive" I'm being. Often I find things get done in a timely manner (even if it's not as fast as I'd like) when I can focus on the task rather than trying to optimize to meet some synthetic deadline.
* Split bigger tasks into smaller tasks and having a series of small "wins" instead of long stretches with no easily measurable or outward facing results. I'm fighting against my own psychology of getting burnt out or demotivated, so making sure there are small, measurable tasks that can be completed helps keep me on track towards making progress on larger issues.
* My apologies if it's too basic, but having a 'todo' list that I can easily see what I need to work on and crossing off the tasks as they're completed helps focus my attention and keep my motivation.
* Sometimes I organize tasks with a 'priority' and 'effort' qualifier. There are "easy" wins for a task is high priority and low effort. Medium to low priority tasks with low effort allow for "easy" wins to keep motivation. High priority, high effort tasks can be at least identified and maybe be broken up further. Low priority high effort tasks are something that can be punted to when I have free time or potentially ignored altogether.
Most projects aren't going to draw the attention of most people, especially when it comes to finding other developers to work on your project, so one can expect to mostly go it alone. But, just because you're most likely the sole developer, doesn't mean you can't talk to people in your circle about some of the issues or challenges. Your friends are probably in a good position to be sounding boards, give advice, work through problems or even be "rubber duckies" in the worst case.
To keep myself going I don't push myself too hard. I manage my time and my productivity well. and I break down tasks into small little chunks and when I complete them I celebrate the win and take a break.
I gave myself occasional pep talks, and hype up my work to myself because it's enjoyable, and make extensive use of voice memos to talk about like where I'm up to in my project and sometimes to like reevaluate you know what's my original goal and what's my goal now. Basically I'll kind of keep a development log using voice memos and just like talk out my thoughts if I run into some issues or what I'm doing... I'm not going to be talking all the time but like I'll find it helpful as a way to sort of talk through some opportunity for improvement, some challenge.
But the most important thing I think is I always like build something I can use. like I'll try to build the simplest version, like the prototype --you could call it a minimum viable product, right?-- the thing that I want to build and I'll try to build that quickly so then I get like these big feedback loop where like I'm using the thing that I want to build but it's just a simple version of it.
So I try to get to the finished product--but not polished at all--as quickly as possible that's usually my first goal. Get to like some proof of concept prototype that I can actually use, that's the first goal in the project and then it's like a series of basically adding features and refining that so you go from like a coarse-grained lower resolution so to speak prototype to a finer grain higher resolution high Fidelity prototype of your original idea and at each stage you have something you can use that you can enjoy and then your enjoyment increases as you continue building stuff.
edit: Oh shit, I forgot, I also like to post my work, and partial work to Show HN, I find that can be rewarding for me as well. Even if no one looks at it, posting is sort of like another way to mark the moment, and the milestone, and to celebrate a win. One reason is because I'm saying, 'Here, I have something. It's kind of finished. Take a look at it. It's ready for that.' It's also a great, like um...it sort of focuses the thing's that need to get done, too.
But I try to have fun while I'm still here. Not for profit, just for me.
Second part which motivates me is realising that huge part of my competences as software engineer came from hobby projects when you do all stages of product development by yourself.
Then the patience goes, the vision needs adjustment, and finally the conviction is in doubt...
So good job hanging in there.
Here are things that help me:
- I encourage myself to b*tch about it, especially if I am passionate about it. Never did this before but it's just a fun alternative to being too serious...and still being annoyed. And if you have even the tiniest amount of bad == good reverse psychology, this will be giving yourself energy by definition. "I hate this piece of sh*t hobby! God what a waste of--" (suki no uchi dazo)
- I use micro-passions instead of micro-visions. I put it aside until the next wave comes. If I'm afraid the next wave won't come, I rank the micro-passions. Like break it down to 5-10 components (at least) that you like, and then rank them by how much you like doing them. (Not how much you like completing them) From there it becomes a question of surfing the waves as they come.
- Human psychology is really, really primitive in terms of its use of interest-symbols as pointers to deeper insights, so you can sometimes take advantage of it. Study what the specific hobby-topic says about your life, and what it's suggesting. This can help you be less serious about a hobby, even if you're still interested in it (== better able to commit steady, patient interest to it over time). IOW you might realize "I'm building and painting model cars because my mind is hitting me with a clue-bat, suggesting I can maybe design an enjoyable life where I'm in control of the wheel and actively going somewhere" is a surprisingly a) good fit to one's subjective reality sometimes and b) disturbingly funny insight into where you're at. You can start with a dream dictionary since those are really just symbol dictionaries.
- Document your progress, this is huge. If you lose clarity on your next step (of say, 2-5 minutes length) it's easy to get derailed. If you lose track of your personal method because you never documented it, ditto. Nobody wants to re-figure-out that stuff. I make sure there's a how-to component and a logging component as well.
One other big one:
- Keep a list of your interests. What happens is, you'll discover that you're always in the mood for _something_ so if you like lots of things, you'll effectively never be able to lose touch with your passions. And this feels damn good. "Ah damn, my hobby nuclear reactor isn't feeling interesting today, good thing I have been needing to put in some time on my donut-critic hobby!"
Hang in there, and may your visions come true in ways that force a good cackle.
I have many hobby projects, ideas, partly-built things. I have some that are very near to completion, and others that are probably a lifetime's work.
I tend to work on them in short stints: a few nights, sometimes like a month or two. And then set them aside as I burn out on that idea, or come up with a compelling extension/revision/use-case/etc for a different one.
It's really crucial to document where you're at in this model: you need to be able to pick things up again without too much time to figure out where you were. I have two things that help with that:
Firstly, a README.md file for each project which includes my roadmap, with stuff crossed off as I get it done. So I can pull it up and see exactly what's next and what I just did at a glance.
And secondly, I keep a (large) journal.md file, divided by date, where I write down what I did. Especially stuff that I needed to research to figure out. That includes literally copying command lines out of my shell and into the journal. It's just a massive bulleted list, but when I restart something, I can quickly search back to the date of the my last commit, and see exactly what (and how) I did the things I did in that burst.
Combining my roadmap/README, journal notes, and Git history generally means I'm productive again in about 15 minutes.
Anyways, documenting projects for yourself is very important. Treat your future self as best as you can. Think about the problems your future self my encounter.