Software Developer Life

by David Xiang

  Whatever your go-to methods are, dabbling with new techniques can provide a deeper comprehension and round out your understanding. This chapter summarizes various styles of learning—pick and choose as you like.

  Learn by Doing

  Just do it. This is the easiest and most straightforward way to learn anything. Start that side-project, or pick up that unfamiliar ticket from the backlog. Register for that intimidating CS class, request a transfer to a different department, or make a hard pivot into a new industry. Sooner or later, all roads of learning lead here. This is— and will always be—the bread and butter of progress. It doesn’t get any simpler than this. Just do it.

  Learn from a Mentor

  Having a mentor is a luxury. You have found someone who has gone through what you’re going through or has reached a level that you aspire to reach. A mentor is very different from a role model. A mentor gets to know the real you and provides personalized guidance. A role model is a celebrity that you follow on Twitter. A mentor will take time to understand your experiences, your level, and your outlook on the future. They’ll take your context, combine it with their own journey, and use it to reflect on your life. The end result is priceless, individualized advice.

  This sounds too good to be true, and it is. Many of us will never have the luxury of a true mentor. However, there is good news. We can find pieces of mentorship in a variety of places—YouTube, podcasts, books, strangers. When sifting through public resources, search for people who have shared your experiences and whose background you can relate to. The key is to have some level of shared experience. Without it, you become susceptible to unrealistic comparisons. If you’re from China and have set your goals on coming to the U.S. to become a programmer, you’re not going to relate much to the wealthy American student who takes out zero loans and gets into MIT.

  In a world with billions upon billions of human experiences, you will find someone who’s been in your shoes and has accomplished your goals. If you’re trying to transition from developer to product manager, there are a hundred people in your city who’ve done it—go to a meetup and find them. If you’re trying to break into coding from creative writing, there are a thousand blog posts from people who’ve made the switch—read them. Whatever you’re going through, I guarantee that someone has gone through it, learned from it, and shared it. It’s a privilege for us to have access to these resources. Dig for them.

  Learn Through Research

  Learning through research is the natural complement to learning by doing. Not only must you use technology, you must also study and read about it. For example, if you want to become a Node.js master, step zero will be getting your chatroom pet project off the ground. To round out the experience, spend the extra time to understand the technology’s origins, its pros, its cons, and how it got where it is today. What problem was it trying to solve? What problems does it not solve? What were the major milestones for the technology? Do not put blind faith into pumping out code; it alone is not enough.

  Not only must you use technology, you must also study and read about it.

  I categorize writing about software into two categories. There are a certain set of books that are dedicated towards the “doing.” These are fifty-pound language reference books and detailed walk-throughs of frameworks. They are simple. They are concrete. They are objective. A huge book about Java is going to include everything there is to know about Java.

  The second category of writing is the subjective software opinions of other developers. Many pioneers have written books with musings on computing and software as it’s evolved over time. They don’t care about detailing the syntax of the new C++ features, they simply want to share their thoughts about technology. In addition to writing a million lines of React code, read a blog post that hates on React, then read a blog post that puts React on a pedestal. For every software opinion you have, there’s someone else who thinks exactly the opposite.

  Learn from Role Models

  Role models are people we look up to. We all have them, and now the Internet can give us a glimpse into their minds. Turn on your computer and you can watch Elon Musk talk smack in an interview or see candid footage of Linus Torvalds yelling at someone.

  Just because Tony Robbins takes freezing baths in ice water doesn’t mean you have to as well.

  As I stated earlier, role models are different from mentors. While mentorship is catered to you as an individual, a role model is simply someone you respect, someone to look up to. They don’t need to share your experiences or empathize with your background. Peter Theil and Steve Jobs may not be your perfect mentors, but their accomplishments still deserve our respect.

  I highly recommend watching interviews, podcasts, and candid footage of your role models interacting with people. One of my favorite clips on the Internet sees Jack Ma getting the original Alibaba team hyped up about the future. He talks about the differences between U.S. tech and Chinese tech, sets an extremely high bar for his employees, and puts his foot down on Alibaba’s IPO date. Just from this five-minute clip, you get a sense of Jack as a person and how he’s wired. We’re lucky to have that video in the public domain, and I watch it every time I need a quick injection of motivation.

  Witnessing how our role models behave in the world is something we take for granted in our digitally connected age—something that wasn’t so easy just ten years ago. Watching them not only serves as inspiration, but it also gives us the psychology behind how they tick. It shows us how people at higher levels operate, and it also shows us that they are still human. You will never get a sense of this from a crafted speech or a premeditated book.

  Do not follow role models blindly. Just because Tony Robbins takes freezing baths in ice water doesn’t mean you have to as well. Role models are a source of inspiration. They present their advice in two ways—whatever works for them, or whatever sells more books. Many people attempt to copy and paste these behaviors, and it fails them. For role models, take their knowledge merely as a resource—a rough guideline—and integrate it into your life on your own terms.

  Learn Through Discussion

  An amazing way to solidify your understanding of a tough topic is to discuss it openly with your peers. A solid discussion is an open forum—with open minds—participating in a mutual back and forth. This is very different from a lecture. There must be an authentic expectation for discussion.

  A discussion isn’t designed for you to be on the receiving end of a knowledge hose or for you to preach the gospel. It’s designed to spark a dialogue over something that doesn’t have a concrete answer. It’s a place to uncover the pros and cons. It’s a place to share light bulb moments with your friends.

  Learn Through Teaching

  Teaching is one of the most underrated techniques of learning. A long time ago, I was a novice C developer who somehow landed a teaching position at a summer camp teaching young high schoolers how to code. Even though I was teaching the super-noob course, I was still nervous, because I wasn’t all that confident with my C.

  Teaching is one of the most underrated techniques of learning.

  Unexpectedly, those three months turned out to be a very productive summer for both me and the kids! Teaching basic C to the students helped reinforce my own understanding of the language. The more I explained the labs, diagrammed pointers, and debugged the students’ code, the more I strengthened my own foundation.

  Teaching is an art form. If you’re doing it well, not only will you seamlessly transfer your knowledge, but you will also enhance your own foundation. Furthermore, teaching serves as an honest audit for your skills; if you can’t explain something simply, it means you don’t understand it yet. Remember, you can always learn something from someone else. Try to teach your friend about the latest JavaScript framework you picked up, then have him or her return the favor. Don’t worry if you think you’re not ready, you’ll surprise yourself.

  38: Watch The Side Effects [Coding]

  Throughout your career,
