What I’ve Learned in 45 Years in the Software Industry

> Clean, understandable, and navigable code and design

It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue-cli, Rails / Grails, gradle, and many other dynamic frameworks.

They achieve remarkable simplicity, yet I often end up hating them and swearing at them because I can't exercise my understanding of fundamentals to reason about them and rationalise what they are doing. "The database connection must be getting established somewhere - it should be traceable back from the point where the connection is used in some way" - well, no you may have to understand most of the entire underpinnings of the framework before you will achieve that understanding.

I think this "navigability" idea really fills that gap well. Things should be simple, but they should always stay navigable based on fundamental knowledge.

> initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s

I think OSS adoption explains this. Standards were all about advocating for common interfaces, even if the implementations were proprietary. Proprietary software was more a thing in the 90s and 00s.

Nowadays, common practice is to use open implementations, not just open interfaces. Nowadays, we only see widespread initiatives for standardization when people are trying to cement the long-term survival of their implementation's interface.

See, for example, the Open Container Initiative, put forward by Docker (a company that engineers were concerned about betting the barn on, in 2015).

Contrast that with S3, which does not have a corresponding commitment to an open interface standard. Their interface has been copied nonetheless by several vendors (DO, Linode), making it a de facto standard, albeit a fragile and autocratic one.

Basically, I'm not sure if standardization has evaporated, I think it's diffused, and OSS is (ironically?) a contributing factor.

All of that applies to frontend development too.

At the end of the day, some people like Javascrip and CSS. And "full stack" only means that they will work with those, SQL, and some backend language (that may be Javascript too). It doesn't imply anything on the workload, all it does imply is that the place is hiring a generalist instead of specialists.

Speaking as a career-long technical person,

1) All of those people aspects are very, very important.

2) Stacks don't matter. Languages don't matter. Editors/IDEs/whatever-the-hell-else doesn't matter. What I used to call a "firm theoretical grounding" does matter.

What does that mean? At the base, the ability to write clear code that other people can read, and the ability to read code that other people have written. (Don't laugh, it's not uncommon to get called in when someone has bugs (or features) they can't get fixed after they've painted themselves into a corner.) (For me, the key to this is formal logic and what is variously known as axiomatic semantics (http://homepage.divms.uiowa.edu/~slonnegr/plf/Book/Chapter11...) or Hoare logic, or predicate transformer semantics. Theoretical, right? But the ability to think about a piece of code as a block of text, without "simulating the computer" is darn useful.)

Further, algorithms and data structures. No, you don't have to memorize a bunch of algorithms. But it's a good idea to understand what kind of things are out there and what they can do, as well as having experience writing them yourself. (I get downvoted a lot, but I do have to point out that everytime anyone puts code in an editor, they're building a data structure or writing an algorithm.)

Then, at least some knowledge of computer architecture and all the stupid little electricy bits. :-)

Then there is a stack of things that build on that, some of which are only relevant to some tasks: databases, network protocols, and so on.

None of this has changed fundamentally in 30 years. The only major change I've seen is an increase in the importance of continuous math---which I noticed because I've always had a hate-hate relationship with trig and calculus and so on. But all of machine learning and statistical techniques are based on that nastyness, so you can't ignore it any more.

Why does nobody mention technical things? For one thing, they're hard. You can practice communication at the grocery store. Not so much with technical matters. Further, the people aspects are important everywhere, whereas technical things just aren't. And at some point, it's easier to convince some one else to do the work while you have the ideas. (Personal motto: Ideas are cheap. Implementation matters.)

Finally, technical mastery is not really encouraged. Outside of academia, there are no real incentives for it. (Inside academia, there are almost no incentives for it.) After 20, 30, or 40 years, people will migrate on to something else, even if they don't like it or are really horrible at it.

I think an important continuation of this same thought however is that since complex systems can emerge out of simple rules. And since reasoning about the behavior of entire systems (emergent or otherwise) is an essential element of being a programmer. It true that over simplification of the elements and generalization can actually result in a much more complex and difficult to reason about system, just as you point out about the game of life.

I guess my point is that sometimes the systems model essential complexity, and by trying to over simplify and generalize elements of that system, you may make the system as a whole more difficult to understand and reason about.