The Repository of Mistakes, Successes, and Everything In-Between

On a cold and bitter February afternoon, a computer programmer’s worst nightmare ensued: all git commands stopped functioning.

I unleashed my best freak-out face: >:0

Time was running out while I tried to figure out how to fix it. For my senior capstone, my teammates and I are creating a web-based game using Phaser 3’s framework to create an educational experience on how to fight wildfires. But I needed to push last-minute updates to the game’s codebase. And Git was not cooperating.

At the time, I used WebStorm, a Javascript and Typescript IDE, to edit the code, which comes with a lot of bells and whistles, including built-in Git functionality. But one day, these tools stopped working. So I switched to using the built-in terminal, but no matter how many branches or clones I made, I was blocked at every turn.

An Unpopular Opinion to Navigate

To make matters worse, GitHub and I have a horrible relationship. It’s embarrassing! I avoided learning git commands for years. Ever since my first computer science course, everyone always told me how amazing using GitHub was, whether they were decades-long professionals or first-year college students. What a bunch of bologna!

Eh. The user interface on GitHub’s website was difficult for me to navigate, and for the longest time, I didn’t realize that manually downloading and uploading updated code to GitHub wasn’t ‘normal.’ Or at least, not the best way to use it. And I didn’t understand what the terminology meant. It felt I was being told to ‘branch’ and ‘fork’ when I didn’t want to. Magic forks are weird! And magic branches feel like ‘Alice in Wonderland,’ and that story always made me feel uncomfortable (the cat freaked me out, and I’m a huge cat person, so that was disturbing). Worse, I didn’t understand what happened after calling those commands in the terminal.

But there’s no way I’m the only computer programmer in the world experiencing these issues!

This is why I want to show you what I appreciate about GitHub now, and a new technology I’m using that helped me understand GitHub at a deeper level, and makes navigating the steps more fun.

The Basic Commands

Based on my understanding thus far, which is very limited, this is the most simple workflow to use when making changes to a GitHub repository.

git clone # make a copy of the repository
git branch # create a new place to store a copy
git checkout # enter that copy
git pull origin main # merge latest code to branch

…make code edits…

git add –all # put changes in a queue (staging)
git commit -m “what you changed” # attach a message to changes
git push origin # upload code changes to main

These are commands that have helped me the most in navigating the crazy web of Git. But given that it’s easy to make mistakes and get lost, GitHub’s documentation is a good starting place, and more understandable after already learning the commands I talked about above.

What I appreciate now about GitHub is that once you understand how a few different steps work, I feel like I’m more in control with how to update different versions of code. I guess since it’s ‘version control,’ that’s appropriate.

But it did take me a while to get to that point. And although using tools with bells and whistles is convenient, sometimes they obfuscate the process. So when something breaks, it’s really hard to know what went wrong. More confusion leads to more frustration, and it can surprisingly waste a lot of time.

I ended up finding a technology that technically still has downloadable bells and whistles, but they do make managing versions not only easier to understand, but demonstrate the process, and make it clear which steps need to occur in order. Surprisingly, it was with a very common free IDE.

I’ll explain.

A Visual Solution

I downloaded Visual Studio Code and downloaded the following extensions:

• GitHub Pull Requests by GitHub
  Why? To review and manage GitHub Pull Requests! This is very useful when working on a team repository.
• GitHub Repositories by GitHub
  Why? To quickly browse, search, edit, and commit to any remote GitHub repository from inside the IDE!
• Azure Repose By Microsoft
  Why? To open and browse repos quickly from any version. Cloning without this can result in working with out-of-date code, especially if the main repository is regularly updated often.
• Remote Repositories by Microsoft
  Why? This one integrates with the GitHub Repositories and Azure Repos extensions. Disabling this extension makes all these extensions (except GitHub Pull Requests) inactive, so I believe it’s to tie them together.

Let’s explore how all these extensions function together. First, I clicked on the Remote Explorer button that looks like a desktop icon in the IDE. Then I clicked the + sign to add a new remote repository.

Which opened up a beautiful window at the top of the window that let me sign into GitHub and open a repository! My team’s is named fire-sim.

Notice that there are options to open pull requests too! These are extremely helpful to look at all the revisions. In my opinion, it feels clunky to use GitHub’s default UI.

Here is an example of what editing a pull request might look like with these extensions in Visual Studio Code. Note the extra ‘pull request icon’ at the bottom of the left sidebar, and how easy it is to see the old code vs. the new changes being requested to merge into main:

But that’s a side point. The biggest feature I want to demonstrate is how to make a new branch after adding a remote repository.

So, when you first open a repository, the codebase opens up. However, in order to make changes on a new branch and make a pull request later, an extra step is required.

