Things were different, but I don't think it's universally better or worse. In 1992: - Every programmer had at least seen, and possibly even coded in, _every e

Things were different, but I don't think it's universally better or worse. In 1992: - Every programmer had at least seen, and possibly even coded in, _every existing language_. I had college classes that touched on or taught COBOL, FORTRAN, Pascal, BASIC, Ada, C, C++, and even a couple different assembly languages. The current proliferation of languages can be a bit overwhelming when you're striving for the "right tool for the job." - Using C++, especially cross-platform, was an act of frustration due to lagging standards adoption. Like others have said--you only learned from books, and stuff that the books said you could use, like templates and exception handling, just didn't work on a ton of different compilers. gcc/g++ was still rough--using the compiler provided by the OS was still the norm. - UNIX boxes like Sun or SGI workstations were _crazy_ expensive, but if you knew the right people, you could buy used stuff for _only_ the price of a Honda. - There were 20+ different UN*X variants already, all with only a modicum of compatibility. 16-bit SCO, 32-bit SunOS, and 64-bit DEC/Alpha architectures made porting...a challenge. - 1996 was the first time I saw my first Linux box in the wild (at a UNIXWORLD expo, I believe? The star of that show was Plan 9.) - Agile/XP/scrum was years away from common adoption. Code reviews were nonexistent. Pair programming nonexistent. Continuous Integration nonexistent. Unit, system, and integration tests were a decade away still: QA was a team, and _manually_ tested builds using a test plan. - To be productive within a code base took time due to lack of standards, making then somewhat impenetrable (sometimes by design for job security), and system setup took days (no docker!). Some people used `make`, but there were a ton of other home-grown tools as well. - Source code control wasn't widely adopted. Some companies didn't see the need. This is pre-git and pre-subversion--some people used CVS/RCS. To get a tree, you had to rsync from another dev's tree, or a master shared filesystem. - Having someone else look at your code was unusual, compared to typical pull-request-style workflows of today. No bikeshedding issues back then, but also, no real opportunity for mentorship or style improvements. - There wasn't really an idea of "shared open source libraries" yet. CPAN (for perl) was one of the first, and started in 1993. - You had to actually _buy_ tooling, like a compiler (like SUNWspro, Visual Studio, or the X-Motif builder toolchain). It made coding at home on a budget a lot more limiting. - Work/life balance back then, just like today, varied widely in the silicon valley. You had to pick a co that met your needs.