My Biggest Failures as a Developer
If an alien race of honest beings chose to study humans, they would eventually take note of the energy we consume to protect our pride. How many times have you chosen to twist, hide, or otherwise fabricate the facts to protect your fragile psyche? One of the most common fibs we tell ourselves is also among the most harmful: when we fail at something new, we assume we are incapable of doing this new thing. We lie to protect our esteem, the same esteem that assumes one must be a genius to compose music, a giant to play basketball, and a lab coat owner to do science…stuff.
This blog post will chip a crack into the dam you’ve built to prevent your passions from flooding the world — that was pretty bad, but let’s just agree to move on, okay? At Bloc, I mentored several Android and iOS students during their apprenticeship. Mentorship involved checking assignments, replying to written requests for help, and most importantly, one-on-one remote pair-programming sessions.
During these sessions, I discovered that the most valuable technique I could impart on my apprentice was acknowledging failure. When I couldn’t remember how to handle view rotation or forgot how to calculate overlapping areas, I immediately opened a browser window and began to Google. Watching me, then a developer with five years of experience, struggle to find the answer was more valuable than any line of code I ever helped them write.
If a few small failures can turn a single student around, then several large ones should help change the world, right? Here are a few of my epic failures — failures that fundamentally improved me.
If It Ain’t Broke…
During my first summer as a “coder,” I wrote an Android application named Notifi. It was a nifty app that let its users modify system settings, launch apps, and just a tad more from within any other application. Despite garnering approximately 50k downloads, I absolutely loathed it a year after its release. After gaining far more experience in Android development, I looked upon my previous work in disgust.
Among the early mistakes I made, one stuck out in particular. Android’s SharedPreferences are meant to track user settings, but I decided to shove an entire database in them. Not too shabby for a guy who didn’t know how to implement a SQLite database and more shockingly, had no clue what a database was. The next summer, I rewrote Notifi from scratch.
After months of work that included a full redesign, I was the proud father of Notifi 2.0. I released the update, smiled a thick grin and folded my arms behind my head to wait patiently for the praise I so rightly deserved. I didn’t have to wait long.
In their reviews, users admired the bravado it took to gather everything they loved about Notifi and toss it into a trash compactor. Notifi’s rating plummeted and the backlash I received from disgruntled users devastated me emotionally. As it turns out, building a much better version of something customers don’t want is still something customers don’t want.
Microhard
Upon graduation, Microsoft looked past my lack of software development experience and graciously flew me to Seattle for an interview. Their campus impressed me but their climate did not (sorry, Seattleites). The weather put me into a foul mood that followed me into each interview like an embarrassing strip of toilet paper beneath my foot.
Here I was, interviewing at one of the world’s most prestigious software institutions and I was complaining about a light drizzle. I struggled with every question and my demeanor betrayed my true feelings. Needless to say, they offered to make me chief executive officer of the “Thanks, But No Thanks” department.
This isn’t as much a technical failure as it is a personal one. It is never a good idea to leave a bad impression or complain when presented an excellent opportunity. However, in bad there is good as well. I may have not wanted the job nor a relocation to the climate of my nightmares, but that should not have kept me from building rapport with industry peers.
How Do I How?
One thing young professionals fear is their inexperience betraying them. When I started working at Zynga, I felt I had to prove that I deserved to be there. At this point, I had no idea how HTTP requests worked so to describe my career as fragile is putting it delicately. For several months I pretended to know every aspect of my job, which meant I sweated… profusely.
At some point, I was asked to work on the aspect of Words with Friends that I feared most: the run loop. Until then, I kept three miles between myself and that portion of the codebase. But like a stupid teenager in a horror movie about a dark basement, eventually I would go to the dark basement. I was tasked with adding a new feature to the game and I had no clue where to begin. The game was written entirely in Java but to me it looked like Wingdings… actually no, Wingdings 2.
I struggled for weeks yet pretended that my deliverable was on schedule. Eventually, my team lead lifted the ornate dish tray cover made of half-truths to reveal the horrifyingly unfinished busy work I tried to pass off as a feature. Backed into a corner, I had no choice but to admit that after many attempts, I simply could not wrap my head around what I was doing. His reaction impacts my behavior to this day.
First, he told me that he also believed the game code was overly complex and poorly documented. That statement crashed over me like a wave of relief. And yet, the next thing he said was far more significant. He did not judge nor did he scold, he only asked that I speak up whenever I needed help. He reminded me that I was part of a team, not a lone wolf. He acknowledged my failure first, then my humanity. He did for me what I did for my apprentices, he showed me that no one was perfect, not even my betters.
Stanley Idesis edits curriculum at Bloc and occasionally falls flat on his face.
