This is a little bit about how free-range learners in programming assess our own skill levels and choose what to learn next. But it's also a response to my own insecurity, and to the sometimes-stultifying weight of concentrating one's work on infrastructure.

Working on things that matter

In the Abstruse Goose comic "Computer Programming 101", a learner provokes an explainer with further and further questions about the CS and hardware and physics underlying a programming task. One reading of the comic: "Get comfortable with abstraction. If you try to understand how everything works, you'll get nothing done."

Yeah, of course, everyone's time is finite, and we all have to make our own decisions about how much time to spend on learning and how much time to spend doing other things, using our existing levels of knowledge. (Although I've recently tripped up on the assumption that the listener aims to get anything in particular "done".)

But there's also a kind of obliviousness that is so helpful, not just cognitively but emotionally, when I'm learning. Not knowing that something is risky, or not really being able to comprehend risk, helps you do it. This is one reason it can be useful to learn a bunch of programming skills when you're young, not just because very little responsibility rests on your code's shoulders, but also because at that stage you haven't yet seen all the vulnerabilities and Daily WTFs and unlocalized sadnesses... you don't even know what all edge cases exist in the world. You can take the leap of faith that all your infrastructure will work -- heck, you don't even know what infrastructure you're relying on! You don't even realize you are taking that leap of faith! -- and concentrate on getting your corner just right.

For context: for my job, I primarily work, and want to work, on mature open source software that many users already depend on. I find a lot of satisfaction in rejuvenating and stabilizing widely-used open source projects and thus healing important parts of the whole system. My professional experience is loaded up with working on stuff like GNOME utilities and MediaWiki and the Python packaging toolchain. (I left the Wikimedia Foundation partly to mess around with blank slates and without legacy infrastructure/stakeholders.... and then turned into the de facto community manager for Python packaging!) I played with BASIC as a child, and I learned a bit of Scheme and bash in college, but I came to programming in a serious, sustained way AFTER years in the industry, as a technologist and manager in software engineering teams.

Which means that when I do want to make a little toy, sometimes it's been hard for me to just come to it with learner's mind. I see that it has no unit tests, no localization, a bad UI, crappy OO, no extensibility and zero separation of concerns, ridiculous performance. There are at least five worlds of software development (that article is pretty obsolete but its point is reasonable) and I am a permanent resident of the People You Don't Know Will Need To Use This Software world. I spent some of my childhood in Playing Around world but it can be hard for me to remember how to get around there. (And oppressed people, out of necessity, often mitigate risk more, tempering audacity. So that's yet another privilege thing.)

As Amandine Lee writes: "People's intuitions and risk-friendliness also vary based on personality, and how they've seen things fail in the past." Yes! But then the very next sentence: "A lot of growing as an engineer is fine-tuning that initial response to design decisions." She meta-cautions us against knee-jerk caution, a reflex that leads to "wasteful carefulness". Was it nearly a year ago I talked about this, about the balance between preservation and growth? Maybe it's a springtime kind of rumination.

Precursors to relaxation

I am trying to think about what helps me let go of those worries and fiddle, sketch, prototype. Curiosity about a specific dataset helps, as does the impatient desire to munge some data into a form I can more easily reuse. Or an external force causing me to concentrate on achieving some specific outcome OTHER than "other people need this," like "I want to create enough of a game that I can put it in my application to the Recurse Center" (e.g., this commit in "Where on the Oregon Trail is Carmen Sandiego?" -- global variables and pretty naive string concatenation abound, as you can see, and I think those were the first two classes I ever wrote). I also think it helps when I feel like I am exploring abundant neat stuff left over by past architects, as with "HTTP Can Do That?!" (video).

