It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

14: Terminal

Being a child of DOS sometimes gives me an advantage and a bit of comfort whenever a project or a task that I have to do involves the command line. I still love a good Graphical User Interface (GUI), and I firmly believe that most applications these days are well-suited to having a GUI, even if it's basically a visual wrapper for three command line applications dressed in a trenchcoat. Having a GUI makes your application more accessible to the person who does not feel at home running cryptic commands and not understanding what they will do. I especially like the people who provide the GUI in a terminal (a TUI) when it makes the most sense for their application to be run from the command line and manipulated in such a way.

Others extol the terminal and the command line as the superior option for all things, because the terminal runs faster than the GUI does, needs smaller files to produce the same outputs, requires less clicking and typing, and because being able to run a thing from the terminal generally means it can run on a much wider variety of things, instead of being locked to those things that have enough horsepower behind them to run graphical environments.

Still others, the people who get the side-eye, say that the terminal is the superior option for all because it functions as a skill gate. People who cling to their GUIs are still n00bs and lusers who have not demonstrated sufficient computer touchery and geekery to be allowed access to this particular tool, and therefore anyone who wants to use this jewel has to git gud. Snobbery is not a good look on anyone, but technological snobbery can be particularly vicious, and there are more people than we'd like to admit who fall into the third category of "people who don't want the less technical 'polluting' their spaces with demands for things like accessibility or an easier-to-use interface or syntax."

It is a potentially scary thing to type in a command that someone has put on the Internet, or in a script, or to run as an executable, and hope that it doesn't do something awful to your machine. And even scarier when the potential for malice is not embedded in an executable program, but instead a script inside an innocuous-looking document, or even as things that may or may not require someone to do anything before their system is compromised. And unlike many GUI programs, the command line is a place where the assumption is that you know what you're doing when you type the command and press enter. Great power, great responsibility, great potential for disaster. Not everyone necessarily wants to learn how the syntax of the command works, what it does and any tertiary pieces of knowledge that go along with it, like how to construct regular expressions, how to pipe the output from one program as input into another for further manipulation, or how to construct Boolean logic to capture all the possible conditions and find the correct one for the situation. These people are still valid users and they should have access to tools just as much as the people who want to run everything through the terminal.

Some of the most common situations I had for working with the command line as a youngling were, naturally, in pursuit of playing games. As described in the first post, once I left the comforts and constraints of Automenu, I learned how to navigate around in DOS and do things with it. As games progressed and started taking up more and more memory, there had to be some tricks involved to ensure there was enough available memory for the game to successfully run. DOS in those days had what they called "TSR" programs (no relation to the company that developed Dungeons and Dragons) - Terminate and Stay Resident. Most of the time, these TSRs were drivers so that hardware attached to the system would function properly. Others might be ways of taking advantage of greater amounts of system memory, and setting things up for something like bank switching, so that from the "conventional" memory space, you could still address, store, and retrieve things from "high" memory or "upper" memory that wasn't subject to the 640k limitations of "conventional" memory. (The deep dive into how to store and retrieve information from a Game Boy cartridge was intensely fascinating, and also helped me understand a little more about clever solutions used in limited circumstances.) The difficulty with TSRs is that they had to stay in the "conventional" memory space, and while there were all kinds of solutions and methods to access and use the higher memory spaces, many of them relied on there being enough conventional memory space available in the right places to implement their tricks. So, as time went on, while there may have been enough available RAM and processing power to run Sierra family games, the setup wasn't distributed properly to work.

Thus, the boot disk. From the TUI of the game installer, there was always an option of creating a "boot disk." In those days and times, DOS progressed through the various drives available to determine what to boot from, and the floppy disk drives were always assigned letters earlier in the alphabet than hard disk drives., so they would always be earlier in the boot order than the hard disks. By sacrificing a floppy to the installer, it would craft a DOS boot environment where the bare minimum of TSRs would be loaded to make playing the game functional, with the assumption that after using the boot disk to load the correct environment, you'd then proceed through the directory structure to the hard disk and load the game that way. And they worked very well, loading the drivers for keyboard, mouse, sound card, and sometimes the CD drive, as well as the tools needed to access the higher memory blocks. Once I was done gaming, I'd reboot the system so that it could return to normal operations and access to things like Windows. These days, we don't need to fiddle around with such things, even as RAM requirements and availability have grown. And these days it would be something more like a boot image of some sort, a way of loading a specific environment and then booting directly into the game itself. I wonder what kind of game might take that on as their packaging method, trying not to allow installs, even if they might allow for the mounting and running of the image inside some form of container, but otherwise trying to keep the entire thing on the disc image created.

