Front-end Developer at Realtruck.com, Organizer of Orlandoâs Project Code Experience Meetup, Co-Host of the Tech Jr Podcast, and all-around Junior Developer Advocate.
Setting clear specifications and goals will help prevent unhealthy perfectionism and also helps define what that is. This is a skill set I see in a lot of good project managers. When I'm working in instances where there is no project manager, I do my best to develop these skills myself. Easier said than done!
When someone submits a PR that only includes refactoring (which of course is good), but the area that they're refactoring is part of the app that no one uses and that will probably be retired.
I probably have some ocd tendencies, so this one hits home for me :) In general I try to treat the code in the same way that I treat my home: Reasonably neat and tidy. At home, I make sure to never leave small chores for later. So, right after I've used some dishes, I rinse them and put them in the dishwasher. I try to apply the same idea to code: If I can see that some code I've written is messy, I will try to clean it up now rather than leaving it for later. There are always more things to do later, and letting them pile up creates a depressing and de-motivating situation. On the other hand, the perfect is the enemy of the good. It's better to have something that works. As long as it's at least in a reasonable state, it doesn't need to be absolutely perfect. Just as at home, the things in the code that I focus on the most are the things I use often.
Too strong of a focus on refactoring/rewriting code, rather than shipping features. It's important to pay down technical debt, but you still have to move the ball forward and improve the product for the end-users too.
Depth-first versus Breadth-first development.
With depth first you would make things feature complete before moving on the next part, instead of first getting to a minimal product. Depth first has little YAGNI and a lot of bike shedding.
It's hard to have self awareness of this, but if you found yourself trying to cover every scenario around the task in hand and make sure you've covered it, it's a sign that you might have fallen in that trap.
I always tell people:
Start small, then iterate and don't overthink your solution
Latest comments (28)
I still don't have real testing in my personal projects
I would say maintaining a high-level of polish on your work is important, but not at the cost of not shipping.
Nobody wants to use a janky/buggy product, but still make sure you have a product.
Setting clear specifications and goals will help prevent unhealthy perfectionism and also helps define what that is. This is a skill set I see in a lot of good project managers. When I'm working in instances where there is no project manager, I do my best to develop these skills myself. Easier said than done!
When someone submits a PR that only includes refactoring (which of course is good), but the area that they're refactoring is part of the app that no one uses and that will probably be retired.
I probably have some ocd tendencies, so this one hits home for me :) In general I try to treat the code in the same way that I treat my home: Reasonably neat and tidy. At home, I make sure to never leave small chores for later. So, right after I've used some dishes, I rinse them and put them in the dishwasher. I try to apply the same idea to code: If I can see that some code I've written is messy, I will try to clean it up now rather than leaving it for later. There are always more things to do later, and letting them pile up creates a depressing and de-motivating situation. On the other hand, the perfect is the enemy of the good. It's better to have something that works. As long as it's at least in a reasonable state, it doesn't need to be absolutely perfect. Just as at home, the things in the code that I focus on the most are the things I use often.
Too strong of a focus on refactoring/rewriting code, rather than shipping features. It's important to pay down technical debt, but you still have to move the ball forward and improve the product for the end-users too.
Someone constantly fixed on a scarcity mindset. Always looking for what's missing.
Be careful to not let the opposite mentality take over,
With this mentality you will create a codebase that is not flexible, difficult to maintain, and doesn't stand the test of time.
Depth-first versus Breadth-first development.
With depth first you would make things feature complete before moving on the next part, instead of first getting to a minimal product. Depth first has little YAGNI and a lot of bike shedding.
It's hard to have self awareness of this, but if you found yourself trying to cover every scenario around the task in hand and make sure you've covered it, it's a sign that you might have fallen in that trap.
I always tell people:
Still plan, but not so far you go out of scope.