
Ask HN: How do you get over perfectionism/overthinking in hobby projects? - rebelhit
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?
======
cweagans
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.

~~~
Jtsummers
The important thing here is:

    
    
      until that chunk of work is done, I'm not doing anything else.
    

Multitasking means you'll take longer to ship anything, though the total time
spent to ship everything may be the same. By selecting smaller units of work
and focusing on them to completion you can reduce the overall latency of the
system.

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.

------
celticninja
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.

~~~
rebelhit
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...

~~~
celticninja
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

------
quacked
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.

~~~
vibrolax
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.

~~~
quacked
What was the first?

~~~
vibrolax
That I am a human being, like all the other humans, and not a robot or
machine. I was hard on myself, and by consequence, hard on others. Learning to
be easier on myself allowed me to learn how to complete good, worthwhile
things without damaging myself or others.

------
kawfey
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...](https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Breadboard_complex.jpg/1200px-
Breadboard_complex.jpg)

[1] [https://imgur.com/zlyHs](https://imgur.com/zlyHs)

~~~
kazinator
> _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.

~~~
beckler
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?

~~~
henrikeh
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.

------
detaro
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.

~~~
jenscow
I wouldn't worry about it at all. Nobody reads nor cares about your ugly code.

~~~
detaro
Easier said than done if you're worrying about it anyways, which I suspected
OP might do.

------
hluska
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.

------
rthomas6
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.

~~~
dewang
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?

~~~
rthomas6
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.

------
beaconstudios
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?

------
jenscow
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.

------
throwaway191701
Perfect is the enemy of good enough

