by David Xiang
Somehow, a big fancy media company wanted to hire me to build their flagship mobile product. Opportunity was knocking. I took them up on their offer and started prepping for my first professional job as a mobile developer. I was employed alongside others to build native apps, on all platforms, for all devices. My job was to work on the iPad version of their newspaper app.
Even though I had no real understanding of what “doing it the right way” meant, I’m pretty sure that the company I worked for was doing it the wrong way. All due credit, though—here were media professionals stepping out of their comfort zone and building a technical product from scratch with no prior experience. Imagine your super-niche engineering research center creating a beautifully crafted newspaper filled with well-researched articles—much easier said than done.
Even though I had no real understanding of what “doing it the right way” meant, I’m pretty sure that the company I worked for was doing it the wrong way.
Everything starts with the hiring. Intuitively, they did the right thing—they hired senior staff first. Where might a media company go to source senior technologists? Their strategy was to jump on Amazon.com, search for the highest-rated technical books, and contact the authors. If you wrote a book about Apple’s iOS, you must be pretty good, right?
These were the early days of mobile development, when Apple’s documentation was somewhat lackluster. Developers writing about iOS frameworks were rare. Anyone who had any experience using these arcane libraries appeared invaluable.
For anyone who’s never developed on iOS before, they have a client-side persistence library called CoreData. In a nutshell, this is the ORM—object-relational mapping—for iOS. An ORM is an invaluable aid for any developer modeling out business logic. These libraries enable you to set up complex relationships between objects, allow for intuitive querying of information, and provide basic scaffolding to make sure your data persists properly. My company had found the CoreData guy through Amazon. He had written the highest-rated CoreData book, so he must have been one of the best. What could go possibly go wrong?
The publishers offered him an absurd amount of money to head up their new iOS team. I give this guy a lot of props—this is a prime example of a developer taking advantage of the trends. Unfortunately, knowing an iOS library inside out does not mean you have the skills to head up and run an entire engineering department.
With the senior staff installed, they moved to fill out the engineering department. The back-end had been contracted out, so they were looking to hire programmers purely for their Apple/iOS expertise. You don’t need that many people to develop a client-side application—two to four reasonably skilled developers can get the job done. Any more and there are way too many cooks in the kitchen. I believe we hired about thirty engineers to work on one single iOS application! The company’s mindset was, the more money we throw at this, the better it will be, and they had a lot of money. The hiring process was insane, but I’m not one to complain—they hired me, after all.
One day on the job, I got an email from an excited hiring manager saying she had just hired a new iOS developer. This developer was supposedly really talented and had even shown up to the interview with an impressive demo on his phone. In those days, not many people showed up to interviews with live portfolios, so naturally, I was also pretty excited. The hiring manager had taped the demo and was hyping it up—there were awesome graphics, cool physics, and some interactive gameplay. I checked out the footage and instantly recognized the app—I had built the same one! It was a template app from a popular online tutorial. The app showed a bunch of bouncing balls that you could interact with. There was nothing groundbreaking about it, just a stock physics engine, some fancy assets, and plug-and-play gesture recognizers.
These terms may sound fancy, but these features come straight out of the box these days—kind of like a steering wheel on a car. A physics engine can determine how a ball bounces with gravity, how two soccer players collide, or how water overflows out of a teapot. Gesture recognizers give you precise feedback signals when you pinch, drag, or swipe on the screen. In modern software, it’s just a matter of gluing things together—no one re-invents the wheel. Obviously, our non-technical hiring managers hadn’t known any better.
And this is how they filled out the engineering team. There was a deadline, a ton of money to be burned, and programmers to hire. This developer, who had been coding for less than six months, was able to land a full-time job—with a decent salary—off the back of a demo app from the Internet! When he showed up for work, it was immediately apparent that he had no idea what he was doing. Somehow, he floated around for the duration of the project; no one was ever quite sure what he was up to.
The project management was appalling. There were no code reviews of any kind. There was no development process. There were no branching or merging patterns with source control. Everything came down to raw Git commits, poorly resolved coding conflicts, and a lot of crashes in production. A few senior engineers tried their best to maintain sanity, but junior engineers were busy pumping out untested code while a set of floaters wandered around like headless chickens. Periodically, people would come by my desk and ask me—the 23-year-old entry-level developer—if there was anything they could work on.
Wherever you end up, train yourself to function independently, no matter how chaotic it may be.
After a year and a lot of Objective-C code, I began to really appreciate my CMU training. All those obscure coding labs and open-ended projects classes made this job seem like a cake-walk. I was already accustomed to digging my way out of darkness to reach lofty ten-thousand-foot-high goals. However, this unstructured environment paralyzed many of my colleagues. Hand-holding curriculums and online tutorials had not prepared them for this. For anyone transitioning from academia to industry, do not underestimate how drastically different the environment can be; you might unknowingly be stepping into a zoo of code. There’s nothing you can do about the environment, but there’s always something you can do about your reaction. Wherever you end up, train yourself to function independently, no matter how chaotic it may be.
Despite the insanity, the company eventually managed to ship product. Somehow, thirty engineers committing directly to the Master Branch still managed to create something that was seen by millions of people. Unfortunately, our apps eventually flopped and are now resting in peace in the app graveyard.
18: Respect Every Position [Daily Life]
My friend Tammy is back. After re-inventing herself post-graduation, she found an amazing group of people at a food startup. Unfortunately, startups go through some bad apples. One of the bigger apples was Tammy’s ex-CTO. A common characteristic of developers is to undervalue the importance of other departments. Too often, I’ve seen egotistical programmers who think their code runs the show. These are dangerous sentiments and can kill any working environment.
Earlier in my career, I worked under an unpleasant CTO who gained a reputation for making our employees cry. I was working at an early startup that had recently promoted an engineer with the emotional intelligence of a brick into the highest ranking technical position in the company. What ensued was tough to stomach. I don’t have any positive memories about that individual, but his actions highlight the countless ways a developer should not act.
During my first couple of months on the job, one of my colleagues from customer service brought a fresh customer complaint to our CTO. It was a startup, so funds were limited and everyone shared the same space in an open plan office. This meant zero privacy—all conversations were public. The first time the service rep came by with the complaint, she was met with a curt, abrupt response from the CTO:
“They’re not using the site properly. Link them to the documentation.”
This is a classic engineering response to any problem. Unfortunately, it’s not very helpful for someone dealing with a customer. The interaction didn’t sit well with me. Is this guy really brushing this off that easily?
Fast-forward a couple days, and the same rep kept coming back with more complaints from different customers about the same issue. Obviously, there was a problem. To my surprise, our CTO was still not giving her the time of day! I was starting to get frustrated, but I was two months into the job and not ready to tell our chief technologist how to behave. Finally, the fourth time around, he decided to take a closer look at the issue. Turned out the customer was using our website correctly; unsurprisingly, there was a bug in the code. Why wasn’t that his first instinct?
It was this interaction, and many more that followed, that convinced me this guy was a jerk. First, his lack of respect for the customer service representative was crystal clear. She was doing her job and didn’t need to be subjected to such demeaning, negative behavior. By the third time she had approached him about the problem, she’d started to tear up from the stress. Second, it showed a blatantly arrogant thought-process. A software bug was the last possibility. The most likely possibility in his mind was that the customer was not using the application properly. That ordering should have been reversed.
This CTO had been programming since he was practically in the womb; he got his first paying job at age 13. For over half his life, he had been getting paid to write code. Technically, I’m sure he was the best of the best. Unfortunately, being a prodigy coder doesn’t translate into becoming an effective leader. He was socially awkward and held on tight to an entitled persona of “I’m worth a lot”—a too-common trait among developers.
At a small startup, every single person’s job is crucial.
Our CTO had a toxic complex in which he believed that his position was more important than anyone else’s. This is where he went horribly wrong. At a small startup, every single person’s job is crucial. If the customer service representative stops answering phone calls, the company will fail. If the accountant stops sending out invoices, the company will fail. If the CEO stops traveling, people don’t get paid. As software developers, we must never think of ourselves as above any other roles or departments. The mentality should never be “I,” it should always be “only possible together.”
The above was an example of disrespect towards fellow employees, but our CTO also had a severe lack of respect for the company as a whole. During his brief tenure, he was working on a book about Redis. Redis is a popular open-source software that many people use to store data and speed up their applications. What’s important to note here is that Redis had absolutely nothing to do with our company. It’s a software tool we utilized, but it was not related whatsoever to the business, our product, or the company mission. It was purely a hobby, a side project for our CTO. But he used our system as a guinea pig to test out strange Redis experiments to include in his book!
This act was negatively disruptive to the company. By using the company’s projects as a testbed for Redis, he created insurmountable obscurity and unnecessary complexity for the team. No one else had any idea how our caching worked. This chokepoint slowed development down to a crawl. This behavior goes against all reasonable software development practice. When working with a team, it should be a priority to disseminate knowledge, increase transparency, enable developers to jump into different parts of the system, and avoid single points of failure. Doing experiments for a personal book does not fall into any of those categories.
We are human, and no one—on any level—is immune to dangerous personality habits.
Even though the CTO was a technical guru, he was an ill-fit for the role. In my career, I have seen countless engineers hold a similar, and similarly dangerous, sense of entitlement that ruins company cultures. This ranges from the developer who thinks he or she writes the best code, to the VP of Engineering who dictates how other departments interact with developers. We are human, and no one—on any level—is immune to dangerous personality habits.
19: The Blessing Of Grunt Work [Learning]
Grunt work is a blessing in disguise. For any level of development, there is a huge pile of mundane, inane, no-one-wants-to-do-it work. It will be dumped on top of you at some point in your career, most often when you’re the newest, most junior member of the team. This could be anything from six hours of pixel-pushing to a month’s worth of technical debt refactoring. It’s like picking up a bunch of rocks just so you can put them down someplace else. As an entry-level developer, you’ll be given an early dose of grunt work in some companies simply as a way of vetting you. This usually reduces to a slow sprinkle once you’ve proven your skills. Do not be discouraged; each of these mundane tasks is an invaluable seed for learning.
As an entry-level developer, you’ll be given an early dose of grunt work in some companies simply as a way of vetting you.
My first software internship was in the beautiful state of Colorado. I was responsible for porting installers across operating system platforms—one of the most prestigious tasks in any software company. For those too young to know about installers, there was a time long ago when you actually had to travel to a store in the real world to buy software. This is how software was once distributed—we didn’t always have the all-powerful cloud.
First, let’s get a frame of reference for installers. Think of installers as huge, complex, software state machines. What happens if they cancel the install at this step? Did we set up all the directory and file permissions properly? What if an older version is already installed? How do we update the registry? How do we clean up the registry? What if the disk is full mid-install? How do you uninstall?
Could we have a moment’s silence for developers everywhere? I was in fifth grade when I started playing Diablo. When I first installed the game, I couldn’t fathom what software was. I didn’t realize that there were developers—real life human beings—out there somewhere writing code so I could kill demons and drink mana potions. I certainly didn’t think about the fact that there were developers out there who wrote Diablo’s installer! I didn’t give it a second’s thought; I just watched the bar crawl all the way to one hundred percent with baited breath. But now here I was, a developer writing installer code. For every interface you touch, every button you see, and all the plumbing you don’t see, there are coders out there making sure it all works.
Initially, I was pretty bummed when presented with this project. It sounded excruciatingly boring. I thought I was in for an unproductive internship. Was I really going to put installer porting on my résumé? I wanted to work on real software. The company had already ported its application code over to Linux and all that was left to do was to package it all up. Unglamorous as it sounds, this project turned out to be one of my most rewarding experiences.
I gained invaluable knowledge that summer. Those three months developing installers laid the foundations for many of the skills that I use today. As a prerequisite for the project, I was forced to learn the ins and outs of Linux. I get nostalgic thinking about those days. I had to read about basic file permissions, learn about the obscurely named top-level directories, and struggle with configurations to get my source code to compile. That summer in Colorado was instrumental in my career.
The coding was a next-level exercise in attention to detail. Unless you’ve developed a ridiculously complicated state machine, not many people appreciate the many nuances and complexities of an install process. You have to update the registries properly. You need to set up the proper permissions across all the new files. You need to make sure all temporary directories are cleaned up. You need to ensure the software uninstalls and upgrades properly. Everything has to be triple-verified. It was a level of detail that I had never experienced before. If the software fails to install or update, you may as well tell the end user they should use somebody else’s app, because yours is broken. The devil is always in the details, and the details make us better developers.
Years later, history would repeat itself when I went through a similar situation as a full-time developer. I expected to get my first load of grunt work early and it came through the door on day one. My f
irst assignment was to revamp an old MAKE system and move it over to a then-shiny new Python software-building solution called Scons. If you have ever had the pleasure of using MAKE outside of homework, I’m sure you know that this task was no joke. That project single-handedly forced me to understand software building on a very deep level. It was another technical level-up for me and my career.
In software development, you’ll get one fun task for every ten mind-numbing ones.
In software development, you’ll get one fun task for every ten mind-numbing ones. If you’re working at a super small shop, you might be lucky enough to have only green pastures ahead of you, where you can cowboy around all day long. But for anyone working in a larger setting, there will be no shortage of mundane work waiting for you. You might be porting build systems or sifting through code that was written eight years ago. I urge you to take on these tasks eagerly. Don’t underestimate this kind of work—it might build the foundation for lifelong skills.
20: Lessons Learned [Career]
During my time at Qualcomm, I was part of a tight-knit, fresh-out-of-college group of engineers. We had been hired in new-graduate batches and quickly formed the kind of camaraderie that comes with the circumstance. After a few years of developing chipsets and getting used to Qualcomm’s product cycle, many of us started turning our heads in the direction of startups—the grass looked greener over in Silicon Valley. My friend Daniel was the first one of our group to take a leap of faith. He was leaving us, his fat stocks, that nice 401k, and all our comfy Qualcomm benefits to test the startup waters. Many of us, myself included, would follow in his footsteps. This is a small sample of Dan’s journey and is packed with valuable insights.