And this is one of the reasons writing things down has been such a useful tool, and starting with a spec is something I now do religiously after spending the first half of my life just diving in haphazardly (and often not getting very far).
Those ultra productive days are often enough to get a pretty decent spec written; something I can flesh out in far greater detail than I could with a productive coding day. Those down days are now bolstered by the thinking of a version of myself that was firing on all cylinders, and solved many of the problems I probably don’t have the brain power to tackle on the fly when I’m tired and stressed for life reasons.
I feel like I’ve squandered really good trains of thought by telling myself “I’ll remember this and write it down later”. So I always start with writing. Future me always appreciates it.
I totally agree about writing things down being useful. I also like the author’s timebox plan as well. I’m great at writing specs to define what I want to build, but my hobby project timelines are nonexistent. I think I’ll give this a try!
Without peeling the whole onion, I've been dealing with a series of autoimmune issues in combination with complex PTSD. I'm working with some really great people to address these issues on all fronts and I'm much better these days than I've been in the past, but it's a work in progress that I'll have to manage for awhile.
A huge +1 to the importance of core habits. Focusing on this has been a key aspect of recovery.
I've been feeling like the software industry is over optimizing engineering output just a smidge beyond what is morally acceptable. Not enough to raise red flags about cruel and unusual, but just over the line of "it's ok to be human". Maybe that's just me and I'm someone who doesn't need a Pomodoro timer or multiple "just for an update" meetings to get work done. But maybe it's also upper management trying to turn business school theory into something real. You're not a number or a widget or for God sakes a brand. You're a person. Remember that.
On the other hand, I've got one large ongoing series of projects that are relatively pointless, and that is the whole point of them. I'm learning from them and I don't have the pressure of completing anything (although I would really like to). From time to time they have been really important for my mental health, and I value them for that.
I'm also quite aware now that I need to feel achievement to keep me motivated, and if I have a plan and can check off an item on that plan then that counts as a good day. Work doesn't always give me that sense of achievement, so having something else that does can be really valuable.
I think those ultra-productive days earlier in my career account for some of the best learning, but now, over a decade into software engineering, focusing on the planning aspect seems much more prudent.
I'm sure it's human nature. But there are some beasts out there like Don Knuth, Torvalds, DHH, that seem to have unlimited stamina. They are the people who advance stuff.
And also therapeutic. I see the incompleteness of my original idea, or plan. I see that the things i declare important feel less so when i have to keep working on it. I start to permanently discard essays, apps, ideas, as i appreciate what it would really take to do them. I say no to myself far more often. I become more disciplined in my work. And more disciplined in my play. I start making more realistic plans and exit points because im not a masochist.
Ultimately i let it change me. I obviously wont grind like this forever. But the grind teaches me, and changes me, into the kind of person that finishes things. Which is mostly about learning to be more selective and less impulsive, and knowing when to play and when to put things down and truly let them go.
I'm not sure I can force myself to keep working, though. Self-imposed deadlines don't help me either. It seems like a willpower problem, like going to the gym.
What's helped me is making projects alongside a small group of fellow programmers. Seems like the author has done something similar with a hackers co-op chat and with Recurse. External accountability is my most successful motivator.
I work with oodles of software developers and almost none of them program on the side.
Or, you start to enjoy the pain, because you enjoy the result. But then your mind does its illogical associative thing and you start to just enjoy the pain on its own. Now you're a masochist!
I jest, but only some. Ask me how I know ...
I’ll admit I’m jealous of this. Most days at 5pm I’m just hitting a groove, but kids need to eat, need family time, etc. I’d love to grind from 8am-11pm but rarely have that luxury.
Whenever I have holidays and weekends or unlimited time and want to work on something I usually don’t follow through.
tl;dr TRIGGERED
I'm in my 40s and for most of my life I had an unending series of unfinished projects that I felt guilty about. Today, I am able to finish some stuff, including some pretty large, hard projects. Better, I don't feel guilty about the stuff I don't finish.
The trick for me is to be deliberate and mindful about why I'm embarking on a particular project.
If it's because I want to feel good by:
* Sharing something with others.
* Accomplishing a difficult, challenging task.
* Proving to myself that I can do something.
* Getting the social cachet of being a creative, productive person. (Maybe this is shallow, but who doesn't like to feel impressive in the eyes of their peers?)
Then the goal of the project is the product it and I focus my attention and discipline on it. I try to have as few of these as possible—like only one at a time—so that my willpower is not diluted.
If it's because I want to feel good by:
* Improving a skill.
* Exploring an unfamiliar domain or learning something new.
* Relaxing by tinkering on something I like.
Then the goal of the project is the process and I don't feel bad about not finishing. The real treasure is all the stuff I learned and did along the way and there is no real destination. I can have as many of these as I want because there's no real failure mode here. They're all recreation.
Once I got more honest and clear with myself about my goals for each project, I started to be able to finish the ones where that mattered and stopped feeling bad about the ones where it doesn't.
I think this is key, and demonstrates the real personal growth, which is more valuable than being able to finish things per-se.
It's the old saw: "what's the hardest thing? To know oneself."
There's a lot of eagerness to jump on bandwagons and do whatever the motivational speakers recommend, but you're not going to find the answers specific to you until you look inside yourself.
Anyway, in short: I agree (:
I'd also add: the reasons and mindset can change not just from project to project, but from day to day as well. Very context-dependent (at least in my experience).
Joking aside, I came to believe that various form of procrastination are a response to pursuing wrong or unclear goals - even when I don’t state them clearly, my brain still somehow knows that I’m not aligned with what my goals should be. Good job, brain!
Yes, but there may be other positive benefits to solving it as well. :)
Neither are very impressive, but in both cases, I ended up having to simply decide I was done and stop working on them. I could continue making changes indefinitely, adding little improvements and such every day, but they were also complete as they were. Once I learned to be okay with that and move on, I learned what finishing a project really meant (or at least one form of it).
With any art, a certain amount of polish is desirable but too much will destroy the essence of the work.
I will find myself actively making a song worse... and then go back a few versions to find the peak.
"Done" is often a compromise. There's more that can be added, there's still burrs and "rough spots," but we need to declare it ready to go out the door, and be prepared to fully support our release.
I've been shipping software for my entire adult life, and have had to embrace this philosophy.
Just the other day, I stopped working on a "play" project that I was working on, because it was a rabbithole, and not worth the agita of fixing the fundamental design issues that I was encountering (an unfortunate by-product of my "Evolutionary Design" process, is that it's quite easy to fall into Wonderland, and I need to learn to understand that I should just let the rabbit go).
As much hate as Agile gets here at HN because of its wrong usage by many people, one thing that Agile recommends is setting up a 'Definition of Done' within your team before even starting your very first sprint.
They would start at the end, and work backwards.
They hated Agile.
Scrum uses the exact "Definition of Done" language, though. I suspect that you are really thinking of it...
Which is humorous given what you said about wrong usage of Agile. Case in point?
Ugh, yes... I wish I had internalized this sooner!
Interesting word, thank you!
I hear the word used, often.
I do disagree with this claim (though later points temper it a bit):
Why is it important to share your work with the world? First, because
there's practically no downside, and very, very high potential upside.
The "why is it important..." question is really critical to motivation, at least for me. A person should give that question honest thought and an answer that rings true to them.
I agree about the therapeutic aspect of putting things out into the public.
Though I don't plan to publicly share all of these proactively, just
knowing that they're publicly viewable helps give me a stronger sense
of accountability. I'm curious if it will make a difference.
Also, apropos of nothing, this article made me think of the (mis-)quote:
We do these things not because they are easy, but because we thought they would be easy!
> Why is it important to share your work with the world? First, because there's practically no downside, and very, very high potential upside.
And say,
> There is a big downside: as the author states, finishing/releasing is hard and time-consuming. You only get one life. Every hour spent doing that stuff you won't get back
Working in public (or working at least from the assumption it will soon be made public), is something folks should try really hard to get into. It should be a default expectation for yourself. The cost is mostly mindshift!
Once you can change your default position, it no longer feels like a cost to work in public. Every action brings release.
Use curiosity and excitement when you can but don't let them be the only way you can work on something.
Some practical strategies I've written about:
- How to prevent stagnation while building products alone [0]
- Multi-Perspective Note-Taking: Mastering focus as a solo-developer [1]
[0] https://www.idiotlamborghini.com/articles/how_to_prevent_sta...
[1] https://www.idiotlamborghini.com/articles/mastering_focus_as...
I would like to add another possible strategy: watching a number go up.
Recently I have started tracking the books I am reading. I track the page number I am currently on via a dashboard I made in Obsidian, which displays a %-read for each book. I have found that "number goes up" gives me just enough of a dopeamine hit to encourage me to pick the books up more frequently than I had before.
But oftentimes when a project or essay is incomplete, it's hard for me to think of a good "number" to track that would be a good motivator (since i.e. lines of code, or the number of words in a draft, don't necessarily feel like a good proxy for progress all the time). I'm curious if there's a metric that would work better?
I'm a typical Starter, and all of the side projects we've been working on together were my idea. All of the projects that we completed and released were solely because of his endurance, discipline and focus. And his constant reminders to not start a new project before the current one was done.
Also very much believe in doing some kind of planning, any kind being better than none at all. Otherwise you put yourself in a tunnel but you don’t give yourself a light at the end. The plan can change and it will, but if you have none, you might end up digging forever
This means when you are at 50% completion, you need to spend more than two times more effort to hit >90% completion.
99 to 100% takes an infinite amount of time.
In the comment section we probably have a lot of “me” stories, but should we not think “we”?
I tried working on multiple projects but my mind always focused on one at the detriment of the others (before ultimately working on something else).
After some time and deep introspecting, I realized working on multiple projects was some complex form of procrastination (avoiding doing hard or boring things on other projects). I also realized working on other projects may have been some sorta coping mechanism to avoid possible failure (if I never finish projects I can never fail).
After the introspection I hit a turning point with two words, "what if".
Instead of bouncing around, trying and learning new things, what if I focused all of my attention on one stack/product/project/industry/thing?
I haven't solved what "done" means yet, but I have come to terms with the shortness of life and my own capabilities. I know who I am and what I can do. It's a start.
I couldn't find it after a brief search. Maybe someone else remembers it.
When you're working on software that has no obvious finish (development could go on indefinitely) you have to set up small milestones. Okay, in this release we're going to get this and that and other thing working, with documentation and test cases. That is in a concrete target. When we have those three things with documentation and test cases we've hit the target and nothing blocks that release anymore.
“1) writing a spec (i.e. a plan) upfront, and 2) timeboxing the project by giving myself a deadline.”
Isn’t this just agile? I’m pretty sure every developer already does this, it’s kind of the whole strategy for completing any project.
Not sure what the point of this article was. He could have wrote “make a sprint and stick to it”
This isn't enough on its own obviously, but just in case anyone's been noticing something of a trend: inability to finish projects is verbatim one of the DSM-V entries for Inattentive-presenting ADHD: https://www.cdc.gov/adhd/diagnosis/index.html
New projects are always nice and "productive", because it's fine. It's meeting the end goal that is harder.
1. Not the right format (essay versus video versus book)
2. My overall philosophy on the topic has changed and I need to restart with something new
To me something is done when it reaches a state where you don't feel you need to tend to it. But it's never actually done. The only things that are truly done are things that will never be used again.
Brevity and Ruthless Editing should be incorporated into your final cycles of 'finishing' working on projects.
The author knows their work isn't perfect, but they're sharing it anyway. This is covered in the first paragraph.
Regardless, I found this post to be perfect. There are good takeaways, it was easy to read, and it wasn't too long.
I'd imagine that the author would happily consider your opinion if you posed it in a more constructive manner.
Poor writing turns off readers, who won't come back and visit again, and it diminishes your effort and message. Pretty basic.
My observation: a promise I made to someone else is harder to break than a promise I made to myself.
TL;DR: To build more quickly, do "outline speedrunning": Recursively outline an MVP, speedrun filling it in, and only then go back and perfect.
[0]: with me: https://learnhowtolearn.org/how-to-build-extremely-quickly/
- don't wait until you feel like doing something
and
- half-ass it
This is a fantastic rule-of-thumb no one ever talks about. We focus too much on learning, honing our skills, becoming experts, and we never find the time to start.
The amusing part was that I told a prospective software development employer about the project because it was consuming a fair part of my life at the time and showed an interest in software development in my spare time. They asked, "Did it work?" I said, "Nope"
I didn't get the job but we both had a laugh about it during the interview.