That time I ran all the things in slash bin

It was a simple piece of advice that I didn't even know I had been missing.

I was in my early days of grad school and I had finally gotten Linux installed on my Dell laptop. The year was 2003, so it would make sense that I was working with a 2.0 or 2.2. release. I had miraculously gotten the wireless drivers working but wasn't exactly sure how to learn more about Linux. Staring at a blank terminal window wasn't getting me anywhere.

I began chatting with a fellow student, significantly older in years and in Unix knowledge, about this problem. I mentioned how I knew I needed to "know Linux" and "know the command line" but it wasn't clear to me how to develop that proficiency.

His first comment was "read the man pages." This is probably my least favorite piece of advice for newbies for two reasons. First off, many man pages are not well structured for the newbie and immediately dive in to the minute details of every command line switch, without providing a simple high-level example. Secondly, as a true newbie, its rarely clear what exactly you need to 'man'. I might know I want to list the contents of a directory, but how do I find the right command for that?

His answer was both brilliant and life-changing for me.

'Well" he said "just run everything in slash bin" to which I replied 'Huh?".

"You know how all the tools you run like ls and cd are in the same folder?"

So I actually didn't know this, but was able to quickly confirm it, given that ls and cd were my two favorite friends that I did know how to use. Turns out they lived in a folder side by side, along with a laundry list of other tools.

And its that laundry list that I became good friends with over the next few weeks. I ran every tool in /bin. Some were easy to become friends with like cat and date. Others seemed to do nothing useful at all. But I count it a success that at the end of the day I didn't delete my filesystem (that's a whole other story).

Instead I ended up with a very hands on understanding of the capabilities at my fingertips on a Linux system, and a laundry list of new-to-me terms to research like hostname and symbolic links. If you're a learning by doing person, this approach is absolutely for you.

But this story also opens up an interesting line of questioning: how do you learn when you don't even know what you need to learn? I feel like that is such a common conundrum in the world of tech, where what you learn in the classroom oftentimes is so far away from the industrial practice. Using source control tools? Not taught in my undergrad or grad computer science courses. The basics of Scrum? Also not taught. How to flip a linked list (something I've never had to do in practice), I've learned in more than one class.

Sometimes when you don't know what you need to learn, you just have to start running experiments. What I've come to realize is that in the tech world, its cheap to run experiments, so just do it. Start running tools that you have no idea how they work. You (likely) won't break anything. And if you do, that's a lesson too. The good part is, there's no fancy equipment like you might need in other fields. There's no test tubes and chemicals to pay for like you might have in chemistry. There's no dedicated lab space needed. At the end of the day there's just your computer, and maybe a cloud bill.

So go out there, create a cloud account (don't forget to setup some AWS Budgets limits), run some tools, and break some ones and zeros.