Two Hour Change Leads to Three More Years.

A short time ago I was applying for jobs at a select few software companies. As an applicant, I tried to determine which company would not only allow for internal improvement in coding and self, but also an environment which I could actively influence. Many might find it appealing enough to fit inside of a software giant, knowing that their efforts will be individual drops in an ocean of vague progress. However, the idea of planting myself inside a seed, knowing that future potential is directly related to the amount and direction of my own efforts – that idea was too good to pass up.

Not that Wealthfront is just a seed. My very first day I saw like-minded persons all around, focused, welcoming, and working toward a common goal. This goal is to make smart investing easier and more affordable than it has ever been before. While we are constantly improving the ease, effectiveness, and affordability of investment, the number of potential investors will rise. This means that anyone of age can join Wealthfront. On a Sunday afternoon someone could stumble upon our site and become an investor with money in the market within that week, as long as they are at least twenty-one years old.

Well, actually, that last requirement is a bit outdated.

After we presented investment strategies to a college-aged group of could-be investors, they asked us why we required our users to be twenty-one. And what a fair point. I’ve often found that when your best answer to a question is, ‘because that’s how it is’, you might want to reconsider. Wealthfront seemed to believe the same, as the new requirement was created.

It was only halfway through my second week in the office and I was tasked with changing code all the way from our Rails frontend to the Java backend. This assignment alone shows two of Wealthfront’s qualities quite clearly: freedom and foundation. There is an implicit freedom in the technologies and projects our engineers can work on: if there is interest, there is opportunity. Our foundation, our system of checks and balances, provides us with confidence that code will be executed properly so there is no danger in giving important tasks to new engineers. A fully test driven environment not only lets us engineers rest easy at night, but it’s also empowering in everyday coding knowing that the incremental changes you are making aren’t destroying the website. As someone who found TDD relatively recently, I can assuredly say this: testing is good, you want testing in your coding life.

So what did this change actually entail? Well, I hopped into our code base and started looking for all the various ways the number 21 could be represented. There were quite a few of them, actually. After narrowing down all the files that dealt with age, I had some pretty standard changes to make. The age of a client is requested in a couple different flows. The first is on the sign up questionnaire (we wouldn’t want someone to get too far into our signup flow only to be told they weren’t old enough to ride) and the second is in the signup form when we ask for the user’s birthday. For both of these submissions we have Javascript validations and for the signup form we have Rails validations. Below are some examples of this code.


After changing the JavaScript/Rails validators and validation messages, I looked at the tests. One message that has been relayed to me through word and action is that Wealthfront rewards risk and ownership of those risks. When I saw the tests surrounding our age validations, I noticed that the tests weren’t properly testing the edges of our validations. With a large codebase, there will always be areas that are weaker than others. A great way to make code consistently strong is to reinforce weaker parts when they are spotted. I didn’t ask for permission to change this code, I used my best judgement with the notion in mind that with risk comes reward. Below we have our old Capybara tests. For those of you unacquainted with Capybara, it is a Rails testing framework that allows the code to remotely control the browser; luckily it hasn’t grown sentient yet.

Two things about the above tests struck me. The first is that our test was growing older due to the fact that we gave it a constant birthday. The second is that they are missing some ‘.should’s, which might explain why they passed so freely. Instead of validating an age that would grow to become older than twenty-one / eighteen (thus invalidating the tests), I changed them to use the current date as a reference point. In this way, our tests are always using a person of the same age, even when the date changes (it happens more than you think). So our ‘should be false’ test used the current date minus seventeen years whereas our ‘should be true’ test used the current date minus eighteen years. We also subtract a day just in case it is a leap year, a forward-thinking co-worker pointed that one out. The result is shown below.

One could look at the changes I made and say that the actual number of code edits are small. That’s true; they are. The whole process, in fact, was painless and accomplished in less than two hours (including pull request reviews). However, improvements small in scope should be small in effort to implement. Yet, software often violates this principle, because small changes are inherently risky and difficult to scope due to lack of test coverage and the high cost of change. So, this small change means small code by our deliberate construction, and not by inherent problem complexity.

After running all our Rspec specs, having the pull request reviewed by four peers, and knowing that the build wouldn’t automatically be deployed if there are any issues in Capybara, I merged with ease. If there were to be some issue, our system would notify us; we’d fix the bug, write more tests, and achieve an even tighter codebase.

On my eleventh day of work, I opened up Wealthfront to three more years of possible investors in a couple of hours. That is the pace of Wealthfront, and I hope to keep that pace for my entire coding life.