Boot disks were another way of helping me get comfortable with the command line, and with giving me an incomplete understanding of how a computer actually sets itself up to run and produces the environment that the user will be working in. That's all basically abstracted away, and we only see a little bit of it when watching the console output scroll by as my current machines load up. I'm glad of not having to make boot disks any more, and I'm glad that we have more sensible ways of managing memory and startup now, so that people don't have to do arcane things to set themselves up for playing games and running software. Terminal comfort can come from other sources than hacing to rearrange your entire environment just to play a game.

For some time after that, as Windows got better, and then became the way that most games were played, and DOS eventually found its way to emulation, rather than being a major part of everyone's lives, those command line skills didn't pick up a lot of use, although they also never really went away, because, as I was getting older, this somewhat new-fangled object called The World Wide Web had joined the scene (again, telling you more about how old I am than not) and the interconnectedness of computers was now not only possible, but achievable to people who weren't on defense or university networks. The early parts of this interconnectedness relied on a few different protocols to make it all work - HTTP for HTML document transfer, FTP for binary file transfer, there was Gopher around, and a few other protocols. (All of these protocols still exist, although not many people are maintaining FTP servers any more, I suspect, having found it easier, faster, and better on the bandwidth to seed large files through BitTorrent.) ECMAScript/Javascript/Typescript were promising new ways of doing things, and a lot of website addresses at the time had a /cgi-bin/ in their paths, so even at that time, there were attempts to bolt interactivity and responsiveness onto the more static HTTP protocol.

Since I missed the BBS scene entirely, and never had newsreader access, I don't have the experience of dialing in with a modem and using a program to peruse the bulletin boards and the newsgroups - that would come later, with things like phpBB and other implementations of forum software, before we all decamped for our individual blogs and tried to link them together through rings and RSS. What I do have, however, is that there was a…surge? resurgence? rediscovery? of the Multi-User Dungeon and the use of the telnet protocol to connect to such things and interact with them. I won't say I was any good at any of them at all, and a friend of mine wanted to have me build some things for their own MUD, but I didn't get very involved with that, and so I didn't contribute all that much to it, either. I could have possibly learned a few things about scripting and other such things if I had persisted with the building aspect of it, but I didn't have the time nor the always-available Internet connection, to do most of my building and scripting work with. A more involved me might have instead grabbed the ability to run a local server on a non-Internet-connected machine and put together all of the things that needed doing to make it work, before uploading all of that to the live instance when I had an Internet connection. Which very well may have required either exporting in some way or retyping everything that I did in the local copy onto the non-local copy.

As it is, I entered university days with some amount of telnet experience with the MUDs, and a little more from having used the earliest form of using computers to make requests from other locations in the library system. (With the added bonus of being able to use that same system to look up and make requests from home, instead of having to be at the library to do so.) This made me particularly well-suited to using whatever computers were handy to do things like work on assignments, check e-mail, and do the occasional bit of socializing or other such between classes. While the university provided us with a disc of useful programs to put on our personal computers in the dormitories, or off-campus, I don't remember how many, if any, of the machines that were in the shared computing labs had those same programs present. As a further not-really-complication, since most students were comfortable with Windows machines, that usually meant the available machines were on the Macintosh side of the lab. As someone who could get things done in both of those environments, it mostly meant that I was on the Mac side of the lab instead of the Windows side. (Even more so in graduate school, as the Macs had a good text editor with syntax highlighting that I could use when I was away from my own Linux machine and its syntax highlighting.) The University e-mail system had a command-line interface and interaction point, and I think that was accessed by telnet as well. (What I remember much more clearly about it was that all of the servers we could connect to were identified as being arcade games. While we used a single point of entry to connect, the server we were assigned at random always was a classic arcade game. Zaxxon, Xevious, Pac-man (and Ms. Pac-Man), Asteroids, Battlezone, etc. I liked being able to get the reference and wondered which game I would be working with every time I signed in.) Pine was the system, I remember that, and it was a perfectly serviceable TUI to check, manage, and respond quickly to various e-mails that had been sent out and I was looking at in the time between classes, or when I was in the lab. I felt smart and technologically awesome that I was able to use the terminal for this kind of purpose, and to do it well. And, yes, I did feel a little smug and superior that I could do this on whichever machine was available, instead of having to wait for a specific machine to come available or to trek to a specific laboratory where those machines were available. My university-aged self is still unlearning things as much as they are learning things, and so I have to treat them with patience and understanding.

