by David Xiang
The core principle that has guided me through these fights is the humble acknowledgement of mutual purpose.
For all the developers out there, respect the product managers and designers—let them do their jobs. When cross-departmental issues arise, be tactful in how you communicate, and keep a collaborative mindset focused on mutual purpose. For all the non-technical people reading, do your homework to empathize with the developers. Respect their work. If you fulfill your own role well, they will respect you.
15: Dominant Behavior [Career]
Pay careful attention to the subtleties in a person’s behavior. This is crucial when interacting with people in more powerful, senior positions than you. This is the big boss about to offer you a job or your manager contemplating your promotion. Focus on how your counterparty communicates; it will showcase their personality and their perception of you. When and if you rise to a position of power, your awareness of these subtle details will come in handy.
If you’re young and pursuing a career in software, I’ll put two hundred bucks down that says you’re feeling restless in your current position. You’ve grown fatigued from tinkering with the same codebase, you hear about your startup friends cashing out from fat Google acquisitions, and you’ve read way too many “How Much Money Do Software Developers Make?” articles on Quora. All these tiny needles keep pricking at your personal concept of developer adequacy. Aside from these distractions, there are the omnipresent success stories and the purposeful neglect of failure stories, mixed together with a huge pool of career options. It’s easy to see why developers get itchy feet.
What’s this got to do with dominant behavior? This restlessness translates into a continuous cycle of job seeking, where you find yourself moving from one job to another every couple of years. Consequently, this puts you back on the interview circuit more often than you would probably like. Once you’re back on that circuit, you’re once again faced with these kinds of one-sided, power-based situations.
In early 2014, I had been working at Qualcomm for about four years when I started to apply to startups. I was completely sucked into the startup hype, and I had read my fair share of Paul Graham essays. Paul is well-known for co-founding Y Combinator, a famous American institution that trains, grows, and mentors startups. My colleagues and I, living far away from Silicon Valley in sunny San Diego, used his blog posts to get a glimpse into the trendy world of startups. Was working at a startup as cool as everyone made it out to be? Did they really give you free food and have cold brew coffee on tap? Could they make you rich? I wanted to find out.
At Qualcomm, they instituted something known as “Matrix Management,” whereby your manager and your direct supervisor were two different people. Your manager—the person responsible for your bonuses and promotions—had nothing to do with your actual day-to-day work. Your direct supervisor—your day-to-day boss—was the one who assigned your daily tasks and had little to do with your career prospects or financial gain within the company. Every six months you’d have a performance review. This started with your selection of five trustworthy colleagues who could speak truthfully, and hopefully positively, about you and your work. These peer reviews were then relayed to your manager, who scored your overall performance in a variety of categories between 1 and 5.
The managers of entry-level developers were mid-level employees—the majority of whom Qualcomm has a tight chokehold over—pummeled by the day-today stress of their own workloads. For them, the added responsibility of managing was merely a bonus added to their salary, coupled with the drudgery of sifting through a pile of feedback twice a year. They had little reason to care about our career paths or personal goals. My manager sat in a completely different building than me, and every six months I would have to re-remind him of what I had been working on. This managerial apathy certainly wasn’t making me feel very enthusiastic about my job.
My manager sat in a completely different building than me, and every six months I would have to re-remind him of what I had been working on.
Another contributing factor to my career anxiety was a general feeling of disconnect. In terms of people, imagine what it feels like to be one of thousands and thousands of developers. You are software engineer #2513. I had a one-on-one with a director of engineering twice during my entire time with the company: once to receive a firm handshake off the back of a promotion, and again after I’d handed in my notice.
As far as the work went, I never felt connected with it; it never felt like my work. I had a reasonable sense of how my code contributed to Qualcomm as a whole, but the tiny-cog-in-a-giant-machine sensation weighed heavy on me. To add to my uneasiness, two major projects I had worked on were canned after months of hard work. All of this made startups all the more attractive. I was young, had few responsibilities, and didn’t mind putting my retirement plan on hold.
I began to apply and interview for startup jobs. It was amazing to see the kind of intimacy within these small companies. Everyone fit in a room. Everyone knew each other’s name. I was infatuated with it all. After four years of working for a large corporation, the startup grass definitely looked greener. I would find out later, of course, that nothing is sunshine and rainbows forever.
During my tenure with a couple startups, I had two significant interactions with two different CEOs. What they said was roughly the same, but how they said it made all the difference. Breaking down each experience reveals important nuances between two vastly different CEOs.
In one interview, the CEO walked in, shook my hand, sat down, leaned back in his chair, and very casually put his feet up on the table. I was shocked. I had never seen anyone do anything like this in a professional setting before. At the time, I brushed it off. I was still wearing rose-tinted glasses—this was just another normal part of startup culture, and startup culture was where I wanted to be.
From the outside, it might seem like this wasn’t a big deal—like it was an entrepreneur challenging the status quo, breaking the job interview boundaries, and welcoming me into the “family.” But in truth it was a subtle display of power. Without anything being said, I immediately felt “in my place.” I was the humble developer, eager to make a good impression, praying to land the job. This guy was clearly in his comfort zone and was dominating the room. It was obvious that he was the decision-maker for the company—I was coming to work for him.
A couple years later, I found myself in the same situation, sitting across the room from another startup CEO, being interviewed for a developer position. Only this time the CEO sat upright in his chair and faced me directly. We had a conversation that was similar to the other; he asked me questions and I answered them as best I could. But this felt different. This felt positive, equal, and respectful. This CEO gave off an air of “Let’s work together” as opposed to the previous example’s air of “Maybe you can come work for me.”
These subtle behaviors showcase the deep traits found behind the personalities of each and every one of us. Both of these CEOs were great leaders, but their styles were as different as night and day. The first CEO stayed hands-off. We didn’t see him around the office often. He came to provide feedback at product demos and checked up on everyone at a high level. The second CEO was a boots-on-the-ground operator. He would be jumping on a sales call, explaining business concepts to us over dinner, and logged more hours in the office than any other employee. They say you should never judge a book by its cover, but in some cases, the cover might be extremely important.
I can’t stress enough the significance of behavior and body language. When making a career or life-altering decision, focus hard on your interactions when you’re with anyone in a position of power over you. This will happen often. Stay conscious of actions that exude aggression, dominance, or power. Your initial judgement of character may save you a lot of time.
16: Full-Stack [Learning]
For any developer, the raw amount of knowledge to gain can feel extremely overwhelming. Sometimes, when there are too many o
ptions for learning, we can become paralyzed before we even start. Am I working on the right things? Is this the correct language to study? Is this technology even relevant anymore? Learning is a life-long process, and the horizon of knowledge stretches further into the distance as we progress.
This chapter focuses on a common question, how much do I need to know? People just dipping their toes into technology will often ponder this question. Do I have to be good at math to code? How much do I need to know about computer science? What about hardware or software? What is it that software developers learn, as opposed to a CS major? All these questions and many more might be running around in your head. My answer to them all is that you don’t have to learn everything—which is unreasonable—but you need to be aware of everything on a basic level.
Learning is a lifelong process, and the horizon of knowledge stretches further into the distance as we progress.
In the world of computers, there are many layers. Imagine a huge stack of technology. At the bottom of the stack we have electrons, science, and raw physics. At the top of the stack we have code, web browsers, and fancy IDEs. Wedged between the two we have a ton of stuff. How much of this stack do we have to understand to get ahead?
“You don’t have to know the details about each layer, but you should be able to talk about each one on a basic level.”
– Bruce H. Krogh
Professor Krogh had a profound impact on me as a student. He taught a wide variety of introductory courses at CMU. I had him for Analog Circuits, Signals and Systems, and Introduction to Computer Engineering. These are all vastly different subjects and he was teaching all of them at university level. Professor Krogh enjoyed randomly calling on students during lectures with random questions that sometimes went off on huge tangents. I got the impression that he just enjoyed seeing his students squirm. He once asked me for five examples of how companies use GPS. I managed three examples and blanked out right before he moved on to the next unlucky student.
Regardless of what class he was teaching, he would always repeat that quote during the first week. He consistently preached the value of a solid foundation and I credit him as the reason I do likewise. He had one particular slide that he would often refer to—a picture of the all-powerful stack of computing. For everything we learned, he would show us that image and indicate where our new knowledge fit into the grand scheme of things. I was in awe of his understanding of technology, as well as his ability to take disparate parts of computing and distill them down into shared concepts. I always thought to myself, how can one guy know so much?
Let’s go back to our mental model of the stack. On the very bottom we have electricity, at the very top we have code, and we have a lot of stuff in between. When you break down one layer of the stack, there will be more and more layers to break down; it never ends. Let’s take a quick walk through this stack together.
First, let’s separate hardware from software—that’s two easy layers. We’ll put hardware on the bottom and software on the top. Let’s break down hardware first. We’ll split it up into three basic levels: circuit design, CPU design, and HW system architecture.
A circuit designer is someone who meticulously designs a specific circuit that performs a specific function. For example, let’s say they’re designing a high-performance arithmetic logic unit (ALU) that can add, subtract, multiply, and divide ones and zeros efficiently. They’re making sure this ALU is the best ALU in the world. That’s their job, and they do it extremely well.
On the next level above, we have a CPU designer who is in charge of creating an entire processor. They need an ALU—maybe a few of them—that will fit into the processor. Along with that, they need a variety of other hardware components to make sure the CPU is up to spec and performant. The CPU designer will utilize the work of a diverse set of circuit designers to put together his or her masterpiece.
On top of the CPU designer is the HW system architect. The architect will be in charge of designing a holistic computing system. They need a multitude of different processors and modules. Let’s assume they’re working on a next-generation smartphone. It needs a powerful quad-core apps processor to run the latest-and-greatest Android operating system. It needs a state-of-the-art GPU to let users play immersive video games. Don’t forget the modem, which will enable the phone to connect to local base stations and make calls. To top it off, the HW Architect wants some kind of motion processor so the phone can detect twists, turns, and your daily steps. Besides the demanding list of unique processing units, the system also needs memories and caches to run efficiently. All these different processors and hardware modules will come together and create a system that will eventually live inside this new cell phone.
We just broke hardware down into three very generic layers. You could take each one of those layers and break it down even further—it would never end. Let’s switch gears to software now. We’ll do the same thing and split software into three generic layers: Firmware, OS Level, and Application Development.
A firmware, or embedded, developer will be working on low-level code. This might be the code that executes before an operating system is even loaded. This is code that runs with very limited resources and may have no concept of dynamic memory allocation. If you have a PC, this is that black BIOS “boot-up” screen that pops open right after you hit the power button. For any hardware to be useful, there must be some software running on it; if we didn’t have software, all our cool hardware would be equivalent to bricks. Embedded developers build the software that sits directly on top of the hardware. They provide essential interfaces to higher level software, allowing it to take control of the hardware itself.
Go up one level and you step into the world of OS developers. These are the guru Linux Kernel developers who push the boundaries of how efficiently software can be run. They’ll handle process scheduling, file system management, and security. How can hundreds of processes run side-by-side on a computer without the whole thing crashing? How can the buggy code you write not bring down the entire system? That’s OS magic for you. If you have a simplistic system like a microwave, perhaps an operating system is unnecessary. But for any intelligent computing device, it’s essential.
Finally, let’s look at application development. Most of us developers work on this layer. This is where all the games are made, where millions of apps are developed, where the shiny web portals get built. We’re at the top of the stack now and it’s a very, very busy place. The demand for application development is high and will forever stay high.
So, what does it mean to be a full-stack developer? Web development is hyped up these days. It’s what ninety-nine percent of startup tech is all about, it’s what nearly every single business needs, and it’s why the Internet is the Internet. Web development is an extremely high-leverage software field to be in and for good reason. No one goes to the store and buys plastic boxes with installation CDs anymore—everything you’d ever need is a click away in your Chrome browser.
Remember, web development is a very small part of application development and application development is a very small part of the software stack. Remember also that our software stack owes its very existence to the colossal hardware stack below it. Web development is a very, very tiny sliver in the mighty stack of computing.
This is why I think the term full-stack is misleading and borderline deceptive. In modern lingo, this term is only ever used in the context of web programming. Within web development, full-stack means two things: you can write some front-end code that runs in a browser, and you can write some server-side code that runs on a computer somewhere. However, if you went up to a Linux Systems programmer and asked him or her if they were full-stack, they would smack you in the face. The modern definition of full-stack simply means you can write web applications, nothing more.
When I think of full-stack, I think of the full-stack of computing. This is hardware that carries the electrons through its metal and all the software that turns it off and on. This
is the stack that we should all strive to understand and appreciate. The concept of full-stack should create feelings of awe in everyone by showcasing how incredible computing really is. This is the real foundation. I cringe when I hear people calling themselves full-stack developers when all they know about is one web framework and some JavaScript.
Being pedantic about titles is not what’s important. What is important is our basic understanding of these essential technical building blocks. Everything you learn—from low-level digital circuit design all the way up to high-level web development—has a position in the full-stack of computing. We don’t need to be an expert in everything, but we must understand each piece on a basic level.
17: Non-Technical Trying To Be Technical [Stories]
Patrick, mechanical engineer turned coder, is back with a whirlwind story about his first job as a developer. Peeking under the covers of professional software development, this story shows just how messy the reality can be. Patrick’s CMU training helps him survive in tough development environments, but you’ll see how this pressure-cooker experience is hard on many.
My first foray into mobile development was as an iOS developer for a newspaper publisher. Aside from a few stories, I was unfamiliar with professional software development and I was relatively new to mobile as a platform. I majored in mechanical engineering but was drawn to coding soon after graduation. Back then I was a complete beginner.