Think of when you are working on a large project and you all of a sudden need to refactor some module which then has a huge impact all over the application. This is similar to a novel where late into the book the author figures out they want to change some part of a main character (like their origin, name, just some kind of detail), which will require fixing it all over the book. Writers refactor similarly to programmers.
Writers have outlines. Programmers have design documents.
There are more parallels between the two, but I forget many of them right now.
It is also (always?) storytelling, I agree.
Imagine if software was physically manifested and somehow translated into familiar aspects of life. Going to buy a car you wouldn't see a lineup of several incrementally different models from different companies, instead you'd see: a bicycle; a tank; a bamboo framed solar powered moped held together by duct tape; a rocketship; a jet pack; a houseboat on top of an enormous tracked crawler; and a pair of rollerskates (both for the left foot). Also, half of them are free, a quarter of them can be bought for cash, and the remaining quarter cost tens of thousands of dollars per unit and can only be purchased through very elaborate contract negotiations (and there's no rhyme nor reason which is which, because the rocketship is actually free, and the rollerskates is one of the crazy expensive ones).
That's software, and that's just a tiny pocket of it. The entire software industry is basically fractally weird in the same fashion, but on a much larger scale. It's commonplace for some metrics to differ between direct competitors by not just percentage points but by orders of magnitude. It's also commonplace for competing products to offer entirely different paradigms of use. Imagine considering buying one of two different hammers, one of which is an ordinary hammer, while the other somehow submerges and infuses your surroundings in a bubble of liquid glue 1 light year in radius, then rapidly cures just the portion of glue you want to cause two things to stick together, then instantly vacuums up the uncured glue remaining in the bubble. That's the scale and weirdness of differences between SQL and NoSQL, or between systems built on node.js and java, for example. But we accept that as if it's normal, and the end user never really sees it. HN is a perfect example. As a user you can't really tell what HN was written in, and you can't discern a difference between its underlying structure and, say, how facebook works (except at a functional and UX level). But underneath HN is written in Arc by a tiny team and facebook is written by an army of devs on PHP and makes use of custom PHP compilers.
So learning programming is like learning language, and should be taught similarly -- lots of feedback (REPL, throwaway projects/conversations) to develop fluency, and once you can carry on conversations, start specializing into specific, valuable subjects you may want to talk about and do business in.
But programming is definitely writing.
All of the most fundamental hard-science engineering advances end up, not just being encapsulated into libraries, but woven into the languages themselves (garbage collection, lexical closures, laziness, STM, generics, ownership and borrowing...), and programmers express their (executable) ideas more clearly using language appropriate to the topic.
I read about, for instance, PG Wodehouse pinning every single page of his book up on a vast wall in a grid, so he could take it all in and then take a step forward and consider what was being accomplished over the course of these two or three pages, and see at a high level what was working or not.
Or Raymond Chandler exploiting the existence of pulps to throw away heavyweight notions of story in favor of a medium where you can just choose to have a man burst through a door with a gun in his hand, so he could throw readers right into the meat of a story. And then burnishing his little hacks to gemstone luminousness by writing them to, according to him, the same level of quality as the "slick magazine stories" of his day.
And Chandler's insistence on the importance of actually playing with, and loving, the words themselves, at the sentence level ...
I think all of the things that make programming unique have to do with its connections to, 1) our basic human language capabilities, and 2) writing for two audiences at once.
It really depends on the industry and context. Part of me really envies you if you can say that much and that reflects your experience.
I spent most of today making sure that my SPMP, SQAP, SCMP, SRS, etc... documents conform to the relevant IEEE standard.
If none of these acronyms means anything to you, again, I envy you.
Yet, the parent is talking about "programming", that is still the most important part (although still a part) of a Software Engineering project.
Software Engineering is a recognized discipline, and although I do work in an EE environment, I believe most software projects (which have a contractual obligation with a definite scope and a deadline) use it in a form or the other.
Consider spending some of your day to automate these tasks. It sounds easily automatable.
I wrote a script that checks that Python scripts conform to standards and it worked well and saved a lot of time. Perhaps something like that would save you a lot of time and allow you to spend your working day doing something more fullfilling.
I wish the best of luck to you sir!
SQAP - Software Quality Assurance Plan?
SCMP - Software Configuration Management Plan?
SRS - Software Requirements Specification?
I've seen "engineering" defined as "statics, dynamics, and thermodynamics", but what you've listed sounds much more like engineering to me.
I might be wrong, but I believe "Software Engineering" is a more common concept in Europe than US, since many "Computer Science" degrees are actually part of Engineering Universities curricula.
That is to say, many universities are more likely to offer a "Software Engineering" degree rather than a "Computer Science" one. But it might be only my experience.
I myself have done web, mobile apps, mobile games, console and PC games, systems programming, database programming and even incorporated my own business. I've done these with open source stacks and Microsoft stacks.
It's all fun in the end, if you have something challenging for me to work on, a new tool and or a new medium I'm all ears, please contact me....I'm 39.
I compare programming to writing, more than engineering. There is no engineering in programming. No matter how many "methodologies" are created, writing good programs and good systems is akin to writing a good story or a good book. It takes practice, it takes courage to remove instead of adding, to make it as simple as possible. The best programmers are Hemingways to me. Terse, to the point. It just works. It looks beautiful.
In the same vein, a writer doesn't usually become a manager. He keeps on writing, until old age, until forever. That's what we do, what we like to do. Sometimes one becomes a manager due to money pressures - after all who's going to pay a programmer the same as a GM or VP. But people like myself secretly or not see themselves programming until the bitter end.