Geoffrey Litt reports that part of it, for him, is concentrated time: "Also, I just gotta say: years of professional software engineering has trained me to work sustainably, but there's something to be said for a few long, unsustainable days of furious programming. Early-stage creative prototyping seems to benefit from a certain energy level that's not easily attainable in a sustainable environment." (Which makes me think about different ways participants can use Recurse Center, deliberately creating bursty rhythms of work and recovery, if they're concentrating on inventing, versus using a consistent routine to aid learning.)

Security and insecurity (how novel, I know)

A few years ago* I started thinking about how to harness this dynamic for play and confidence, specifically by improving my cybersecurity skills. My reasoning went:

 

1. I often see good engineering that is better than I could do
2. There is a counterproductive reaction-pattern in my head that sometimes finds it intimidating, not inspiring, to see amazing work
3. Thus I get turned off in a fixed-mindset way, thinking "I am not a good engineer" because of my relative inferiority
4. But the reverse is also kind of true; if I discover flaws in real running production code then I will notice my relative superiority and feel more confident about my own abilities, which raises my morale and makes it easier for me to try things that I might fail at
5. There is a lot of poor engineering out there, especially when, for instance, viewed through a security lens, and it is probably possible for me to use existing resources to understand common flaws and learn how to find them
6. Thus, it would be a good step for me to learn more about the bit of the software industry that has lots of terribly written code, in production, that I can inspect and feel superior to

(There's something here in common with what I've said about ways to deal with impostor syndrome, and self-assessment vertigo -- find reminders of my own competence as compared to the whole human population, not just the experts whose skill level I aspire to.)

Less coherently, I feel emotionally insecure and feel digitally insecure; I would like to be able to make better-reasoned tradeoffs about my digital behavior and protection. And I was noodling around, thinking about the community of practice of script kiddies, and the envy I feel when thinking about having the time and equipment to play like that, and the joy of feeling powerful but not responsible. I thought that would be something I would get out of offensive (rather than defensive) security skills: a feeling of power without necessarily then feeling a new weight of responsibility.

Fast forward to now. I went in approximately the opposite direction. Sure, I know more about cybersecurity now, and I'm even a visiting scholar in an academic lab working on cybersecurity. But it's to better secure the Python packaging pipeline! More infrastructure work! I have not learned any offensive skills and all of my power comes with responsibility! It's like the sitcom trope where a person says "I think I'm gonna skip that party" and then the show cuts to them seated in the middle of a big banquette table at the restaurant and everyone's wearing party hats.

And I now know myself well enough to know that, as soon as I notice a needless wasteful problem, I itch to fix it, and have to remind myself to pick my battles. So: even if I did grow in my offensive skills, every time I noticed a vulnerability, I would immediately feel a frustrated desire to patch it, more than I'd feel a confirmation of my own capabilities. I am too mature to have power without feeling commensurate responsibility. I missed my window.

Old advice for a new mind

A few nights ago I couldn't get to sleep because of a wave of insecurity and negative self-talk. I never went to MIT and I wasted my social opportunities in college and that's why I founded Changeset solo instead of with a cofounder and that's why I haven't yet achieved what I wanted to! I'm middle-aged and my neuroplasticity is declining and it's too late for me to gain momentum on improving my habits and getting more efficient and making an impact! That sort of thing.

And I remembered an old teacher of mine, Mr. Berkowitz. He taught government and economics at my high school, and he looked ancient and frail -- when he slowly walked the path between the administration building and his classroom, I thought I could see the wind threatening to knock him over. And that's why it made such an impression on me when, on the last day of class, he told us: "if you keep learning, you will never grow old."

And I got out of bed and went to my computer, and figured out how to install Rust (with help from 2 people in the Recurse Center's Zulip chat), and started Rustlings, an exercise-by-exercise approach to learning Rust by fixing code that doesn't work. I completed the first exercise and got the string of "tada" emojis and smiled, a strong real spontaneous smile, and felt and noticed it. And a few exercises later, I was calm enough to go to bed and fall asleep.

I have some unformed ideas about how knowing a bit of Rust might help me with my work, to lead projects like Federico Mena-Quintero's work on librsvg, replacing C library code with Rust. But maybe the big reasons it appeals to me are that everyone I've ever heard of working on Rust is friendly, and the language aims to be really helpful with its error messages, and no one needs me to learn it. It's ok if I don't do it. Which makes it more ok to do it.

In my job I want to work on things that matter. To do that job well I need to learn. The pressure of "this matters" can make it harder to learn. Therefore there is meta-work I must do to make tidepools and sandboxes for myself to learn in, shifting my mindset accordingly. And, for bigger jaunts into Playing Around World, maybe making time for another retreat at Recurse Center sometime.

* I have a note here that maybe this was related to my experience watching a preview of Jessica McKellar's talk "Building and breaking a Python sandbox". In it, McKellar mentioned to us that ping runs as root, which stuck with me.