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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.