Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems.

If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees

Haha, sorry, I'm only kidding.

That stuff a competent graybeard knows already.

You don't think they disappeared in 1990 and re-appeared magically today, or that they didn't kept up with the times during their career, right?

In addition, they would know all the solid stuff -- the things programmers before the internet had to learn the hard way, and lots of today's dilettantes lack.

And you must be very young (20 something?) if you really believe that "the stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today". That's simply not true -- and triply not true for 15 years ago.

I started programming in late 90s but not professionally until 2006 I think, this was probably the late phase of transition to internet as a dominant factor in computing - so I think it gave me enough perspective as to how things changed, plus talking to older developers, reading stuff online and on the forums I know we've come a loong way as an industry.

Or you just don't like management / like programming?

On the other hand, I don't like having to suffer stupid enterprise project managers either, though in my line of work it's better than the norm (more startup-y -- heck, we are at 100 people or so and our founder/boss still codes like crazy, same for the CTO).

I think the ideal for our kind of persons is having your own company -- either an one person one, or a bigger outfit but with someone else handling the marketing and finance parts. You get to both program and chose what and how to deliver.

Not everybody's interested in climbing the corporate ladder or in architecture, management, or consulting. Some people are content to be senior engineers.

"we've come a loong way as an industry"

The industry has certainly changed a lot, but if you keep your skills up to date, that's not going to be an issue.

The longer I'm in software the more and more I find this not to be true. The stuff that has changed is all surface level. The underlying principles are the same. The skills needed are the same. The attention to detail and other attributes needed to get the job done is the same. The problems are basically recycled or scaled up versions of the problems we had years ago.

18 years ago we had much of what we had today. Things might move on but they do not change. I mean hey, everyone still hates Visual Basic!

At least 18 years ago we were actually writing the majority of our code rather than relying so heavily on libraries and third party code. I mean someone only has to pull a Node.js plugin for padding and there is complete melt down!

This is basically false in every way it's possible to be false.

How much time should my team spend on testing vs. code review vs. building new features?

How risky is this feature, and how much QA does it need?

Which of the brand-new engineers on my team needs a careful eye on their code so they don't blow everything up?

When is it time to say screw it, we have to ship?

Which new hip framework is likely to have staying power, because of the people and the commitment behind it?

How do I convince open-source maintainer X to accept my new feature, so I'm not maintaining patches into eternity?

Those are the important questions I deal with every day. I couldn't answer them as well 10 years ago, and I bet I can answer them better 10 years from now.

Design patterns are way older than 20 years... hell, the design pattern bible was published 22 years ago, which means design patterns were in wide circulation well before I could tie shoes. According to wikipedia CVS has been around for 26 years.

Not to mention SCCS for 44 years, and RCS for 34.

To the earlier parent who mentioned process isolation: You're thinking too much about the consumer/desktop world. The entire enterprise world was used to it and demanded it, be it on (hey, humor here) SCO UNIX (yes, they really did make a useful product before they turned evil), SunOS, VAX/VMS, MVS, BSD UNIX, etc.

The desktop world was far behind the state of the art in commercial systems in those days. Even in the 80s, you were quite possibly running your enterprise with an Oracle database, on fully memory-protected hardware. Heck - you may have even been running some of your stuff in a VM on an IBM mainframe. We took some big jumps backwards in pursuit of making computers cost-effective enough for mass adoption, and it took a while before the consumer side of things jumped forward to become the same platforms used for enterprise use.

Kids these days. ;)

