Eating people is gross until it's not
My wife decided to learn to code. Therefore, I'm an observer of a person who is learning to code. This proximity means I reflect a lot on my learning. That leads me to think about vampires. LA Paul asked the question, how should a person decide to become a vampire? If I'm honest, it took me about a year to understand the question. The crux of it, I think, is that becoming a vampire means you'll experience a world so fundamentally different, that the questions you asked yourself before becoming a vampire, aren't really meaningful anymore. I don't think this is discussed enough in the learn to code section of the internet. Learning to code is a non-stop series of viewing the world from different angles and reimagining your relationship to computers. Let's consider:
mkdir some-project
cd some-project
yarn
yarn test
None of those steps are even learning to code, but understanding each one means you understand how to interact with a computer in a way that's wholly different than before. That has some awesome consequences. At first, a text editor is slow, then once you've been a developer for a while, copy-pasting in a word doc feels slow and text editors are fast. It's borderline impossible to go back. You've now become a vampire, especially if you learned Vim.
When you're learning to code, the mental jumps can be pretty profound. There's syntax, computer file systems, some networking, browsers, the entire concept of terminals and ports. Add to this list that there are ancillary systems like git, Github, deployment processes, AWS. As you're learning each one of these things the next becomes more understandable, relevant, and powerful. Before you know it, they're all one interconnected system. Meanwhile, you're just trying to get your mind around what an array is and why it doesn't start at one. When you have the opportunity to watch someone else learn to code keep an eye out for tunnel vision. I'm lucky enough to see it in action. I'd wager when I'm problem-solving one of my biggest problems is focusing on just one thing, rather than the range of issues that might be happening. This is in part because I don't know what the range of problems might be.
This makes me think about chess
I'm not particularly good at chess. I have the chess.com app so I'm better than some, but I'm just realizing that you don't think moves ahead, but rather, you think about territory. I imagine the best chess players don't even think about territory. When you're first learning chess you need to think about the moves. That's a fundamental part of how chess works. Coding works similarly.
const bishop = new ChessPiece('Bishop');
There's a lot there. Just understanding the syntax here is tremendous. The next leap here is understanding that a bishop might be an abstraction of a Piece that has moves or points. Then, that same bishop lives inside a board class. When you decide to learn to code though, did you decide to choose to understand an abstraction like Classes. Or that functions can be chained on each other? Breaking down a concrete thing like a chess piece is a reimagining a game. It's also pretty interesting that you can break the game down, and not understand, how that game works. This is what my wife is learning.
Currently, I'm learning that abstraction is folly. What a twist! In 3 years perhaps I'll realize that abstraction was the right thing all along. One of my favorite parts about unit testing is how deliberate it can be. Explicitly walking yourself through some code and saying, this function returns an array. Perhaps unit tests are thinking a move or two ahead in chess. What makes a good unit test though, is it documenting a part of a code-base? I've yet to experience that but people say it. I suppose someday, I'll see tests as documentation. Maybe I'll restructure my testing strategy to document the code, rather than simply document the inputs and outputs? Maybe that's the coding equivalent of territory in chess.
What about Aristotle though?
I don't know a lot about Aristotle. Apparently, he spent a lot of time thinking about chair and yellow. A chair is a thing, yellow is a thing. A yellow chair is also a thing. Or is it two things? The idea that something can be two things, or one thing with two properties is pretty profound. The word on the street is it's a fundamental insight in philosophy. It certainly is in coding. Something can have properties and values and be multiple things at once. It's like the first time you realize that front ends are just collections of divs on top of divs. When you're learning to code, first you have to learn that a chair is a chair, it's yellow, and you can control it, and make it something else.
I'm not exactly sure that I signed up for that insight when I decided to code. I learned to code for the money. Not because I love it or I like puzzles. Now I'm here and I'm watching my wife. I'm a different person than before. For lots of reasons, but certainly ,because I look at things like a developer now. The same thing is going on for my wife right now. She's practicing reduce statements in the other room. In six months she'll be thinking about how a state machine is a better way to have insight into what's happening in an application. Each practice problem she gets the syntax get's easier, and the ability to imagine the shape of the data gets a little easier. Before you know it, you're just writing some code because it solves the problem you're facing. This is the point of code katas right? Aristotle also thought that at some point, you should stop learning, stop with self-improvement, and get after it.
If Aristotle is correct there are two parts of life (I'll loosely equate this to learning a skill), the becoming, then the part where you are what you're going to be. At least in part, I disagree. Especially, when it comes to development. The practice of breaking down chairs into smaller abstractions of chairs, or building them up into systems that make up stadiums, I am pretty sure that's a continuous improvement process. There's a point however where a person can get a job, contribute to a team, and so on. My wife will never finish learning to code. I suspect that I failed in my duties as a friend and husband when I didn't make that clear. I couldn't make it clear though. I'm a vampire now. She's becoming one, so if I'm lucky, by the time she realizes I've made a mistake, she'll be a vampire and never know.
Top comments (0)