I clicked on the ‘bug’ icon on the left side of the sidebar. This is normally the ‘Run and Debug’ button. Then, I clicked Continue Working On….

This allowed me to choose a new option that says, “Clone Repository Locally and Open on Desktop.” I get to choose a folder to save the code copy in. This opens up an entire new window, and when I open the terminal, I’m already navigated to the copy.

And this is the time to run all the code commands I wish! To add a new branch, I run the following commands:

Now in my IDE, I can make code changes in this beautiful setup.

After saving changes to each code file (eg. Ctrl+S or CMD+S), the IDE automatically detects changes and notifies you to make a commit via the Source Control button!

A new file opens that lets me write a comment, and then once I save (eg. Ctrl+S or CMD+S), and exit that file, I can push the code.

I can also make a commit and push the code through the terminal if I don’t like the GUI version. This kind of freedom is exactly what I was looking for, and might be the key to saving my love-hate relationship with GitHub.

I hope this article helps any other programmers enjoy version control a little more too!

Code can smell really bad when it’s left out in the open. In the last six years, the biggest thing I learned about smelly code is that others than smell it too. So if code isn’t readable, organized, or built with safety in mind, it affects teammates trying to make it better. Thus, making code clean isn’t just a personal matter – but can make or break a team’s success.

This is much easier said than done, and in my experience so far, code smells are very easy to forget about, especially for personal projects. Organized code used to fall at the bottom of my priority list, especially when on a tight deadline. But when I started presenting my code and sharing it with others, having clean, organized code made the interaction more professional, engaging, and effective, since others can understand it and hence, care about it.

Who cares if my code smells?

On this topic, in the first chapter of Robert Martin’s book, Clean Code: A Handbook of Agile Software Craftsmanship, one of my favorite quotes is from Bjarne Stroustrup, the inventor of C++ and author of The C++ Programming Language.

“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.“

A lesson I learned from this is the art of elegancy. Designing code in this way makes it enjoyable for the reader, easier to improve the codebase, and enhances efficiency. One of the best advantages to developing software is speed. However, just because the software works, doesn’t mean it can be improved easily past the alpha stage. But if the code is already clean, then I feel like the team’s ability to advance the project faster and stronger is more likely.

Another problem with smelly code is that it can be so unrecognizable that it’s difficult to learn. I remember one of my earliest programming projects where I needed to complete a Yahtzee game, and the conditionals and functions became such a big web that I just about broke down and had to take a break (true story).

A really good lesson I wish I learned earlier on is how to make functions shorter. In chapter three of Refactoring: Improving the Design of Existing Code, Martin Fowler writes:

“Since the early days of programming, people have realized that the longer a function is, the more difficult it is to understand. Older languages carried an overhead in subroutine calls, which deterred people from small functions. Modern languages have pretty much eliminated that overhead for in-process calls. There is still overhead for the reader of the code because you have to switch context to see what the function does.”

I strongly believe focusing on making functions shorter is the biggest key to designing a program well. On another note, switching context to see what each function of my Yahtzee program did is definitely something I do not recommend (lol). Long functions used to be the bulk of my program. Worse, it made the program difficult to understand and debug, making it impossible to complete the assignment in time. And was I proud of it? Not even the slightest.

But with practice, reprioritization, and learning from advice from reputable resources noted earlier, there is hope for smelly code.

Practice makes perfect, er, de’code’orant

Currently, one thing I would like to start doing more often is making functions shorter. In the past, I assumed that talented programmers can handle reading long lines of code… but that kind of mindset just makes everyone’s lives more difficult (including my own). By making functions shorter, the code is more readable and easy to understand.

A good example of this is how my team and I formatted our app.js file in our fire simulator game this year. Below is a screenshot on the file that configures all the settings of our game correctly using Phaser, an HTML 5 game framework.

Notice how each block of code is short with steps that describe what the code does. The file itself can probably serve as a singular function.

However, deep in the FireSpread.js file, I implemented a feature that allows users to extinguish fires using the water icon. I was short on time and new to the methods that were required, so this the slimy spaghetti that resulted:

Even though there are some comments explaining the output of the program, it’s unclear why each line is integral. This function also does more than light fire – it creates an animated object, generates the frames for it, plays the animation, makes the fire clickable, includes an event that detects when and how the fire sprite is clicked, and deletes the fire sprite when clicked. As you can see… that is some smelly code!

In the future, I want to avoid repeating this type of mess for each feature. Even though being feature-focused will be important for the current sprint, being elegant-focused will allow features to be easier to add, especially if every function in the program is readable and reusable.

Before I return to my computer to put some de’code’orant on this code smell, one thing to always remember from here on out: embracing elegance leads to embracing what matters.