"Refactoring risks introducing new bugs" Any changes risk introducing new bugs if tests are not sufficient (even bugfix changes). Refactoring is not special in that regard

@SergeyZolotarev: Exactly. But tests often are not sufficient, and unlike bug fix changes this does not have immediate value to the company. It may be important, but it is far from urgent, and what you should be working are the things that have higher combined urgency and importance. That's the priority score. By all means put refactoring on the backlog of technical debt; then ignore it until there is nothing of higher priority to do, or do it piecemeal when you are working on that corner of the code anyway. Frankly, improving the documentation is usually a higher priority than refactoring.

I'm totally on board with you when it comes to documentation. But here's the thing: it's either standards or no standards. You can't have mess in one place and order in another. Mess propagates, permeates throughout. If you believe I have better luck advocating for a better documentation, think again

@SergeyZolotarev: it isn't all or nothing. Reality is fractal. If you want perfection rather than product success, do consider an academic career. Otherwise, I strongly suggest that you work as directed for much more than one year, to understand real world imperatives, before trying to change the system.

And if you're complaining about lack of tests: everytime you touch code, write a test to confirm your change. If you keep doing this, eventually you wind up with a library of tests. It isn't as thorough as test-driven design, but it gets the job done. And writing those tests is also higher priority than refactoring.

But one of the reasons I do refactor is to make our classes testable! They are not, at the moment! I do write tests too, if it's possible. I'm the one who wrote first ever tests for our key module used in more than a dozen others. I didn't have to, they didn't pay or commend me for that. Not some old hand but me, a newbie. Guess what, then some weeks later the lead comes along and says, "You know, we need tests for certification, let's write some tests for the sake of formality". It was quite amusing for me

More than 20 years since the project was started, they finally realized tests may give them a competitive advantage. No way! I was ahead of all that

Welcome to the profession. Legacy code is legacy code. You learn to work with it, and around it. Or you start your own company, write code from scratch, and make your own mistakes. Completely clean, documented, tested code of more than a few hundred lines is a platonic ideal never achieved. As a student, you rarely exceeded that threshold, and never had to maintain code over a time period of more than a term. You don't have to like the real world, but you have to learn to work with it and around it. Trying to break it down by hammering your head against it is painful, and does not work.

When they ask you to write a new class, you can set an example of how it should be done. But don't expect it to stay clean.

@keshlam, "Or move to academia, where elegance is more important and practicality less so." - are things elegant in academia? Academics seem even more out of touch than non-technical managers. It's been 50 years since academics were making sense, and 25 since industry was generative.

@Steve: your experience is different than mine. Perhaps this reflects the schools we attended.

The last sentence is possibly the least true thing I've ever read: even games programming cares more about elegance than academia.

@keshlam, perhaps a difference in era. My impression of academia nowadays is that it is a hive of uncritical thinkers peddling hobby-horse ideologies. All the respectable academics I can think of were formulating their ideas in the 60s, and the foundations of complex software I use was set by the 90s.

Where as I went to a research institution in the late '70s which had a leading computer science department. (Hint: Liskov. I still wish more of CLU had survived into what became object-oriented programming; it has taken indecently long for people to rediscover some of her ideas.)

All the code I've read out of academia was borderline unreadable. YMMV ofc, but I wouldn't blindly go to academia hoping it's a paradise of good coding practices.

Academia, in my experience, preaches good coding practice, whether they actually practice it or not. This leads students to expect good coding practice when they leave the halls of learning, resulting in frustrations such as this one. (Where else do you think somebody with one year of experience has gotten this fixed upon best practices?)

@keshlam, the late 70s is 45 years ago! 😂 Honestly I don't think 1970s academia resembles what it is more recently. Most students today are getting their ideas from various industry pundits, many of whom are unsound, and many of whom are interpreted outside their context.

I have friends who are in academia, but I will grant that I haven't looked at enough curricula to have more than an opinion.

Having moved from academia to a big software company: In academia, what mattered is the next paper and only the next paper. You wrote code for that and when that was accepted, you moved on. In a software company, you need to prepare for someone looking at your code 1 year, 2 years, or 10 years from now.