Why I Built a Chess Engine in Java Instead of Another CRUD App

Every learning path for developers eventually hands you the same shopping list. Build a Todo app. Then a Notes app. Then a Blog CMS. Then, if you're feeling adventurous, an Inventory System with user roles. I built most of those. Some of them twice, in different frameworks, because that's what you're told to do when you're trying to "get serious."

And for a while, it worked. Those projects taught me real things. But somewhere around my fourth CRUD app, I noticed I'd stopped learning and started copying myself. I could scaffold a new one in an afternoon without thinking. That's a nice feeling for about a week, and then it turns into a quiet panic: am I actually getting better, or just faster at the same trick?

So I did something that made no sense on paper. Instead of building a fifth CRUD app to round out my portfolio, I built a chess engine in Java. No product. No users. No monetization. Just a program that could look at a chessboard and decide on a decent move.

It was the single most frustrating, humbling, and genuinely useful thing I've done as a self-taught programmer. This is the story of why I chose it, what broke, and what it did to the way I think about code.

Table of Contents

• The problem with endless CRUD projects
• Why chess is an unusually rich problem
• Why I chose Java on purpose
• Designing the engine
• The hardest bugs
• Implementing minimax and alpha-beta pruning
• Building an evaluation function
• Performance optimizations
• Testing everything
• What this project taught me
• Would I recommend it?
• If I started again
• Frequently asked questions
• Conclusion

The Problem With Endless CRUD Projects

Let me be fair to CRUD apps first, because they get dunked on and they don't deserve all of it.

If you've never built one, a CRUD app teaches you the actual plumbing of modern software:

• How a request travels from a browser to a server to a database and back
• Authentication and authorization
• REST API design and status codes
• Database schema design, migrations, and relationships
• Form validation and error handling
• Deployment, environment variables, and the joy of a broken build at 2 a.m.

Those are not small skills. They're most of a real job. So build a couple. Genuinely.

The problem is the ceiling. Watch what these classic beginner projects actually have in common:

• Todo App — create tasks, list tasks, mark done, delete
• Student Management — create students, list students, edit grades, delete
• Expense Tracker — create expenses, list expenses, edit categories, delete
• Hospital Management — create patients, list appointments, edit records, delete
• Library System — create books, list loans, edit due dates, delete
• Employee Portal — create employees, list departments, edit roles, delete

Notice anything? Strip away the domain and it's the same four operations wired to a different-looking table. The nouns change. The verbs never do. Once you've internalized the pattern, you're not solving an engineering problem anymore — you're renaming columns.

The tenth CRUD app doesn't teach you the tenth thing. It teaches you the first thing, again, in a new costume.

The core issue is that CRUD apps rarely have hard logic. The database does the heavy lifting. Your code is mostly a polite translator between an HTML form and a SQL row. There's no moment where you have to sit with a whiteboard and genuinely think about an algorithm, because there isn't really an algorithm — there's a query.

I wanted a project where the difficulty lived in my code, not in a library I was gluing together. I wanted something where being clever actually mattered and being sloppy actually hurt. Chess turned out to be exactly that. If you want the broader argument about which side projects actually stand out, I wrote separately about the portfolio projects that got people interviews.

Why Chess Is an Unusually Rich Problem

Here's the thing about chess that sneaks up on you: the rules sound simple until you try to write them down as code. Then they explode.

Consider what "make a move" actually involves. A piece moves from one square to another. Easy. Except:

• A pawn moves forward but captures diagonally, and only diagonally.
• A pawn can move two squares, but only from its starting rank.
• A pawn reaching the far side promotes into a queen, rook, bishop, or knight.
• En passant lets a pawn capture another pawn that just walked past it — a rule that depends on what happened last move, not the current board.
• Castling moves two pieces at once, but only if neither has moved, the squares between are empty, and the king isn't currently in check, doesn't pass through check, and doesn't land in check.
• You can't make any move that leaves your own king in check. Even a legal-looking move is illegal if it exposes your king.
• Checkmate is check with no legal escape. Stalemate is no legal move without being in check — and that's a draw, not a loss.

