- 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.
- 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.