>I think there are two strategies that would help a lot: 1) writing a spec (i.e. a plan) upfront, and 2) timeboxing the project by giving myself a deadline.
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.
Ooh I like that! I definitely feel that in some sense when I have a good streak of commits per day, where I don't want to break the streak. Or for workouts, it's suuuper motivating to see the number continue to go up.
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 had a teacher once, at a training seminar, that kept repeating the phrase "We need to know what 'done' looks like."
"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.
Yeah, the Toyota JiT stuff, but the company I worked for is a 100+-year-old engineering corporation, and didn't do stuff in no new-fangled, 1950s-kid-playground way.
But the term "Agile," is a lot more recent (and US-based). I rapidly learned never to use that word within earshot of my managers. Sort of like saying "California Roll" in a traditional Tokyo sushi joint.
> I rapidly learned never to use that word within earshot of my managers.
Stands to reason. Agile, in the Manifesto sense, defines the considerations to consider should managers be eliminated from the picture. Nobody is going to be comfortable knowing that their job is on the chopping block.
It's because that company is laser-focused on Quality (they have a well-earned reputation as one of the highest-Quality manufacturers in the world).
They believe that Agile promotes bad-quality work, because it promotes a lack of Discipline and checks and balances (which are necessary components of high-Quality production).
I disagree, but many of the Agile proponents exemplify low-quality work, because they deliberately eschew Discipline and checks and balances. They use Agile as "Santa Claus for young developers," as opposed to what I believe is Agile's focus on delivering high-quality, useful, and timely, product to end-users.
We need more examples of the Agile process doing really good work.
> They believe that Agile promotes bad-quality work
Whether or not that is true, why would they care? They'll be gone.
> Agile's focus on delivering high-quality, useful, and timely, product to end-users.
I tend to agree. As managers are removed from the picture, there is no manager to hide behind. You're working directly, each day, with those who are going to hold you accountable.
> We need more examples of the Agile process doing really good work.
To be fair to the managers, are there any? Even the C3 project that gave birth to Agile is widely regarded as a failure.
> Whether or not that is true, why would they care? They'll be gone.
Well, it’s not true (in my opinion), but try telling that to people who have been successfully shipping world-class optical gear, for a century.
I have learned that, if we want to introduce new paradigms, it’s a very bad idea to do so, by telling folks that the way they do it now, is wrong (even if it is).
That experience taught me a great deal about working within a super-high-Quality context. The personalities and opinions are very powerful, and most of the senior folks involved, got there, by being very, very good at their jobs. A true meritocracy.
They won’t react well to having some wet-behind-the-ears yank, come in and tell them that they are wrong, when that’s clearly not the case (in their eyes).
I’ve found that, if I want to introduce change, I need to begin by respecting the context and the people, and using that as a substrate for change, as opposed to suggesting it be removed, wholesale.
Or start my own company, which is what a lot of folks do, these days. It’s not an option that’s available to many. Also, those companies often encounter problems that have nothing to do with the tech, and everything to do with the inexperience of the founders (like reckless behavior).
Agile is from 2001. What you seem to be thinking of is the Toyota Production System. It is quite possible that TPS inspired Agile, but to claim that it is Agile is like saying that GPT is from the 1960s (because it shares some resemblance to Eliza).
I resonate strongly with this. I found something pretty simple thats been helping me lately though. I uhh, i just force myself to keep working on it until its done. Grind it out. Work on it especially when i dont want to. Ditch those little relaxing moments for it. Wake up early to find time for it. Its torture.
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.
Yeah, definitely. I know this is a somewhat controversial opinion, but I do think there's value in developing the muscle around "grinding it out". I think the tricky part (depending on your personality type) is knowing when it makes sense to give up and move on to something else.
> I start making more realistic plans and exit points because im not a masochist.
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!
In my life, I've kindof developed a rule of thumb: if it's the more difficult path, it's probably the better path.
That heuristic isn't always correct, but I find it to be pretty good. Problems can arise when I follow it blindly, though.[1]
I've just generally found that a lot of good things in life are on the other side of a barrier, and crossing that barrier usually involves effort and pain.
So, it starts to develop into an association of "if it's hard/painful, it's probably leading somewhere good."
And that starts to develop into "seek out pain/difficulty."
Ironically, I'm also someone who values being comfortable in my own skin.
But I feel more comfortable doing something painful for my own (masochistic?) reasons than doing something painful for an external goal.
----
I do feel like there's often an element of masochism in people who excel at some activity. Plenty of stories of top athletes or musicians etc. who do it for their own reasons, and not to win a trophy or acclaim. Getting good at something is generally a painful process of dealing with failure over and over. If you don't have a stomach for that pain, you'll give up. If you grit your teeth and force your way through it, you may become competent, but probably won't excel. If, somehow, you enjoy that pain and are drawn to it, then you will put in the hours to keep getting better and better, unboundedly.
But that's just one perspective.
The grandparent comment seems more like someone who likes to "keep their eye on the prize," whereas I'm more of a "do it because I enjoy[2] it" person. I suppose if you are motivated strongly enough by some external goal, it could push you through the hard times, too. And if the goal keeps moving, you might keep pushing, unboundedly, too. Not my path, though.
Also, I find taking a hard path is sort of a Great Filter for other people; there will be fewer others on that path (I'm fairly solitary, so it suits me), and what people there are will have something in common with me.
----
[1] When I hear about people trapped in abusive relationships, trying to "fix" it rather than leaving, I feel like I understand them somewhat. At the same time, some relationships are worth saving, even (especially?) in the hard times, so being able to navigate the pain rather than run away can a strength, too. Depends on the situation.
[2] with "enjoy" being somewhat perverse, at times (:
For a long time, I was lazy, and took pride in quoting Bill Gates "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it."
I thought I was smart, but after years I discovered I became more lazy, and had never developed any deep knowledge on matter.
"if it's the more difficult path, it's probably the better path", I like that :)
+1 to being selective and ruthlessly deleting time-draining ideas.
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.
A few open-source communities have forums/channels like #showcase, where it's easy to drop a screenshot and get feedback. I'm thinking of the Discord chats for Textual and p5.js, for example, if your project uses their libraries.
Or if you're the party planning type, perhaps consider forming your own group. Even ~6 people meeting once a week for a month works well.
> ”i just force myself to keep working on it until its done.”
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.
I don't want to be too abrasive, but family people unironically complaining (almost humble-bragging in some cases) about their lack of time to others who may or may not have had the same opportunities on that front (e.g. no marriage prospect, possibly loveless life) can be very tiring.
I don't want to be too abrasive, but people without families or hobbies tend to fuck up work life balance for the rest of us. It's very tiring dealing with people like you who do nothing but work and bitch about how they don't have anything else going on.
Just to give you maybe another perspective: I think part of what makes the work interesting is that I can’t do it all day as I please. So when I have time to work, I am super motivated. As unsatisfying as that might be.
Whenever I have holidays and weekends or unlimited time and want to work on something I usually don’t follow through.
Over the years I’ve noticed that I’m often operating in various “modes”. Some of this is related to depressive episodes, but often it’s just a more neutral ebb and flow. I’ll have a week where ideas are flowing and connections form easily. I’ll have a week where it feels like I can’t engage so deeply - like my system is cooling off after exertion.
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!
I do. These days, I'm all in on Obsidian. It's been a great tool for thought that ebbs and flows with me, and helps me see how things have been going.
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.
But also, don't over optimize. For example, if your routine or schedule is mostly working but you feel like you need some less structured time, don't schedule it, just go out and do that. Don't work it in for the purpose of being more "productive" later.
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.
These pointless meetings are usually a result of the fact that people feel things are going better if they are a little bit involved, even if their involvement is not actually contributing to the solution.
Also it’s a lot about lack of trust in large orgs.
I think its not always that people want to feel important. It's more like the subtle change perception: Whenever you are part of a discussion, you have the feeling that it's going better, just because you are there.
That's me. I even have days that I'm completely enthralled in a project and work 12 hours straight in it. And the next day I don't care about it.
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.
This resonates a lot. For years, I would dive in for a week or two, sometimes I would make it to a few months. Lately, I've just been telling myself no, to keep focus on my start up, but it sometimes feels like I'm squandering this spark of energy you described. I absolutely love your approach of doing the planning in that initial burst rather than just getting some part of the idea working in a day or two.
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've come to a similar conclusion lately. I used to spend a lot of time jumping on my latest idea, researching and even writing a bit of code to get started. I'm much better off writing my ideas down, hopefully in a form where I can consolidate the ideas into a few projects, but even if it just stops me wasting time on an idea that I'll lose interest in soon, it's worthwhile.
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 don’t remember which book
I got idea from but idea is to work in different modes. When you work as programmer then there are no deadlines and etc. So sometimes you have to put different hat, e.g. CEO hat. It took several months to work out but overall result is reasonably good.
I sometimes battle perfectionism for various reasons. Someone pointed out that it can’t be perfect if it isn’t even finished, so why not add “done” to what it means to be “perfect.” Somehow that tweaked my perspective in a helpful way. Edit: on reflection, possibly because it doesn’t imply a compromise of my standards, but actually strengthens them, so I don’t have the feeling of giving up or giving less.
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
Always glad to see articles discussing an emotional side of software development (:
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.
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. So, not a direct cost, but an opportunity cost. Personally, I find it important to acknowledge this and face it head-on, rather than waving one's hands and saying "oh, there's basically no downside." Though I admit that the latter can be a useful self-mind-hack to get the ball rolling. But first you decide what you want to do, and why you want to do it, and then you tell yourself whatever lies you need to help it get done (:
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.
Just getting things out of one's mind, and into the world (even if nobody sees them), can be important (helps my sanity, at least).
Even just the "rubber duck" sense of imagining someone might see it, can catalyze thoughts in a way that wouldn't otherwise happen, too.
Then, having people actually see them is another layer, and can be humbling and educational.
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.
There was a post on HN recently about building software for yourself - forget the possible audience of millions. If you focus on yourself as the end user then the whole thing becomes easier.
I couldn't find it after a brief search. Maybe someone else remembers it.
I genuinely consider two of my greatest accomplishments to be building a game and composing a song.
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).
I really disagree that releasing a project publicly is a necessary step to deem something done. I have so many projects in my src/ directory that are (in my mind) finished, but that I will never release to the public. I wrote them for my own education and entertainment, not as things that I think the rest of the world would benefit from. And certainly not as a way to build some kind of (ick) -personal brand- among the open source community, or to give me some sense of accountability (to whom?). I don't need GitHub stars or social media thumbs up or hacker news upvotes to measure the worth of something I made.
Reposting an old Reddit comment of mine that I think agrees with much of this article:
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.
> Better, I don't feel guilty about the stuff I don't finish.
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).
So you’re saying in order to finish projects I just need to learn how to be honest and clear with myself? Seems like a reduction to a harder problem :)
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!
For me this sounds a lot like a distinction between being intrinsically motivated (“because it is fun for me”) and extrinsic motivation (“I want to achieve something in the outside world”)
There's no such thing as finishing a project. My most successful open source projects requires ongoing maintenance work to this day and the various dependency updates require constant refactoring.
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.
Great stream-of-consciousness style article, I relate and appreciated the practical advice!
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
Im on the same sitatuation, i had an idea month ago that i thought it might be useful,started building, but when i finished the main parts i gave up, i just had the "what if" question, what if nobody actually want this and i've never touched since then the code is still in github tho
I don’t want to come off as mean and spoil the article but the author writes he can’t get anything done and the strategies that might help him with finishing things is..
“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”
Here's just a little silly story from my own life of unfinished projects. I wanted to make a sort of shazam where I could hum the tune of a classical piece of music and find out what it was. I hacked together an enormous midi database of classical music with a couple of libraries to take a hum and turn it into midi notes in order to find the pattern in the database based on the difference between each note in a melody of a classical piece as an identifying key (pun intended). As a really bad singer, I couldn't hold a note, but you can imagine the work required to get this to actually work.
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.
102 comments
[ 3.2 ms ] story [ 181 ms ] threadI 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?
"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).
Ugh, yes... I wish I had internalized this sooner!
Interesting word, thank you!
I hear the word used, often.
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.
How old? The origin of Agile goes back to the 1950s in Japan
But the term "Agile," is a lot more recent (and US-based). I rapidly learned never to use that word within earshot of my managers. Sort of like saying "California Roll" in a traditional Tokyo sushi joint.
Stands to reason. Agile, in the Manifesto sense, defines the considerations to consider should managers be eliminated from the picture. Nobody is going to be comfortable knowing that their job is on the chopping block.
It's because that company is laser-focused on Quality (they have a well-earned reputation as one of the highest-Quality manufacturers in the world).
They believe that Agile promotes bad-quality work, because it promotes a lack of Discipline and checks and balances (which are necessary components of high-Quality production).
I disagree, but many of the Agile proponents exemplify low-quality work, because they deliberately eschew Discipline and checks and balances. They use Agile as "Santa Claus for young developers," as opposed to what I believe is Agile's focus on delivering high-quality, useful, and timely, product to end-users.
We need more examples of the Agile process doing really good work.
Whether or not that is true, why would they care? They'll be gone.
> Agile's focus on delivering high-quality, useful, and timely, product to end-users.
I tend to agree. As managers are removed from the picture, there is no manager to hide behind. You're working directly, each day, with those who are going to hold you accountable.
> We need more examples of the Agile process doing really good work.
To be fair to the managers, are there any? Even the C3 project that gave birth to Agile is widely regarded as a failure.
Well, it’s not true (in my opinion), but try telling that to people who have been successfully shipping world-class optical gear, for a century.
I have learned that, if we want to introduce new paradigms, it’s a very bad idea to do so, by telling folks that the way they do it now, is wrong (even if it is).
That experience taught me a great deal about working within a super-high-Quality context. The personalities and opinions are very powerful, and most of the senior folks involved, got there, by being very, very good at their jobs. A true meritocracy.
They won’t react well to having some wet-behind-the-ears yank, come in and tell them that they are wrong, when that’s clearly not the case (in their eyes).
I’ve found that, if I want to introduce change, I need to begin by respecting the context and the people, and using that as a substrate for change, as opposed to suggesting it be removed, wholesale.
Or start my own company, which is what a lot of folks do, these days. It’s not an option that’s available to many. Also, those companies often encounter problems that have nothing to do with the tech, and everything to do with the inexperience of the founders (like reckless behavior).
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?
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.
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 ...
Have a poorly-ordered braindump:
In my life, I've kindof developed a rule of thumb: if it's the more difficult path, it's probably the better path. That heuristic isn't always correct, but I find it to be pretty good. Problems can arise when I follow it blindly, though.[1]
I've just generally found that a lot of good things in life are on the other side of a barrier, and crossing that barrier usually involves effort and pain.
So, it starts to develop into an association of "if it's hard/painful, it's probably leading somewhere good." And that starts to develop into "seek out pain/difficulty."
Ironically, I'm also someone who values being comfortable in my own skin. But I feel more comfortable doing something painful for my own (masochistic?) reasons than doing something painful for an external goal.
----
I do feel like there's often an element of masochism in people who excel at some activity. Plenty of stories of top athletes or musicians etc. who do it for their own reasons, and not to win a trophy or acclaim. Getting good at something is generally a painful process of dealing with failure over and over. If you don't have a stomach for that pain, you'll give up. If you grit your teeth and force your way through it, you may become competent, but probably won't excel. If, somehow, you enjoy that pain and are drawn to it, then you will put in the hours to keep getting better and better, unboundedly.
But that's just one perspective.
The grandparent comment seems more like someone who likes to "keep their eye on the prize," whereas I'm more of a "do it because I enjoy[2] it" person. I suppose if you are motivated strongly enough by some external goal, it could push you through the hard times, too. And if the goal keeps moving, you might keep pushing, unboundedly, too. Not my path, though.
See also "Type 1,2,3 fun", eg: https://essentialwilderness.com/type-1-2-and-3-fun/ (definitions vary)
----
Also, I find taking a hard path is sort of a Great Filter for other people; there will be fewer others on that path (I'm fairly solitary, so it suits me), and what people there are will have something in common with me.
----
[1] When I hear about people trapped in abusive relationships, trying to "fix" it rather than leaving, I feel like I understand them somewhat. At the same time, some relationships are worth saving, even (especially?) in the hard times, so being able to navigate the pain rather than run away can a strength, too. Depends on the situation.
[2] with "enjoy" being somewhat perverse, at times (:
For a long time, I was lazy, and took pride in quoting Bill Gates "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it."
I thought I was smart, but after years I discovered I became more lazy, and had never developed any deep knowledge on matter.
"if it's the more difficult path, it's probably the better path", I like that :)
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.
I found this group recently: https://lmt2.com/
The author made a group: https://www.hackercoop.dev/
If you like fiddling with HTML, there's groups like the homebrew website club https://indieweb.org/Homebrew_Website_Club or sunday sites https://sundaysites.cafe/.
A few open-source communities have forums/channels like #showcase, where it's easy to drop a screenshot and get feedback. I'm thinking of the Discord chats for Textual and p5.js, for example, if your project uses their libraries.
Or if you're the party planning type, perhaps consider forming your own group. Even ~6 people meeting once a week for a month works well.
Everyone works on their own things.
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.
tl;dr TRIGGERED
Whenever I have holidays and weekends or unlimited time and want to work on something I usually don’t follow through.
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.
Also it’s a lot about lack of trust in large orgs.
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.
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.
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.
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
I do disagree with this claim (though later points temper it a bit):
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. So, not a direct cost, but an opportunity cost. Personally, I find it important to acknowledge this and face it head-on, rather than waving one's hands and saying "oh, there's basically no downside." Though I admit that the latter can be a useful self-mind-hack to get the ball rolling. But first you decide what you want to do, and why you want to do it, and then you tell yourself whatever lies you need to help it get done (: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.
Just getting things out of one's mind, and into the world (even if nobody sees them), can be important (helps my sanity, at least). Even just the "rubber duck" sense of imagining someone might see it, can catalyze thoughts in a way that wouldn't otherwise happen, too. Then, having people actually see them is another layer, and can be humbling and educational.Also, apropos of nothing, this article made me think of the (mis-)quote:
Good article (:> 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.
I couldn't find it after a brief search. Maybe someone else remembers it.
https://www.robinsloan.com/notes/home-cooked-app/
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.
https://github.com/shepherdjerred/practice
https://github.com/shepherdjerred/archive
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. :)
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/
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.
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.
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
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...
“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”
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.