This is only tangentially related, but in cases like this, the strategy of improving variable names when you’re working on a piece of code is significantly more valuable than searching for code to refactor and improve.
It’s true that improving a random variable name in your code base is not a big win, but:
Since you’re already looking at this piece of code and presumably making a change, the cost of changing the variable name is lower than if you were changing a random part of the code.
The fact that you’re looking at this piece of code and not a different one is evidence that this is something people are more likely to look at than usual, so the benefit of improving it is higher than improving a randomly chose variable name.
Because of these two things, the procedure “improve code you’re working on” is signifantly more valuable than you’d expect if you think the procedure you’re following is “improve all the code”.
Oh yeah, that’s something I’ve actually been thinking about recently. Unfortunately, I think it isn’t very compatible with the way management works at most companies. Normally there’s pressure to get your tickets done quickly, which leaves less time for “refactor as you go”. And then if you’re lucky, they’ll allocate some time for tech debt. But as you say, that’s less efficient than “refactor as you go” because you have to load all that context back in to your working memory.
All of this is a big part of what I had in mind in writing this post though. If managers/decision makers took the outside view on code quality, maybe they would encourage developers to take their time and refactor as they go rather than having pressure to finish tickets quickly.
Unfortunately, I think it isn’t very compatible with the way management works at most companies. Normally there’s pressure to get your tickets done quickly, which leaves less time for “refactor as you go”.
I’ve heard this a lot, but I’ve worked at 8 companies so far, and none of them have had this kind of time pressure. Is there a specific industry or location where this is more common?
Interesting. My impression is that it’s pretty widespread across industries and locations. It’s been the case for me in all four companies I’ve worked at. Two of which were startups, two mid-sized, and each was in a different state.
Improving code you work on is also good because you are likely better understand the purpose of the code when you are working on it then when you look at a random part of your application.
This is only tangentially related, but in cases like this, the strategy of improving variable names when you’re working on a piece of code is significantly more valuable than searching for code to refactor and improve.
It’s true that improving a random variable name in your code base is not a big win, but:
Since you’re already looking at this piece of code and presumably making a change, the cost of changing the variable name is lower than if you were changing a random part of the code.
The fact that you’re looking at this piece of code and not a different one is evidence that this is something people are more likely to look at than usual, so the benefit of improving it is higher than improving a randomly chose variable name.
Because of these two things, the procedure “improve code you’re working on” is signifantly more valuable than you’d expect if you think the procedure you’re following is “improve all the code”.
Oh yeah, that’s something I’ve actually been thinking about recently. Unfortunately, I think it isn’t very compatible with the way management works at most companies. Normally there’s pressure to get your tickets done quickly, which leaves less time for “refactor as you go”. And then if you’re lucky, they’ll allocate some time for tech debt. But as you say, that’s less efficient than “refactor as you go” because you have to load all that context back in to your working memory.
All of this is a big part of what I had in mind in writing this post though. If managers/decision makers took the outside view on code quality, maybe they would encourage developers to take their time and refactor as they go rather than having pressure to finish tickets quickly.
I’ve heard this a lot, but I’ve worked at 8 companies so far, and none of them have had this kind of time pressure. Is there a specific industry or location where this is more common?
Interesting. My impression is that it’s pretty widespread across industries and locations. It’s been the case for me in all four companies I’ve worked at. Two of which were startups, two mid-sized, and each was in a different state.
Improving code you work on is also good because you are likely better understand the purpose of the code when you are working on it then when you look at a random part of your application.