Are you a perfectionist? That kind of a person that can never say "I'm done", "it's ready" or "let's ship it"? The one who can't release the new fe...
For further actions, you may consider blocking this person and/or reporting abuse
Fantastic Post Elena!!
I am working towards finding the middle ground. In my current job, delivering the product takes priority over quality of the code some times. It's not too crazy, however being a perfectionist, I tend to feel uneasy submitting a PR that doesn't satisfy the code quality I set for. Over a period, I'm learning to see the trade-offs and makes appropriate decision.
I would like to ask you two questions.
How do you handle the technical debts? There are situations where you want to ship the code however bad the quality of the code is, as long as it's working. I find it very difficult to convince the management team to get time to improve these "Just Enough" working solutions.
Have you been in a situation where you needed to handle a co-worker who's always trades off code quality to finding "Just enough" working solutions (No matter there's deadline or not).
Hi Subbu,
Thank you for the compliments! :)
Regarding your questions.
1) I completely understand how you feel. The trick for me is to think from the business perspective. Is it beneficial for the company to refactor now or later? Can I justify investing time in it? There can be different answers depending on a situation. If I need to convince someone on a high-level position, numbers help as well. How do you estimate the workload in, say, 6 months without refactoring? Sometimes I find out it really doesn't matter that much - in this case I need to silence my inner perfectionist.
2) Yes, I have. This also depends on the company's priority. If it is a non-critical piece of code, is needed only once, and has to be finished very soon - maybe speed is indeed more important.
Please note: I am not trying to convince everyone to produce bad code quickly :). This is about how a perfectionist learns to prioritize better.
For me it's the opposite. I've recently worked at a company where we focused on end-user value. A feature that was badly needed by lots of people got priority, and bugs that could easily be reproduced but wouldn't bother so many people got down prioritized. Which is as it should be if you ask me. Well, it all depends on what kind of software you're talking about and how critical it is for the business. And now I work at a company where the focus is more on code quality and we try to make sure no bugs slip in.
To me there is a point of diminishing returns. To fix all and every bug is going to require an infinite amount of time because as soon as you touch the code you risk introducing new bugs. For me I can't stop imagining how many actual end users will be affected by a certain bug. If one or two people is going to be bothered by this bug once or twice, it may not be worth spending even a 1/30th of my salery to try to fix it with the additional risk of introducing new bugs, which always happens. And for me to spend a week on something, it's got to be a bug that causes real problems for people. End user value is what it is all about and whether it is financially worthwhile to spend time on it.
Great article! I'm in the company that needs to deliver high quality code (it's typically safety critical), and there we've done a good job of knowing where to draw the line (i.e. it's ok to ship with bug X, we'll fix that in the next release but it's not ok to ship with bug Y, it's dangerous and needs to be addressed now). There are always code reviews, and lots of testing to try and make sure nothing slips through.
My problem is with my side projects. Because I can't come up with the perfect idea, I'm paralyzed by indecision and can't seem to get started. I'll keep trying and see if I ever decide to actually do something; but reading this was helpful. It's always nice to know that others have struggled with the same problems, and found a way to overcome them.
Thank you, James, nice to know you liked the article!
I know exactly how you feel. Your approach works perfectly well in your current company, but for some "less important" projects it's really hard to switch this mindset.
Yes, you need to be brave and decide to release, even if it's not perfect. You'll feel very good about that, I promise! You'll get a lot of endorphins :).
Also, the earlier you release, the more user feedback you'll get, and the better you can move forward with your project. The user feedback is both reassuring (people actually like your thing!) and helpful (they tell you what features they'd like, and you can focus on them first).
Lol, when I read this post I was like: How could she so accurately describes Me!!? 😂
💯 agree
Thanks!:)