
Ask HN: How to convince my coworkers to ship imperfect code? - artpi
We’ve heard mantras many times. Mark Zuckerberg urges to „Move fast and break things” ( although it’s „move fast with stable infrastructure” now.  ). Reid Hoffman says, that „If you are not embarrassed with first version of your product, you are too late”. And in my company, we are buying in the adage of moving fast.<p>In the trenches, close to the code, perfectionism is chipping away at our productivity.<p>&quot;Let’s take time to make this piece future-proof because we never get around to refactoring things later”.
The motivation is noble - save ourselves and future victims of our code some problems.
But, what I’ve seen is:
- We never get around to refactoring because we take SO MUCH time honing v1 that nobody sane gives us more time to make it better. Maybe if we shipped sooner, we could refactor later? (That is my personal experience when I just wanted to refactor)
- We spent days making some solution perfect but it turns out the whole data structure is useless and has to be thrown away because it just does not fit to overall infrastructure.
-  That making perfect blocks other people from iterating on it.<p>I found out that following approach works best<p>1 Hack together an end - to - end prototype to test if all pieces can work together in the hackieshest way possible
2 Design interfaces between the pieces
3 Extract classes, libraries, etc so improvements are easy to collaborate on
4 Ship MVP to production to get user feedback
5 Introduce every non-critical part of the feature while taking user feedback into account<p>Perfectionism is something that is plaguing authors and other professionals  ( Although I hate „code is poetry” adage, I do see shared struggle between coders and authors and a lot of advice can be inferred from books like „Bird By Bird” by Anne Lamot - especially concept of „shitty first draft&quot; )<p>Soo… How do I convince my coworkers to iterate more? Ideally, I’d like to create online perfectionism-antidote.
Or am I wrong maybe?
======
artpi
I love my coworkers, they are truly the smartest people I know and I never
dreamed of such productive work environment, but these are the practices I
found to be problematic:

\- Writing tests in the sam PR introducing a library that is not yet used is
waste of time since that library will go through several revisions before
fitting in the whole project. In the meanwhile, tests are usually testing
interfaces (which is of questionable benefit) and take time to rewrite every
time lib interface needs to be adjusted

\- „Taking time” to make it „proper” . „Proper” is usually currently hyped
opinion and in our case (12 year old product) consistency is always a choice
with what we want to be consistent. I am strong believer in coding standards,
but I hate consistency with randomness. What I mean is - I’ve seen decision
made at random (because sometimes we’re exploring the unknown) and then we
force consistency with that decision never reexamining it.

\- Designing classes / libraries up front- this is the design process that
takes 0 data and turns it into binding decisions. It should be done at the
end!

\- „If we make code better, the product will be better by extension” - this is
pure BS. There is an infinity of nice things you can do with the code that DO
NOT trickle down to product experience. Rich Americans getting richer does not
trickle down to poor Americans getting richer.

\- ‚We are not some code sweat shop where we pump shitty code”. Well, we are
not and we CAN make code better AFTER it is working.

\- Perfect IS NOT set in stone. There is no 1 perfect solution. There is a
myriad of good enough ones, and I love good enough ( it has to be better than
„just working" )!

------
Eridrus
I have no solutions, only commiserations.

Is there a process that is slowing you down? Can you find a partner in crime
to help you circumvent that process? Be it a co-worker to sign off on code
reviews or a manager to shield your work?

