Better advice: Go to where they actually care about what you're doing, if you can. Otherwise, put effort into what you're doing, but don't go overboard, and absolutely never work overtime.
Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount of money on the line that drives these decisions. And, so it goes, "get it done and ship it yesterday" is the commonality that I see.
That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.
I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you.
The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit.
The former usually means that you'll try and budget in time after the crisis to fix it up, the latter tends to spiral into a complete mess that no one wants to touch after a certain amount of time has passed.
Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.
Yeah, there's a natural tension in this. I know I tend to wander towards the "ship it" category but yet I've found my best work was when I was paired with someone on the "correctness" side of the equation.
It forces a constant re-evaluation of your methods and reasoning on both sides which leads to something even better than the two individual approaches.
Not sure why there's a hard-no on working overtime. Not everyone finds value or fulfillment in the same way or has the same goals.
My cousin just went from being an intern at Tesla to a FTE. This group change entailed going from 11-12 hour days to 9-10 hour days. It's crazy and maybe not for everyone but he's happy there.
I work at a more chill company, but sometimes there's something I want to do on the company code base that is not asked for by any stakeholders. I'm happy to occasionally put in an extra 10% to do something that scratches my own itch. I don't see much difference between this and someone who goes home and works in their garden or plays with Arduino or tinkers on an old car.
Working overtime? It happens. I accept it as part of the job, as long as it's rare.
Working overtime to clean up other peoples' mess that nobody else cares about cleaning up? Hard no.
If it floats your boat, if it's a hobby to you, if you want to spend your free time on it, then sure, knock yourself out. Have fun. Feeling like you have to? No.
I get where you're coming from. I just did this the other day (worked through the night on something for someone else over the weekend) but I may not have if I knew someone was going to come behind me and blow it away.
Maybe what I learned from it alone would be worth the effort. Tough to say.
That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.