14 Nov 2015
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
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.
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
branch=`git rev-parse --abbrev-ref HEAD`
git push origin $branch
Another addition to
git is aliases that you place in your
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.
12 Sep 2015
Recently I have been enjoying some great books from the San Francisco Public Library. Even with great weather, plenty of work, and new people to meet I still enjoy finding time to read a good book. Here are a couple of my favorites that I have recently finished.
Flash Boys by Michael Lewis
A great book about high frequency trading and the heart breaking story of Sergey Aleynikov a programmer for Goldman Sachs that was arrested for stealing code. The controversial trial was supposedly over open source improvements made by Aleynikov. It was also great to read about the technology used by small trading startups and large banks. How the startup firms could create code that was always faster and better than the large banks.
How We Got to Now by Steven Johnson
An interesting read on six critical inventions shaped the world. One of Steven's thesis was the fact that no one invention is solely created by one person. He describes this as the Hummingbird Effect- how one invention is really built from previous advances over time. Many of the inventions we take for granted in this modern time such as light, cold (air conditioning, ice), and cleanliness were all huge inventions that shaped the world we see today.
Catch-22 by Joseph Heller
The only fiction I have read in awhile came from recommendation by quite a few people. The story takes place during World War II following a Air Force Bombardier named Yossarian. Yossarian does anything in his power to stay alive and most people in his unit seem to think that makes him crazy. The entire book has a very dark sense of humor that makes the book a great read.
The Innovators by Walter Isaacson
My latest read is another book about inventions changing our world. This book is filled with innovators and hackers that have created much of our digital world. Without these innovators I would not have had my job, without these innovators I don't know what my hobbies would include because without these inventors we wouldn't have the computer or smart phones.
04 Apr 2015
Nearly a hundred times had I gone through the app and tested this one feature, the Android Contacts app. The second I pressed it the emulator froze, my heart skipped a beat. My palms were already sweaty from presenting in front of so many people. Laura looked at me and knew something was wrong, I closed the app, waited a second and attempted the button click once more.
It froze once again, for another 30 seconds before Contacts crashed. I had no idea how to fix this, an error that we could never had imagined happened during the worst time.
In 2011 I signed up for my first Bronco Appathon with a friend. Little did I know how much this would have an impact on my future. This friend would become my roommate for the next three years, I would fall in love with the entire mobile development field and ultimately pursue it as a career.
My first Appathon was started with humble beginnings, a small list of links that freshman of Boise State could visit to learn more about the school. Various links were all over the Boise State Website. Our app was the one place where you could figure out the gym hours and the cafeteria hours. It was a big deal for us, just figuring out how to build the Android app was a challenge. We finished it and drew the short straw to present first. We had no idea what to expect, this was our first Appathon, and it was the first Appathon ever. We did not do well with the judges but it was the first time building an app and it would not be the last.
The second Appathon I signed up for in 2012 we decided that we needed a bigger idea. We had more development experience, more people, and we were confident that we would do better than in the past. We brain stormed some ideas and came up with the app Health Walk. It would track your movements using a pedometer and graph that against the calorie intake of food you entered into the app. We ran into technical difficulties in our over ambitious idea and were unable to present because we could not get the Android app to run.
The third Appathon we were determined to do better than the two before. We had a new team, a new idea, and we decided that we needed something more than just engineers, we needed a graphic designer. This graphic designer would help us create branding, create a color scheme, and make our app the real deal.
After working the entire weekend we created Localize which we dubbed as "A local social network". We were extremely excited about our idea and it paid off when we got a great buzz and reception by the audience and the judges. We walked away with third place and best design. I also walked away with the desire to win, I had one last Appathon, and I wanted to go out with a bang.
Suggest was our attempt to fix annoying group messages by suggesting an activity to friends by filling who, what, when, where and why. We believe that every action starts with a suggestion and our app Suggest allows you to do that.
Keeping plans simple with Suggest will promote more meaningful activities between people.
The team was gathered together weeks before the Appathon began and this year we chose to have one graphic designer (Laura), one entrepreneur (Jackson), and two developers (Hank and I). This gave the team great balance, but it cut the number of developers in half then a majority of the teams.
Hank and I decided as a team to write for the Android operating system as we both have more experience in this development area. We used an Amazon Web Services EC2 server with a MySql database and a tomcat web server for our API.
I first started with writing the database tables and writing the API service for Suggest. This took me longer than I would have liked, almost a whole 24 hours went into writing the back end. Once I was finished with the back end Hank was making tons of progress on the front end and I needed to start to connect the pieces.
At about 2 AM on Sunday (about 10 hours until presentation) Hank and I looked at each other and knew we needed to make major progress to be ready to present. We created a priority to do list with five items on it and then we started to grind out code. We checked off the first three items before 4AM, with only two more to go we were looking good. By 6AM (about 5 hours until presentation) when we started to practice our presentation we had a nice MVP of Suggest.
We practiced Suggest's presentation for more than an hour, it was the most important part we had learned in three years of previous Appathons. We had the best presentation I had seen in all three of my Appathon years and I was very excited to show the judges what we had come up with.
Our team name was called, we walked up, and started the well rehearsed presentation. The first use case brought us to the first crash. The Android emulator I was using must had been corrupted some how because the second I clicked on the Contacts app it started to freeze and eventually crashed. It was embarrassing, but it was not a show stopper. I killed the Suggest app and tried once again to run through our use case. The Contacts app responded the same with a crash.
I started to grow very nervous as the crowd reacted to our app looking extremely buggy. Luckily one of the judges said, "Murphy's Law! It's OK!" I restarted the emulator completely and was able to run through our use case. I knew it looked bad, but I was hoping that somehow we could show Suggest's true potential.
Presenting an app that you had slaved over for 72 hours straight with only a couple hours of sleep was stressful. It was more than stressful, it was down right absurd, but for our team it was what we decided to do for the weekend.
We watched other teams present and I grew nervous as the competition was growing. The judges announced that Suggest won second place! I was ecstatic, all our hard work had paid off big time.
I thank the Bronco Appathon judges, contestants, and organizers for without the Appathon I would not be the developer I am today.
24 Feb 2015
"We become what we behold. We shape our tools, and thereafter our tools shape us."
Choosing the right tool is one of the most important tools when starting a project. Adjusting that tool to work best for your needs is arguably more important.
Here are a list of my changes to Intellij/Android Studio default key map.
I will continue to update this list as they change.
- Find Usages
^ + F - This is one of my most common tools used and I like the ability to call it quickly.
- Editor Tabs -> Close
⌘ + W - I cannot get over that this isn't the default
- Run in Intellij
^ + R
- Make Project
⇧ + ⌘ + M - Quick makes are nice to see any compiler errors
22 Feb 2015
The Bronco Appathon is coming up in a couple of weeks. This is my fourth year in a row participating in this extra curricular event. In short the Appathon is a weekend coding competition to deliver a functioning mobile app at the end of the weekend.
Every year I am lucky enough to be able to work with some extraordinary individuals to build something. Each Appathon without doubt, I get to work with someone new or improve relationships with existing colleagues. I find myself looking for some qualities in a person when working with them in a exciting, stressful, and intense environment as the Appathon.
con·fi·dence \ˈkän-fə-dən(t)s, -ˌden(t)s\
a feeling or belief that you can do something well or succeed at something
The first thing I look for is confidence. When a person can say something confidently, explain their side and really stick up for their opinion, I seem to be able to work better with them. If they are wishy washy with what they say I have a hard time thinking they believe in an idea. I admire when someone is confident and wrong. If they stick to their guns and really, truly believe in an idea you can really see their true colors.
a strong feeling of enthusiasm or excitement for something or about doing something
Passion for an idea, a technology, or just passion in doing things right is something I also look for. If the team is filled with people who are passionate they will be current with new technologies in that space. They will provide an in depth knowledge of their passion on the spot. The passion will enable them to deliver a product that is so much closer to the customer's solution than someone with no drive for the idea.
gen·er·al·ist \ˈjen-rə-list, ˈje-nə-\
a person who knows something about a lot of subjects
Lastly, I look for is one of the most important qualities of a team member on a small team with a time crunch. Being a generalist does not mean you know a little about a lot. It means you know a lot, but more importantly, know how to learn on the fly quickly. Being a generalist does not mean you know the entire iOS Operating System, but knowing how to read the documentation and come up with a solution to a problem. Someone who can wear two different hats and enjoys it.
Last year with a great team of Chris, Darrel, Hank and I were able to build a great app called Localize.
The most important part of our team was how great we were able to work together. The Bronco Appathon 4 brings a new team, new ideas and another great product.