- Programming computers was something you learned in college.
- Software came in a box, with media and manuals.
- You purchased your compilers and IDE, and they weren't cheap.
- Spelling correction was something word processors did, not compilers or IDEs.
- The libraries you used to build software were something you created and/or paid for, and you knew where they came from.
- You often didn't have the source code to the libraries that you didn't create.
- Builds were performed by humans, or at the very least, the scripts were created by humans.
- Testing was performed after the code was written.
- Debugging was clunky and difficult.
- Architects understood each part of the system deeply.
These days,
- Many people learn to program computers before college, and some really good programmers never took a course in programming at the college level.
- Software is downloaded over the Internet.
- Many decent compilers and IDEs are free.
- IDEs do spelling correction.
- Many of the libraries are free, and you don't necessarily know where they came from.
- You frequently have access to the source for libraries you didn't create.
- Builds are performed by machines, and machines often create the build scripts.
- Tests are often written before a line of code.
- Debugging is pretty simple.
- Architects don't necessarily understand how all of the parts work.
My recent foray into building a component to demonstrate sending of a Direct message used completely free software, all of it downloaded from the Internet. I had to struggle to find which libraries I needed, because I refused to download yet another component that does a bunch of stuff for me without telling me what I'm getting. That was probably half of my time. I still want to know what my dependencies are. Testing, well, this was a throw-away project, so I didn't invest much in testing, but I certainly took advantage of tests that were included with the code I was using to verify I had installed certain things correctly. Having access to the library source code was critical for understanding how things worked. One of the challenges with documentation that comes with software these days is that it is often of poor to mediocre quality. The loss of printed manuals also means that we lost things like editors and technical writers along the way who ensured that the documentation was of high quality. I have a better idea than many how the parts of software that I use work, even though it comes from a variety of different sources, but only because I make it a point to learn. Even so, there are times when I have to rely on the source code to figure it out.
Oh, and as for learning to program, I wrote my first decent computer game at the age of 13.
Overall, I think the changes between now and then (20 or so years ago), represent an overall improvement. I do fear somewhat that the complexity of software is creeping beyond what many architects can reasonably handle. While I think that most of the automation being developed is good, I still feel like some of it is a crutch. I suppose eventually, I'll adopt more of it myself, if only because I want to use more of my gray cells for doing cool stuff, rather than understanding all of the details of the pieces I'm using to do it.
At one point in my life (more than a decade ago), I'd written a business plan to form a company that would do context sensitive spelling correction for compilers and IDEs. Eventually, I discarded it. Not because I thought it wouldn't work, or that I couldn't develop the software needed, but rather because I had already seen spelling correction as a business come and go in the business application market. It simply seemed like the second time around, it would happen so much sooner, and I'd never have the time needed to capitalize on it in a way that would make me really successful.
i contend that many of these existed in the 1970s. I learned BASIC using the free compiler included from microsoft. I found lots of code, using gopher.
ReplyDeleteGrowing problem, and not limited to software. I spent an interesting afternoon last year with MIT profs who where re-examining how they taught electronics. Most current design is based on mystery black box components of great complexity. Nobody fully understands how most of their parts work. But they need to know how to find parts, evaluate parts, select parts, use parts, and troubleshoot designs. The challenge for the teachers is to figure out what skills remain necessary and what can be dropped from the curriculum.
ReplyDeleteThe major growth is in the use of system design understanding. There is also an effort to make awareness of ignorance a conscious skill. A good engineer or scientist understands the nature and limits of their understanding.
But there remain the question of how much basic electronics should be taught. Some relationships remain crucial. Concepts like reactance and capacitance are rarely needed in digital electronics, but you need enough awareness to recognize when they might have an affect on the system. Similarly, it's unlikely that an electronics designer will ever control the dialectric constant of their materials, but they need to be able to work with and discuss these issues with the materials selection staff.
Another key skill is assessing the build-buy decisions. I recall one engineering discussion that revolved around whether we would write a 100-line bit of new code, or pull in a library component that carried a 1MB code penalty for all the other stuff it dragged in. There was real concern that future staff would not have the skills needed to maintain the code. Basic algorithm design is no longer taught in many schools, and the new staff did not recognize that this was a commonplace well established algorithm. They only saw the custom code replacing their usual building blocks.
It's a long and a difficult process to find the right balance between teaching the fundamentals and ignoring unnecessary details. It's made more difficult because the system engineering skills that are increasingly needed are also much harder to learn that the old basics. Most people are taking the path of deceiving themselves. They think that they are learning engineering, programming, or whatever, when all they have actually learned is recipes and trial-error methods of plugging things together without understanding.