Every one of those is a special case that interacts with the others. A move that's legal in isolation can be illegal because of a pin. A game that looks winnable is actually a draw. This is a state machine with genuinely tricky rules, and there's no ORM that models it for you.

That's what makes chess a rich programming problem. It forces you to confront things CRUD never does:

CRUD asks "where do I store this?" Chess asks "given this situation, what happens next, and is it even allowed?" The second question is the one that makes you a better engineer.

CRUD app vs chess engine, side by side

Neither column is strictly better. The point is that they train different muscles, and if you've only ever trained the left column, the right one is where the growth is hiding.

Why I Chose Java on Purpose

I could have written this in Python. Fewer keystrokes, faster to prototype. I deliberately didn't, and I stand by it.

Chess is fundamentally about objects with clear identities and behaviors. A board, pieces, moves, a game. Java's insistence on structure — which feels like bureaucracy when you're building a Todo app — becomes a feature when your domain is genuinely object-shaped.

Here's what Java gave me that mattered:

• Strong OOP — a Piece hierarchy with a Bishop and a Knight that override behavior maps naturally onto the problem.
• Type safety — the compiler caught dozens of mistakes before I ever ran the code. When your logic is this interlocking, catching a wrong type at compile time saves hours.
• The Collections framework — List, Map, EnumMap, and friends handle move lists and lookups without me reinventing anything.
• Performance — a chess engine searches millions of positions. Java's JIT-compiled speed matters once you go more than a couple of moves deep.
• Debugging and IDE support — stepping through a recursive search with the debugger, setting conditional breakpoints on "only stop when depth == 0," was invaluable.
• JUnit — testing game logic is central to this project, and JUnit made writing hundreds of assertions painless.

Java encourages disciplined design almost against your will. It nudges you toward interfaces, clear class boundaries, and explicit types. For a project where a single sloppy shortcut can corrupt your entire board state, that discipline is a gift, not a tax. This was the Java programming project that finally made object-oriented programming click for me, instead of being a thing I recited in interviews.

Designing the Engine

I'll be honest: my first design was bad. Not "junior developer" bad — genuinely, "this cannot work" bad. But you learn more from a design that collapses than from one that's handed to you correct.

My eventual class breakdown looked roughly like this:

Game          -> owns the current Board, whose turn it is, move history
Board         -> an 8x8 grid of squares, knows how to apply/undo moves
Square        -> a coordinate (file, rank), may hold a Piece
Piece         -> abstract base: Pawn, Knight, Bishop, Rook, Queen, King
Move          -> from-square, to-square, plus flags (capture, castle, promo)
MoveGenerator -> produces all legal moves for a side
Evaluation    -> scores a position for the AI
Engine        -> runs the search and picks a move

The inheritance mistake

My first instinct was deep inheritance. Piece was abstract, and each piece overrode a getMoves() method. That part was fine. Where it went wrong was that I stuffed board-scanning logic inside each piece — the bishop knew how to slide diagonally by directly reaching into the board and mutating things.

That coupling was a disaster. Pieces and the board became tangled. When I needed to simulate a move to check for check, pieces were mutating real board state as a side effect of asking what their moves were. Asking a question changed the answer.

Here's a trimmed version of the piece hierarchy after I fixed it — pieces describe their movement, the board executes it:

public abstract class Piece {
    protected final Color color;

    protected Piece(Color color) {
        this.color = color;
    }

    // Return candidate moves. Does NOT mutate the board.
    public abstract List<Move> pseudoLegalMoves(Board board, Square from);

    public Color getColor() { return color; }
}

public class Bishop extends Piece {
    private static final int[][] DIRECTIONS = {
        {1, 1}, {1, -1}, {-1, 1}, {-1, -1}
    };

