Ask HN: How do you get over perfectionism/overthinking in hobby projects?
I have many empty repositories at Github which were supposed to be ML softwares. The reason is that whenever I started to write code, I was obsessed with making it abstract, extendable, modular, easy-to-read, ... (Rare thing among ML softwares)
So most of my time was spent on designing modules without writing any actual ML code! And then I got disappointed and let it go.
Any suggestion on how to cool down this obsession so I can write at least some actual working code for god sake?
10 comments
I used to engage in a lot of yak shaving (needless refactors, redesigns, etc), but I never actually shipped anything. I was tired of having a big pile of unfinished projects, so I forced myself to take a more waterfall-y approach to some smaller projects: define the requirements and build only what is needed to meet those requirements. Once it's shipped, I allow myself to look at biting off another chunk of work, but until that chunk of work is done, I'm not doing anything else.
The important thing here is:
This doesn't even mean Waterfall (big design up front). Agile workflows operate on this same principle. If you elected a Scrum-styled approach you'd select the work for the current Sprint and run it to completion. If you elected for a Kanban-styled approach, you'd look at how many things are in each stage of completion and stop inducting new work when you realize you have 20 projects that are all at the "refactor for publishing" stage.
until that chunk of work is done, I'm not doing anything else.
This doesn't even mean Waterfall (big design up front). Agile workflows operate on this same principle. If you elected a Scrum-styled approach you'd select the work for the current Sprint and run it to completion. If you elected for a Kanban-styled approach, you'd look at how many things are in each stage of completion and stop inducting new work when you realize you have 20 projects that are all at the "refactor for publishing" stage.
Will anyone else notice?
When I am doing DIY I always want it to be perfect, because I know the project inside out. I know where I had to cut a corner or where some ends didn't quite meet and had to be filled, where a seam isn't as invisible as I would like. To stop myself obsessing over the tiny details I ask myself, will my wife notice it? If she would then it's worth spending a bit more time on, if she wouldn't notice it, do the best you can and move on with more important jobs. Once the job is finished I can go back to that little issue that only I know about and tweak it so it is better.
In software just build it, make it do the minimum required however you can and then tidy it up and make it extendable/modular etc.
When I am doing DIY I always want it to be perfect, because I know the project inside out. I know where I had to cut a corner or where some ends didn't quite meet and had to be filled, where a seam isn't as invisible as I would like. To stop myself obsessing over the tiny details I ask myself, will my wife notice it? If she would then it's worth spending a bit more time on, if she wouldn't notice it, do the best you can and move on with more important jobs. Once the job is finished I can go back to that little issue that only I know about and tweak it so it is better.
In software just build it, make it do the minimum required however you can and then tidy it up and make it extendable/modular etc.
I guess yes. I recently found out that some part of my motivations about doing things has been getting feedback from people (It releases dopamine and makes you feel validated).
I used to be a software engineer and I'm somehow obsessed with designing software architectures with minimum cost of change in future. It makes me crazy to design something on-the-fly without considering the cost of changes. That's the reason I have obsession for writing general-purpose abstract codes... It really makes me crazy but I don't know what to do with it...
Getting feedback is good, but you want feedback on what the product does, not how it does it.
Personally I prefer to get feedback that tells me why something I did was the wrong way as long as I also get told why and what the correct way would be. That way I can improve my software and learn something at the same time. Being told my solution is e.g elegant, is nice in the short term but less helpful in the long term
Personally I prefer to get feedback that tells me why something I did was the wrong way as long as I also get told why and what the correct way would be. That way I can improve my software and learn something at the same time. Being told my solution is e.g elegant, is nice in the short term but less helpful in the long term
I can't speak for any projects related to software, but I am a hobbyist musician and have just last year started writing songs, I've joined bands for open mic nights, etc... I have a strong perfectionist streak and used to become very frustrated when I could hear small mistakes or if any facet of a project wasn't shaping up in real life as well as it had in my head.
To fix my frustration and increase my output, I focused on:
1) Changing my anticipation of a reward from the perfection of the project to the completion of the project. This required me to actively tell myself "this isn't that good, put I'm executing regardless". Being able to tell my friends "hey, I wrote this song" is better than being able to say "hey, I've got this great idea for a song", but it didn't more satisfying until I had written a bunch of songs (quite a few of which weren't good).
2) Anticipating the reaction to the project from people who don't know the details rather than the reaction to the project from the experts. An amateur barbershop quartet may sound medium-talent in the eyes of a vocal professional (who I was initially working to impress), but it's fun and sounds great to the average person at an open mic (who I started working to impress).
Other tips:
- Rather than trying to implement perfectionist ideas in the moment, note them down and continue making an imperfect project. Once you've got something done, you can look at your perfectionist notes and decide whether or not to go back and fix/rewrite. This is how I finish scripts for plays and new compositions.
- Adopt the mindset intended by this reddit anecdote I'm paraphrasing: "You're 30 and you can't play guitar. Yeah, you missed the window of time where you could have been a great professional guitarist at a young age, but ten years from now you're going to be 40, and you can either have spent 10 years practicing guitar, or you can have spent 10 years regretting how you didn't become the best guitarist it was possible to be and imagining how it could have been different". Apply to coding as necessary.
To fix my frustration and increase my output, I focused on:
1) Changing my anticipation of a reward from the perfection of the project to the completion of the project. This required me to actively tell myself "this isn't that good, put I'm executing regardless". Being able to tell my friends "hey, I wrote this song" is better than being able to say "hey, I've got this great idea for a song", but it didn't more satisfying until I had written a bunch of songs (quite a few of which weren't good).
2) Anticipating the reaction to the project from people who don't know the details rather than the reaction to the project from the experts. An amateur barbershop quartet may sound medium-talent in the eyes of a vocal professional (who I was initially working to impress), but it's fun and sounds great to the average person at an open mic (who I started working to impress).
Other tips:
- Rather than trying to implement perfectionist ideas in the moment, note them down and continue making an imperfect project. Once you've got something done, you can look at your perfectionist notes and decide whether or not to go back and fix/rewrite. This is how I finish scripts for plays and new compositions.
- Adopt the mindset intended by this reddit anecdote I'm paraphrasing: "You're 30 and you can't play guitar. Yeah, you missed the window of time where you could have been a great professional guitarist at a young age, but ten years from now you're going to be 40, and you can either have spent 10 years practicing guitar, or you can have spent 10 years regretting how you didn't become the best guitarist it was possible to be and imagining how it could have been different". Apply to coding as necessary.
Seconded to the max. Being able to finish things is a more important ability than being able to do things perfectly. In my 30's, I put aside the pursuit of perfection in favor of developing the discipline to finish with acceptable results. It's the second most important improvement I have made in my life.
[deleted]
From a hardware perspective, I spent wayyyy too much time re-wiring breadboard circuits with perfectly measured and cut lengths of wire to make them look "beautiful," turning something like this[0] into this[1].
That was a waste of time. Both have the same result, but the ratsnest is always faster. The goal isn't beauty, it's meeting the requirements. The pretty one might be a little easier to debug and transcribe into a schematic for PCB layout and for someone else to understand, but IMO breadboarding isn't the right time for that.
[0] https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Br...
[1] https://imgur.com/zlyHs
That was a waste of time. Both have the same result, but the ratsnest is always faster. The goal isn't beauty, it's meeting the requirements. The pretty one might be a little easier to debug and transcribe into a schematic for PCB layout and for someone else to understand, but IMO breadboarding isn't the right time for that.
[0] https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Br...
[1] https://imgur.com/zlyHs
> Both have the same result, but the ratsnest is always faster.
I simulate as much as I can (e.g using LTSpice) and then go straight to circuit board (DIY at home laser/LED printer toner transfer). Mucking around with unreliable breadboards isn't much fun.
It's too easy to make mistakes and bad connections in breadboard layouts. Then if it's not working, you have to figure out whether it's the circuit, a mistake in the assembly, or a bad connection.
If I'm going to go to PCB anyway, might as well route that and use it from the get go.
I simulate as much as I can (e.g using LTSpice) and then go straight to circuit board (DIY at home laser/LED printer toner transfer). Mucking around with unreliable breadboards isn't much fun.
It's too easy to make mistakes and bad connections in breadboard layouts. Then if it's not working, you have to figure out whether it's the circuit, a mistake in the assembly, or a bad connection.
If I'm going to go to PCB anyway, might as well route that and use it from the get go.
sorry for sounding green, but I've been tinkering in electronics, and PCB design is has been the part that's daunting.
I would prefer to make PCBs, but how do you handle the footprint of some components? like do you measure each one and then design it in eagle?
I would prefer to make PCBs, but how do you handle the footprint of some components? like do you measure each one and then design it in eagle?
The datasheet for the components almost always describe the dimensions and often the recommended footprint (landing zone). Depending on the industry different additional standards apply (for example “space grade” have increased focus on reliability; mobile devices on area reduction; etc)
CAD packages ship with or have collections of common footprints, but be aware that there aren’t truly standards and two footprints might be named the same but have quite different dimensions (even within a single manufacturer). It is rare but it happens and thus it is worth checking.
KiCAD has a large repository of common footprint layouts which I believe is of a reasonable quality, but I have never used them myself.
CAD packages ship with or have collections of common footprints, but be aware that there aren’t truly standards and two footprints might be named the same but have quite different dimensions (even within a single manufacturer). It is rare but it happens and thus it is worth checking.
KiCAD has a large repository of common footprint layouts which I believe is of a reasonable quality, but I have never used them myself.
Well, if you ever deal with sensitive analog signals, what you're doing would reduce delays and inductive pick up from other lines. Of course, you'd only clear the area for those, not the whole board.
Don't put it publicly on GitHub from the start (=less worry about "what if someone sees my ugly code?!"). Go to something working on more or less the shortest path possible, and then extend it step by step, introducing abstraction only when you actually need it.
Honestly, it depends on the project and why I'm building it.
If I'm building something because I want to learn something new, I give myself permission to spend as much time massaging it as I want. For me, being able to chase 'perfect' is an important part of my learning process.
On the other hand, if I'm building something I want to ship, I like to set rabbit hole alarms. Whenever I sense that I'm about to start going down the winding road of obsession, I set a timer (usually for half an hour). I let my mind go wild until the timer goes off, then I move onto the next task.
If I'm building something because I want to learn something new, I give myself permission to spend as much time massaging it as I want. For me, being able to chase 'perfect' is an important part of my learning process.
On the other hand, if I'm building something I want to ship, I like to set rabbit hole alarms. Whenever I sense that I'm about to start going down the winding road of obsession, I set a timer (usually for half an hour). I let my mind go wild until the timer goes off, then I move onto the next task.
This is what I do:
1. Meditate every day
2. I have the following text file on my desktop. Answer the questions before you start, then start, and do nothing else but the steps listed for the amount of time listed.
What are my steps?
Why accomplish this?
Provide a conductive environment: (Make a list here of actions to take to get you ready to start (bathroom, water, close door, close other programs, etc.))
What length of continuous time will I work on this?
Doing step 2 has always worked when I actually fill out the answers.
1. Meditate every day
2. I have the following text file on my desktop. Answer the questions before you start, then start, and do nothing else but the steps listed for the amount of time listed.
What are my steps?
Why accomplish this?
Provide a conductive environment: (Make a list here of actions to take to get you ready to start (bathroom, water, close door, close other programs, etc.))
What length of continuous time will I work on this?
Doing step 2 has always worked when I actually fill out the answers.
Any practical recommendations on how to get into a daily meditation habit. Do you use an app like Headspace? Any special mind hacks you use?
I greatly prefer silent meditation. People prefer different things, so ymmv.
My advice is to carve out 30 minutes in the morning and just start. Pick a focus; most people pick a sensation of breathing. While focusing on this, observe what your mind and body do, without reacting to it, and without judging it or yourself. When your attention wanders, re-focus it without judgement. This will happen a lot, noticing your attention wandering and re-focusing is part of the practice. It will happen less and less over time.
There are no mind hacks, but here are some things that might be helpful to look out for. These are things to verify for yourself through direct insight: don't take my word for it.
* Your thoughts are not actually part of your identity. You are not your thoughts, judgements, emotions, etc. The "voice in your head" is not you.
* Most people actually see and live in a landscape of subjective thoughts based on reality, instead of seeing and living in reality directly.
* People are primarily harmed not by events, but by their reaction to the events.
My advice is to carve out 30 minutes in the morning and just start. Pick a focus; most people pick a sensation of breathing. While focusing on this, observe what your mind and body do, without reacting to it, and without judging it or yourself. When your attention wanders, re-focus it without judgement. This will happen a lot, noticing your attention wandering and re-focusing is part of the practice. It will happen less and less over time.
There are no mind hacks, but here are some things that might be helpful to look out for. These are things to verify for yourself through direct insight: don't take my word for it.
* Your thoughts are not actually part of your identity. You are not your thoughts, judgements, emotions, etc. The "voice in your head" is not you.
* Most people actually see and live in a landscape of subjective thoughts based on reality, instead of seeing and living in reality directly.
* People are primarily harmed not by events, but by their reaction to the events.
I had this problem myself. My solution: focus on agile, feature-driven development. Make the next feature work in a scrappy (ie exploratory coding) way, then take what you learned and refactor. Don't take it as an opportunity to refactor everything - just the code around that one feature, and close relatives e.g. common functionality that can be abstracted out.
Presumably you're working on your software for a reason - not just to press keys for hours on end. So focus on getting the software ready to fulfil that purpose and don't get so caught up on software engineering practices. Most best practices in software engineering are solely there to allow large teams to work on a single codebase anyway (especially so for extensibility and modularity) and that doesn't apply to your project so why would you follow them?
Presumably you're working on your software for a reason - not just to press keys for hours on end. So focus on getting the software ready to fulfil that purpose and don't get so caught up on software engineering practices. Most best practices in software engineering are solely there to allow large teams to work on a single codebase anyway (especially so for extensibility and modularity) and that doesn't apply to your project so why would you follow them?
There's nothing wrong with having good workmanship in the things you produce. More so for the things you enjoy doing.
If you enjoy writing these abstractions, then knock yourself out. You said "hobby", right?
Personally, I'm slightly against this type of thing.. abstractions/modularity for the sake of it. An abstraction for a single concrete thing is actually less readable. A good goal would be to design/write so it can be abstracted later (if required).
GoF is an excellent guide, but it's not a rule-book.
If you enjoy writing these abstractions, then knock yourself out. You said "hobby", right?
Personally, I'm slightly against this type of thing.. abstractions/modularity for the sake of it. An abstraction for a single concrete thing is actually less readable. A good goal would be to design/write so it can be abstracted later (if required).
GoF is an excellent guide, but it's not a rule-book.
Perfect is the enemy of good enough