There can exist a chasm between what you learn in bootcamp and what you will work on in your career. In bootcamp you might have spent your educatio...
For further actions, you may consider blocking this person and/or reporting abuse
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 ))
I agree, but working on legacy jQuery projects isn't really a transferrable skill. You'll be left in the dust if you spend too much time at a company hacking their legacy codebase. At some point you'll probably leave that company and have to invest a ton of time into catching up with the rest of the industry. Unless of course you're happy getting comfy at a big company with steaming pile of jQuery and coffee script.
You'd be surprised at how many places outside of silicon valley/major tech hub cities are still heavily dependent on using classic templating (jsp/jsf style coding), asp.net razor templating, jquery based ui's etc. For example, tons of bootcamps focus on things like ruby on rails, react, vue, etc...however in many many places outside America, the number of companies you find using those sorts of tools drastically goes down. Not saying I like the situation...as i'm an avid fan of React and node, however saying "you'll be left in the dust" feels a tad hyperbolic.
I agree mostly, but do disagree a bit. The actual experience of jQuery may not be as transferrable, although learning solid JS principles, learning how to work on a team, how to take part in a code review and a lot of other skills are very transferrable. Additionally, if you are part of the work of upgrading the codebase, those skills I believe are very in demand: How to understand what another programmer wrote, how to refactor it meaningfully and efficiently, etc.