So when it comes to the terminal and the command line, I have decades of experience in using it, in having things blow up in my face, in having to use it because various utilities, servers, and tools run best (or at all) from terminal, and in using it because I want to see what a piece of software does, and whether I can get things to go faster from there than from other methods. I'd say that comfort with the command line is a second-order comfort when it comes to computers, because you can't really get comfortable with a command line until you are properly comfortable with the machine itself, and feeling competent and curious enough to try things, have them explode, recover from them, and otherwise recognize that many things that wreck a computer can be recovered from, although what form the recovery takes is different depending on how big of an explosion happened, and that most systems with a GUI will ask if you're sure before they do something destructive. This is the kind of thing that a spare machine is perfect for, because spare machines are what you do things that are destructive or explosive on, and then when they do explode or do unwanted things, you have gained knowledge about what to do or what not to do, or that the thing you tried to do was not properly formed, even if it was accepted as valid. Sometimes you discover some really cool things you can do and then take that knowledge back to the main machine to make it run better and more according to your needs.

Once you have the willingness to experiment and see what happens, and the knowledge backstopping you that you can get out of most common bad situations, and perhaps even the knowledge of how to reconstruct a system from scratch and start again, then you can start getting more comfortable on the command line and using the terminal when it seems appropriate or useful to do so. Because, again, many terminal commands don't ask if you're sure, they just do what you told them to do. (More of them probably should ask, but most of the core utilities and commands on any operating system were developed and used by people who did know what they were doing, and they probably found it annoying to have to confirm it every time they wanted to do something. For Linux specifically, even though many distributions of Linux are better about not requiring the use of the terminal or the command line, there's still a certain assumption baked in that the terminal is the real heart of using Linux, and everything else is eye candy, abstraction, or concession made to those who don't want to do everything from the terminal. The terminal-centric focus of Linux makes it both very powerful and very portable, since the terminal itself, and the core utilities don't require a lot of fancy anything to work, and can be put in embedded or underpowered systems to provide functionality and flexibility to their operation. Terminal commands and abilities are also part of creating scripts and programs that will chain together commands to produce useful output, which is the part where the possibilities expand outward exponentially.

I'm trying not to make the terminal sound completely intimidating, and that you need all the time and experience that I have with it to produce useful things and be comfortable with it. But especially in Linux systems, grasping the terminal and what you can do with it is almost a prerequisite for unlocking the full potential of such a system. And I don't fully know everything that I can do with the terminal, because I haven't had to learn it yet, so you don't have to know everything and read all the man pages before you can start using and experimenting with it. I do think, though, that having grown up in an era where the command line was the primary method of accessing programs and using the computer has made it easier for me to re-adopt a terminal, now that I've chosen an operating system that relies on it. I'd still rather that people took the time to put in interfaces and help for people when they release programs to users, or that, if it makes sense, they build a GUI component for their program so that it's more widely accessible, but that is not always the case.

I guess the point is to say that computer touchery does not have to involve terminals and text editors, and that there are several fine programs that require neither to run admirably and well. And that for as much as I have experience with it, there's still plenty that I don't know and may never know. It's one of the places where I can have a growth mindset about myself, and I think it's one of the places where others can, as well, so I'd encourage you to dive in, in whatever way that you can. There will be gatekeeping jerks, there will be unhelpful StackOverflow answers, and sometimes the thing that's the best and most useful response for you will be a blog post from decades ago, but there is a certain satisfaction, at least for me, that comes from accomplishing a task through clever program use or even writing the script yourself and seeing the output that you wanted to have happen scroll by in the console. I am unlikely to claim that I'm good at any of this, but I could venture forth that I am at least semi-competent.

It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

00: Fool

The Fool, in all his forms, represents unlimited potential. The Major Arcana places him at 0, the number that requires some other number than itself to provide the context of what zero means. Zero is cyclical, and represents both start and end of journey at the same time, ready to embark upon new adventure and learn, and returning and integrating what has been gathered so that the next loop goes with more information and knowledge. Zero is the first index value, which is a thing you have to learn and remember when working with computers. Humans generally start from one when they count, because zero holds no intrinsic value to them. (Zero is actually a fairly abstract mathematical concept, despite being crucial to most operations. I think its only rival for importance and many-faceted-ness in mathematics is one.)

Unlimited potential describes infants and children very well, since their brains are in their most plastic states, learning and absorbing the world, language, society, and how to operate their bodies in space at a phenomenal rate. Eventually, that learning rate tapers off as decisions get made about what to practice and obtain skill in, sacrificing plasticity for efficiency, but it never goes away entirely. We get all kinds of "human-interest" stories in the media about someone of a somewhat advanced age picking up and obtaining great skill in a discipline that they had no knowledge or practice in not that long ago. The entire system of athletics, whether for Olympic prizes or lucrative sport contracts, starts very young and demands both skill and discipline to rise in ranks where someone might challenge for those same athlons. And in other tracks, we see stories all about smart people doing smart things (and a fair number of stories about smart people doing things they believe are smart, but have consequences that are clear and obvious to people outside of their specific discipline.)

Carol Dweck, in the early 2000s, published a book called Mindset: The New Psychology of Success that introduced to us two new concepts to work with: a fixed mindset, where someone believes their intelligence is finite and there is no way of developing it further, and a growth mindset, one that believes there is development potential skills, abilities, and intelligence. This became simplified in the popular parlance and spawned a fair number of ideas about how to keep people, and especially children, out of the fixed mindset, usually centering around the idea of praising students for the effort they've put into their work rather than suggesting that they lack smarts or other fixed qualities that would make them good at things like schoolwork and the various subjects. Dweck came back to revisit these ideas with clarifications and to squash the idea that effort was the only quality that was praiseworthy in helping someone develop a growth mindset in a 2015 Education Week article. And to say that most people have a mix of fixed and growth mindsets about their skills, abilities, and applications of intelligence.

I'll say that mathematics is one of the spots where there's the easiest contrasts of fixed and growth mindsets, although there's some confounding coming from xkcd 385 that contributes to some students being steered heavily toward fixed mindsets. I mostly mention this in the context that I didn't hit my math wall until integral calculus, where I didn't fully understand how I was supposed to go about transforming an equation into forms that I could apply rules to by using the various exotic and trigonometric properties of one, as well as the occasional shuffling of various components to one side of the equation or other so that I could, again, put things into forms where rules could be applied. This makes a little more sense, because geometric proofs were the thing I disliked the most because of the way they made me go through logic and fill out what I knew from what was provided. Despite the fact that I like playing games and solving puzzles, which is the same kinds of things, just with different visuals.

But until that, and with a fair number of other subjects, I was cruising with absorption of knowledge and doing well on tests, and all was well, at least in the realms that can be measured and quantified. My second grade teacher thought I might have a learning disability, because she never saw me do work in class. She saw that the work was good and done well, but she never saw me go to work on the worksheet and finish it while she was explaining and demonstrating the concepts and procedures on the board, such that I was done and quietly reading by the time she turned back around to give us time to work on our sheets. The tests came back that my weak spot was at least one grade level above my current space, and the opportunity to pick up that I did have something affecting me was lost, because that's not what was being tested. They wouldn't have diagnosed me then, anyway, because I presented atypically for my gender presentation at the time, and there wasn't any reason to test for it. These days, I think that if someone comes back as some sort of savant or "gifted" student, you should run them through a battery to see if they have any accompanying neurospice that could cause them great grief in their future.

This ease at things that others considered difficult meant painful emotional experiences when the perfect child turned out to be human after all. And I also had at least one physical altercation in my life because I saw something as simple that someone else found difficult, and they didn't like my attitude about it. (I'm not surprised that I would have come across as arrogant about it or similar. I wasn't intending to do it that way, but I'm definitely a poster child for "What I intend and how it's received are two different things, and I'm not great at accepting that it was received differently than I intended it to be.") It makes me sensitive to the disappointment of others, and it also makes me want to avoid situations of consequence or importance, because if it's important and I fail, then the fallout is both deserved and all my fault, regardless of how the failure happened, and someone will be by to punish me for failing soon.

