To write software, you used to have to be a physiscist. Or a least a mathematician with a deep understanding of why the registers were working.
Then, the physics was more or less mastered and the profession split into electrical engineering (the physicists lamented this degradation I'm sure) and applied mathematics.
Then, the math was more or less mastered to a level it could safely be abstracted away and math spun off computer science and software engineering. I'm sure the mathematicians were upset then at the degradation of the profession.
Then, software engineering advanced to the point that ever higher levels of abstraction were present on ever faster computers, no longer did you have to get the logic right _and_ the math perfect for your program to run in acceptable time. And higher level languages emerged, assembly leading to c leading to python and JavaScript. And at every stage there was moaning, and excitement.
Now, we stand on the precipice of the next great division. People can get a reasonably complicated website up by configuring Wordpress or Joomla or Drupal without writing a single line of code. A 14 year old can run a mcafe script at the geek squad counter and get the users computer back in decent shape. We are at the point of adding moderately skilled technicians to our field.
We can piss and moan about the division, or we can recognize that it's part of the process of the industry and vocation maturing.
The engineers at GM aren't bemoaning the fact that "car maintenance gurus (mechanics) don't have to understand the heat displacement of aluminum vs steel"
Having mechanics makes the car industry more efficient and lets the engineers focus on the real hard problems. The same will be true of software, eventually.
I don't think your history is really quite correct in its nuance. Programming as an actual trade emerged quickly in the 50s. The 60s saw the rise of computer science degrees, often coming from either the Math or the EE side. During the 50s and 60s, the computers had tons of people working with FORTRAN/COBOL (& others) to churn out business code. This accelerated in the 70s. There were armies of basic programmers out there. It only takes flipping through Dijikstra to realize that these people were not super well trained.
Occasionally in the recollections of the really early programmers, we learn that they were hired from the secretarial pool and trained if they had math aptitude. Not from physicists or the PhDs always. I am sure this was very true for the line of business & banking apps.
I'm sorry, but the truth desperately matters in your account. Timelines are very important in understanding how knowledge flows from group to group and from generation to generation. In particular, these things need to be highlighted:
- Computers became commercialized around 1952-54. Immediately prior to that, physicists hired programmers for the clerk work of coding up their problems (interesting note: they usually were women. You can find the story online of the programmers who worked with von Neumann. It's very interesting).
- Business adoption was pretty good! In fact, by the late 60s, software was exhibiting its standard characteristics - buggy, late, expensive, hard to control. See the NATO conference on software engineering, 1968.
- In the early 60s, dynamic languages came about in the form of Lisp. This did not take off until, AFAIK, Perl started making headway in the 90s.
- Cobol, Fortran, and others that I don't remember were standard in the 50s & 60s. And everywhere. These preceded the foundation of computer science as an academic discipline, which became institutionalized in 1969, give or take.
- Where did these business developers come from? I don't have job ads, but in my readings from the journals of the times, academic work seems to have gone on fairly apart from the line of business development.
How do these differences change the crux? We are in the process of the industry splitting into technicians and developers and this is overall a good thing?
I think they are interesting details, for sure, but I don't see exactly why you think they're relevant on a first order approximation.
"But, I try not to let the exact truth get in the way of a good story unless the exact truth is the crux of the argument."
The computer cares not for your platitudes. Fix your shit.
(More specifically, at least put some timelines on your milestones--you overlook, for example, a lot of computer early adoption by banks and insurance companies. A lot. See Burroughs et al.)
(These feel-good stories only serve to further undermine our profession.)
I think I gave an account of history that is accurate enough on a first order approximation, and it is history as parable to come sideways until I got to the key point of: specialization is a good thing.
Are any of the field divisions I mentioned inaccurate? Or is it the chronology youre objecting to?
This isn't a feel good story, it is a parable. My entire point could be rephrased in a more hostile fashion as: It is not presently feasible to be an expert in every aspect of computing, so why is further division of the field a bad thing?
You could've made that point and probably gotten a decent enough discussion out of it, no harm done.
The problem with the parable is that it didn't read like a parable, and instead read like a layman's explanation of history--were it more clear or disclaimed, I doubt any of us would've taken offense.
It really isn't that hard to do basic research to test your assumptions. If you don't do it for us, at least do it for yourself. A good story is all of accurate, insightful and entertaining. Yours is mainly the latter, lack of accuracy relegates the insight you were hoping to convey to bullshit.
It is not hard. But it is also not justified by a cost benefit analysis of the situation (this is after all a comment thread on hn). I gave a historical parable about not getting high and mighty when the industry advances its abstractions to the point where less years of study are needed to efficiently build things.
If you feel my level of detail takes away from my goal of providing a relatable parable, please let me know how.
Two general trends I've seen since the 80s. Not entirely different than your observations, but a little different.
Lack of ability to evaluate competence means the loudest peacocks at the quickie-oil-change shop proclaim themselves gods gift to automotive engineering. They get laughed at a lot, but they also collect a lot of undeserved money.
Another trend is a profound lack of abstract thinking ability especially as regards problem solving. This is best seen as "this nuclear aircraft carrier has a GUI and a tablet app, therefore it requires no training, education, intelligence, or experience to operate".
I make a lot of money cleaning up after people dumb enough to believe those two general lines of thinking, so I'm not entirely bothered. We have a lot of carnival showmen, but as long as I'm making stacks of cash cleaning up after them, I'm not all that bothered. It is kind of silly though.
Adding 'technicians' is not a bad thing, because like you said it lets us focus on the real problems. The 14 year olds can configure their blogs and fix peoples' computers while we write the software to send spaceships to Mars.
But let's face it: the more extroverted among us are jealous of the "social media gurus" who are waving their hands on the television stations and spewing garbage opinions. They didn't work for engineering degrees like we did, but their words are still heeded more than ours, even though it's just hot air.
Imagine what the world would have been like if the internet had existed when the automobile was introduced. I'm sure that the automotive engineers would be bemoaning the fake experts just are we are now. But the automotible did not make everyone's voices heard.
The very nature of our field means that we create technology that makes it possible for the loudest voices to carry the most weight, even if they don't know what they're talking about. It's the bitter pill we have to swallow.
I remember seeing a documentary on ford where craftsmen who built non-interchangeable-parts cars bemoaned the loss of craftsmanship in the assembly line method. Bitching and moaning about progress finds a way, even with the most rudimentary of tech.
"assembly leading to c leading to python and JavaScript" - it sometimes baffles me why people decided that basic code quality doesn't matter any more and we ended up with script-like languages... Definitely a strong contributor to the subj problem. If the dev world went the OCAML way we could maintain a stronger professional image...
Then, the physics was more or less mastered and the profession split into electrical engineering (the physicists lamented this degradation I'm sure) and applied mathematics.
Then, the math was more or less mastered to a level it could safely be abstracted away and math spun off computer science and software engineering. I'm sure the mathematicians were upset then at the degradation of the profession.
Then, software engineering advanced to the point that ever higher levels of abstraction were present on ever faster computers, no longer did you have to get the logic right _and_ the math perfect for your program to run in acceptable time. And higher level languages emerged, assembly leading to c leading to python and JavaScript. And at every stage there was moaning, and excitement.
Now, we stand on the precipice of the next great division. People can get a reasonably complicated website up by configuring Wordpress or Joomla or Drupal without writing a single line of code. A 14 year old can run a mcafe script at the geek squad counter and get the users computer back in decent shape. We are at the point of adding moderately skilled technicians to our field.
We can piss and moan about the division, or we can recognize that it's part of the process of the industry and vocation maturing.
The engineers at GM aren't bemoaning the fact that "car maintenance gurus (mechanics) don't have to understand the heat displacement of aluminum vs steel"
Having mechanics makes the car industry more efficient and lets the engineers focus on the real hard problems. The same will be true of software, eventually.