I’ve been a developer for several years. Between freelancing, working at startups, and being an engineer for an established company, the most important thing I have to do to benefit me as a developer is work on personal programming projects.
It opened my mind up creatively and congenially in ways that never would have been possible in any other way.
I didn’t get into programming to analyze meaningless data for a Fortune 500. I got into programming to turn my ideas into reality and make the things I want to make. often we lose sight of that as we start taking jobs and climbing the corporate engineering ladder.
So how do you think about your problems effectively and how do you improve?
So let’s say you have some kind of problem. What do most people do, they just start writing code, especially beginners. They just start writing code and they try and see if something works, if something doesn’t work, they just write more code, and print more stuff. But they’re thinking about the program very, very linearly. It’s this one thing.
So, let’s say you have to make, I’m gonna use a simple example, let’s say you have to make a Tic-Tac-Toe game. If they have to make a Tic-Tac-Toe game, they’ll just start writing it and they will think of everything as just one thing. So this includes, you know, they’ll think of the diagonals and the columns and the rows and all that as one thing and they start coding something up. But, what you need to do before you start on a project like that is, use frickin’ whiteboard.
Whiteboards are awesome, so get a whiteboard if you don’t have one, invest in one, it’s one of the best investments you can make. But, if you don’t have a whiteboard just use a piece of paper or something, okay?
But you want to think about this problem and coding is thinking and I feel that sometimes people forget that. When they’re following tutorials, they’re just typing stuff and following along, they’re not actually, actively thinking. When they are trying to solve a problem, they’re just typing stuff, running it in the terminal, and see if it works. But, if you wanna go about solving a problem you need to think about it. So, if I have to solve a problem like the Tic-Tac-Toe, right? I’m gonna be thinking about it, I’m gonna break it up into different components. So Tic-Tac-Toe, first of all, Tic-Tac-Toe I have to come up with a representation of the grid, of the board. So first I’m gonna be like, okay, first, the thing I’m gonna have to do is create a board, right? A three-by-three board. So you know, that might be like this type of board, okay? And whatever, for now, I’m just gonna have all X’s in there or all zeroes or ones, doesn’t matter. But first I have to represent this, this is my first problem.
Then my second thing is that how do you detect a win? So I need to be able to detect a win. So what are some ways you can detect a win? Well, okay. I can detect a win based on rows, so if you have all three in a row you can win, right? And you have to check consecutively. Then I have to detect a win on the columns and then I have to detect win on the diagonals. So that means that I’m gonna create like a function and I’ll have one function that’ll just be called like check rows. Pretty simple, right? So I’ll write one function and all that functions job is to check the rows. That’s it.
So what I’m doing is I’m taking this giant problem and breaking it into its component parts. Taking this giant problem. It’s almost like how do you eat an elephant? How do you eat an elephant? You eat an elephant very slowly in one bite at a time and over the course of days, weeks and months. I never ate elephant but I assume that’s how you eat one. Probably can’t eat one in one sitting.
Most people code like they’re trying to eat the elephant in one sitting. It’s not gonna happen. You have to break it down. You have to understand all of the component problems that one problem has, right? It’s a layer of problems. So I want to be able to check the rows, then I want to create a function called check columns, alright, and then I’ll create a function called check diags. So now I’ll have three different functions. One function can check a row and tell you whether there’s a win, somebody has won or not. Then we have a function called check columns and that can detect if somebody has won on the columns or not, then we can have check diags that can check if somebody’s won on the diagonal or not. And then we can have something called check win, alright? So we have all these functions. The check win function, well all this can be, it can just be comprised of all three of these functions, right? Because you can just run check win and then it will run check rows, check columns, check diags, and it will run all three of these functions until it finds a win, alright?
So right now we’re just trying to think at a high level. We’re not trying to get too bogged down in the coding details of how it’s gonna work, what data structure we’re using, we’re trying not to think about all those things. We’re just trying to think at a high level of this problem and try to solve it in these basic components.
Eventually you’ll have this to-do-list and then all you do then, then the part is easy, you write code, you do research, you figure out technically, but now you have a big goal of what you actually need to do. Because otherwise most of the people, you know, are coding blindly. I have all these functions that can tell me if a win took place, right? And then I have functions that can determine a loss, we can have a function that can detect whose turn it is. Or whether it’s nobody’s turn, right? So we need some states as well, for this board. We need to have a state where it tells us whether the game is still playing so for example, we can have a still in play or we can have a state that says you know, game over, so I’m meaning somebody won. So what this would do is if we have a while loop, right?
And we’re running this game over and over and over again, then it would be in this state, it would always check if the game is still in play, but if the game is not still in playand somebody has won and somebody has connected all three in their rows, columns, and diags, it will change the state of the game to game over. And then it’ll stop the game, right? And then a new game might start after that.
The point is not to solve this Tic-Tac-Toe problem right here, right now, but my point is to get you to actually think at a higher level about your coding problems. You need to break them down into components and in the start it’s gonna require you to understand it in English or whatever language is you know, your mother tongue, but first you’re gonna actually need to understand the problem in English and be able to describe it, visually have it somewhere, then you need to break it down into its component parts and know exactly what you need to do.
So first I will say understand in English. Two, break it down, okay, So you want to break the problem down into its component parts, that way you know exactly what it is you need to do and then you have a plan of action. So after this once you’ve broken it down, you know, you have a plan of action. And then it’s simply about what order you want to do this in, what it’s gonna be. Are you gonna make check rows first, are you gonna make check win first? Are you gonna make check diags first? Or are you gonna make 3-D board representation first? So it all is gonna be about you know, what your plan of action is, and then once you get inside of a function, that’s when you start needing to worry about what data structure you’ll be using, how you’ll be actually making it happen.
The point is your not going to be able to truly adopt a problem solvers mindset without activly solving problems which is impossible without actually building projects.
I’ve known developers that used to spend all their free hours working on personal projects but as they’ve gotten better and gotten a stable job they stopped. I encourage everyone not to do that just because your stepping back does not mean your moving forward . Life is not a zero sum game and neighter is programming.
Solving problems and building projects will give you undendiable experience that cannot just be crafted in a classroom.
You can also build projects you are genuinely passionate about. Programming at its core is boring to put it simply. Its tedious, nuaratic, and often leaves me confused and with a migraine; But I love it because it gives me the power to build things I want to build.
For example, when I was in middle school I used HTML canvas 5 to make stupid video games to play in the summer.
When I started high school I built python program to cheat on my pre-calculus homework.
When my grandma went blind I made a haptic device that uses AI to help her go to the grocery store.
The point is no matter how good of a programmer I became (and I still got a long ass way to go), I always stayed true to the principle of building projects and trying to solve problems and I always will.
Enjoy the journey, and keep building!
