How do you solve a problem of unseen-code?
I've been thinking a lot about how to get better at code when it's in my own side projects. I do these side projects pretty much in isolation. Maybe sometimes I get a comment or, if I tweet about it enough and it's relevant, it might get rolled into some blog post. When that happens it's great! But it doesn't really give me feedback on my work or the quality of it. Without feedback it's hard to improve.
Don't get me wrong, I do these projects for myself. I do them because I want to find something out and I need a tool to do it. I do them to learn new things because learning is fun. I do them because I want to create something cool that lets me play in code. These are all core to why I even bother with side projects.
I don't want to stagnate in these side projects. I want them to get better, I want them to make me better, I want to make the projects better, and I want to advance my skills while working on them.
At work, when I'm putting code together, I get opportunities to talk over ideas, plan architecture, and then, of course, I get feedback on my approach and technique in pull requests. PRs can be frustrating, revelatory, or any feeling in between, but I always learn something, even if it is just another way to approach how to write code.
This process makes better coders. It makes me a better coder. Exponentially so. I badly miss it when it comes to side projects, but there doesn't really seem to be any formal structures around how to make getting feedback part of casual coding projects. So, I thought about this for a while.
Then three things happened.
Play To Find Out
One: I started to play more Powered by the Apocalypse (PbtA) tabletop games. Then I started to write Powered by the Apocalypse games. Then I started to write rulesets for Powered by the Apocalypse games. This meant reading a lot of other people's PbtA games. I saw and came to appreciate one of the core rules for all Powered by the Apocalypse games, which is "Play to Find Out".
Play to Find Out is deceptively simple; it means that you don't pre-decide the outcomes. It means that games don't go off the rails because they don't have the rails. You have a general endpoint in mind... maybe... but the more important thing is to not be a game "master" in the way D&D games are run, but to be a facilitator. It's to let go of the style of absolute control and realize that sometimes decisions come from outside and are driven by accident and play as much as they are by starting intention.
This was the first idea to build on. I started thinking about these side projects less as end goals that leveraged things I knew and more as opportunities to explore the ecosystems and communities of the libraries and code samples I built on top of and potentially contribute back to them. I wasn't just going to go with my favorite tool, or what I wanted to learn, I was also going to go with the flow to some extent, even if it meant trying a library I neither needed to learn or would get any particular job-relevant knowledge from.
I know it seems strange to say this, but this sort of thinking led me towards moving more with the flow of the work. I began treating side projects less as an outcome or desired product and more of an exploration. This has led me down some weird roads, but I think has made the process more sustainable and fun and will continue to do so!
Math and Showing Your Work
Two: I started to get more into math. I know people generally expect those who work with code are "math-y" (for lack of a better term). But that was never my path. I wasn't particularly engaged (and, therefore, not particularly good) with math in high school or college. I never enjoyed it, nor could I focus on it. However, I've been encountering more complex math and math concepts through my work with the W3C.
I discovered that math was fun to read about and, more importantly, fun to play with conceptually. This is something I've been doing more. I think there's an image painted in most people's minds that an outcome of learning math in-depth is becoming the Math Expert, standing at a chalkboard working through equations. But I'm starting to think that's not the outcome, but the path.
To learn and refine our practice as coders we play towards an outcome with sketching system architecture, or pseudo code, both at a whiteboard.
Learning math isn't about getting to the point where you can stand at a whiteboard and do equations, it's about the process of learning through playing at the whiteboard.
The problems of my math education came out of a solutionism approach. So many of the problems that I've had trying to figure stuff out with code stem from the same frustrations I had as a kid with math: that there is only one methodology, only one solution, only one way, and I just have to find it like I'm digging up an artifact.
Solutionism isn't just a problem in how I learned math, solutionism is a fundamental tech issue. Approaching these projects as if they had ready-made solutions walls me off from collaboration in work. If I assume the solution is already there, ready formed in the metaphorical block of marble, I block out other viewpoints unlike mine and I remove the fun from the process of building, the exact opposite of what I want to do.
When I learned math, we always had to "show our work". But showing our work wasn't really the point of my math education. "Showing your work" was code for "prove you didn't cheat," and it wasn't about exploring the problem... it was about showing you could recite back rote methodology. It was an approach that enforced the opposite of what showing your work should be about. It was trying to enforce the concept that there was only one solution to any math problem. Math became something to be whipped into you.
No wonder Americans resisted so hard when math educators proclaimed that there might be more than one way to Do Math and that they were going to teach a different way to do so with Common Core. The math education I, and I suspect most others, received was designed to enforce that--not only was there a single solution--there was only one way to get to it. Learning some other approach to math hit a wall of dogma that the education system had handed down in math classrooms for decades.
So, from this realization that my math education was injured by a lack of play, I realized that what I needed for my side projects was to spend significantly more time showing my work than showing the resulting product. If I was going to be able to keep track of projects and enjoy my time on them, they had to be a vehicle for play, and the way you play with code is by working through it, sometimes down the wrong path, sometimes down an unexpected one.
Streaming Code
Three: Then I saw someone who had really encoded the first two realizations I had into their programming process and turned it into not just a way to work but a resource. I'm talking about this very cool thing that Paul Frazee is doing with his work where he livestreams himself coding, working on his project. He talks through what he's doing and the decisions he's making, and opens himself up to feedback from a live and later reviewing audience. This is very much like the writing-circle-style coding approach that I want to create.
Even better, his code livestream becomes a permanent resource about his work that others can look to through his dev-vlog, which links commits he's made during livestreams to the actual video where he's making those commits.
I think that, in some regards, streaming oneself doing code is terrifying. It means admitting that you have to look things up, that you don't know everything, and that maybe your code isn't always the best. It also means opening yourself up to a community of feedback, for better or worse.
I think my main hesitation with opening up my workflow like this is I worried that process is less interesting, even when I'm just thinking through an approach. I was disabused of this notion when I watched Helen 侯-Sandí do her bug scrub livestream as part of the WordPress development workflow. Watching people at work is interesting, regardless of the work.
Principles of the Dev Blog
So, taking these inspirations, I decided that what I really needed was a dev blog... heavy on the log part.
I could have done a video stream, like a number of other people do. Clearly, there are some great examples out there. But I don't think that model fits for me. I don't code regularly. This is a fun thing to do in my free time and I don't want to make a schedule for it in the way that livestreaming seems to require. Also, sometimes I think up something at lunch and jot a note about it and some code down. Or, I do very little one day. Or, I spread it out over small sessions. My approach for the projects I want to document just doesn't seem to be the right one for livestreaming.
It's less of a resource that way too, at least when it isn't attached to a specific project. I want this to be as much of a reference as a log. Part of the goal here is to create stuff that is useful to people. Even if maybe I need to de-index things via robots.txt with some regularity.
So, instead, I decided to create a written blog, which lets me exercise my writing too. This is another practice I enjoy but don't spend enough time doing.
On top of everything else, this will help me solve a problem where I often like to put projects down for a while, or switch projects, and then when I come back to it I can't remember what I was doing. With an active log, it'll be easier to pick up and put down projects, which will be more fun.
I decided it needs principles
- Commit often: better to save a reasonable mistake than forget it and repeat it.
- Work in the open: with errors and frustration on display.
- Play to learn: work through the problems instead of around them, even if it means sticking with a library that might frustrate me.
- Document the mistakes.
- Always take the opportunity to contribute: so that means building plugins, making PRs, leaving Issues and taking feedback in my own issues or PRs. Engage in the communities around the code I use, even if it means slowing down and breaking from working on a project.
- Work towards readability: The goal should always be to make my work readable in both log and code formats and to be clearer through things like leaving in scrap print statements and comments so others can reuse my shown work as much as the end product.
- Write messy, clean another day: Logs should be raw first and then edited and cleaned up on a later date.
- Define scope, but don't make it the absolute limit.
And I decided I needed to make the first project this blog documented the making of the blog itself.
So, that's what this is about, trying to code but without a solutionism bent, instead with a mind to show my work, to show that this is a process, and not always an easy one. That this type of work is better done with a community, open to input, and out in the open. That I might fight with my tools, but that's part of the process. Hopefully, by opening up that process, I can help others.
Also, I'm just a big Flobots fan.