DEV Community

BendyLand
BendyLand

Posted on • Updated on

Nothing to it, but to do it

(This post was written as part of an assignment for the Computer Science Career Path from Codecademy.com)

If you told me a week ago that the hardest part of finishing an assignment for Codecademy would be to write about it for complete strangers online...

I probably would've believed you.

So let's give it a try!

The Background

I've been coding for a little over a year now casually, but a few months ago, when I learned that I would not be returning to my job for the following year, I decided it might be a good opportunity to jump into a new field. Lots and lots of thinking and planning and gathering materials and information later, and now I'm finally starting to work through it all.

Right now, I am mainly using Codecademy's more guided paths (I am currently on the CS career path), since I know that I would benefit from the added handholding at the beginning. This was my way of attempting to fill in the gaps in my knowledge (since I was mainly self-taught), but it turns out I should really give myself more credit if it's due. I should have realized that when a course says it is "beginner friendly", it really means beginner friendly.

Getting Started

As I started working, I quickly realized that to get the most out of this learning, I was going to have to consciously keep track of the time I spend on the projects. I usually tend to do one of two things: I'll either speed through everything and make a ton of mistakes just for the sake of moving onto the next thing, or I will do the complete opposite, and refuse to move on from a project until it is exactly the way I want it.

My new objective was clear, but still somehow ambiguous. I've settled on saying that I need to spend a good amount of time on my work (but not too much!). I especially need to push past the urge to fly through everything and submit the first fully working solution I find; but I also need to stop myself from getting caught in an endless loop of debugging and optimizing.

Am I putting too much thought into it? Who knows? I'm sure most people would probably say to stop talking about it and just write some code, so let's take a look at some.

Take me to the GitHub page!

First of all, what did I make? Well, the task was to build a terminal game using Python and version control with Git, then write a blog post about it (I really wasn't expecting that part, but here we are). It actually caught me so off guard to see the blog post requirement that I decided to dedicate the title to my long-standing and fairly severe fear of public eyes. I joked about it at the start, but it was a joke very much based on reality. All right, tangent over. Back to the project!

I decided on a Connect-Four style game, since I thought it would be a pretty straightforward task. This was a little more tame, since this project had the most open ended directions, where I could use whatever methods I wanted; but to be honest, I put way more effort into the project before it (since it was a topic I was less comfortable with), so I think I might've actually just gotten lazy with this one. (You can find the GitHub page for the previous project here.)

The Project

A portion of code visible at the top of a text editor and a connect four game running in a terminal at the bottom

The program itself is very straightforward; at the top it prompts the users for a name and sets the global variables (I know I know, global bad; but again, trying to find a good balance between rushing through and getting caught in "paralysis by analysis" as an old music professor of mine called it). The game board is stored in lists, and when a player selects the column they want to place a piece in, a loop iterates through the rows to find the lowest option that hasn't been played, and changes the placeholder to the current player token before toggling the global variables.

All of the game logic is contained in three functions: display_board, play_round, and check_win. This is another area that I feel could have been improved with a bit more time and nitpicking. This is especially true for the check_win function, which is just plain cumbersome, and should probably make use of some smaller or higher order functions; not to mention I had a little help from Professor GPT for the diagonal checks after spending more than double the time on it that I wanted to. Again, coming back to, "I probably could've solved it myself, but that would've taken disproportionately longer and would've been much messier, so to save time I'll have a robot do it cleanly now and I'll just tidy it up to make sure it works then go back to analyze the structure myself later".

All that said, I'm not too concerned with the code. I know that it could be better, but I also know that it could be worse. I know that there are people out there who would've written it better, but I also know that there are people who would've written it worse. I'm happy with it as is, for being in the beginning stages of my structured learning. This was more about finding an approach that keeps me happy (something that wasn't always guaranteed at my old job), seeing how well I could balance my time, and getting over my huge fear of being seen (even if it's only by a name online). I'm sure I won't win the "race to senior dev" with that attitude, but I'll bet that I will be happier and have more fun. That's good enough for me, at least for now ☺️

Top comments (0)