DEV Community: Randall Wolfe

The Training Wheel Must Come Off

Randall Wolfe — Thu, 16 Oct 2025 16:56:35 +0000

Tutorial Hell

Like many that have come before me, I have landed in Tutorial Hell. When learning to program, Tutorial Hell is when you're stuck feeling unprepared, feeling that you need just one more video or article or tutorial. It is an insidious cycle. For me, I feel confident during a lecture or tutorial. I'm following the instructions, and I feel like I understand why we are doing each step. Then I feel like the rug is pulled out from under me when I go to start building on my own. So, I turn back to the tutorial, and the cycle continues.

Why is this happening? And How do I get out?

To use the training wheels metaphor: I ride my bike with the training wheels from point A to point B, and I feel great, so I take the training wheels off. When I start to ride I immediately fall over. This happens because the training wheels can help you practice the motions of riding a bike, but they remove the resistance, the need to balance. However, the skill of riding a bike is balancing. In other words, training wheels will allow you to practice the motions you need in order to practice and develop the skill of balancing on your bike, but they will prevent you from practicing the skill of balancing on your bike. This is contradiction of learning. You need something to practice the motions, but then you have to use the motions to struggle against a problem.

On leaving Tutorial Hell and where learning happens

I didn't think that I would end up in Tutorial Hell, because I am a teacher. I know how learning happens, and I know I've been doing everything wrong since graduating from The General Assembly Software Engineering Bootcamp. But just like riding a bike with training wheels, tutorials make you feel like you're coding when you're actually just practicing the motions of coding. In order to actually develop and learn, you need to struggle against a real problem. You need to go through the process not just the motions.

Real learning happens in the process not the motions.

But, what does that mean? The process is applying the motions to solve a problem. Going through the motions without the risk of failure does not result in learning because the problem is already solved for you. Think about driving before we all had GPS. You used to know how to get to tons of places with directions because you went through the process of getting there and the motions became automatic. Now, how many times have you pulled up the GPS to get to the supermarket or a friend's house? I believe this is because many of us have offloaded the process to the GPS, and driving is just the motions.

This is the same with a tutorial. The information has already been processed. The author of the tutorial is not teaching you the process, they are showing you the motions. The instructor has chosen the framework, the language, the architecture, etc. This is why we panic at the blank page. It's why we all fall when the training wheel comes off, but falling is a part of the process, failing is where learning happens. Maybe failing is the wrong word, so lets say struggling is the first step to learning.

So what do I do now?

Now, I'm going to struggle. I'm going to go through the process, not just motions. I'm going to plan and build projects without tutorials. I'm going to build until I get stuck, then I will search the documentation for the answer to get unstuck. If we keep with the riding a bike metaphor, I will ride until I fall, then I get back on the bike and keep riding. I'm strengthening muscles here, so I need to accept that this is going to be uncomfortable, I'm going to feel like I don't know what I'm doing, but that's how learning happens.

Now to be concrete because it is all well and good to tell someone it is like riding a bike, or driving a car, or whatever metaphor you want to use, but programming and writing and all other abstract tasks are different because they do not have a predefined goal. When you are physically going from point A to point B, it should be obvious when you get to your destination.

So here is the process that I am going to implement and the rules. I'm giving myself permission to not be creative.

Stage 1: Plan

What is the problem this app will solve?
Who is this app or project for?
Why do you need this app or project?
When do I expect to complete this project?
How will I know this is done?

Rules:

You must be able to answer these questions concretely.

Deliverables for this stage:

A clearly defined MVP
User Stories of features
Wireframes
A timetable

Stage 2: Build

Work on one user story at a time.
Test each feature as you go
Commit each feature individually
Get it working, no optimizing before it works.

Rules:

No tutorials.
No AI
Go to the official docs first

Deliverables:

Public Github Repo
Deployed Live Demo

Stage 3: Get feedback

Ask people to use your app, hopefully the who from stage 1. Ask for what they like and what they think could be improved.
Ask programmers for code reviews. What did you do well? What could be improved?

Deliverables:

Write a reflection based on the feedback (you also need to process the feedback)

Stage 4: Return to Stage 1 with the feedback

Rebuild #1.2: Just use F***ing use HTML

Randall Wolfe — Fri, 10 Oct 2025 21:36:29 +0000

A friend of mine once told me, there are two wolves inside of every frontend developer:
just fucking use html vs just fucking use react.

