by David Xiang
Software Developer Life
Copyright © 2018 David Xiang. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except in the case of brief quotations embodied in critical articles and reviews, without the prior written permission of the publisher.
ISBN paperback: 978-1-7323459-0-4
ISBN ebook: 978-1-7323459-1-1
FIRST EDITION
To my father who has given me underrated career advice over the years and to my mother who got me through my first C class.
Contents
ACKNOWLEDGMENTS
0:INTRODUCTION
1:PEER-VS.-PEER [STORIES]
2:TECHNICAL FOUNDATION [LEARNING]
3:WRITING EMAILS [DAILY LIFE]
4:THE ANGRY GUY [CODING]
5:INTO THE DEEP [STORIES]
6:FIFTEEN MINUTES DICTATE A YEAR [CAREER]
7:THINK BEYOND THE TICKET [CODING]
8:CHOOSING YOUR WORDS [DAILY LIFE]
9:EMBRACE CONFUSION [LEARNING]
10:DIGGING YOURSELF OUT OF DEMOTIVATION CAREER]
11:SPEAKING AT MEETINGS [DAILY LIFE]
12:CODE SENSE [CODING]
13:DOES GOING TO A GOOD SCHOOL MATTER? [LEARNING]
14:CROSS-DISCIPLINARY ASSUMPTIONS [DAILY LIFE]
15:DOMINANT BEHAVIOR [CAREER]
16:FULL-STACK [LEARNING]
17:NON-TECHNICAL TRYING TO BE TECHNICAL [STORIES]
18:RESPECT EVERY POSITION [DAILY LIFE]
19:THE BLESSING OF GRUNT WORK [LEARNING]
20:LESSONS LEARNED [CAREER]
21:DIVA DEVELOPERS [DAILY LIFE]
22:LEVERAGE [DAILY LIFE]
23:THERE IS NO ONE-SIZE-FITS-ALL [LEARNING]
24:YOUR BOSS [CAREER]
25:UNDERSTAND WHAT YOU ARE DOING [CODING]
26:RED FLAGS WHEN YOU INTERVIEW [CAREER]
27:SETTING EXPECTATIONS CLEARLY [STORIES]
28:YOUR INITIATIVE [LEARNING]
29:THE QUICKEST WAY OUT [STORIES]
30:DURESS AND RATIONALIZATION [STORIES]
31:PLACES YOU CAN WORK [CAREER]
32:SIMPLICITY [CODING]
33:FEELING LEFT BEHIND [CAREER]
34:ALIGNING YOURSELF WITH A STARTUP [CAREER]
35:WHO DO WE NEED TO HIRE? [DAILY LIFE]
36:NOTHING IN THE GRAND SCHEME OF THINGS [DAILY LIFE]
37:STYLES AND MEDIUMS [LEARNING]
38:WATCH THE SIDE EFFECTS [CODING]
39:COMMUNICATION [CAREER]
40:WRAPPING IT UP
Acknowledgments
Thank you to all my friends who have shared their stories.
0: Introduction
We’ve made a dent into the 21st century and software has been eating the world. Suspenseful tech dramas play out in the news, boot camps churn out entry-level developers in a matter of months, and there’s even an HBO show dedicated to Silicon Valley. In the midst of these trends lies a severe lack of attention to the daily life of the developer—the day-to-day reality that surrounds each line of code. There are plenty of resources available to help the budding developer learn how to code, but what about everything else?
My name is Dave Xiang. I grew up in suburban Massachusetts. My extra time went into playing Starcraft and leveling up Everquest characters. My extra money went into playing Dance Dance Revolution at the local arcade. I majored in Electrical/Computer Engineering (ECE) at Carnegie Mellon (CMU), got a job straight out of college as a firmware developer, and transitioned into full software-mode a few years later. Though I am no veteran developer, I’ve been through the paces in my eight years as a professional and have held a number of distinct developer roles.
Let me give you some backstory. This all began with a video I uploaded to YouTube way back in 2013. Like every Millennial, I wanted to do something. It started off with an embarrassing vlog, a couple breakdancing demo reels, and then I uploaded a video explaining the basics of RAM. I didn’t think much of it at the time, but it was well received. The video didn’t go viral exactly, but it gave me an idea, a hint of potential.
A few years and a bunch of uploads later, and I’ve built a decent fan base of ~40K subscribers. My content reflects all that I’ve learned throughout my career, packing significant personal experiences into short, vlog-style videos. My aim was to create a space where people could come learn about new technologies and get a better understanding of life as a professional programmer. The many positive comments online I’ve received have kept me motivated.
I am not an illustrious coder—I haven’t created my own programming language, and I don’t have a white wizard’s beard. I’ve held a handful of cookie-cutter software jobs and have a knack for story-telling. As such, this book aims to help students, new professionals, and anyone looking for a sneak peek inside the world of software.
With respect to my content, the analytics never lie. My softer content consistently gets more watch time than my technical videos. The stuff about daily life, interview rejections, and “How to be a Better Programmer” have always resonated more with viewers.
Throughout this book I have drawn on personal experiences, but it is also filled with many perspectives and unique stories from my friends. I went around and interviewed everyone I know that is, or has ever worked with, a software developer. Everyone has a special story to tell and a wealth of advice to share. Their names may have been changed but their stories never will.
This book consists of 40 chapters. Each chapter is influenced by someone’s experience in the tech world. I’ve included a mix of concrete advice, abstract meta-principles, and entertaining stories. Each chapter belongs to one of five categories:
1.Career
2.Learning
3.Coding
4.Daily Life
5.Stories
This book is a highlight reel of software development life. Enjoy!
—David Xiang
1: Peer-Vs.-Peer [Stories]
Every fall, Carnegie Mellon University hosts a job fair called the Technical Opportunities Conference (TOC). For many students, this event is a counter-productive stretch of two hours that leaves people feeling unexpectedly depressed about their future. The university’s student center fills up with job booths while hordes of students wait in line to speak with a handful of company reps. The reps are usually CMU alumni looking to fill their hiring pipeline with fellow Tartans.
The competition is stiff and more often than not, the conference provides students with zero productive leads. Regardless, CMU recommends that everyone attend. We practice wearing our over-sized suits, get an opportunity to professionally present ourselves, and get a taste of the fabled real world that’s waiting for us outside university grounds. This conference purposefully promotes peer competition and serves as an unbiased progress marker for students; how well you navigate the booths reflects your current aptitude.
Looking back, it’s impressive the difference one year makes for the typical undergraduate.
Looking back, it’s impressive the difference one year makes for the typical undergraduate. As a freshman, the non-introductory classes the sophomores are taking seem light years away. Sophomores get jealous of the shiny internships that the juniors are getting. Once you’re a junior, seniors taking their capstone projects and getting fat job offers start to intimidate you. By the time you’re a senior, you grudgingly bow your head to seasoned professionals with real jobs, even though some of them are no more than a year or two older than you.
NVIDIA always had a cutthroat presence at the TOC. Founded in 1993, NVIDIA is a living legend in Silicon Valley and they are still kill
ing it today. At CMU, they gained TOC-notoriety through the use of a simple but terrifying 3-question quiz.
There were two flavors of quiz, Analog and Digital, each capable of demoralizing the unsuspecting underclassmen. These quizzes were NVIDIA’s way of rooting out the incompetent: an easy and effective way to filter down the magnitude of students pouring through their booth. When I took them, the analog quiz covered voltage differentials and asked you to explain what an amplifier was doing. The digital quiz made you map out some gates, reason through some logic, and enumerate a truth table.
You never really fail the quiz, you just fail yourself. Once you get to the front of the queue, you’re handed your questions and ushered into a staging area of standing desks. Around you, any number of sweaty students are staring pale-faced at their own test sheets. After filling out the questionnaire, you wait in line again to review your responses with an official NVIDIA judge. Overlay this whole scene with a subtle but very clear power differential between student and employer, and you should have a good picture painted in your head of what this tech-based cattle market is like.
First time around, I failed myself. I looked at the quiz, realized I couldn’t do any of the problems, and quietly excused myself from the booth. I was doing everyone a favor—one less person in line for the other students and one less incompetent prospector to discourage for NVIDIA. I’ll always remember that moment; as I walked away, I felt the laser burn of all those eyes following me out of the booth.
Fast-forward one year. I was a budding junior; a little smarter but still hating the TOC. First things first, I headed straight back to NVIDIA, because I remembered the questions and thought I knew the answers. This time, I finished the quiz and made it to the final line. Unfortunately, it turned out I still didn’t know the answers; I scored about a 1.5/3 and proceeded to botch my interview with the NVIDIA rep. My résumé went straight into the please-do-not-call-back-these-students pile. I would have been crushed except that I saw underclassmen doing the exact same thing I did the year before. They picked up the quiz, looked very sad, and quietly left the booth. I wanted to give them all hugs.
After some more running around futilely handing out résumés, I bumped into an ex-girlfriend from my sophomore year. She was with her new boyfriend, Mike. By the way, CMU is filled with Asian-American Mikes who play basketball, dominate at Street Fighter, and are incredibly smart. He was the same major as me, one year younger, and had already worked at Microsoft. Damn, she upgraded! Let me remind you again of the CMU student dynamic and mindset. Big company internships are coveted; the people who land them are the cream of the crop. Fancy internships are on people’s minds 24/7, so naturally I was jealous of Mike. When we bumped into each other, my ex-girlfriend graciously asked:
“Hey Mike, do you think you could help get Dave an interview at Microsoft?”
“Maybe. Is he smart?”
The exchange was lightning quick and I got an influx of different emotions. It was a mix of shock, sadness, and damn this guy. Mike looked at my résumé, came to the conclusion that I hadn’t taken the right classes yet, and decided he couldn’t help me. Did I just get pseudo-rejected by Mike?
I don’t have a name for this feeling, but I’ll describe it for you. Something happens to you that doesn’t seem like a big deal at first. The day goes by and you dwell on it more and more with each passing hour. Before long, your day is ruined. Let’s call it the “increasingly unfortunate hindsight emotional trauma due to crappy person and interaction feeling.”
I would stop putting the better engineers on a pedestal and begin to wean my mind off inter-student comparisons.
A day later, I finally stopped thinking about Mike and made an important decision. I would stop putting the better engineers on a pedestal and begin to wean my mind off inter-student comparisons. It wasn’t easy to do; peer competition is rampant in any engineering school in the U.S. We compete with our classmates for the most elegant coding solutions, the top test scores, and the best internships. One of my CMU courses would publicly post everyone’s coding scores on the class website. Everyone used aliases, but we all knew who was at the top. The TAs made sure you knew who wrote better code than you. This was the kind of competition we had to deal with on a daily basis.
Whether they admit it or not, CMU breeds a cutthroat environment. On the one hand, the peer-vs.-peer competition pushes everyone hard; if you respond well to this kind of atmosphere, you quickly rise to the top of your game. On the other hand, it’s a little messed up.
My biggest takeaway from this experience is that you can’t let another person’s progression disturb you from yours. There will always be students like Mike; they’re younger than you, ahead of you in class, and smarter than you. Extrapolate this idea out beyond academics. Each one of us is on our own timeline. Taking random samplings of timelines out of context is never helpful. Your 25-year-old self is probably not comparable to 25-year-old Bill Gates. Don’t dwell on this, but use it for discretionary doses of motivation. As long as you—and only you—continue to progress, everything is on the right track.
2: Technical Foundation [Learning]
Understanding the basics is the key to software development. I will go further and claim that it is the key to every single profession. The significance of fundamentals is frequently underestimated and often neglected. People tend to associate this with being easy, but there is nothing easy about it. I like to encompass these values and their importance with one word—foundation.
A solid foundation can support the tallest buildings. Foundational ideas form the basis for complex theories and they enable the extensions of novel ideas. For any field, the people at the highest level are the ones who deeply understand foundation; that’s why they can break it sometimes. To this day, I am still self-conscious about my fundamentals. Getting a refresher from an old textbook is never something to be embarrassed about.
At CMU, I spent 150 dollars to purchase a Computer Systems textbook that I barely read as I scrambled to keep up with lectures. It wasn’t until I started working that I began to fully appreciate its content. I’ve broken its bindings from too much page flipping and it has never failed to deliver me technical guidance in times of need.
The first—and perhaps most difficult—step is pinpointing areas where we’ve missed the basics. During my first couple years of college, I often found myself staring blankly at coding assignments. Things didn’t make sense. I had missed a fundamental concept.
During academic life, curriculums and course progressions can assist with pinpointing weak areas in our foundation. If we fudge some code or bomb a test, we know something has gone over our heads. Retracing old homework and lecture notes is never a bad place to start. The most significant value an engineering school can offer its students lies in its curriculum—your learning has been organized for you. After entering post-academic life, shaping your progression gets harder. You don’t have convenient, “Move on to Part 3.4” markers to guide you. In real life, all the knowledge is out there, it’s just not served straight up for you on a platter.
For any field, the people at the highest level are the ones who deeply understand foundation; that’s why they can break it sometimes.
I preach foundation often, and I’ll preach it again, I’m sure. Always, always make sure you understand the fundamentals. If you’re learning something for the first time, be completely honest with yourself about your level. If you think you’ve grown beyond the fundamental concepts, go back and re-read them; you will always uncover more nuances. At CMU, I tricked myself into thinking that I understood pointers. Reality kicked in when I got into the labs for linked lists and trees. I couldn’t wrap my head around pointers to pointers. Is a pointer a memory address? Is it a variable? Is it both? What’s this deep copying thing?
You will inevitably fall behind in your engineering classes. The reason for this is that these courses focus on content over pacing. An engineering course’s definition of pacing is simple—students do wha
tever it takes to keep up. Each course is packed with content, and rightfully so. This may sound discouraging, but everyone is in the same boat. Professors have only a limited amount of time to teach you; it’s up to you to sufficiently allocate and utilize your time to ensure you understand the material. And if you don’t, then seek help from the faculty. That’s what they’re there for! Remember, you’ll never have the opportunity to pick the brains of these people again once you leave. Good teachers want you to learn as much as they know.
Understanding the basics is essential. Just like a tall building, our technical foundation needs upkeep and must be periodically reinforced. Here are a few tips and tricks that may help.
Basic Idea
We must have a complete understanding of even the simplest things. Fundamental principles, ideas, and methods have to be mastered. This results in a solid knowledge foundation, which is everything.
Revisit Often
Once is never enough. There is always a concept that you can understand better by examining it again.
Blank Document Test
Open up a blank document on your computer. Do not refer to anything and write an outline of any concept you’re trying to understand. If you can’t write anything, then you don’t understand it at all.
Focus on Sub-Problems
Do not tackle huge issues in their entirety. Find a sub-problem and understand it completely. Each complicated subject has a handful of core ideas. Isolate each one and figure out how it contributes to the whole.
When You’re Stuck
If you find yourself stuck on a particular concept, ask yourself: is there a simpler concept beneath this that you do not fully understand? For example, if you’re struggling to understand how buffer overflow works, is it because you haven’t grasped function call stacks? Train yourself to pinpoint that more fundamental concept quickly. Once you’re proficient at digging down to the simpler concept beneath, you will rarely get stuck and your progression will accelerate.