you will be writing a lot of code. At some point, you may fall out of love with it. And then fall right back in love with it again. I’ve seen developers struggle for years to get into management roles, only to willingly transfer back to being individual contributors (ICs). I’ve had to listen to tenured VPs tell me how the only interesting thing left in their day-to-day is squashing a bug. Coding is where it all started; it’s the roots.

  It goes without saying that not all code is created equal. Your code is better than your roommate’s, say, but it’s not on the same level as Bjarne Stroustrup’s code. One thing that distinguishes the senior from the junior is their mindfulness of the side effects.

  One thing that distinguishes the senior from the junior is their mindfulness of the side effects.

  Let’s talk about the aspect of coding that is new feature development. You have a stakeholder, a set of product specifications, a design template, and you’re about ready to switch into dev-mode. Take a moment to appreciate the blessings of a new feature— most of the time, adding is significantly easier than changing, refactoring, or removing.

  New feature development can lull the unsuspecting developer into a false sense of security. The grass is green, the dependencies are low, and decision-making becomes liberal. During these times, we must tread very carefully; it’s dangerously easy to overlook unintended— and very serious—side effects.

  A software system is in a perpetual state of change. Hundreds of developers add, delete, and modify thousands of lines of code every day. Understanding your own changes is basic table stakes. Understanding how these changes affect the system—from now and into the future—is what separates you from others. Here are some common areas where you must stay extremely vigilant—incorporating new third-party libraries, touching any interface across processes, changing any kind of serialization, changing any kind of deserialization, updating any dependency, barely modifying a query, trying to cache new data. There are too many things to list. Every single line of code requires your utmost attention.

  To expand on that, ask yourself these questions. Does this change make development harder for my colleagues? Does it require a workflow change? How would this change affect everyone else’s local environment? Who would want to talk about this change? Is there parallel work going on that affects this? Not all changes live in code. Don’t underestimate your work’s ripple effect; see it in advance.

  Let’s examine a concrete example. For anyone out there that’s using relational databases, I’m sure that some of it is managed through an Object Relation Mapping (ORM) library. ORMs don’t quite bake you the full cake, but they come pretty close. They are incredibly useful libraries that kill a lot of cumbersome boilerplate. For the majority of use-cases, ORMs work just fine and product can be shipped. However, there can be times when these libraries won’t get the job done, and custom SQL must be written. If you enjoy picking away at and timing the execution of SQL blobs, then all power to you! The world needs more people like you. But in my humble opinion, ORMs beat out handwritten schema and queries any day of the week. Remember that black-boxed software magic is a double-edged sword. ORMs are rife with potential side effects—they’ve tripped me up many times.

  External libraries encapsulate a lot of functionality away from you—as they should. An ORM can guess when you need to eager load, it’ll be smart about caching associations, and it can suggest missing indices. Despite the magic, we must not ignore how they actually work. When I first went diving into web development, I was asked to make a seemingly simple change to an ActiveRecord query. I made the change with only a couple lines of code, but the cascading side effects were devastating. A couple innocent lines of Ruby code turned into five extra joins, extra seconds of execution, and a big problem for production.

  I messed up in two places. First, it was obvious that I still didn’t really understand our system. I wasn’t aware of all the use-cases that flowed through this query’s code path, and I didn’t have a firm grasp of our schema. Unless you built a system from scratch, none of us can know all the nuances of a project. Every codebase has a long history filled with deprecated features and failed refactors. This history takes time and effort to understand. Put in the hours of research until you understand the subtleties of your codebase. If it’s too much to fathom, ask your neighbor—he or she will have no problem telling you the war stories. A two-line change may not be as simple as you expect! All of this is to help you watch out for the side effects, which enables you to make robust updates to the system, and turns you into a higher-value developer.

  Second, this mishap showed that I had not fully grasped what the ORM was doing. Why exactly were these lines triggering extra SQL? What could I have done to keep the performance the same? How was this ORM even generating its SQL? Do not put blind faith in external libraries to do everything for you in the best way possible. Third-party libraries have their own bugs, nuances, and side effects that you must understand. The moment you decide to take on a library, you own it.

  Code is meant to be shared and loved. It’s not just your code—it’s everyone’s code.

  This is a lesson in details. Take care of the details in your work, and be aware of the details in the side effects; very rarely does your code only affect what you want it to affect. This lesson isn’t designed to scare you. You don’t want your code to exist in a silo. Code is meant to be shared and loved. It’s not just your code—it’s everyone’s code. Good software teams work collectively to elevate an entire system. Your code should have side effects, but they need to be positive side effects! As you familiarize yourself with any codebase, stay vigilant and be sure that your improvements benefit everyone. The details are what matter and what separate you from everyone else.

  39: Communication [Career]

  Every developer job posting requires applicants to have Excellent Communication Skills. Sounds cookie-cutter and cliché—but what exactly does it mean? Is it enunciating words clearly? Is it speaking at least once during meetings? Is it another way of saying you should always be giving killer presentations?

  A good communicator is someone who can effectively explain their thoughts and keep their peers updated about everything that’s going on. Seems simple, yes, but it’s a skill that takes time to develop. How do you choose your words? How did you introduce the context? How do you prepare your code reviews? How quickly can you explain your work? Is your project progressing or lagging? How does your colleagues’ body language change when you’re around? How would you describe your tone?

  People underestimate the power of communication. Not only does it serve its functional purpose of disseminating information, but it also acts as the necessary precursor to gaining respect. Pay close attention to others and develop your communication skills. It will pay huge dividends in your career.

  Express Yourself Clearly on All Platforms

  You must articulate your thoughts clearly on all platforms—emails, meetings, presentations, code reviews, messenger, direct speech. We discussed emails earlier, but the detailed how behind all these platforms is outside the scope of this book. Place a sincere effort into each and every one of these mediums.

  Everything you produce—from an instant message to a code review—must show clarity. For digital messaging, ensure your tone is respectful and your intention crystal clear. Use as few words as possible, pace the conversation, and refrain from dumping paragraphs of technical text into an unsuspecting chatroom.

  For code reviews, ensure your code is nicely wrapped up with a ribbon. Don’t put up a thousand lines of garbled red and green that barely got your feature working. Don’t continue developing and committing to a live review. Your pull requests should have a well-defined purpose, include documented “gotchas,” and let ninety-nine percent of the code speak for itself.

  Always Prep Before the Conversation

  A huge percentage of our communication will be asynchronous. You have the afternoon to set up your code review, you can take three minutes to respond t
