[britch]

I think about this a lot. My belief is professional programmers should not be artists.

I think about other professions. A cook cannot spend time making every dish perfect. A bricklayer isn't perfectly aligning every brick. Even in movie-making there's a shooting schedule. Things go wrong and the best filmmakers know how to keep the production moving.

I love the craft of programming, but I see a lot other craft-oriented programmers who want every line to be beautiful. If you want to write code poetry in your off-time, that's your business. But that's not the job.

At work we are bricklayers and cooks. We practice a craft, but also have time constraints. I try to do my best work while working at pace. Sometimes my code could be better, but it's not worth the time to fix. Ultimately the thing we make is the running software, not what's under the hood. The business people are sometimes right

[fragmede]

The bricklayer's building that falls over, or the cook that makes food that tastes bad and no one wants to eat and makes people sick isn't going to have a job for very long, however. And of course, the job of "cook" runs the gamut from minimum wage at a shitty diner, to being very well paid at a Michelin star restaurant. So shipping code > beautiful code, but three years from now, that one "quick and dirty hack" just to get the next version out the door has become three hundred hacks, and that tech debt is a liability preventing any movement, either fixing existing bugs or in shipping new features.

So maybe not every line of code needs to be even more beautiful than the last, but there's clearly a balance to be had. And yes, sometimes the business people are right. Sometimes they are wrong, however.

[britch]

I think we're both arguing for balance here

When I started programming I wanted everything I wrote to be museum-ready. I was slow as shit and waaay too precious about code. As I've matured I realize that's not a good way to work.

I think my lowest acceptable quality bar is still pretty high (and I'm fortunate to work somewhere that is valued). But as time has gone on I've tried to emphasize speed and knowing when something is "good enough"

I feel that it's an important skillset for the profession, but often craft-oriented engineers dismiss it at "business people not understanding"

As always this depends a bit on where you work and your projects

[pdimitar]

Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross.

Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall over in a near-impossible deadline and with a lot of pressure then you are actually doing a huge disservice to yourself because the leadership will think "welp, obviously he can do it in those conditions" and next thing you know, next time around it will be even more difficult.

"Give them an inch, they will take a mile". Sadly this proverb very often applies to business people.

Most commercial programmers are extremely squeezed. I started daydreaming for another profession lately but yeah, ain't happening in my 40s with a very unstable financial situation.

I've read your sibling comments. It seems like you were on the other extreme and it does seem to me that now you are overcompensating by being too sympathetic with business and management. Whiplash effects are very understandable while one is still trying to find their balance. Still, don't give those people too much credit.

[britch]

What do you mean by basic level of quality?

What are you being pressured to do to meet a deadline that's on the level of building collapse?

"skimp on the tests" or "do this hard to maintain fix as the solution" is maybe the hardest I've gotten pushed. Are people telling you to skip auth to hit a deadline?

[pdimitar]

Here's mine from my most recent consulting engagement:

"We understand and recognize that this feature we asked of you absolutely cannot be done without the database denormalization you warned us is necessary several weeks ago, but we are still unhappy with you that you couldn't make it work without it and so we are ending our cooperation."

Consider yourself privileged.

I do all sorts of root-cause analyses and I don't sit to code until I am reasonably sure I'll make a positive impact. Long gone are the days when I started coding enthusiastically after hearing just two sentences.

It was still not enough.

I'll not start a flame war -- too tired for it -- but let us just say that some stereotypes exist for a reason.

[britch]

That's fair I appreciate you taking the time to respond, that's a helpful example

[viraptor]

> A cook cannot spend time making every dish perfect.

That's too generalised. A fast food cook can't spend time to make things perfect. A tiny, fancy Japanese place will spend time to manually craft a perfect dish and you'll wait while watching the whole process.

I suspect that you can find something similar in every category you mentioned.

[Nevermark]

> watching the whole process

I think this is worth exploring. Not shoving the details of work in people's faces to assert its quality, but somehow creating some drama or interest in its quality. In a way compatible with the immediate practical needs.

This isn't an easy problem to solve. And the example of a boutique Japanese restaurant is a good one. In this case, the process is designed to make consuming the food, the immediate practical problem, more satisfying.

Perhaps the code equivalent, would be seeing changes in sequence, where each change is obviously well done from the user's and manager's perspective. A process more easily achieved by green field work. Which is also relevant to the restaurant example, where each dish is its own creation (within a well thought out process).