My Big Fat Scary Pull Request
Getting things right the twelfth time around.
SAN FRANCISCO, CA — A hopeful 20-year-old college student walks into a new office and sits down with his MacBook at the kitchen table. Why does this table look like a bowling alley? He meets and greets the people who will be his coworkers for the next three months, wondering how he’ll fare amongst the talent in the room. Christ, that’s him, that’s the Bootstrap guy!
Landing
I was hopeful. I knew an awesome opportunity had come up, and I was super proud of myself for taking it on. It had been my first time flying alone, and my first time being so far away from family. A sheltered boy in a big new city, hoping to advance as an engineer and become a better human, I was terrified. Thank heavens I was greeted with a big smile and a “Hi you must be Jordan!” or else I may’ve fainted right then and there.
After some thorough orientation and getting my environment set up — none of that “wait two weeks for your login credentials” business — I got a chance to meet my new mentor (and by the end I had two!) and started working. First agenda item, tooltips.
Yes, tooltips
This is not an article about tooltips, but rather an article on what it’s like for a junior-junior engineer to try and craft web experiences with a world class team. At times it can be intimidating, remedied by the helpfulness and encouraging attitude of my coworkers — a group of individuals without whom I would’ve been stuck in the quicksand. Why do they waste their time helping a newbie like me?
“Tooltip” is almost a funny word around here now, because of the events that followed. See, the general idea behind tooltips is pretty straightforward: you hover over an element and a box points at it, great. The interesting thing is how far you run with this concept: the nuances in behavior, edge cases, and extensibility. Combine that with a junior-junior engineer swimming through a huge codebase and you end up with the following:
And now for a close-up, in case you missed it:
79 comments. Each one along the lines of “What if you tried doing X instead of Y?” or “Try refactoring this logic into Z.” There’s nothing wrong with the code review process, it’s just thorough. The project was planned and scoped well, it was just executed poorly, and for this junior-junior engineer, it was a humbling experience to say the least. “Rite of passage,” I heard, jokingly, but it was the truth.
Am I ever going to be able to ship code at this company? Will every pull request blow up like this one?
Well, one future pull request had a similar number of comments, and another nearly double. But, in time, the numbers started decreasing. I was working more quickly, and I could see my progress in real-time. I thought about the number 79 for a while, though.
These figures are a testament to the attention to detail in our software, and they can be frustrating. I just wasn’t used to such strict code review, but if you’re looking for a good learning experience, look no further. The power is in the details, and I was fortunate enough to learn all the little development tricks that fall between textbook chapters and StackOverflow answers. This team was pro, plain and simple, and I often found myself muttering the phrase “Welcome to the NFL” every time one of them dropped knowledge on my partially-developed intern brain.
The cool part of all of this is that I still shipped those tooltips. Yes, it took two weeks and hours upon hours of facing my mistakes, but I ended up with the quality library that suited our needs much better than off-the-shelf alternatives. The quality of that ship (and the dozens of other ships!) is something I’m extremely proud of.
More than just programming
I learned that being a programmer involves a lot more than code. It sounds cliché, but I never really felt it until I was exposed to this work environment. You can learn all the syntax you want (and I learned a lot of syntax), but prioritizing your work, communicating with others, and surfacing concerns are all incredibly important skills that lie outside of your favorite text editor.
My big fat scary pull request taught me exactly this. I could use all the knowledge from countless 4AM code binges, but that merge button would remain untouched until I could switch gears and interact with others: asking for help when I needed it, and trying to communicate my thought process with those reviewing my code.
It was a good wake-up call.
So what did I learn?
A lot, actually. Code reviews are where you learn (since your mistakes are pointed out pretty clearly), and because the process was so thorough, many of those concepts stuck with me. The second time around, when I worked on something similar, I successfully applied many of the concepts I picked up during code review. Those skills are transferrable, too, and will follow me into future projects. The feedback loop was a total success.
I’m incredibly fortunate to have learned so much from a rock-star team, including things originally so far out of my knowledge base that I can’t actually remember how I worked before. I have evolved as an engineer, keeping up with the professionals and dropping some knowledge of my own. That nervous kid at the bowling alley kitchen table has come a long way.
Above all, I was exposed to these concepts in a neat little package — one big scary pull request.
