Some of my greatest "Aha!" moments in programming are connected, somehow or other, to Pokemon. I can study Full Stack Open all day and memorize syntax until my eyes bleed, but it's often only when I connect a concept to its Pokemon equivalent that all the pieces finally snap into place and I'm suddenly full of ideas and excitement.
Technical Evaluation
Over the last month, I've been studying to pass Fractal's technical checkpoint - essentially building a backend Express server to handle CRUD operations and a frontend React app that renders database entries. The most common example is a simple notes app - for extra practice I decided to build a Pokedex too. I started with just name, type, and id properties, which was still complex enough to make it challenging: template strings to combine properties into "Pokedex entries," additional state variables, ordered lists, and trying to go from start to finish with minimal Googling.
I did it! Initially, I felt extremely proud and accomplished - but this feeling was soon hijacked by imposter syndrome, which told me my Pokedex was NOTHING compared to Bulbapedia and didn't provide value to anyone. I ignored that voice, at least for a bit.
Dreams Without Labels
I've become hyper-cognizant about explicitly labeling dreams and converting ideas from abstract into concrete. The first time Parth and I went to dinner - which would catalyst him becoming a lifelong friend, roommate, groomsman, and companion in birding, transformative video games, and coding - we talked about what drove us, kept us up at night, how we want to change the world. We kept the conversation extremely abstract. Instead of "let's start a podcast," we discussed what about podcasts allows people to be transformed, why the release of ideas can be profound, what aspects of media truly provide value to humans.
At one point, I suggested something concrete - "I really want to start a YouTube channel" - and Parth immediately stopped me: "No no no, don't put a label on it yet, that will only limit us needlessly." I realized he was right. By putting such a concrete label on my dreams, I'd been putting a limit on what I might become or what I was capable of.
The Checkpoint
The night before the technical evaluation (and before building the Pokedex), I stayed up until 1am with Parth building a chatroom application. I'll be honest, I thought it was stupid when we started. I had a concrete list of 10 subtasks to showcase in 12 hours, and I figured our call would be a simple "checking the boxes" to ensure I was ready for the evaluation.
First, I didn't think that the chatroom suggestion was even relevant to what I needed to be able to build. And second, we spent a chunk of time writing out the structure and data we needed before even writing any code. Only after passing the evaluation with flying colors did I realize he was correct on both accounts.
Writing things out before building ended up being extremely helpful, and an important step of competent software engineers. However, I was impatient, so I decided to start building while we talked (sorry Parth). I had a "get it done" attitude and maybe even a subconscious desire for superiority ("I don't need silly exercises, I'll start the actual work while he dicks around with his notebook").
Karma would teach me a lesson. I had violated the software engineer's oath: build things one step at a time and verify your application works at each stage. Instead, I was starting every component I could think of, writing pieces that immediately came to mind ("need a useEffect here," "need an event handler," defining state variables, HTML skeleton, etc.), and I ended up needing to rework a lot of aspects.
Memorization vs. Understanding
This gets at another idea I've been noodling on about competence. Back in grade school, I was a STEM kid through and through - advanced placement math, engineering courses - but I always struggled with History, English, Theology, etc. I distinctly remember feeling frustrated after bombing a 4th grade History exam: "I'll never be good at this stuff. I get the material, but as soon as the teacher rewords the questions, I don't understand it anymore. It's like I can't access the information unless the question is in EXACTLY the same format."
This was my running theory for years - that my brain somehow "understands numbers and logic, but not words, events, or facts". It wouldn't be superseded until 10+ years later when I thought: Maybe it's NOT that my brain simply CAN'T demonstrate understanding - maybe I just didn't actually UNDERSTAND the material, but rather only KNEW it from reading it a couple times. Therefore, my ability to demonstrate what I had studied was limited to that exact, single that I had learned it in. When presented with even a SLIGHTLY different context, my thought process broke down.
The same phenomenon reared its head during my initial technical checkpoint attempts. I had learned to create servers and React apps following tutorials, and mistook "having built this thing" for "actually understanding how this thing works and being able to build it, troubleshoot it, and explore alternatives." So even though I encountered a similar breakdown in thinking to when I was in 4th grade, I had a different reaction to it this time. I was armed with my new theory of competence and conviction that I AM good at coding, so I understood that even if I conceptually grasped the material, I simply wasn't at the desired level of competence yet. I needed more practice.
The Payoff
Those silly exercises Parth had me doing until 1am actually paid off. Or more succinctly: Parth was right, Ben was wrong.
I should've known better. It's fundamental to all engineering to begin by laying out assumptions, problem definitions, and what you know, don't know, and need to know - all before working on solutions. This is what makes engineering difficult and separates good engineers from great ones. Good engineers know how to code and set up servers, but great engineers solve problems that haven't been solved before, create real solutions to real problems - without following tutorials.
As Einstein said: "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."
I also realized that Parth is a better engineer than I gave him credit for. He often defies my expectations, which can be confusing or frustrating, but more often reveals deep insights I didn't even know I needed.
Complex Children's Games
After passing the technical, I wanted more practice before bootcamp starts. After briefly starting a task tracker, I decided to expand my Pokedex app. After adding PUT and DELETE routes, my brain was generating ideas faster than my fingers could code, so I created ideas.txt and began throwing every functionality I could think of onto the screen.
Adding base stats, abilities, held items, descriptions, sprites would be straightforward. But evolution and learnsets made me stop. Should I create a nested 'evolution' object within 'pokemon'? Should evolveFromMethod and evolveToMethod both live there? How do I account for branched evolution trees, and odd evolutions like Sirfetch'd or Runerigus? With learnset, I started with [move, levelLearned] arrays, but quickly thought: I don't want to repeat move data every time a Pokemon can learn it, so how do I "call" move data when it appears in a learnset?
It wasn't until I'd mapped out this complex structure that I remembered something called "PokeAPI" in my bookmarks. One click and boom - all my questions were answered. Everything my brain had been furiously trying to process appeared on screen.
It was simultaneously validating, groundbreaking, and crushing. Validating because my "original idea" WAS potentially valuable to people, evidenced by the fact that someone spent a LOT of time building the thing I was trying to make. Groundbreaking because my concept of possibilities suddenly expanded. Crushing because seeing the paragon of your struggle-filled project makes all that effort feel...unnecessary. But it's a good kind of crushing. Maybe feeling that a day's work was unnecessary is a necessary kind of crushing.
Susan Sontag wrote that "depression is melancholy minus its charms." Feeling that your life and work is meaningless - that's depression, no charm to it, tough stuff. But discovering PokeAPI after unknowingly trying to reinvent it - that's melancholy. After the disillusionment passes, what takes its place is often deeper understandings and new drives to learn and grow.
After reflecting on where I'm at post-PokeAPI-discovery-and-giving-up-on-everything-I-was-working-on: Coding is still cool, I still want to become a really good engineer, and life can still be meaningful even when you're being crushed.
P.S. In case anyone is interested, the following is how far I got before rememebering PokeAPI existed:
pokemon: {
id: 1
name: "Bulbasaur",
type: "grass",
evolution: {
evolveFrom: {
tf: false,
method: null
}
evolveTo: {
tf: true,
method: [level: 16]
}
},
learnset: {
byLevelUp: [
[move: "vine whip", level: 7],
[move: "razor leaf", level: 20],
[...]
]
byTM: ["hyper beam", "frenzy plant", "surf", ...],
},
abilities: {
base: ["Quark Drive", "Guts"],
hidden: ["Sap Sipper"]
},
heldItems: ["some berry"],
category: "Seed Pokemon",
description: "Bulbasaur is a small, quadrupedal amphibian Pokémon that has blue-green skin with darker patches.",
obtainMethods: [trade, "Viridian Forest", "Cerulean City"],
sprites: [bulbasaurMain.jpg, bulbasaurBack.jpg],
breeding: {},
cries: {},
experience: 101,
height: 10,
weight: 10
}
}