Just because people did not use a standalone program for version control does not mean that they did not version their code. This goes all the way back to card/tape drawers and paper tape revisions (there is a great anecdote about this in Steven Levy's Hackers). Look at software from the late 1970s/early 1980s - there will be versioning information there, and usually changelogs describing what was changed. A lot of operating systems also had file versioning built into the filesystem (https://en.wikipedia.org/wiki/Versioning_file_system#Impleme...) that was used for revision control. Since most of these OSes were timesharing systems this was in effect team-based version control.

SCM was the norm, at least in certain circles, maybe you should read up on stuff as:

https://en.wikipedia.org/wiki/IBM_Software_Configuration_and...

https://en.wikipedia.org/wiki/Source_Code_Control_System

Now of course, many PC developers came from 8-bit computers rather than mainframes, where SCM didn't really mattered, because programs were very small.

Automated testing - well, I have seen Lisp compiler written in the 80s that had them. So where it made sense and was possible to do, I think people did it. (IMHO it only makes sense for programs or their parts that are written in purely functional style, which is not a big chunk.) The workflow was different in the past (big emphasis on integration and system testing) and I wouldn't say it was necessarily worse.

Design patterns definitely existed, but they weren't named as such.

I am not even sure if people (writing business applications) are more productive today. We have lot of new artificial requirements. In the past, it was typical for datatypes and other things to be constrained by design. Today, people are unwilling to do that, even though it wouldn't change anything from the business perspective.

Or take a look at web. It's a tangled mess of HTML, CSS and JS (it's been 20 years and people still can't agree whether or not is a good idea to produce HTML in JS!). In the past, you would use something like CICS or VB or Delphi, which is a consistent framework, written for the purpose of building interactive business application.

> we've moved from mainframe/single PC shared memory model in to distributed/cloud/networked computing in the last 20 years and the problems from that era are completely different to problems today

Not really. The tradeoffs are simple to understand for somebody who had CS course 20, or even 40 years ago. And even back then people writing applications didn't hand roll their own SQRT, even back then frameworks and libraries did that for you.

My first Unix programming job had me first learn RCS and then we later switched to CVS. I used CVS personally for years after that until I switched to Subversion, then Mercurial, and now Git. What I'm doing isn't that different from when I used RCS. There's more steps because of the added complexity but it's roughly similar.

Um, nobody did this 20 years ago, either.

Not exactly SQRT, but.

Security was abysmal probably because there were nowhere near as many threats.

Some things change. None of it goes away.

Automated testing wasn't science fiction. It was regularly done, just as system or integration tests. You'd see who did the commit that broke the build. This was before QA even got to do their work. This was something done across the company and I'm certain that it wasn't the only company that did this.

> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.

Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before.

Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share.

I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone.

> This is the drag&drop and copy-paste as an abstraction VB shit era.

And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful.

> People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.

What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level.

> Security was abysmal - you didn't even have process isolation on OS-es.

Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse.

> Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.

The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things.

Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).

When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources.

As much as people like to bitch about our industry we have heavily increased engineering standard, if you don't use source control these days you get laughed at, if you don't use automated testing you're an amateur, even junior programmers know about patterns and nobody copy-pastes code over their code base - stuff like this was the exception back then not the norm as it is now. You can say MVC was invented in the 80s or w/e but up until maybe 10 years ago the internet was full of tutorials/guides on how to do web coding by interpolating PHP inside of your HTML, using string concatenation to build SQL queries and such nonsense. Sure top 10% never did that but the vast majority of programmers did and the broader industry has improved significantly since then, in no small part thanks to the frameworks that constrain the bad developers on to the "good path".

If you don't use automated testing, you are probably average.

Plenty of junior programmers know nothing about patterns except how to cargo-cult them.

Plenty of people copy-paste code everywhere.

I'm curious how long you've been doing this stuff, because this sounds like neophilia.

At its core, 90% of professional programming is:

1. Plumbing: Routing data from this component to that one through this API

2. Processing: Algorithms, most which have been published for decades)

3. Formatting: Ingesting data in format A and displaying it for the user in format B.

This is true today, was true when I started, and was true 20 years before that.

The inability to use abstractions properly has long been a sign of inexperience or incompetence. I'd really like to see some evidence that this was any more prevalent in 1996 than it is in 2016.

There's definitely more of a concern these days in the general programming world about "best practices". But those best practices weren't invented yesterday. They're usually incremental changes of older practices, and the results of bitter, painful experience of doing things the "wrong" way. Exactly the kind of experience that senior engineers have that junior engineers lack. It's senior engineers who create those best practices in the first place.

I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant.

I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes.

MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems.

Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations.

I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.

And don't get me wrong I don't think what we have today is anywhere near perfect or even good, frameworks are often more trouble than worth but at least frameworks showed people that <?php mysql_query("select * from foo where id='" . $_GET["id"] . "'") ?> isn't the only way to write code - I do not want to go back to those days.