At the end of my bootcamp, I was firmly in the React camp. For most situations, I still am. But as I navigate through components on my Mastermind rebuild, I keep looking back fondly at my vanilla JS version and thinking the same thing over and over: why didn't I just fucking use HTML?

I decided to dive into the functionality once I got the layout down and styled to an acceptable level. That's when the frustration set in. I'm losing steam because of the overhead and complexity React introduces for such a simple project. My original vanilla Mastermind was three files with very clear separations of concerns. Now I'm stuck in prop drilling hell, reconsidering the whole approach.

I'm tired of setting the state of the game board. More specifically, I'm bothered by the need to use state to handle the board when a simple 2D array worked fine before. Keeping the HTML and JavaScript separate made managing game state straightforward. With React, it feels unnecessarily complicated.

I think I'm ready to call this experiment a bust. It could be a skill issue, a planning issue, or both, but the juice isn't worth the squeeze right now. I'm putting this project down.

Here's what I'm concluding: simple games like Mastermind are better served by a vanilla stack. The cognitive load of React adds nothing to the user experience and only slows my development process.

Check out the original game here: MasterMind

Tell me in the comments: do you think this game would actually benefit from React, or do you agree that some projects are better left vanilla?

Rebuild #1.1: When Quick and Easy Became A Learning Moment

Randall Wolfe — Wed, 08 Oct 2025 19:38:19 +0000

I think we've all said it: "This will be super fast." That was definitely the plan for this rebuild. One day, tops. Spoiler alert: that's not how it's going.

I've hit a couple of rookie mistakes that are slowing me down, but they're teaching me something important about working with the right tool for the job:

Treating React like vanilla JS
Hard-coding HTML and Tailwind

Treating React Like Vanilla JS

When I started this rebuild, I didn't plan thoroughly enough. I figured, I know React and I know this project. This will be a simple rebuild. But then I just started copying what I did in the original vanilla JS version, which entirely misses the point of the exercise.

I've been dividing the HTML into components without actually thinking in components. That's an absolute rookie mistake. Instead of leveraging React's strengths, I'm just making it feel like more work than a simple vanilla stack.

Hard-coding HTML with Tailwind

This is where the pain point really showed up. I don't think I would have noticed my mistakes as quickly if I wasn't using Tailwind.

I was struggling to get momentum because there are a lot of repeated elements. The game grid alone has 5 rows, each with 4 boxes and 4 pegs, all styled as individual divs. At first, I started thinking Tailwind was the problem, that it wasn't a good fit for a project like this. Again, I was thinking in vanilla JS, not React.

But this got me thinking about what I was actually doing wrong and how I could pivot my approach. As I considered moving to a different CSS library and what that refactor would look like, I realized Tailwind wasn't the problem. It was just pointing out that I wasn't writing DRY code.

The Reset

So, as I start the build again, I'm focusing on not repeating myself. Specifically, I'm thinking about component architecture and data mapping instead of hard-coding repeated elements in my JSX. Sometimes the fastest path forward is admitting you need to back up and do it right.

Rebuild #1.0: MasterMind, planning the rebuild.

Randall Wolfe — Mon, 06 Oct 2025 19:52:12 +0000

Now that I've finished the General Assembly Software Engineering bootcamp, I want to maintain momentum and apply all the things I learned. So I'm starting a rebuild series of my projects from the bootcamp.

Why rebuild instead of refactor? I'm rebuilding as a learning exercise, and especially for the earlier projects because I hadn't learned the frameworks that I plan to use. Then, after each build, I will reflect on the original and rebuild tech stacks. Was the rebuild overkill? Did the framework make it easier to add and maintain features?

For this first rebuild, I'm tackling MasterMind.

MasterMind

This was my first project at the bootcamp. It was the culmination of learning HTML, CSS, and JavaScript. The game itself is a Wordle-style deduction game based on the board game Mastermind. In my version, I changed the number of guesses from 10 to 5. Otherwise, the game is largely the same. The game randomly generates a sequence of four colors out of a possible six with no repeats. The user attempts to guess the sequence in five tries. After each guess, the user is told the number of colors that are in the correct position, and the number of colors that are in the sequence but the wrong position.

The Original Code

GitHub Repo: MasterMind

The game was simply three files: index.html, script.js, and style.css.

The Rebuild Plan

For these rebuilds, I'll be focused on using React instead of vanilla JavaScript, with particular attention to how state management and board generation are different.

One thing I know I want to change first is that I hard-coded the board into the HTML. Instead, I want to dynamically create the board in JSX. I'll also split the board into multiple components:

