GBGames

As a child, I consumed information around me. When I discovered a topic existed, such as the Pacific Theater of World War II or how to create your own pop-up books, I wanted to learn everything about it. I read books, watched the History Channel back when they actually showed history (oh, the History Channel is this generations’ MTV, isn’t it?), asked questions, and pretty much did whatever I could to feed my passion for learning.

As I got older, I found I had to be more selective with my attention. I had more demands on my time. I couldn’t immerse myself in a single topic unless it was for school or work.

Or at least, I felt that way.

I have friends, grown-up friends, who I can say are still passionate about things I used to love. A few of them geek out when NASA or the ESA publicize their latest successful missions. Another loves all things dinosaurs.

And I realize how much I have missed about being passionate about a topic to the point of becoming an amateur scientist or historian.

The cool thing? I can immerse myself in something now, and I’m old enough to understand it a lot more than when I was a child. And we know so much more today than we did just 10 or 20 years ago, so there’s more to learn.

And even cooler, we’re still learning. We now know what Pluto looks like, and soon we’ll know more about the makeup of Jupiter. We found a regaliceratops in Canada last month when we didn’t even know it existed before.

Do you wish you knew more about theatre? About movie-making? About the lives of authors? How to start a business? Weigh-lifting and nutrition? Sustainable gardening? Game design and development?

Did you ever wonder what was in the ocean, whether here on Earth or on Neptune? Or have you ever thought about how thinking actually works?

And did you ignore the curiosity, or did you let it lead you to answers and more questions?

Yesterday at the day job, a coworker and I were discussing coding challenges. He was talking about how he came across one that, even though he knows how he would approach it, it would still be fun to do.

He said at one point, “I’ve never actually written a program to solve Sudoku.”

Another coworker chimed in to say, “Yeah, but you know you could write one.”

First coworker: “True, but while I know I could, I never have.”

And they went back and forth for a bit, with one arguing that he’s more interested in tackling the unsolved problems of the world rather than work on problems he knows he can solve.

I thought about his position, and I have concluded that he’s wrong.

I agree with the desire to work on something worthwhile. Writing your own Sudoku solver when others already exist isn’t likely to result in any significant, lasting impact. Solving engineering problems such as aiming NASA’s New Horizons at Pluto accurately over the course of almost a decade? That’s gratifying work.

But there’s a difference between knowing you could write a “Hello, World” program and being able to say you’ve done it, and it’s not just about bragging rights.

Here’s a “Hello, World” in C++ that took me a mere moment to write just now:

#include <iostream>

int main()
{
   std::cout << "Hello, World!" << std::endl;
   return 0;
}

I’m confident I don’t need to run it through a compiler to make sure I wrote it correctly. I write C++ code often enough that something this simple usually works just fine the first time, although feel free to tell me I made a mistake if you spot one.

But it wasn’t always this easy for me. Before I wrote code regularly, I’d make mistakes that would seem boneheaded to me today.

For instance, I might forget to include the iostream header in the first place. Coming from a QBasic background, where PRINT was a built-in command, it was odd to have to include a separate header to do something so basic as output text.

Another example is forgetting which way the streaming operators go for output versus input. << or >>? When I wasn’t writing code daily, I would have a hard time writing new code that used cin or cout because of this issue.

I had no idea there was a need to flush the output when I first started coding in C++, so I might leave off the std::endl, probably because I didn’t know it existed at first. I would wonder why my program wouldn’t spit out the text I expected to see, or why only part of the text seemed to make it and the rest was missing.

And of course, I might accidentally forget a semicolon or two.

That’s a lot of potential mistakes for a “Hello, World” program, and I am sure I ran into every single one and possibly more.

Before I was considered an expert C++ programmer, I could argue that I know how to write a “Hello, World” program. In general, that is. I knew the trick was to use some command to output a specific string, just like most programming languages.

Boooooooriiiiing! I’m above this. I want to do something more interesting!

I remember feeling this way, but I also remember the feeling the first time I tried to read some source code I found on the Internet. I couldn’t follow it! Everything was more complicated than it needed to be, and they used “advanced” things such as std::vector.

It was around this time that I found a good C++ book and followed the exercises in the chapters. I used to skip them because I thought, “Yeah, I get the gist.”

But actually doing the work helped me internalize the lessons. I didn’t have a vague, general understanding of the code. I KNEW the code.

It’s like the difference between being told about a majestic view of the mountains are and seeing it for yourself. One is story, and the other is experience.

“Hello, World” is pretty easy to master, but writing the code to handle input correctly and spit out appropriate output builds upon the knowledge you have for doing this easy work. And the new code will have its own common pitfalls that experts don’t run into anymore but that trip people up when they first encounter it. Did your stream try to convert the user’s input into an integer and fail? Are you handling this situation correctly?

Yeah, you might get the general idea and know you COULD write the code, but until you do, you don’t get to claim expertise in writing such code. Knowing the mechanics of diving isn’t the same as knowing how to dive. Knowing how to use color to simulate shadows and lighting doesn’t mean you know how to paint a bowl of fruit.

I would love to be involved in a worthwhile, complex, never-before-solved project, but it’s hard to demonstrate competence when I’m struggling with common mistakes in the solved problems.

You have to put in the work. Until then, you’re untested.