New Essay, some thoughts on method vs process
No Newsletter Next Week
I hate to do this twice in three weeks, but I have a TLA+ workshop next Monday.
A Brief Introduction to Esolangs
Two pieces of content for you!
- A 20-minute talk: https://www.youtube.com/watch?v=cQ7bcCrJMHc
- A 4000-word companion: https://www.hillelwayne.com/talks/esolangs/
The two pieces are intended to work together, but I believe they work independently, too. Watch one watch both watch none I don't care it's done
A bit of backstory: back in March my friend Felienne Hermans asked if I wanted to write a lecture on esolangs for her class. Being a fan of weird niche languages, I jumped at the chance. The problem was that her class was 9 AM Central Europe time, which would be 3 AM Chicago time. And I've wanted to learn audio and video editing for a while now, mostly to try making a self-serve Alloy course, so I figured this was as good as any a chance to start.
It was way, way, way more work than I anticipated. Like holy crap I have no idea how people can manage to do this full time.
In any case, "hay new post" does not a newsletter make, but between this and real life responsibilities I haven't had a chance to think about anything besides esolangs and video editing, so…
Methods vs Practice
As a teacher, one thing I'm constantly worried about is "expert blindness". That's when you know something so well you can't comprehend why other people find it hard. One way I have to fight expert blindness is to regularly learn new things that I don't understand, to constantly put myself back in the shoes of a beginner. That makes it easier to empathize with people who don't understand something I find natural.
Video editing was the most "out there" thing I've learned in a while. It's totally unlike any of my other skills or hobbies and it felt good to be a clueless newbie for a while. While googling and reading manuals and searching how to do things, I realized there were two kinds of things I was trying to learn. The first was how to do something:
- How do I remove breathing sounds from the audio clips?
- How do I zoom in on something in the middle of a shot?
- How do I replace one clip with another, or insert a clip without messing up the timeline?
- How do I add markers and flags to clips?
The second kind was how to do something well:
- Should I record audio a couple sentences at a time, or do the entire scene at once and edit several of those takes together?
- Should I do all the audio and then all the video, or build both out section-by-section?
- How should I organize my media into bins? By timeline, by concept, something else?
- How can I use markers and flags to improve my video editing?
- What're the best ways to look for things that are "off"?
I didn't need the second type of knowledge in the same way I needed the first type. Even if I didn't have the best organization, IO could still make a video. It'd just take longer and the video would be lower-quality. Unsurprisingly, finding resources on the latter was much harder than finding resources on the former.
Call the different "methods" vs "process". Extending the same idea to programming, what would be the programming questions on processes?
- How should I lay out my windows when writing code? Two files, side by side? A file and a REPL? Does it change if I'm reading code vs writing it?
- There's a bug with my code. Where should I start? When should I be thinking "debugger" vs "print statements"?
- When should I be making broader abstractions and when should I be YAGNIing?
- How do I navigate better between files?
I think there's two different things going on in "process", and distinguishing them is proving tricky. You can know about categories of bugs and how to use a debugger, but still not really approach debugging "well". Maybe the key thing is process that leads to different outcomes vs process that doesn't. The way you lay out your coding windows probably won't change the code you write, but it could mean you converge on the code you write faster or better somehow. Then again, I feel like TDD and BDD count as this kind of process (people already knew how to write unit tests, TDD changed when and how much you wrote), but they also influenced the kinds of tests people wrote and how they think about testing as a whole. Maybe the difference isn't nearly as big as I think so here.
Even so, it still feels to me like there's a category of process knowledge we don't talk about as much as "professionalism" dictates. Like doubling the amount of available content on Kubernetes or patterns won't make as much of a difference to software engineering as doubling the amount of available content on debugging, or organizing information about a project, or whatever.
I feel really off my game rn. Hoping that after next week this crazy month will be behind me and I can get back to researching software again.
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.