Author: Taylor Kuno

Transitioning to an internship has been exciting and intimidating in many ways, but knowing my code is contributing to a living product might be the most intimidating part. The company I work makes a suite of electronic medical record products for groups like EMTs and Fire Departments. So needless to say, errors and breaks can be costly! The code base is humongous. While I knew that real software suites would be large, it has still been a bit of an adjustment. I looked at my local repo for work today and it has 63,000 files and growing. I am sure this is not even in the largest tier of software code bases, but still, my small school projects hardly even begin to compare in complexity. The thought that the three files I just created are getting dropped into this ocean of code is a bit terrifying. I have never been so nervous typing into a terminal as I have been when committing and pushing code in this new role. Don’t even get me started with merge conflicts.

GitHub is one of those tools that simultaneously feels simple and complicated all at the same time.

It’s funny how something created to help preserve working builds build is actually one of the tools that freaks me out the most. Talking with classmates and reading posts on Reddit shows that I am not the only one intimidated by this beast. So then, how do we approach it?

I have tried worked with GitHub through IDE extensions, GitHub desktop, Git Bash and the online tools that it offers. There are definitely some user interfaces out there that ease some of the deer-in-the-headlights feeling that could come from starting at a blank line in Git Bash, but is the trade off worth it? While clicking clearly labeled buttons is nice, I have found that I ultimately enjoy the Git Bash command line more. User gyroda’s response to a similar question on Reddit resonated with my experience. There is something about using the command line that has reinforced my understanding of Git version control more than I ever had been able to with the UI.

In this case, I think choosing to dig into the more manual approach provides a more tactile way to learn version control. In a GUI, it’s hard to try to do something “wrong”. And while this may sound like a good thing, I think it can rob you of important learning. In Git Bash you can type in any command at any time whether or not it makes sense for the context. When it comes down to it, typing in incorrect commands and receiving error messages back has probably taught me more about git than any of my successful bash commands. Even in the tech industry, relying on automation or software to perform tasks introduce the problem of abstracting the task at hand so much that you lose the deeper understanding of what you are actually doing.

If you are like me and feel intimidated enough by git to want to avoid learning it, I encourage you to check out gyroda’s response. They lay out a beginner friendly approach to learning git. Git is an amazing tool that I have only begun to scratch the surface of, but it has become a staple in both my career and hobby coding projects.

Ironically, I found that a setting was incorrect on my keypress counts so I have a huge update for my Undo stats.

import current_stats from 'failure_stats.py'
import datetime

current_stats(datetime.today())

Output: 
# Undos as of today: 2014
# Deletes as of today: 1597
# Backspaces as of today: 22113

My very first car was a blue stick-shift Chevy S-10.

I don’t know how many of you have ever learned how to drive a manual transmission, but it’s as frustrating as it is enjoyable, at least for a beginner. If you don’t coordinate shifting with releasing the clutch perfectly, then your engine completely stops and you have to restart your car.

Lately I have been feeling that I am “stalling out” while coding. I will be cruising along, finishing up different tasks and pushing code frequently when all of the sudden I get stopped in my tracks by something I don’t understand or get lost in a frustratingly simple bug. Damn you curly braces!

These roadblocks are particularly common in my internship where my role is to help transition an old code base into a new framework. Specifically, I am migrating the old Java/Kotlin architecture to a new JavaScript/React framework. The product I am working on is an electronic medical record best suited for EMTs, fire departments and police forces. Needless to say, the code base is enormous with both a web and mobile suite. Not to mention hardware integration for different medical devices and handling sensitive health information. Going from a code base of less than 20 files to one with 1000+ files makes me dizzy. And being a part of such a large and important piece of software is definitely intimidating!

Though stressful, beginning programming in the commercial world has been just as rewarding as learning how to drive a stick-shift. By far there have been more good experiences than bad ones. And just like learning to drive, the more time I put it, the easier and more natural it becomes.

import current_stats from 'failure_stats.py'
import datetime

current_stats(datetime.today())

Output: 
# Undos as of today: 2014
# Deletes as of today: 1597
# Backspaces as of today: 22113

Cut yourself some slack. Invest in yourself. You are smart enough to make it through this program and onto the other side.

import current_stats from 'failure_stats.py'
import datetime

current_stats(datetime.today())

Output: 
# Undos as of today: 2014
# Deletes as of today: 1597
# Backspaces as of today: 22113