Dweck is trying to encourage instructors and people who are working with others to adopt the idea of the growth mindset and try to foster it in others. Not just a matter of changing feedback so that it focuses on qualities and items that can be improved or the effort put into the situation (and avoiding feedback that references fixed or intrinsic qualities like "smart"), but also providing the scaffolding and feedback that allows for growth and learning, so that the skill can be not only practiced, but practiced correctly and well. It's not enough to praise effort if the answers are still coming out wrong and there's no understanding of what's going on and where the mistakes themselves are coming from. Humans are capable of learning and doing all kinds of things, many of them remarkably complex. Instruction and repetition and refinement are generally the ways that this works, and if we're going to require all of our small humans to go to school for twelve-thirteen years of their lives, we may as well make the environment as rich in opportunities to grow as we can. (There is an entire separate post here about the ways many educational systems provide the exact opposite of this growth-rich environment, and not all of it is the fault of the instructor and the feedback they give.) While that sometimes gets tritely summed up as "Whether you think you can, or you think you can't, you're right," that reduction makes it seem much more like it's a matter of willpower rather than one of opportunity.

Many of the creative arts, and several of the scientific ones, are less about people of great inherent talent having an inspired burst and then created a masterpiece out of whole cloth using nothing more than their raw talent. Musicians rehearse, writers compose, artists have references and practice works, dancers and athletes train and practice. The skill-taste gap is real, and while some things may be easier to pick up than others, the actual limitations of the brain and body are about whether the brain can translate verbal or demonstrative instructions into body movements, and whether the body in question can perform those movements at the desired level of skill and speed. Where I think a lot of our childhood pathways fail us is that we get told early on to focus on what we're good on, and our feedback tends to be in that form. The point of the schooling system (and the university system beyond that) is to get us in a state where we can perform labor for wage, unless we are one of the lucky few capitalists where we have enough for ourselves and our work is instead making others perform labor for us for wages. Creative arts and other such pursuits might be where our desire lies, but the necessities of not starving often prevent us from fully exploring those arts and pursuits, or they twist it into something that is used for not starving instead of for exploration, practice, and attempting to grasp a little of the numinous. The messaging about doing what you do well, combined with the artificial scarcity of capitalism, can often put us in fixed mindsets about creative arts, because the standard warps from "will doing this make me feel like a fulfilled and whole human being?" to "can I do this well enough for other people to give me money so I don't starve?"

