Or how I need to learn to love failing again
If you’ve been reading my other posts, you’ll notice that I have no real issues with using LLMs to generate code for my own services. Some software engineers have issues with this, and I get it, and to a large degree, I agree with the notion that LLMs are good at getting you results but not necessarily good at writing maintainable code. But that’s somewhat of a price I’m willing to pay since I know, after 10+ years of fiddling with computers professionally and amateurly, what the LLM is doing.
More often than not, I ask Claude to write me services I’m lazy to write myself in a way that gives me satisfaction earlier. However, that leaves all of the fun that I used to have toiling and struggling and figuring it out by myself on the table. Which, as I delve deeper into academia in my PhD, is a feeling I really miss.
It’s a feeling that I’m naming ‘learning is the struggle’
How do we learn?
Remember when your classmates used to say “oh, I’m a visual learner” or “oh, I can’t learn from the textbook. I have to do the problem set” or “I learn better when I explain the concepts to someone”?
I think there’s some truth to people learning slightly differently, but I think the main point is that people learn by grappling with the concept in some way.
For me, personally, I was always a mix of learning styles. I found myself learning the best from listening to people talk so much so that I rarely took notes in class. I relied mainly on homework assignments and problem sets to take me from being exposed to content in lecture to hammering home concepts during problem sets. Then, I’d try to explain those concepts to my peers who didn’t fully understand which both helped me reinforce my own understanding of the topic and (hopefully) helped my peers too.
But, notice how there’s a small feedback loop here:
Concept is introduced -> explored through trial and error -> mastered through explanation
I argue that the middle step is the most important here.
You don’t know what you know until you explain it to someone
I run a home server as is detailed in my numerous posts about it. I’m not the premier software engineer by any means, but I feel like I know a thing or two at this point.
My friend, on the other hand, well, he uses his computer like anyone else; he plays games, watches Youtube, edits his photos, but he doesn’t write programs and doesn’t really tinker at a software level with his computer. Which is totally fine.
I was surprised, really, when he came to me saying that he wanted to turn his old gaming PC into a media and backup server.
I was thrilled actually.
I’ve had so much fun building out my home server with all its intricacies, so I wanted someone else to have a fun experience too.
But when you go to teach someone what you know, you don’t fully grasp what you already know– your baseline knowledge is intrinsic at this point.
I didn’t really think about why I use Tailscale or why I use ZFS. Those are decisions I made years ago when setting things up, and I can justify the decision, but explaining it in the moment to someone who knows nothing about networking or servers is a challenge.
Case study
How do you teach someone who’s never really used anything other than Windows with a mouse, keyboard, and a GUI, that you can configure a computer to do more than just visually show you information?
I started by just telling him that.
I got him to install Truenas Scale through a bunch of trial and error where I helped him troubleshoot Secure Boot issues, SSDs not showing up during installation, and Tailscale configuration for remote access.
But during the whole process, it felt like I was feeding him the fish not teaching him how to fish.
But I had no idea how to teach someone else to fish because I’ve known how to fish for a good chunk of my life.
I decided to just give him the basics of a working system: Tailscale, Immich, ZFS mirrored pools, and a few other nice-to-haves so that at the very least his system worked, and he could use any and all time he wanted to go deeper into the system building aspect.
What was great, once I left him alone for a few days, was that he fully set up a Minecraft server by himself!
But, he only really learned that because I left him alone; he had to struggle to figure it out.
And when he did hit roadblocks he couldn’t get around, he messaged me, and we sat on a call for a bit and figured it out together.
It’s easy to forget your early struggles
One point I find myself coming back to is that with learning any new skill, it’s a good idea to compare yourself to a toddler.
You learn how to walk through trial and error and lots of watching when you’re a toddler. But when you become a child and then a teenager and then an adult, you never remember the actual struggle itself. You know how to walk without remembering how you learned how to walk.
Similarly, with skills and knowledge I’ve had for a while, it’s easy to forget the initial struggle and on ramp that I had to get to where I am today.
Removing the struggle removes the learning
Now let’s take the counterfactual. Imagine my friend hadn’t come to me for help on his server. Imagine he had gone straight to Claude or ChatGPT and asked it to build everything for him.
Based off of his profile as a photographer, with only two 1TB hard drives and the promise of two more 12TB hard drives coming, an LLM might have recommended he go with Proxmox ZFS configuration and port forwarding. Or it might have told him to use Tailscale. Or it might’ve told him to focus on getting Windows running with everything else tacked on top.
The whole time, though, he’d have to blindly trust that the LLM understands what it’s doing and completely miss the implementation struggle since it’s so easy to let it do everything for you.
But by getting some fundamental ideas briefly explained by a person, he has faith that the technologies themselves are sound. And then, he’s able to find tutorials online to teach himself how to deploy new services himself, like his Minecraft server especially since I am not available to do everything for him.
In research
I find myself like my friend in research sometimes. I’ve done research for a few years through undergrad labs, through my work at Octant, and now in grad school.
But I’m pretty new still. I’m not a first author on any papers still.
So I find myself reaching for Claude a decent amount. And part of it is because it gives me results quickly.
I’ve been trying to figure out a balance with utilizing LLMs for research without outsourcing my cognition. And, to be honest, it’s really easy to slip.
More practically, I’ve started having Claude ask me questions that allow me to reason by myself what I’m actually doing. I try to ask questions back that point at flaws in its reasoning. But the hardest part is to not just set it on auto mode and have it execute on a whole plan it generated which I lightly skimmed.
That removes the struggle. That removes the learning.
To fail is to succeed
Over the years, I’ve found myself more pressed about succeeding than being okay with failing. It’s a bad habit of mine, and I think it’s something that a lot of people learn as they grow up. That failing at something doesn’t mean that you’ll never be good at it.
I think research is the same for me, and writing this blog post after being inspired by my friend’s curiosity in a completely new space for him, is an attempt at holding myself accountable as I continue my PhD.
It’s easy to look online or talk to people in industry and even in academia these days and think that not using LLMS means you’ll not be productive and you’ll fall behind. But I think one thing I’ve realized is that a PhD is not about outputting as much as possible in as little time as possible. If that were true, I don’t think I’d be in grad school right now.
And the same people telling others that? Well they already did the struggling, but they forgot how they learned in the first place.
So, in this way, I’d like to keep failing. I’ll let myself use LLMs for things I feel like I’ve done countless times, but for new things, I need to relearn to struggle a little.
It’s okay that I don’t understand it right away.