What I try to focus on: progress over perfection
Perfectionism can be a strength in design, film, and coding, but for startups it often slows progress. Learn how shifting focus to consistent progress over perfection helped me break the cycle and move forward
What I try to focus on: progress over perfection
As a graphics designer and motion graphics artist I developed that eye for detail and strived for pixel-perfect designs. Later, when I started taking photographs and editing, this eye was crucial in identifying things that were out of place — from composition to strands of hair on a model’s face. When I started my film directing phase, learning from the works of David Fincher, this eye was even more crucial, as I could try to spot inconsistencies on set, feel the change of emotions, and spot the micro-emotions of my actors.
Every step I took fueled my perfectionism and fed the slight form of OCD I had developed — even having the switches on my four-gang light switch box misaligned was enough to make me walk across the other side of the living room to adjust them so they were all in the same direction. Perfectionism was everything to me.
As I moved into software and development, this style was clear in the way I write code. I'm not the kind of person that would hack things together just to get them over the line. I can go fast and create clean code, and always try to enhance the flow and make the code as clean and maintainable as possible as I make changes.
This all feels like a perfect skill to have and develop — until I started working on my startup.
Perfection is the enemy of progress - Winston Churchill
As a startup founder, perfectionism seemed to slow me down. It meant over-thinking engineering tasks and over-analyzing problems. It delayed me over the years; every project I started seemed to take the same pattern:
Excited => Analysis => Slow => Exhausted => Dropped => New shiny project
This seemed to be the case with all my previous attempts — until January 2025, when I forced myself out of this routine. I still can’t fully shut it down in other areas, but I learned to cope with it through tickets. I started the same way I approach every project — excited. I did the same analysis I normally do, except things changed after that. Using the MOSCOW method I identified what areas were a must-have for my project, which areas should be included as a bonus if there was time, and which areas I could do without for now. This narrowed my scope and made the project smaller. As I started work on the project, anything that surfaced that would change my flow, I created tickets for using GitHub Projects. These tickets were detailed analyses of the problem and possible solutions. The reason for this was it allowed me to explore that itch in my mind only long enough to create a ticket. Eventually, if the same problem surfaced multiple times, it meant that this ticket was important enough to warrant figuring out how to include it in my project.
It’s better to make half a product than a half-assed product. - David Heinemeier Hansson (@dhh) (basecame founder and creator of Ruby on Rails)
I set a time when I’m between tickets to look at the problem again and apply the MOSCOW method to the ticket after breaking the problem into smaller tasks. This allowed me to have the full solution but only develop the vital parts to include in the first phase.
It’s not a perfect method, but it’s a method that has allowed me to work on my project in a consistent manner for the last 8 months. Every night and every weekend, I chip away at the project with constant progress. I still have my perfectionist mindset, but I’ve learned to apply it to areas where it matters more.