Reflections of a new developer

I started at Expensify in the beginning of August, on nearly the three month anniversary of working at my first full time position I took some time to reflect on what I have learned. I have boiled my thoughts down to three crucial aspects of my job that I have learned so far.

Find the right tool for the job and use it

Search

In small projects for school that you wrote from scratch you knew the entire project. You knew the organization of the code, because you wrote the code. Once projects became larger at school with other team members it was still easy to poke around the code because the projects were not huge. In my experience it's impossible to poke around code bases that are in the wild. The scale of projects will leave you feeling lost and confused if you do not learn how to use search.

Not only will learning how to use grep prove useful, but using search in individual files has proved to be important. Even when classes are organized into smaller files, you can still feel lost in new areas of the code.

Time savers

When you start to use your tools you may notice rough edges, things that aren't as fast or elegant as you'd like. One command that I found myself running multiple times a day was git push origin andrew_feature. A quick function you can place in your ~/.bash_profile to speed up this is a push() utility.

function push(){
    branch=`git rev-parse --abbrev-ref HEAD`
    git push origin $branch
}

Another addition to git is aliases that you place in your ~/.gitconfig file.

[alias]
    co = checkout
    cb = checkout -b
    rh = reset hard HEAD
    ss = stash save
    sp = stash pop

It may seem like typing is git co not much shorter than git checkout, but overtime these aliases and sharpening of your tools will save you tons of time.

Everything is connected

In smaller projects it is easy to abstract out logic into their own places. When projects become larger and more complex it becomes increasingly hard to have them not be connected. This becomes a problem when fixing bugs in a program that you are not familiar with all aspects of the code base. Fixing one bug may create three new bugs in different places of the code. As a new programmer this can be extremely discouraging, finding a fix to a bug and then realizing you've created a few more in the process. Testing your fix and using search to find other parts of the code that access your new code can help finding this before it becomes a problem.

Get an version one working

Adding a new feature can seem daunting at first, it can seem almost impossible. One thing I have learned is to get a small version working first with hacked, ugly, and slow code. Just make it work and call it version one. Once you have a version one working, iterate over the version one to make it faster and more beautiful. Don't be afraid of something that seems hard and get worked up about the minor details. Make the code run in O(n^2) time. Make it so hacky you feel uncomfortable committing it. But most importantly make sure it works. Once you have it working start thinking about optimizations and refactoring to improve it.