Software Developer Life

by David Xiang

  Organization at All Levels

  Enforce stringent organization on every level. Here are three levels as a rough guide. First, the raw software must be clean. Use design patterns as long as they make sense and refrain from introducing fancy new ones for “fun.” Second, the directory and file structure must be intuitive and consistent—here is where we keep third-party libraries, this is where our schema definitions go, and here is how you separate versioned interface files. Third, put effort into building and deploying. How clean is our build process? Artifacts always go here, documentation always gets generated there, and the version number always gets updated like this.

  Every level of software development needs this level of attention. Starting with individual lines of code, this detailed attention should go all the way up to how you finally deploy out to production—the whole system should stay highly organized.

  Show That You Care

  All code will always reflect the code writer’s commitment. How do you personally develop a baseline for this? You start by practicing this commitment yourself. We must care about the code we write—it is our craft.

  There are two benefits here. First, your baseline as a developer rises—you will writer better code, faster. Second, you will naturally recognize sloppy code and your code sense will strengthen. Your attention to detail is what sets you apart.

  Conclusion

  We’re just at the tip of the iceberg here. There are awesome books out there on how to write clean code and be a great software developer. Learn more than one language, try out new frameworks, and keep your queue of reading materials fresh. Always care about the code you write, write a lot of it, and you’ll get your own magical code sense in no time.

  13: Does Going To A Good School Matter? [Learning]

  This question is ranked #3 on my list of most popular FAQs. As careers in software development continue to trend, there are now numerous ways to get your foot in the door. The classical way is entering higher education, pursuing a four-year college degree, and entering the workforce post-graduation.

  In addition to this, we now have accelerated boot camps that train productive developers in six months and send them off to big tech companies. I can personally attest to their results, having seen an acquaintance go from zero coding to Uber developer within one year—quite incredible. Yet another new entry method is the gradual cross-departmental transition, supported by large companies. A friend of mine started his career as a customer support representative, transitioned into a manual quality assurance (QA) role, and eventually got a position as a developer—all at the same company.

  With so many different entry points and backgrounds, the tendency for comparison arises. Developers from boot camps want to know how they stack up against the MIT graduate working beside them. High school grads begin to debate whether or not it’s a good idea to invest the heavy cash to get their bachelor’s when they see boot camp graduates getting six figures after six months. So—does going to a good school matter?

  The advantages that academia provides can be wildly different. Some will say it was the perfect springboard into their careers, and others will question if there were any advantages at all. I was lucky enough to gain a lot out of my years at Carnegie Mellon. Everyone’s situation will be different and it’s impossible for me to determine if going to a good school matters for you specifically. Many variables play into what you get out of school. For me personally, it definitely mattered, and here was my circumstance.

  First, I am fortunate enough to have been provided the resources to attend university. My parents grew up during the Cultural Revolution and were forcefully removed from academics to go work in the countryside. After it ended, they picked up their studies, moved to America, and saved enough money to send me to an absurdly priced private school. They have my eternal gratitude and I will be hard-pressed to follow their achievements.

  Second, I targeted my major of choice while I was still in high school. After years of gaming, building computers, and taking introductory C courses, I had an affinity towards engineering. I wasn’t exactly making a ten-year plan as a high school junior, but I had made up my mind about what to study. I applied early decision to CMU, got in, and that was it. I mention this because it’s uncommon to be so definitive about higher academics when you’re 16. Many of my friends had trouble deciding what to study and fell into generic majors. Some flip-flopped between colleges; others found themselves with degrees that they weren’t quite sure what to do with.

  Third, I was able to participate in a world-class engineering program. I will enumerate a few of the benefits, but there are many more than this. The professors are the top of their fields and have honed their textbooks and curriculums over decades. Challenging course work and peer-to-peer competition instill strong work ethic into students—a skill that translates beyond coding. The school has a huge network and goes above and beyond to set students up for their first jobs. This includes frequent job fairs, round-the-clock career centers, and an up-to-date alumni directory. Overall, the institution provides a lot.

  My story sounds like the perfect, classical entry point into tech—and it was. I solidly hit all three criteria. I was lucky enough to have the resources and support from my family, I knew early on what I was going to study, and I was fortunate to be a part of an amazing program. So, for me, the stars did align and going to a good school did matter. However, this is only my circumstance and will be completely different from yours. Perhaps you’re only comfortable with two out of three of these criteria points, perhaps you have none of them, or maybe this story is not even remotely relatable for you.

  Before jumping into the chapter, I have a few additional introductory points to make. First, if none of the stars align for you, tread with extra caution. If you’re indifferent about what to study, are considering taking out debilitating student loans, and didn’t get into a strong program—maybe you should think twice about that bachelor’s degree. Second, take stock of your responsibilities. If you have dependents, medical bills, and loans to pay, perhaps putting a four-year pause on your life to be a full-time computer science student isn’t feasible. Finally, school fills a short period of your life and the knowledge you gain there will be overshadowed by the knowledge gained later. It is not the be-all, end-all of your learning, but merely a place where you have the opportunity to lay your technical foundation.

  The Name Counts

  We are all judged continuously throughout the entirety of our lives. We are powerless to prevent these judgments, and we’re usually just as guilty as the next person of making them. But we are empowered to choose how we let judgments affect us—it’s not a big deal unless you make it a big deal. In the completely subjective and wishy-washy arena of judgment, we must do our best to start with a solid footing.

  We are powerless to prevent these judgments, and we’re usually just as guilty as the next person of making them.

  External judgment starts with our accomplishments. A childhood spent playing RPGs makes me look at my own accomplishments as badges—You’ve earned the High School Diploma Badge! +1 Competency! We are judged on everything—the languages and frameworks we’ve used, the places we’ve worked, and the schools we’ve attended. All of these accumulate and their branding always counts. Our society revolves around these markers and it’s why we still utilize résumés and LinkedIn.

  I was working at a large corporation for almost four years before I decided to jump ship and get into startups. The transition was difficult because I had none of the skills that the startups I approached actually valued. I had C/C++ on my résumé instead of Ruby on Rails. How could an embedded developer know how to write web applications? No way! The reason—truthfully, the only reason—that some startups talked to me was that they saw Carnegie Mellon next to “Education” on my résumé. That single badge was enough to get my foot in the door.

  The Work Ethic

  Many people underestimate the work ethic gained from a challenging engineerin
