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