In the late 90s, I started hearing a lot about Linux and wanted to give it a shot. A friend of mine had the CDs for Red Hat 4-point-something and he lent it and a copy of his 2.5-inch thick Red Hat Linux Unleashed (or some such title) book to me, and I undertook a project that would ultimately change my life as a hacker and a computer scientist: I tried to get Linux installed on my "state-of-the-art" Pentium II computer. Installing Linux back then, while I'm sure it was light-years ahead of where many practitioners started, was still difficult enough that I actually had to learn something about computers to make it happen. The whole process took a couple of weeks, filled with reading, research, trial and error, and ultimately, it was the beginning of a process of knowledge and skill acquisition that continues today.

Here are a few of the things that I learned in those weeks:

• Despite having an installation process that walked me through the the steps necessary to install and configure the system, there were many questions along the way. How did I want my disk partitioned? How much swap space? Which packages did I want installed? How did I want my network configured? Each question sent me off on an investigation about the possibilities, and the advantages and drawbacks of each option.
• I wanted a dual-boot system since I wasn't really ready to abandon my Windows 95 use yet given it was all I really knew. This meant learning about the boot sequence, boot loaders, the MBR, lilo, disk partitioning, and even a little about disk geometry.
• Of course, I wanted an X windows based system so that I could run graphical apps. Back then, autodetection of video card and monitor settings was dicey. To get it up and running meant learning about video timings, how to modify the XF86config file, and reading the arcane spec sheets that came with my monitor and video card to find a compatible setting so that it actually started up.
• Once I had gotten things installed, the next step was figuring out what I could do with the thing. I had some familiarity with a CLI from my DOS days, but a real shell is a little different. Even simple things such as "how do I run a program?" turned out to be tricky, and learning that I needed to prepend "./" to run a command in the current directory was a revelation.

Like most things, I got better with experience. Pretty soon I was figuring out how to burn CDs (and understanding file mounting, CD disc structure, and some basics of device drivers), download and compile software using the configure/make/make install pattern, and much more. Within a year I was setting up a Linux box to provide NAT for my cable modem (I was lucky to have access to an early cable modem service), meaning I learned a ton about the nitty-gritty of real world networking, iptables (it was probably ipchains then), and how to set up and configure a small home network including local DHCP and DNS services, port forwarding, and much more.

The freely available nature of Linux and it's subcomponents, coupled with the vast resources of documentation and community mean that any self-motivated person can spin up on pretty much any technical topic and actually try out a working implementation to get a feel for how the idea plays out in practice. In the early days of computing, it was this way for the vast majority of users, with the tradeoff being that there was no easy alternative for non-technical users. Since the rise of Windows and Mac as the dominant operating systems, this option has been hidden or even taken off the table for many up and coming programmers.

The fact that you have to "think" to use Linux has been criticized, but few people seem to note the danger of having many developers learn on an operating system that requires little or no thought. Whether or not you agree with the sentiment that Linux makes you think too hard, there is no reason we can't have an OS that is for the "masses" and another for developers who actually care about what is going on on their system, so this isn't so much a criticism of Windows as it is a criticism of computer science programs and software development shops complacency in accepting Windows as their standard platform.

My advice to young programmers is, rather than always working with software that doesn't make you think, spent some time with some that does.  Like learning a new programming language, it's a great way to expand your knowledge of computer science concepts, as well as develop important problem solving skills.  You will be surprised at what you don't know when the configuration  tools and installation wizards are stripped away.