My biggest benefit from writing my own tool set is that I can build the tools that exactly conform to my workflows, rather than constructing my workflows around the tools available to me. This means the tools can truly be an extension of the way my brain thinks and organizes information about the world around me.

I think it’s easy to underestimate the extent to which our tools can constrain our thinking, if the way they work goes against the way we work. Conversely, great tools that parallel our minds can multiply our creativity and productivity, by removing the invisible friction of translating between our mental models and the models around which the tools are built.

I don’t think everyone needs to go out and build their own productivity tools from the ground-up. But I do think that it’s important to think of the tools you use to organize your life as extensions of your mind and yourself, rather than trivial utilities to fill the gaps in your life.

I've noticed that most devs, anyway, are either front-loaded or back-loaded."Front-loaded" means that the part of a project they really enjoy is the beginning part, design work, etc. Once those problems are largely worked out, the project becomes less interesting to them. A common refrain from this personality is "the rest is just implementation details"."Back-loaded" is the opposite of that. They hate the initial work of a project and prefer to do the implementation details, after the road is mapped out.Both sorts of devs are critical. Could it be that you're a front-loaded sort? If so, maybe the thing to do is to bring in someone who's back-loaded and work on the projects together?

Even if it's just a personal project, think about the time and money you'll need to invest, and the benefits and value it will provide. Think on why you should prioritize this over other tasks or existing projects. Most importantly, sleep on it. Get away from it and do something else. Spend at least a couple of days on and off planning it. Outline and prioritize features and tasks. Decide on the most important ones and define the MVP. If, after this planning process, you still feel motivated to pursue the project, go ahead!

Quick win is to ask yourself: What have I learned from this project? And make that the result of the project.

Find a job/role/gig where you think of the solutions and let other people implement them. Just always remember that it is no longer your project. You might have thought of something, but without the efforts of others it will never amount to anything, ever. So as long as you can respect the work of others and your own limitations in doing what they do you will do fine.

Find more challenging problems. I usually do this by trying to expand something that spiked my interest to make it more generically applicable or asking myself if the problem is actually worth a solution ('faster horses') and if the underlying problem is not more interesting (mobility).

it helps to promise other people something: Present your findings, write a paper, make a POC by an agreed upon deadline. Now you have to be empatic enough to want to meet their deadline and thus create what you promised with all the works that comes with it. That is your result. You also have to be selfish enough to tell people that is where you end your involvement, because it no longer interests you, regardless of the plans they have pursuing this further