    public Bishop(Color color) { super(color); }

    @Override
    public List<Move> pseudoLegalMoves(Board board, Square from) {
        List<Move> moves = new ArrayList<>();
        for (int[] dir : DIRECTIONS) {
            board.slide(from, dir[0], dir[1], color, moves);
        }
        return moves;
    }
}

The lesson underneath this is one you hear as a slogan and only believe after it bites you: favor composition over deep inheritance, and keep responsibilities separate. The piece shouldn't own board state. The board shouldn't know a bishop's movement rules. Once I drew that line clearly, half my bugs became impossible instead of merely fixed.

The Hardest Bugs

This is the section I'd have wanted to read before I started. Move validation is where the pain lives, and it's a specific, memorable kind of pain.

Bug 1: The king that walked into check

My first move generator happily let the king move into a square attacked by an enemy piece. Illegal, obviously. But detecting it is subtle: to know if a move is legal, you have to make the move, then ask "is my king now under attack?", then undo it.

The naive fix caused a worse bug — infinite recursion. To check if a king move was safe, I generated the opponent's moves. To generate the opponent's moves, I checked if those left their king safe. Which generated my moves. Which... you see it.

The fix was to separate two ideas cleanly:

• Pseudo-legal moves — moves that follow a piece's movement rules, ignoring check.
• Legal moves — pseudo-legal moves that don't leave your own king in check.

And critically, "is this square attacked?" must not recurse into full legality — it only needs pseudo-legal attacks. That one distinction killed the infinite loop.

public List<Move> legalMoves(Color side) {
    List<Move> legal = new ArrayList<>();
    for (Move move : pseudoLegalMoves(side)) {
        board.make(move);
        if (!isKingInCheck(side)) {   // uses pseudo-legal attacks only
            legal.add(move);
        }
        board.undo(move);             // this line hid a monster
    }
    return legal;
}

Bug 2: Undo that didn't undo

See board.undo(move) above? For two days it silently corrupted the game. After a capture-and-undo, the captured piece would vanish. My Move object recorded where a piece moved but not what it captured, so undo had nothing to restore.

The symptom was maddening: the AI would evaluate positions based on a board that was slowly losing pieces during the search, then make an insane move in the real game. The board on screen looked fine. The board inside the search was rotting.

The fix was to make moves carry everything undo needs:

public class Move {
    final Square from;
    final Square to;
    Piece captured;        // filled in when the move is made
    boolean wasEnPassant;
    Piece promotion;
    // castling rights + en passant target before the move,
    // so undo can restore them exactly
    CastlingRights prevRights;
}

Undo must restore the complete prior state — captured piece, castling rights, en passant target, everything. Miss one field and your search silently lies to you.

Bug 3: Castling through check

Castling has, by my count, five preconditions. I implemented four. I forgot that the king can't pass through an attacked square. So my engine would castle its king straight through a square controlled by an enemy rook, which is illegal and also looks like cheating to anyone who knows the game. Caught it only because a friend playing against it said, "wait, you can't do that."

Bug 4: Checkmate that never triggered

My checkmate detection asked "is the king in check and are there zero legal moves?" Correct logic. But it was calling my pseudo-legal generator by mistake, so it always found some move — including illegal ones — and concluded the game wasn't over. Games would continue past checkmate into nonsense. The bug wasn't in the checkmate logic at all; it was one wrong method call feeding it bad data.

Bug 5: Evaluation returning garbage

At one point my evaluation function returned wildly positive scores for losing positions. Turned out I was summing material for both sides but forgetting to negate the opponent's. The AI thought sacrificing its queen was brilliant. It was very confident and very wrong.

That fourth one deserves a word. Early on I "copied" the board for the search by copying the array of squares — but the squares still pointed at the same piece objects. Mutating a piece in the search mutated the real game. Deep versus shallow copy stops being a textbook question the moment your king teleports.

Implementing Minimax and Alpha-Beta Pruning

