I've seen what happens when people stop focusing on code. It's a timebomb for institutions. Code should always be focused on; it should be constantly rewritten, taking the lessons into account from previous iterations.
In most businesses, code is a tool to get to the desired outcome, not the desired outcome itself. Like most tools it is most valuable when being used to create the outcome, not being endlessly perfected. Good enough is good enough. Perfect is a waste.
Again, context matters. The code that runs a million times a day is more important than the report that runs once a year.
Equally, a well architected system will need to balance the needs of any different users, with potentially different goals. In other words, lots of compromises are necessary. The code reflects those compromises. There's a balance, good enough is good enough, time to move on.
I will say though that your attitude is not unique. I have come across many employees, and even one-man-companies that focus exclusively on the code. Often (not always) because code offers the programmer complete control. Unlike co-worker, bosses, employees or customers, it is not messy - perfection is achievable. Dealing with people is messy. Other tasks (like marketing) are vague or immeasurable. Code is simple, objective, doesn't talk back.
Certainly coding well offers an emotional reward. It's a clean game with fixed rules, and performance can be objectively assessed. For many of us it's a safe haven in a very messy world. But unfortunately it's usually just a tool, not the outcome. Someone in the messy outside world has to pay money - and that adds 10x more messiness, which someone has to deal with.
Progressing from junior to senior programmer, then into a business space (like analyst or architect) is really just the understanding, and skills, that come with balancing that messiness with the desire to write code.
Unless you're operating at a particular scale or with specific constraints, the main important thing is passably meeting acceptance criteria accurately enough to check a box and say you did it in some period of time that you probably agreed to. That's all the business cares about, therefore that's my job. I've never once met a customer/user in my course of employment, therefore they only matter as much as the company defines and empowers my success as closely tied to it. I'd love a job like that, it would be a change, but that seems to be scarce, and until then I'll just chip away on this dashboard only imagining at a distance what the impact of my work could be.
Usually what happens is the attitude carries throughout.
E.g. when developers start saying that optimisations don't matter they get into the habit of never doing it until it breaks. At that point it's too costly to fix and spirals out of control.
Why not just get into the good habit of writing good code that might cost a bit more upfront but will settle down and be a positive impact going forward?
Is good code just for the outcome?
Your statement neglects that developers are humans. If you have a new hire and they look at the code and have to spend forever understanding it - is that not a cost? Or perhaps they'd look for the next job just based on how much it annoys them.
It's the same as not cleaning your house or office. The desk is just a tool so you can get your outcome. Let's leave it right? Let's also not mind if rats watch you do your work!
Being a perfectionist is bad and for that I agree but that's not code specific. I don't get the concern. Surely people also spend too much time on things like presentations that might not impact the outcome. It's all just human nature and not developer specific.
>> it should be constantly rewritten
There's nothing wrong with writing good code. Ideally it should be good the first time, not the 3rd or 4th time. If you are writing code in a well architected system, using consistent techniques and styling, then it's not a mess, but it doesn't need to be perfect.Good enough implies good.
To follow your cleaning analogy, there's some cleaning to do regularly (maintainence etc) but you don't raze the building and rebuild every 5 years just because a new kind of brick comes out.
Say those organisations that have brand new offices all the time and move staff into it? Say those people that do home renovations? It does happen. For whatever reason. And no 1 says it has be rewritten completely. So the same applies. Whether you've upgraded your PC, replaced your monitor, your clothes or anything like that you don't "need to" to do whatever task but you do.
I get back to the point of why single out developers for any of it?
I'm not defending developers in particular. It's just human nature. Getting a new logo that looks 90% the same for millions is likely 100% worse than rewriting some part of the code.
What's the justification to rebrand, get a new logo, new name, change the font a little, etc? There's no need to get a new website either is there? Do you 1st go out and get data that a new website will attract more customers before doing it?
The other view I have on this is around trust. Do I need to "focus" on the code if I have people on the team whose job that is? At what level? At a more senior position I shouldn't be looking into the small parts, the more effective use of time is ensuring the larger components are going in the right direction and/or we're not spending time on parts expected to be unused due to a strategic shift coming in. Maybe it's more important to focus on documentation right now, or perhaps it's important to get people working on different things because everyone's fixed on their small problem and not understanding the integration issues we have.
Code is important, but it's important for a reason. Create your artistically beautiful perfect codebase when that's the goal perhaps as a personal project, but businesses have different goals and its focus should be on achieving those.
"Focus" or attention I guess, is a limited resource. Spending it on one thing is not spending it on another. Balance is needed - 0% interest in the code is a big issue, but so is 100%.
For most businesses, still being around and profitable is an implicit, if not stated goal.
I'd say that companies have more specific goals than making money - it's usually making money in a particular field. There are then strategic goals, set semi regularly by the leadership, which are the level I'm generally talking about.
You should have that concept of making money in mind though, as it helps guide what to prioritise. I've seen engineers spend thousands and thousands of pounds of their time (more if you consider the opportunity cost) to lower some bill by under a hundred a month - a large upfront cost with years before it'll pay back.
Your PO: I've noticed you've been rewriting a lot of methods in the code base. Can you please tell me which stories on the board this sprint those rewrites are attached to? We need to focus on sprint work, and as we established as a team last PI Planning meeting, the emphasis this quarter is on shipping features from the Customer Experience epic. Please refrain from needless refactoring not accounted for in your sprint work.
At any level, you have in front of you people with a lot on their plate, competing interests and different prioritisation abilities and it’s your role as a manager to give them enough information for them to prioritise adequately.
It might be straightforwardly reminding a developer that right now we really have to ship this feature or it might be subtly making a manager understand than it would be in their interest in the upcoming reorg if they were seen as a strong asset in solving a specific issue even it’s not directly part of their KPI and explicite goals.
I am a professional. I do not need to be reminded about what I have promised to do. Maybe that's why I'm paid good money to do what I do.
There is a reason we’ve decided what to work on. We have customers and a runway to consider, and targets we promised investors to reach. I also would like to work on fun stuff instead of fixing those bugs! That seems to be something you only understand later in your career though.
It's gonna get much, much harder to find the kind of laid-back company you favor, where you can work on whichever part of the code base you want, when you want. There's much less money sloshing around, and what's there needs to be spent on priority items.
Doing what the company needs done can also mean not taking orders from your PO. Depending on your situation, that could manifest as ignoring them, working around them, convincing them it was all their idea, directly challenging them, or going over their head. Skullduggery. Ass-kissing if necessary. Be a hero or a martyr in the end, but at least end each day with a clear conscience.
None of that being my preference, given the choice. All I expect from a PO is a collaborative relationship where I'm treated as an equal and not some member of the worker underclass who's just there to close tickets.
When the project collapses under its own weight as a consequence of the PO's own choices, is the PO going to take the blame? Is the PO going to help when production goes down? Will they working overtime to fix things? Who suffers? The PO? Not so much.