Your opinion is not uncommon, but alas it is wrong (in most cases.)

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.

The code is not always about the code but mindset, culture and attitude.

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.

I think the key point was this line;

>> 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.

>> 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?

It's just a very junior opinion in my mind. I haven't really cared deeply about re-writing code or different ways of doing the same thing for a number of years, and I think of it more as maturing, even though some junior could probably come in and make the same amount as me because my work history and connections are weak or volatile.

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.

You need focus on other parts though, you can have the most beautiful codebase with the most efficient algorithms, the highest coverage and the most extensible yet simple and elegant architecture but if you're not solving the business problems someone's going to eat your lunch with a hacked together excel sheet.

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%.

> businesses have different goals and its focus should be on achieving those

For most businesses, still being around and profitable is an implicit, if not stated goal.

This is a forum for VC backed startups. We sell dollars for 90 cents here but we’ll make up for it in scale

Yes, this is different than "have a clean codebase".

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.

> Code should always be focused on; it should be constantly rewritten,

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.

Then again, if I had been given a cent every time I had to tell a member of my team "please, do the job we pay you for before doing the thing you find fun but have no actual business value" I would be a rich man by now.

A programming manager told me once that his job consisted of, every day, visiting every programmer on the team, and asking them about what they were working on. He'd then gently nudge them back onto what they were supposed to be working on.

I’m sure some people would find this overbearing, but to me this sounds like an exceptional manager.

It must suck having to work with people who need to be “nudged” to do their jobs, every day.

It’s very much part of the job at any organisation.

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.

My manager does not have to do this with me. We meet once a week where I update him on my progress for the projects assigned to me, or decide which next project I should take on. If anything impacts my ability to deliver, or if anything is unclear in terms of scope or priorities I talk to him on Slack to resolve it.

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.

It's funny people tolerate this kind of stuff. I'd be out the door immediately, and I have been before. You don't have to work for companies that do this kind of insanity.

What insanity? Being asked by your PO to work on the actual stuff your team has agreed to work on in the sprint planning , you know the stuff that management thinks will actually happen? If you don't tolerate this, it's certainly better for both sides to depart.

Let me tell you, it’s so frustrating to having to catch engineers veering from one fun thing to the next, it feels like being a kindergartener constantly trying to prevent a handful of kids from killing themselves with the next fucking thing they see.

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.

At any company, your job is to do what the company needs done and that is rarely your choice.

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.

> At any company, your job is to do what the company needs done and that is rarely your choice.

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.