Header
Rows
GuessRow
FeedbackRow
Color keyboard
Buttons

Lastly, I plan to use Tailwind CSS to style the board. I'm still deciding if I like Tailwind CSS over using CSS modules. So for the styling element, I want to see how readable my code is with Tailwind and how the development goes when I'm styling the components separately.

Questions I Hope to Answer

Did React add any improvements to the development process and/or user experience?
Did Tailwind allow me to more easily achieve the style I planned, and how did it affect the readability of the code?
How does component-based architecture affect code maintainability compared to vanilla JavaScript?

What's Next

I'll be documenting the rebuild process and sharing what I learn along the way. Follow along on here or on LinkedIn if you want to see how it goes, and feel free to drop suggestions or your own experiences with rebuilding projects.

MiniMax Algorithm: Or, How I learned to Stop Worrying and Love Recursion.

Randall Wolfe — Thu, 02 Oct 2025 15:43:49 +0000

I love it when curiosity sinks its teeth into me, when my need to know drives me to go above and beyond the assignment. When did you go above and beyond the task just for the sake of your own curiosity?

At the start of my Software Engineering Bootcamp, we were tasked with programming a simple tic-tac-toe game to practice DOM manipulation. Before the bootcamp, I had taught computer science, and already had a firm grasp on DOM manipulation. So, I wanted to push myself, and I knew from the 1983 classic film WarGames that tic-tac-toe was a solved game. In other words, if both players know how to play the game, it will always end in a tie. So, I asked myself, “could I program an unbeatable computer player for my game?” From my experience I knew I could use selection to determine the computer’s moves, but the number of conditionals that would take would be too many to type or even think about, and it would be very easy to miss a condition.

Enter recursion.

I knew about recursion, but I was scared of it because it hurt my brain, and I had never encountered a problem I both wanted to solve and needed recursion to solve. So, this was it. I knew I needed recursion because of the branching factor. From my googling I quickly came across the minimax algorithm. Minimax is a simple recursive algorithm that assigns a value to the base case, or end state, of a board game. So, for tic-tac-toe, if the player is X and the computer is O, my computer player would assign -1 to any base case where X wins, 0 to a tie, and 1 to any base case where O wins.

That’s where the recursion came in. Each move branched into more possibilities, and the minimax algorithm allowed me to explore them all without writing out endless conditionals. The computer could now simulate every possible outcome of a game, evaluate them, and then choose the move that maximized its chances of winning, or at least guaranteed a tie.

When I finally got the algorithm working, it felt like unlocking a new way of thinking. Recursion wasn’t abstract anymore. It was practical, powerful, and elegant. And beyond the code itself, the project reminded me why I love learning. Curiosity pulled me past the assignment into uncharted territory, where the real growth happened.

In the end, I didn’t just build a tic-tac-toe game with an unbeatable computer player. I proved to myself that the things that once felt intimidating, like recursion, could become tools I reach for with confidence.

So now I’ll throw the question back to you. When was the last time your curiosity pushed you beyond the assignment and what did you discover?

Also let me know if you’d be interested in a walkthrough of my implementation of the minimax algorithm. Here is the live demo if you want to try and beat it! I themed it as Pirates vs. Ninjas for fun.

Live Demo
Github Repo

What was the first sign that you would love Programming?

Randall Wolfe — Fri, 26 Sep 2025 18:17:50 +0000

I’ve always loved computers and games, but I didn’t always think programming was for me. Like many others, I believed you had to be a “math person” to be good at it.

Now, math is absolutely important in computer science, but it shouldn’t be a barrier to entry. That misconception kept me from pursuing software engineering as a passion and a career. In fact, it wasn’t until the school district I worked for offered to pay for my computer science teaching certification that I finally gave it a try.

I was floored by how quickly I latched on to programming. That was my aha! moment: it wasn’t about math,it was about logic. And if there’s a Venn diagram between English and math, logic sits right in the middle.

Looking back, I missed some pretty obvious signs I would love programming. I’ve always been a fan of Final Fantasy, and while my first was FF7, the one I want to highlight is Final Fantasy XII. Its combat system introduced the Gambit system, basically conditional statements you could assign to characters.

“If an ally’s HP < 50%, heal them.”
“If an enemy is weak to fire, cast fire.”

You could automate strategies and watch them unfold and I adored it. And only years later, when I started programming, did I realize that was programming! Automating tasks, creating patterns, solving problems.

So now I’m curious, what was your first sign you’d love programming? And did you miss it like I did?