>Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be.

True, but I think any attempt to standardize or to make it another engineering discipline would mean the end of high programmer salaries. Just follow guidelines and standard procedure in a book and you'll end up with a reasonable solution that is reasonably good and reasonably reliable at a reasonable cost. Most businesses would jump at that...

And I'd argue that would be a good thing for all the sectors where programming is important, but no good programmer wants to actually join because its not sexy. (coal mining, medical equipment, etc)

> I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development.

Yes but no business actually cares about creative solutions, unless algorithms are core to their business (and even then, other human factors outweigh finding the optimal, bestest, fastest solution). They simply want to use computers to solve a business problem. They want a runner to run from A to B, not an Olympic sprinter who is going to break a world record. Do you know a reasonably decent sort algorithm? Good, just use it. Profiling? Optimizing? That's for Olympic sprinters. Design patterns? Blindly apply a GoF design pattern that approximates your problem, etc etc.

To me, your line of thinking seems to suggest that there is some end-game where a canonical program could be written and all programs would converge towards this with standardization. But that won't happen just by standardizing structure. The structure still holds content which has to adapt to those business goals etc.

I think it is more helpful to think of programming like other writing tasks. The difference in size and structure of programs is more like the difference between tweets, blog posts, shopping lists, poems, political essays, short stories, daily news articles, novels, anthologies, text books, academic articles, encyclopedias, court records, state constitutions, legislation, car repair manuals, and tomes by Russian authors.

Having standards and idioms for structure in writing doesn't remove the need for writing, creative input, nor even for creative exceptions to those standards and idioms.

But I don't agree that programing SHOULD be a creative task. The primary reason being that A creative tasks' output depends quite a bit on the person performing the task. Whereas for an engineering task, less so - as long as the engineer is trained, knowledgeable etc, etc (usual caveats for pedants..)

>But that won't happen just by standardizing structure. The structure still holds content which has to adapt to those business goals etc.

I agree, but i'm thinking along the lines of - more LEGO, less literature. I.e. A move towards a more standardized problem specification process that itself becomes the solution, or at the very least through minimal effort.

> I agree, but i'm thinking along the lines of - more LEGO, less literature.

That's what I see happening. There's already a huge reliance on just connecting together libraries within the confines of a framework for lots of problems.

> no good programmer wants to actually join because its not sexy. (coal mining, medical equipment, etc)

Good programmers don't want to join these kinds of jobs because most normal businesses don't understand software engineering or the market and treat it like a cost center.

I started out my software career by writing vb macros in excel and saved my "boring business" company hundreds of thousands as a side effort to my normal job. Yet I couldn't get any traction to do it full time or to have autonomy or to get a meaningful (30-50%) pay increase to match the dev market salary.

I think our industry can come to _understand_ and _articulate_ the skill set without having to standardize/certify it.

Civil architects can be wildly creative and artful in their industry which understands its own domain deeply.

I would agree that there is an artfulness, for lack of a better term, in engineering. However, there is a lot of science and math i.e. structural engineering that underlies building a structure that is safe and won’t fall down. Admittedly it still does happen from time to time due to mistakes or things that might have been misunderstood, e.g. the Tacoma Narrows Bridge.

The field of software engineering is very nascent and is still in need of the underlying science and math foundations like you find in other engineering disciplines. Unfortunately methodologies like Agile and Waterfall seem to have become synonymous with software engineering.

Right, but when you hire an architect to design a random office building, you're not expecting a piece of art. My point is the vast majority of programming projects are random office building # 23.

Then we’re in the realm of automated or at least codified/systematic process, or we should be, no?

Yes, and we should be encouraging more of that. But as programmers (well to my mind anyway) it nags us when we look at inefficient solutions, even those which are reasonably robost/adequate. We tend to scoff at people using Visual Basic to solve a business problem, when its probably the best language for a large chunk of the problem space.

> I think any attempt to standardize or to make it another engineering discipline would mean the end of high programmer salaries.

I think you might live in a tech city bubble.

Outside of a few tech cities developer salaries are well below engineering salaries.

If development was treated more like engineering then developer salaries would go up. A lot.

As a thought experiment imagine an org that hired for organizational/abstraction skills and landed a single worker good at algorithm design. (This is a distilled/simplistic example but bear to the point.)

10-20% of time in my career building business/productivity application systems have I needed to design & impl a complex algo.

Okay so my fictional team abstracts away that need and my algo guy colors in the deets. (In most cases this is possible; in rarer cases the performance of the algo needs to cross-cut.)

But the point is what you’re saying—one skill is pluggable, the other is not.

Kind of making this less interesting (or more?) is that learning algorithm dev tools/skills is far, far easier than learning the architectural/organizational skills. So no wonder the current prevailing hiring emphasis.