I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Computer & social scientist merging both worlds to build interactive software. Working as web dev focusing on front end engineering, interaction design, information architecture & data visualization.
dev/IoT advocate.
my neurotransmitters enjoy: foodie, penguins, and esoterica (the arts, oddities, antiques).
my demons have funny names: AuDHD/MDD/GAD/cPTSD
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
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.
The fact my personal site has taken 6 complete reworks, almost 4 years and still has never actually had more than a coming soon message.
Its just never perfect...
For my actual work, I play the game of bouncing it off testers when I feel its about there. This goes on till they accept it. It stops me over thinking and over working on things.
About a year ago I started my first version of my website. I used Wordpress so it was up and running in no time, and most of the content was ready. Then a few weeks ago, with new knowledge and tools, I started to remake it from scratch. I had to “start over” from zero 3 times, but now it’s a lot better than it was before and it’s pretty much ready. Not that I won’t keep working on it indefinitely, though.
I like to think, “is this code I have right here better that what’s online? Yes—ship it.” And in my opinion, almost anything is better than a coming soon page! 😉
Good luck on your projects! In case you want to take a look, my site is at cecilelebleu.com. Although it’s not perfect, it’s better than it was yesterday!
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.
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.
I'm a web sysop and support engineer. My skills are mainly in back-end: Java, Linux, Python, PostgreSQL, Git, and GitLab. Currently I'm learning front-end skills: JavaScript, and Ruby.
Haha I’m also guilty of that. My solution is making a bunch of small changes and commit all of those as “minor improvements”. This solution is probably worse than the problem itself, though.
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.
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.
Not shipping anything. 😉
I'm in this comment and I don't like it
Yeah ;-)
Simple but true! 😅 #guiltyAsCharged
big oof
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.
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.
When people spend longer telling you why something won't work, than making it actually just work would have taken!
The fact my personal site has taken 6 complete reworks, almost 4 years and still has never actually had more than a coming soon message.
Its just never perfect...
For my actual work, I play the game of bouncing it off testers when I feel its about there. This goes on till they accept it. It stops me over thinking and over working on things.
About a year ago I started my first version of my website. I used Wordpress so it was up and running in no time, and most of the content was ready. Then a few weeks ago, with new knowledge and tools, I started to remake it from scratch. I had to “start over” from zero 3 times, but now it’s a lot better than it was before and it’s pretty much ready. Not that I won’t keep working on it indefinitely, though.
I like to think, “is this code I have right here better that what’s online? Yes—ship it.” And in my opinion, almost anything is better than a coming soon page! 😉
Good luck on your projects! In case you want to take a look, my site is at cecilelebleu.com. Although it’s not perfect, it’s better than it was yesterday!
It's not bad actually, I like it
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.
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.
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.
The GitLense heat map shows more edits in comments than in code?
But more seriously, if you have a lot of small commits, could indicate obsessive compulsive edits. I'm guilty of that
Haha I’m also guilty of that. My solution is making a bunch of small changes and commit all of those as “minor improvements”. This solution is probably worse than the problem itself, though.
It starts to take (time & effort) way more than expected.
I'm not sure that works in all scenarios. I find frequently with legacy code even hacky changes can take a lot longer than expected.
If it's not worth the extra time and effort, then it lies within the perfection boundaries.
Ah there we go. It takes more time/effort than expected AND it is not worth it :)
Someone constantly fixed on a scarcity mindset. Always looking for what's missing.
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!
I think too many premature performance optimizations, which might not even be optizimations, due to maybe not even Profiling...
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 still don't have real testing in my personal projects
When customer value addition gets overthrown buy a missing comma or wrong variable name.
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.