Once the rules worked, the fun part began: making the computer choose. This is where the minimax algorithm in Java comes in, and it's more intuitive than its reputation.

The idea: chess is a tree. From the current position, you have some legal moves. Each leads to a new position where your opponent has moves, and so on. Minimax explores this tree assuming both players play their best.

• You want to maximize the score.
• Your opponent wants to minimize it.

You look ahead a fixed number of moves — the depth — then use an evaluation function to score the leaf positions, and let those scores bubble back up.

                (you: pick MAX)
                /      |      \
           +2         -5        +1        <- opponent replies (pick MIN)
          / \        / \       / \
       +3  +2    -5  +4    +6  +1          <- leaf scores from evaluation

At the bottom, you evaluate. One level up (opponent's turn) you take the minimum of each group. One more level up (your turn) you take the maximum. The move leading to the best guaranteed outcome wins.

int minimax(Board board, int depth, boolean maximizing) {
    if (depth == 0 || board.isGameOver()) {
        return evaluate(board);
    }

    if (maximizing) {
        int best = Integer.MIN_VALUE;
        for (Move move : board.legalMoves(WHITE)) {
            board.make(move);
            best = Math.max(best, minimax(board, depth - 1, false));
            board.undo(move);
        }
        return best;
    } else {
        int best = Integer.MAX_VALUE;
        for (Move move : board.legalMoves(BLACK)) {
            board.make(move);
            best = Math.min(best, minimax(board, depth - 1, true));
            board.undo(move);
        }
        return best;
    }
}

The catch: the tree is enormous. There are around 20 legal opening moves, and branching stays high. Searching even a few moves deep means evaluating an eye-watering number of positions. Plain minimax at depth 4 was already sluggish.

Enter alpha-beta pruning. The insight is beautifully simple: if you've found a move so good that your opponent would never allow the position leading to it, you can stop examining that branch. You track two bounds — alpha (best the maximizer can guarantee) and beta (best the minimizer can guarantee). When they cross, you prune.

int alphaBeta(Board board, int depth, int alpha, int beta, boolean maximizing) {
    if (depth == 0 || board.isGameOver()) {
        return evaluate(board);
    }
    if (maximizing) {
        int best = Integer.MIN_VALUE;
        for (Move move : board.legalMoves(WHITE)) {
            board.make(move);
            best = Math.max(best, alphaBeta(board, depth - 1, alpha, beta, false));
            board.undo(move);
            alpha = Math.max(alpha, best);
            if (beta <= alpha) break;   // prune: opponent won't allow this
        }
        return best;
    } else {
        int best = Integer.MAX_VALUE;
        for (Move move : board.legalMoves(BLACK)) {
            board.make(move);
            best = Math.min(best, alphaBeta(board, depth - 1, alpha, beta, true));
            board.undo(move);
            beta = Math.min(beta, best);
            if (beta <= alpha) break;
        }
        return best;
    }
}

Alpha-beta pruning in Java gave the same answer as plain minimax but visited a fraction of the nodes. Watching my search go deeper and faster after adding a few lines of pruning was one of the most satisfying moments of the whole project. Same result, far less work — that's the kind of elegance you rarely bump into wiring forms to tables.

Building an Evaluation Function

Here's the uncomfortable truth nobody warns you about: the evaluation function is an opinion, not a fact.

Minimax tells you how to search. Evaluation tells the engine what "good" even means, and there's no objectively correct answer. You're encoding chess judgment into numbers, and reasonable people disagree.

I started with the obvious: material count.

• Pawn = 100
• Knight = 320
• Bishop = 330
• Rook = 500
• Queen = 900
• King = enormous (losing it ends the game)

int evaluate(Board board) {
    int score = 0;
    for (Square sq : board.occupiedSquares()) {
        Piece p = sq.getPiece();
        int value = pieceValue(p);
        score += (p.getColor() == WHITE) ? value : -value;
    }
    return score;
}

Material alone produces a bot that grabs pieces and otherwise wanders aimlessly. So I layered in more factors, one at a time, testing after each:

• Piece-square tables — a knight on the rim is worse than one in the center, so each piece gets a small bonus/penalty per square.
• Mobility — more legal moves usually means a better position.
• King safety — an exposed king is a liability; pawns in front of it earn a bonus.
• Center control — occupying or attacking the central squares matters early.
• Pawn structure — doubled and isolated pawns are weaknesses.

Each addition changed the engine's personality. Adding piece-square tables alone made it visibly less clumsy in the opening. The point I want to land: evaluation is iterative and subjective. You tweak a weight, play some games, watch what changes, and adjust. It's less like solving an equation and more like tuning an instrument by ear. I never found the "right" numbers, because there aren't any — only trade-offs I could live with.

Performance Optimizations

Depth is everything in chess engines, and depth costs time exponentially. Here's what actually moved the needle for me, roughly in order of impact:

1. Alpha-beta pruning — by far the biggest win. Turned a depth-4 search from painful to instant.
2. Move ordering — alpha-beta prunes far more when you examine good moves first. I sorted captures before quiet moves (try the promising stuff early, cut more branches). Cheap to add, big payoff.
3. Make/undo instead of copying the board — early on I cloned the entire board for every node in the search. That's millions of object allocations. Switching to a make/undo model on a single board cut memory churn dramatically.
4. Reducing object creation — I was creating a fresh Move list and new objects everywhere. Reusing structures and avoiding needless allocation reduced garbage collection pressure noticeably.
5. Profiling before guessing — I assumed evaluation was my bottleneck. The profiler said move generation was. I'd have optimized the wrong thing for a week without it.

The copy-versus-undo decision is worth dwelling on, because it's a genuine engineering trade-off. Copying the board is simpler and less bug-prone — every node gets a clean, independent state. Make/undo is faster but demands that undo be flawless, which, as the bug section showed, is where bugs breed. I chose speed and paid for it in debugging. On a bigger project I might have started with copy for correctness and switched to undo only where profiling justified it. Knowing when to trade simplicity for speed is a judgment call, and this project gave me real reps at making it.

Testing Everything

Here's a claim I'll defend: testing game logic is genuinely harder than testing CRUD endpoints, and it's where I grew the most as an engineer.

Testing a CRUD endpoint is mostly mechanical. POST this, expect a 201, check the row exists. The space of behaviors is small and the correct answer is obvious.

Testing chess is different, because "correct" is a maze of interacting rules. My test suite ended up covering:

• Unit tests — does a bishop on an empty board generate exactly the diagonal moves?
• Edge cases — en passant only on the immediately following move; promotion into each piece type; castling with every precondition individually violated.
• Position tests — set up a known board, count the legal moves, compare to the known-correct number. (Chess programmers call this perft testing, and it's brutal at catching move-generation bugs.)
• Regression tests — every bug above became a permanent test so it could never come back quietly.
• Stress tests — let the engine play thousands of moves against itself and assert the board never enters an impossible state.
• Manual testing — actually playing it, which caught the "castling through check" bug no unit test had.

@Test
void enPassantOnlyAvailableImmediately() {
    Board board = Board.fromFen("... a black pawn just moved two squares ...");
    List<Move> moves = board.legalMoves(WHITE);
    assertTrue(moves.stream().anyMatch(Move::isEnPassant));

    // make an unrelated move for both sides, then the window should close
    board.make(someQuietMove());
    board.make(anotherQuietMove());
    assertFalse(board.legalMoves(WHITE).stream().anyMatch(Move::isEnPassant));
}

@Test
void knightInCornerHasExactlyTwoMoves() {
    Board board = Board.empty();
    board.place(new Knight(WHITE), Square.of("a1"));
    assertEquals(2, board.legalMoves(WHITE).size());
}

Position counting was the technique that saved me. If the known number of legal moves from a position is exactly N and my engine says N+3, I have a move-generation bug — probably an illegal move slipping through. It's a single number that validates a mountain of logic at once. I've never had a testing signal that clean in a web app.

What This Project Taught Me

I'll skip the platitudes and give you the specific things that changed.

• Thinking recursively became natural. Before this, recursion was something I understood in theory and avoided in practice. After writing minimax and check-detection, recursive reasoning stopped being scary and started being a tool I reach for.
• Problem decomposition got real. "Build a chess engine" is overwhelming. "Make a bishop generate diagonal moves" is a Tuesday. Learning to slice an intimidating problem into boring, testable pieces is maybe the most transferable skill I gained.
• Debugging patience. Some of these bugs took days. I learned to form a hypothesis, isolate variables, and resist the urge to change five things at once. That patience shows up in my day job now.
• Clean code stopped being aesthetic and became practical. When your logic is this interlocking, a muddy design causes bugs. Clear class boundaries weren't about looking professional — they were about being able to reason at all.
• Performance intuition. I now instinctively think about allocation, recursion cost, and profiling before optimizing, instead of guessing.
• Object-oriented design finally clicked. Not from a tutorial — from a problem that genuinely needed it.

Skills gained

None of that came from wiring a form to a table.

Would I Recommend It?

Honestly? It depends who's asking, and I'd be doing you a disservice to pretend it's for everyone.

Build a chess engine if you:

• Already have the basics of a language down and want to stretch rather than review
• Enjoy algorithmic problems and don't need an immediate practical payoff
• Want a portfolio project that starts real technical conversations in interviews
• Are okay being frustrated for days at a time

Maybe skip it (for now) if you:

• Are brand new to programming — build a couple of small apps first, genuinely
• Need a project that demonstrates web/backend skills for a specific job
• Get demoralized by long debugging sessions with no visible progress

Realistic prerequisites: comfort with functions, classes, arrays, and basic recursion. You don't need to be a strong chess player — I'm mediocre at the game — but you need to know the rules cold, because you're about to encode every one of them.

Realistic expectations: your engine will not be strong. Mine plays like a decent club beginner who occasionally sees something clever and occasionally hangs its queen. That's completely fine. The strength of the engine was never the point. The engineering you do to get any working engine is the point.

If I Started Again

I learned enough building this that I can see, clearly, what I'd do differently. I want to be upfront: these are things I'd add next, not things my engine already does. No pretending.

• Bitboards. I represented the board as an 8x8 array of objects. Serious engines use 64-bit integers (bitboards) where each bit is a square. Move generation becomes bitwise operations and gets dramatically faster. I understand them now; I'd use them from the start.
• A cleaner architecture from day one. I'd draw the piece/board boundary correctly before writing code, having learned the hard way.
• Transposition tables. The same position often arises via different move orders. Caching evaluated positions in a hash table avoids re-searching them. I skipped this entirely.
• Iterative deepening. Instead of searching to a fixed depth, search depth 1, then 2, then 3, using each result to order moves for the next. Better time control and better pruning.
• A stronger testing harness up front. I bolted tests on reactively. I'd build perft testing before the move generator, not after.
• A better GUI. Mine was functional and ugly. Fine for learning, not for showing off.
• UCI protocol support. The Universal Chess Interface is the standard protocol chess engines speak. Supporting it would let my engine plug into real chess GUIs and even play against established engines like Stockfish — not to beat them (it wouldn't come close), but to test and analyze against a known-strong reference. That's a future project, and I'm looking forward to it.

That list is really a map of everything this project revealed I didn't know existed when I started. That's the sign of a good learning project — it hands you a bigger map, not a finished journey.

Frequently Asked Questions

Is building a chess engine a good portfolio project for a software engineer?

It's an excellent project if your goal is to demonstrate engineering thinking rather than web or backend plumbing. A chess engine forces you to work with real algorithms, careful state management and genuinely hard debugging, which gives you a lot to talk about in interviews. It's a weaker choice if you specifically need to show REST APIs, databases and deployment for a web role. For most people, one strong chess engine plus a couple of practical web apps is a stronger portfolio than five CRUD apps alone.

Why choose Java to build a chess engine instead of Python?

Java suits a chess engine because the domain is naturally object-oriented and the compiler catches a lot of the interlocking mistakes before you run the code. Strong typing, a clear class structure, the collections framework and JIT-compiled performance all help when you're searching millions of positions. Python is faster to prototype and perfectly capable, but Java's discipline pays off in a project where a single sloppy shortcut can corrupt your entire board state.

What is the minimax algorithm and how does alpha-beta pruning improve it?

Minimax explores the game as a tree of possible moves, assuming you try to maximise your score while your opponent tries to minimise it, then picks the move that leads to the best guaranteed outcome. Alpha-beta pruning is an optimisation that gives the same answer while examining far fewer positions: it tracks the best result each side can already guarantee and stops exploring a branch as soon as it proves that branch can never be chosen. In practice, adding alpha-beta pruning let my engine search deeper and faster with only a few extra lines of code.

What are the hardest bugs when building a chess engine?

The hardest bugs cluster around move legality and board state. Kings moving into check, castling through an attacked square, infinite recursion when checking whether a square is attacked, undo logic that forgets the captured piece, and shallow board copies where pieces are shared between positions are all classic traps. Most of them come from the same root cause: not cleanly separating pseudo-legal moves from legal moves, and not restoring the complete previous state when you undo a move.

What prerequisites do I need before building a chess engine?

You need to be comfortable with functions, classes, arrays and basic recursion in your chosen language, and you need to know the rules of chess thoroughly, because you'll be encoding every one of them including castling, en passant and promotion. You don't need to be a strong chess player. It also helps to be prepared for long debugging sessions, since a lot of the value of the project comes from working through problems that don't have a ready-made answer online.

Will a self-built chess engine be able to beat strong engines like Stockfish?

No, and that shouldn't be the goal. A first hand-built engine typically plays at a modest level, making a reasonable move most of the time and occasionally blundering. Strong open-source engines are the product of many years of specialised work using techniques like bitboards, transposition tables and highly tuned evaluation. The value of building your own engine is the engineering you learn along the way, not the playing strength you reach.

Conclusion

Here's what I keep coming back to.

The chess engine will never go in an app store. It has no users. As a "portfolio project," it's arguably worse than a polished CRUD app, because a recruiter can't click a live demo and immediately get it. By every conventional metric of building-something-to-show-people, it was the wrong choice.

And it was still the best thing I've built.

Because the value was never the artifact. The value was every hour I spent staring at a board state that shouldn't have been possible, forming a theory, testing it, being wrong, and trying again. It was the moment infinite recursion finally made sense. It was watching alpha-beta pruning do the same work in a fraction of the time and actually understanding why. It was the specific, hard-won intuition you can only get from problems that don't have a Stack Overflow answer waiting.

CRUD apps taught me to assemble known parts. The chess engine taught me to think when there were no known parts — to decompose something genuinely hard into pieces small enough to reason about, and to sit with a problem past the point of comfort. That skill doesn't transfer from a tutorial. It transfers from a fight.

Building complex projects develops engineering intuition far more than endlessly repeating CRUD applications. The struggle is the curriculum.

So if you've built your third or fourth CRUD app and you feel that quiet plateau — that suspicion that you're getting faster without getting better — take it as a signal. Pick a project that scares you a little. A chess engine, a small interpreter, a physics simulation, a tiny database. Something where the difficulty lives in your code and can't be Googled away in one search.

You'll be frustrated. You'll be stuck. You'll rewrite things you were proud of. And on the other side of that struggle, you won't just have a project. You'll have a way of thinking that no amount of wiring forms to tables could ever give you. Build the hard thing. That's where the engineer actually shows up.