g curriculum. This is more than just learning linear algebra, implementing basic algorithms, and understanding how a computer works. These are the habits, mindset, and attitude towards tackling problems. You can gain this in a variety of places. Maybe you learned how to work hard by starting your own T-shirt business in high school. Maybe your work ethic came from years of moonlighting projects after your nine-to-five. A strong work ethic takes time to develop.

  The mindset and routines behind a strong work ethic must be developed.

  One benefit of academia is that a four-year engineering program will give you this for free. I didn’t notice this until I became a professional. I realized I had gained much more than just book knowledge; repeatedly spending eight hours in a computer lab builds out some grit.

  The mindset and routines behind a strong work ethic must be developed. You can either get this automatically with academic study, or you can grow it in your own way. I include it here because it is a convenient byproduct of a challenging school and it is often overlooked. Learning and working hard is a lifelong process; make this your mindset.

  Better School, Better Education

  Better schools will provide a better education. There is a reason why MIT is MIT. Elite schools are elite for a reason, and they have honed their curriculums over many years. Not all “Intro to Programming” courses are created equal.

  No Shortcuts

  Good things come with time. The rise of software boot camps has given people the unrealistic notion that they can become a software developer in the space of three to six months. Boot camps are a result of the market; the world demands more developers and these camps create the supply.

  Boot camps are great entry points into software development, as long as your expectations are realistic. If you have the time and money, an accelerated program might be a great catalyst for your future career. In doing so, however, stay mindful that you are only dipping your toes into the water—there is a long journey ahead of you. To be clear, I am not dismissing boot camps, I’ve seen a select few that have trained great developers and provide thorough programs. I will issue a warning, though, for anything that is advertised as a shortcut— when it sounds too good to be true, it always is.

  Structure Helps

  When you’re a Level 1 Warrior, you will need some structure to get started. At ground zero, you don’t even know what you don’t know. This is when the core benefit of an academic institution—the curriculum—has huge value.

  One of the biggest pain points I’ve seen with aspiring developers is that they’re not sure what to study first, what to study after, and how to fill in the blanks. I have seen exceptions to this, but only among people who have previously experienced structured learning. For example, a previous candidate I interviewed held a PhD in mathematics and was able to pick up programming in a few months with no problems. He had already developed the habits and analytical intuition to steadily progress through coding. If you’ve been a freelance blog writer since high school, the knowledge path might not be as clear.

  With school, this path has been paved for you; all you have to do is put in the work. These roads are not so clear once you leave academia. Whether you choose to go to school or not, I highly recommend using a structured curriculum in the beginning. You will be flying blind and wasting your time otherwise.

  Conclusion

  Committing to school is a significant decision for anyone. If the circumstances are favorable and your objective is well-defined, I think the full classical four-year degree provides great benefits. However, your situation will be unique and you will have to make your own call. There are countless examples of successful software developers who did not come from the classical approach. Finally, do not forget about the habits and mindset behind a strong work ethic. Whether it’s through school or on your own, this value must grow and stay with us for our entire lives.

  14: Cross-Disciplinary Assumptions [Daily Life]

  I met Billy in San Diego, while he was writing code for a defense contracting company in Los Angeles. Since then, he switched career paths to become a product manager (PM) and now works in New York City. When I asked Billy about his juiciest stories, he prefaced all of them with one major theme—the over-simplification of someone else’s work.

  As a non-developer, here’s the worst thing you can say to a developer:

  “Hey Joe, these new features shouldn’t be too hard to implement, right?”

  Five years ago, I made the transition from developer to product manager. What is a PM? An easy, but unrealistic, reference point is Steve Jobs. Think about Steve for three seconds—then come back down to reality. A product manager is someone who is able to generate a vision, communicate it to the people that need to implement it, and facilitate its iteration. He or she will understand the customers and uncover their pain points. At an even higher level, the PM will uncover things the customers don’t even know they want. A company’s revenue and brand are defined by its products. The PM is the one responsible for managing its development.

  A product manager is someone who is able to generate a vision, communicate it to the people that need to implement it, and facilitate its iteration.

  The easy part is generating the vision; ideas are cheap. The meat and potatoes of the work revolve around communication and implementation. The scope of product and your responsibility will vary. At an ivory-tower, Steve Jobs level, you dream up the idea of the iRocket and an army of people under you build it. Small startups employ a single PM to create a holistic product, style, and brand for the company. For larger companies, product managers are placed hierarchically, just like any other role. You might be managing a couple new buttons for iTunes, or you could be planning Apple’s ten-year roadmap.

  Overall, this is a thankless job, and I concede that it is often filled with a healthy amount of baloney. The bottom line for a PM focuses on how well the product is doing, yet this is most likely out of their control. From my experience, responsibilities are split between two themes: research and implementation.

  For research, you must dig into analytics, locate the elusive “market fit,” and determine how the product integrates into the business. You must study the competition, conduct consumer studies, and make decisions about what should or should not be built. The implementation is trickier because the PM doesn’t implement anything. This comes down to getting everyone else on board to deliver and iterate on the product. The day-to-day of this work is nuanced and complex. It revolves around your salesmanship of the product, your communication skills, and the respect you garner from your colleagues. PMs will sway along this spectrum. Some will live in documentation and research, while others will just “get it done.” On the surface, this role appears to come with great power, but in reality, it is very much the opposite.

  As a PM, I’ve lost count of the number of heated clashes I’ve had with developers. Behind ninety-five percent of these situations, the root cause is always the same—we make assumptions about each other’s work. The developers tell me what parts of the product need to be cut, and I tell the developers that building out password reset is “no biggie.” I attribute many of these fights to me being a developer in my previous life. Cross-disciplinary assumptions are dangerous and can be a surefire way to rub someone the wrong way if you’re not careful.

  I take great pride in being an ex-coder. It has helped me communicate and empathize with developers; I appreciate their work more than most. My self-proclaimed title of “Technical PM” also has a nice ring to it. After school, I spent two years writing Java at a consulting company. We were fulfilling contracts for huge government projects. It wasn’t the sexiest job, but it was a job, and I got a taste of what it meant to sift through millions of lines of code.

  After two years of Eclipse grinding and stepping through break-points, I started attending customer meetings out of curiosity. Speaking with customers automatically turned me into the “Requirement Translator” for my fellow developers. Shortly after this, I was given t