The Fool and the concept of Beginner's Mind are intertwined with each other. Approaching any situation, including existing in a body of matter, with the curiosity of someone who doesn't know anything about the situation, but is interested in learning about it, or observing it and letting it move on, is to approach something with the greatest potential for growth. By shedding as many preconceptions as possible about the thing being approached, the full realm of possibility opens up before you. Admittedly, sometimes conceptions of things come with experience, and that's useful to bring in. Not approaching something with an expectation of how it will turn out, but being prepared in case it does go a way that you have experienced before. Zen, and its famed koans, and much of the practice of it revels in contradiction. Practicing meditation is so that you can get to where you already are. Sitting and observing the world as it goes by, without chasing after any one thing, lets the mind realize the impermanence of all things, the great constructions that take place within our very selves. Knowing about it makes it easier to jettison the whole thing and to practice approaching each moment of life as it is, rather than what it will be, or what it was, and without the structure of preconceptions clouding reality. It always seems impossible until it is done, and Zen tends to work toward the sharp flash of insight when it stops being a theoretical and starts being a practical. In response to another person saying they wanted to become a monk to "deepen their practice," a monk starts laughing and says the person seeking to become a monk already is one, and that there is no deeper to the practice of Zen, just the one level. The one, seemingly-impossible-until-insight level.

We see breakthroughs like this happen all the time with small ones and ourselves. It doesn't make sense, it doesn't make sense, it doesn't make sense, and then it does. With enough time, practice, and instruction, some things that were thought to be limits aren't, and it's not that the person is stupid, it's that they didn't have the right frame to work with. Or not enough opportunity to practice and refine. Or a low-stakes situation where they could get over the anxiety about it needing to be perfect or sale-worthy and instead focus on doing the actual practice.

There are going to be limits, where some things just won't happen, or be comprehensible, no matter how much good instruction and practice we get. I suspect, however, that most people don't actually reach their true limits on most things in their lives, because they don't get the opportunity to see where those true limits are. Many of the stories that appear in this and other series where I talk about myself are stories where I thought I wasn't "good at" something, but I could practice it and approach it in a Fool-ish way, and now it's (marginally) better than it was before. Because of the experiences my brain has had around praise and punishment, saying I have expertise in things is unlikely, but demonstrating that I have it is routine. And it's tempting to have a fixed mindset about things that are difficult, because I spent so much of my life with things that were not difficult to me. Letting myself overgeneralize into the belief that I used all my skill points on these things and there are none left over for anything else is an easier thing to believe, rather than it being a matter of time and practice. You'd think that being an information professional, where the formal training you go through is much more about learning underlying concepts and methods that then get put to use in specific situations, would make it easier for me to recognize and dismiss the fixed mindset, but, alas, brains. The best I can do is continue to be a Fool when I recognize the need for it.