At work we live the scout principle. Leave the codebase in a better state than you found it.
This could be small things like formatting the code as of the current atandard but these things add up in the long run. And you really can embrace change. (Also acceptance tests are a wonderful way to gain confidence in the changes you make)
But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and ressources have to be aquired to fix the issue.
We would all be in a happier place if everyone lived by the scout principle. Also, I completely agree with: "But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and resources have to be acquired to fix the issue."
I think everyone sincerely does. Its just that many juniors (including me) should not have been allowed to commit for some time after they (I) were hired. Many of us (if not everyone) thought at some point that using syntatic sugar and ternary to make methods shorter is cool (like in hacker cool) - honest commitment to boyscout rule that results in a horrible codebase. I think in our industry we all thing of ourselves as unique artists with vision and dont like our code to be critisized. Of course this is only one of many problems in this disturbed industry )
It depends on the change. But seperate commits is imho the go to. This way you can distinguish between the actual "issue" and the house cleaning. If you touch logic it may make sense for a seperate branch so a coworker can review it
I have a different POV, refactoring on its own is pointless. Its always a part of a feature. Cleanup of a code that is relevant to a feature you touched should not confuse your coworker. Refactoring of a feature that never gets a business requirement is pointless - its already good enough, as it doesnt require attention ))
We really do have a different point on view on that part. It's totally right that we are mostly hired to create business value.
And we should only do things that create business value. Getting more pace at the development process imho creates business value. If we talk legacy code it is not only about new features. If multiple contractors worked on a piece of software over multiple years things tend to have some ugly places. You could fight it with every bugfix or new feature again and again or you can make a difference.
And i git is a wonderful tool if you want to keep track of why something happend. And housekeeping and the work for an actual fix are two different things because you obfuscate your intent.
Imagine you're fixing a little bug. Let's say it took one line. Then because you're convinced that the code should be formatted as of current standards. You run a tool in your IDE and boom thousands of files reformatted (extreme case but gets my point accross). It get's really complicated to reason about the change and find the spot you actually changed.
At the end of the day it's about making your and the life of your coworkers easier. (More readability, safer code, etc). You are not obligated to do that and go the extra mile but in my opinion it is totally worth it.
reformatting the whole codebase is definitely not something that should be shipped with one-line bugfix. neither it is something one person should author (as an idea, not as commit’s author)))
so codebase re-formatting is super specific edge-case. In most of day-to-day situations, however, its possible to make small steps. so small that they could be embedded into feature PRs )
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.
At work we live the scout principle. Leave the codebase in a better state than you found it.
This could be small things like formatting the code as of the current atandard but these things add up in the long run. And you really can embrace change. (Also acceptance tests are a wonderful way to gain confidence in the changes you make)
But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and ressources have to be aquired to fix the issue.
We would all be in a happier place if everyone lived by the scout principle. Also, I completely agree with: "But deprecated runtimes years in the EOL are a warning sign that there is something wrong imho. That needs to be addressed on a management level and resources have to be acquired to fix the issue."
I think everyone sincerely does. Its just that many juniors (including me) should not have been allowed to commit for some time after they (I) were hired. Many of us (if not everyone) thought at some point that using syntatic sugar and ternary to make methods shorter is cool (like in hacker cool) - honest commitment to boyscout rule that results in a horrible codebase. I think in our industry we all thing of ourselves as unique artists with vision and dont like our code to be critisized. Of course this is only one of many problems in this disturbed industry )
How do you go about it in practice though? Do you include the refactorings in the feature branch you're working on, or do you commit them separately?
It depends on the change. But seperate commits is imho the go to. This way you can distinguish between the actual "issue" and the house cleaning. If you touch logic it may make sense for a seperate branch so a coworker can review it
I have a different POV, refactoring on its own is pointless. Its always a part of a feature. Cleanup of a code that is relevant to a feature you touched should not confuse your coworker. Refactoring of a feature that never gets a business requirement is pointless - its already good enough, as it doesnt require attention ))
We really do have a different point on view on that part. It's totally right that we are mostly hired to create business value.
And we should only do things that create business value. Getting more pace at the development process imho creates business value. If we talk legacy code it is not only about new features. If multiple contractors worked on a piece of software over multiple years things tend to have some ugly places. You could fight it with every bugfix or new feature again and again or you can make a difference.
And i git is a wonderful tool if you want to keep track of why something happend. And housekeeping and the work for an actual fix are two different things because you obfuscate your intent.
Imagine you're fixing a little bug. Let's say it took one line. Then because you're convinced that the code should be formatted as of current standards. You run a tool in your IDE and boom thousands of files reformatted (extreme case but gets my point accross). It get's really complicated to reason about the change and find the spot you actually changed.
At the end of the day it's about making your and the life of your coworkers easier. (More readability, safer code, etc). You are not obligated to do that and go the extra mile but in my opinion it is totally worth it.
reformatting the whole codebase is definitely not something that should be shipped with one-line bugfix. neither it is something one person should author (as an idea, not as commit’s author)))
so codebase re-formatting is super specific edge-case. In most of day-to-day situations, however, its possible to make small steps. so small that they could be embedded into feature PRs )