he generic title of “Business Analyst.” I did that for about half a year before I picked up my first role as a PM.

  Why is my career transition relevant? Because I want to make one point very clear—no matter how technically inclined you think you are, you should never make assumptions about the technical implementations involved in any project. Let’s put that even more generally: you should never make assumptions about another person’s job. Period.

  I can’t control your thoughts. I can’t stop you from thinking, God dammit, this developer is lagging. I know this feature isn’t too hard! But I urge you to be careful when these thoughts arise. Thoughts easily leak into actions and subconscious behaviors. While your thoughts will always be your thoughts, your actions affect everyone around you. You must act tactfully to maintain a comfortable work environment for you and your colleagues.

  Everything we’ve talked about so far is what you should do. You must keep your assumptions in check, you must act with tact, you must respect the difficulty of someone else’s work. But what happens when this comes back around at you? As a PM, I get bombarded with product opinions 24/7. Every single department, from marketing, to design, to engineering, all have their own would-be-Steve-Jobs insights.

  Originally, for many of my cross-departmental conflicts, I felt justified in making engineering assumptions because the engineers were making product assumptions. If they kept telling me what to change in the product, I could keep telling them which features were easy to implement, right? No, this is the wrong way of thinking. Because someone tells me how to do my job, it doesn’t automatically give me the right to tell them how to do theirs.

  The core principle that has guided me through these fights is the humble acknowledgement of mutual purpose. Mutual purpose is a mindset that we must steer ourselves towards. It won’t be second nature for most. Always remember that you and your colleagues—despite having very different specialties—are working towards the same goals. You’re both struggling to get more customers and five-star reviews. You’re both on the line to get the project finished on time. In the grand scheme of things, your cross-disciplinary quarrels are dwarfed by the larger goals of the collective. Furthermore, your random issues at work are blips on the radar when you consider your whole life.