o an important message, and you have a whole evening to write a well-thought-out email. Where asynchronous communication is convenient, expressing yourself in real-time can be challenging and stressful. We’re talking about those weekly meetings, the design discussions, retrospectives, and day-to-day peer programming sessions. Even though you might prefer to skulk in your cave, you won’t always be able to lock yourself in a cubicle pumping out code 24/7. Sooner or later, you will have to speak in real-time with your teammates.

  Effective discussions start before the discussions even happen.

  Effectively expressing yourself in a live situation is a practiced skill. I can’t help you with the actual practice, but I can leave you with the number-one tip that has helped me throughout the years—prepare for every, single interaction. Whether it’s a big meeting or you’re simply asking someone to come by your desk, you must be prepared.

  Before the conversation happens, you should have already gathered all the context you need. It should be fresh in your mind. Effective discussions start before the discussions even happen. Once you get into that meeting room, the only unknowns left should be the ones the meeting is about to uncover. So many valuable engineering minutes are wasted due to someone’s lack of context and preparation. Not only is this wasted time, but it’s just a bad look. Great preparation begets seamless communication. Don’t forget about it.

  Body Language and Respect

  Another essential part of communication lies in the receptiveness of other parties towards you and your thoughts. A lot rides on your body language and how the words come out of your mouth. Not many of us are psychology experts, but we should all understand and appreciate its teachings.