Introduction

I recently completed my first 30-day coding challenge over on GitHub.

I wanted to change careers, get into software development.

While I already had some experience with coding from my previous education, I was out of practice and needed to see great improvement in a short span of time.

I had also been badly neglecting my GitHub over the years, and while I could have dug through my old university laptop for old projects to upload, I decided to start completely from scratch.

Here are five lessons I learned during the last 30 days.

Lesson 1 - What to Code?

To develop and code.

There's over a dozen different types of software development and I'd given myself a short enough time frame to improve, only thirty days. Learning them all within such a small time-frame was unlikely even with the best learning plan in the world.

And I'd also decided to start learning with a clean slate, so I couldn't even look at old projects for ideas.

I needed to decide on what kind of software development I wanted to pursue before actually getting started with any new projects.

And with that, it would determine other factors like:

The tech stack I would need to learn to use.
What certificates I should focus on, if any, to earn.
The budget I would need to pursue larger projects.
Any other additional software or platform I would need to learn to help polish my work and showcase it.
How much time it was going to take to reach basic competency for that branch of software development.

In the end, I decided to base my decision on learning to make something I already knew I enjoyed as a consumer.

Video games.

By narrowing the scope of my task to video game development, I was able to answer the questions above and could rule out the majority of the tools I would need to spend time installing on my laptop to get started.

Lesson 2- Daily Routine

Consistency over quantity.

Early on, I pushed myself to try to do many things all at once in my learning, and simply put, it wasn't sustainable.

A key part of maintaining my thirty-day streak came down to setting myself the much smaller goal of five minutes a day to sit at my laptop and just work on something.

What I could do in those five minutes was:

Open up my laptop and VSCode.
Open my GitHub.
Look at my folders for something to work on.
Edit my personal README.md on my profile or upload something I had completed the day before to GitHub.
Decide if I wanted to continue when the five minutes were up.

It was a lot easier to promise myself those five minutes over trying to mentally prep for two to five hours of code everyday and ultimately telling myself I couldn't do it.

Lesson 3-Resources

Finding learning materials.

I need to clarify that I'm not an expert in self-learning, and I'm not here to promote self-driven learning over attending a workshop, taking a certified course, or getting a degree if that's what you prefer.

When I started, I wanted to avoid ending up with expensive equipment or books I might not use if I changed my mind during my thirty-day journey on what I wanted to learn. So I looked at my options, ranging from free to as low cost as possible.

Here are the most useful learning materials and sources I found:

My local public library. They may not have everything you need right away, but you can request books, use the computers, and explore for ideas. They offer much more than just books, and it's a great way to take a break from coding and get out of the house between development sessions. You can also order what you need online once you have a library card and account set up.
YouTube Tutorials. The quality can vary based on the channel and creator, but YouTube remains a great place to learn in 2024. Most content is free, though you will have to watch a few ads.

From my own experience, I recommend sticking to content that is frequently updated or created in the past year. This ensures you have the most relevant software installed to follow along. There are exceptions, but the less time you spend worrying about version releases and editor settings, the faster you can progress.
freeCodeCamp deserves a mention because, as the name suggests, it's completely free and aimed at independent learners who want to start coding or improve in a specific area of programming. They explain it much better on their website, but for the past few weeks, I have been following their curriculum to help myself relearn how to code. What's great about the courses is that not only do you get a shiny certificate to show off on your LinkedIn profile upon completing a section, but you also create your own portfolio pieces as part of your learning.
Humble Bundle is another excellent website for finding books and software courses if you want to learn a specific skill without spending a lot of money. When you buy a bundle, you also donate to a sponsored charity and can choose the amount you want to give for each bundle.

While the website may not always have exactly what you're looking for, as their content can range from coding to woodworking to animation and back again, I have found most of their bundles to be a great way to discover new tools and books I might not have found otherwise.

Lesson 4-Learning Godot.

There's a lot more than just code involved.

There are many Game Engines available online, each with its own learning curve, supported languages, and hardware recommendations.

At the time of writing this, I am using Godot 4.2.2 on Linux, which is completely free to use under the MIT License .

I'd never used Godot or made a game before. There wasn't a helpful button anywhere in my editor labeled "Make Game" that would automatically create the game of my dreams for me when I opened it up for the first time.

Godot also has it's own native language called GDScript that I had never used before and a unique node-based system I'd never seen anywhere else, where each node in it with it's own unique behaviors and constraints.

I decided to follow Brackey's tutorial for Godot to see if I could understand what I would need to do to develop my own 2D games. I managed to finish the tutorial, and the project is viewable here on GitHub.

I still haven't made my own game as I write this, but it gave me a better understanding of what I should look for when making my own games.

Some elements that go into making a good game:

Storytelling: Even without a narrator or pop-up text boxes, you still need to tell players the basics, like controls, combat, and their end goal. It doesn't have to be the most detailed exposition, but the idea is to convey what the game is about.
Assets: Aesthetics aren't everything in life, but good artwork can make even the simplest game more fun if they're eye-catching. I enjoyed working with sprite sheets while completing the tutorial project on Godot. Also, games don't feel right without background noises, the sounds of coins being picked up, enemies hitting you, etc.
Level Design: This is separate from storytelling or the assets used in a game to make it look and sound pretty. Creating obstacles, rewards, and a world that provides just enough challenge to be fun without causing frustration or boredom is harder than you would think when designing layout. The fun part of this aspect is you get to play test what you build and share it with friends, get feedback and make things better. Increasing and decreasing the difficulty of stages as you go along.

So the biggest takeaway with learning a new game Engine was what makes a good game is not always down to the code within it.

Lesson 5-Repositories.

Finished is better than perfect.

Keeping projects or code private is something I always use to do, even as a student, to the point of not wanting to upload to GitHub in-case someone else saw my work and hating it.

But being shy about what repositories and code I have wasn't a good way to show I was learning. It's also not the best way to grab the average recruiters attention online.

I added GitHub Stats to my personal README.md. Which does still track uploads and commits to private repositories for your GitHub streak but won't show the languages within them unless they're public.

Without showing the languages I am working with or the code I'm was trying to develop, I would be leaving everyone else, including potential recruiters, in the dark about my actual progress and my career interests.

I'm not saying I'll be posting about every tutorial I finish online, every challenge completed and every certificate earned.

But to get the most out of the 30 day of code, I had to accept even my messiest attempts should still be viewable publicly on my GitHub.

Worrying about polishing off works-in-progress takes away time to learn and do other things and actually make progress.

Conclusion

What comes next?

After finishing my 30-day challenge, I can argue that I have relearned how to code. But I could stand to get a whole lot better at it and software development as a whole.

I plan to continue my current streak to reach 60 days on GitHub.

I also plan to keep updating this blog throughout my journey.

I still have a lot to learn, and if I want to make my own games, it will take more than just learning code to achieve that and reach my dream of becoming a game developer.

The key is to just keep going and see where the journey takes me.

What I Learned from 30 Days of Coding

Table of contents