How drawing a chess board became my greatest coding lesson
Tags: webdev, programming, productivity, opensource
Published: 2024-06-11 10:35:16

his blog was originally published on Substack. Subscribe to ‘Letters to New Coders’ to receive free weekly posts.

Within a few weeks of starting my university computer science program, I hit a pretty demoralizing “coder’s block.”

This hiccup was agonizing at the time — but ended up giving me one of the biggest lessons I learned in my coding career. I’m sharing this lesson today in the hopes that it will save you some potential stress along your own journey.

## The chess board

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f0o8hwkcoz08xwcsbue3.png)

In one of my Intro to CS courses, we had been given an assignment to build a **chess or checkers board**: an 8x8 board of black and white squares.

At the time, I was working on what’s called a Disk Operating System (or DOS). This was a text-only window, with no graphics library to call upon. As I stared at the text on the screen, I couldn’t compute how to conjure a chess board.

The problem stumped me for over a week.

Eventually, I had a breakthrough — but only after I finally looked at the solution.

The breakthrough actually wasn’t about the solution itself (which, as it turned out, was under my nose the whole time). What I realized was that my real problem with the assignment was a crippling case of self-doubt.

Surprisingly, the self-doubt wasn’t even about my programming skills. It stemmed more from my insecurities with drawing.

I have always been terrible at drawing. (I’m so bad that my friends used to play Pictionary with me just to laugh at me — I’m not kidding). Since childhood, I had never been able to draw anything well, even a simple thing like a chess board.

If I couldn’t draw it myself, how was I supposed to be able to tell a computer to do it?

So I cheated a little bit, and I looked at the solution. And only after I looked at the solution could I see that the approach to solving the chess board problem was the same as solving any coding problem.

**The solution is to break the problem down into small steps.**

In this case, I had a big chess board that needed to be broken down into smaller segments. What shape is a chess board? It’s a large square… consisting of small squares.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d59pdsc0et6kngku830d.png)

All I needed to do was create a combination of alternating white and black squares. And because the DOS screen was black, the program technically didn’t need to print anything for the black squares.

So the solution was to alternate between two steps:

- Print a white square
- Skip a square (to create the illusion of a black square)
- …and so on
The answer was easy. Talking down my self-doubt was the hard part.

## Understanding the root of self-doubt

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pcrr86ccxutinnkbbeiy.png)

If you experience self-doubt as a new coder, you’re in good company.

**Self-doubt** affects many new developers. (Its close relative, Imposter Syndrome, affects even the most experienced developers, but that’s a topic for another day). Self-doubt is the usual culprit when you find yourself thinking you’re not “smart” or “good” enough for something.

If you peel off the layers to look underneath, you’ll probably find that you have very specific doubts about your ability to learn programming:

-Am I good enough at math?
-[Am I smart enough?](https://www.letterstocoders.com/p/3-things-id-do-differently-if-i-learned) (Which I debunked in my last post)
- Will I be able to get a job?
Etc.
(In the case of the chess board, it was, “Am I artistic enough?”)

Self-doubt has nothing to do with logic. It’s often rooted in past experiences and biases, which can lead to irrational or limiting beliefs. With the chess board, I believed my success relied on my artistic skills, rather than from leveraging the programming constructs I already had at my disposal.

It was only after I took a small step back that I was able to take a big step forward. It never hurts to take a pause to reassess the problem — and always do your best to challenge any underlying beliefs about your abilities.

## How to get unstuck
Getting stuck is not a bad thing. In fact, it’s an important part of the learning journey.

All it means is that you have encountered a knowledge gap, and are on the verge of a breakthrough.

If you’re coding and get stuck, here are some strategies that can help you:

Take a step back and reevaluate the problem
Break the problem up into its component parts
Try to spot any biases or limiting beliefs that might be inhibiting your progress
Look at the answer (yes, this can be a helpful strategy)

If self-doubt is the reason you’re stuck, it’s important to b**ecome aware** of it earlier rather than later.

Being able to identify the doubts holding you back can help you untie yourself from their bind. No matter what doubt is plaguing you, remember that your success in learning to code depends on one thing only: **committing and putting in the hard work**.

You can find tons of **beginner-friendly, interactive courses** and projects with Educative’s [Learn to Code platform](https://www.educative.io/learn-to-code?utm_campaign=learn_to_code&utm_source=devto&utm_medium=text&utm_content=&utm_term=&eid=5082902844932096). (And while you won’t find the chess problem, you can try your hand at similar logic puzzles with a free [Taste of Code](https://www.educative.io/path/learn-to-code-become-a-software-engineer?utm_campaign=learn_to_code&utm_source=devto&utm_medium=text&utm_content=&utm_term=&eid=5082902844932096)).

Happy learning!

– Fahim