by David Xiang
No one could discount Martin’s technical skills; he had coding chops, stayed up to date with the trends, and was a natural with edge cases. Diva developers are usually good programmers, but they’re completely incapable of working cooperatively as part of a team. Martin’s arrogance drove him to believe that he and he alone should take on this project, without letting one single other person know about what he was doing. Not sharing his work with the team shows a total lack of respect for his colleagues, for their abilities, for the project, for its deadlines, and for the company itself. It demonstrated that he had a selfish reliance only on himself.
The ability to work as part of the collective, to be a team player, will always trump technical skill when it goes rogue.
In your journey, you will encounter many developers like this. The ability to work as part of the collective, to be a team player, will always trump technical skill when it goes rogue. Many 10x developers are let go due to this kind of behavior.
This story shines a light on another issue that happens often in software development: preferential treatment. Protection from bosses and biases in favor of developers is rampant in the tech industry. Companies put developers on a pedestal. After the ordeal with Martin settled down, I felt obligated to share my thoughts with my boss and also, more importantly, with Martin’s boss.
Regarding Martin’s boss, I agreed with his high-level priorities—Martin was to be spending his time getting up to speed with our code. However, I crossed my fingers, hoping that he would acknowledge how Martin’s behavior was disruptive to our preexisting team dynamic. Perhaps he could steer Martin in a better direction next time.
Unfortunately, that’s not what happened. With minimal thought about our remote team in China, Martin’s manager reassured me that this initiative was an innocent “learning project.” According to him, Martin should be able to take as much time as he needed to learn the ropes and make independent decisions on how to improve the technology. In addition, Martin’s reworking of the system would move more expertise to our main headquarters, something the company originally wanted.
Though I agreed that this sentiment was technically pragmatic, I still didn’t think it justified secretly rewriting big features or making a whole team upset. From my perspective, Martin and his boss had simply prioritized local engineering above all else. They had little empathy for the complications added to product development, for our offended developers in China, or for the serious butterfly effect that radiated out from his actions.
Nothing came of the situation. Martin continued being Martin, and eventually the teams were reorganized, with no effort spent on remedying the situation. This obscene bias towards engineering was shocking and demoralizing to the point where I came to accept it as company culture. No one should be put up on a pedestal. Developers are valuable assets, but that doesn’t mean they get a free pass to do whatever they want. Empathize with both non-technical and technical colleagues. Take time to understand what matters to other people and how your actions might adversely affect them. You might be the diva on your team, changing the entire dynamic without knowing it.
22: Leverage [Daily Life]
The word leverage is casually tossed around in software development and can take on different meanings across different contexts. The idea is simple, yet subtly abstract—we must focus on high-leverage activities to become effective software developers.
A high-leverage task benefits something bigger than itself and does so for an extended period of time. It is implicitly associated with a high return on investment. For example, a week spent implementing a smarter way to aggregate logs will save hours of debugging in the future. There are two parts to this definition. First, high-leverage work has the ability to elevate the work of the people around you—their jobs get easier, they gain efficiency, and the quality of their work rises. Second, high-leverage work creates long-lasting benefits; a one-and-done type of job just doesn’t cut it. Keep these two points top of mind, and work them into your daily developer habits.
A high-leverage task benefits something bigger than itself and does so for an extended period of time.
Onboarding
A thorough and well-designed onboarding is a no-brainer high-leverage task. This is paramount for any organization and will dictate how efficiently developers are integrated into the flow. Thought and effort must be spent here; a good onboarding system should grow and last the lifetime of the company. There’s a reason companies fly employees across the country to attend orientations.
Technical onboarding revolves heavily around your initial projects. For the engineering managers out there, take the time to think of assignments that will bring new-hire team members up to speed as effectively as possible. Consider who they have to interact with, what code they have to touch, and the progression of difficulty. For all the new developers being assimilated into established teams, put in the extra mile to integrate yourself; you’ll have to do more than just that simple starter project.
Documentation
Documentation is invaluable. If possible, document your work from project inception all the way to launch. Anything from an informal technical proposal to a polished wiki page holds value. Documentation reinforces design decisions, keeps you organized, and is an excellent evergreen resource for the rest of the team. Knowledge must be persisted and disseminated. I guarantee that you will forget your own code decisions and thought processes less than a year after you made them.
Data Accessibility
It’s highly likely that you will be collecting and managing data at work. Whatever it might be, your employer has deemed specific data to be precious, or else you wouldn’t be collecting all those bytes. Data is an important asset. Many of your colleagues—across many departments—need access to it.
Data is an important asset. Many of your colleagues— across many departments— need access to it.
Do whatever it takes to make your data accessible to the rest of the company. Huge software companies like Tableau owe their very existence to this concept. Tableau’s service provides an intuitive way to plug into any data source and generate graphs, reports, and CSV dumps. Data is only useful if you can extract and make sense of it. Large companies will have teams dedicated to data accessibility. If such a team doesn’t exist where you work, then there’s room for you to implement something!
Design Patterns
Injecting software design patterns into your team’s routine is a double-edged sword that has the potential to be a high-leverage task. Patterns give consistent answers to questions like how to implement certain features, and they can neatly organize your software. However, they can also be areas of contention if other people aren’t committed to following the patterns.
For ninety percent of software use-cases, existing patterns solve existing problems. For example, many people hate on Ruby on Rails, but I enjoy it. It may not be the most performant, it may not be the trendiest, but it is simple and it works. Ruby on Rails has well-defined patterns to help you implement web applications. As long as you’re not expecting Facebook-level traffic, Rails is a great solution for many small to medium-sized projects. The framework is a strong solution because it defines simple, re-usable design patterns. No matter what feature you’re implementing, if you follow the Rails convention, everyone on the team will understand your work.
Let’s imagine that you have been assigned to implement a standard-protocol email authentication flow. Nothing fancy, a simple feature with a simple implementation. If you hold dearly to your personal preferences and refuse to adopt the Rails design patterns, performing a custom implementation would be a selfish act on your part—you’ve just sacrificed longevity and readability for ego.
There will be times that call for custom implementations. This is when no existing Rails design pattern fits the spec. These scenarios are rare, but they will happen and there’s no reason to force convention on an unconventional situation—a custom problem warrants a custom solution.
> Understand Neighboring Applications
When an application you’re working on has neighbors, other applications and services that have a direct dependency on yours, it’s easy to bury your head in the sand and treat them as someone else’s problem. Do not do yourself and your neighbors this disservice. While it might be unreasonable to expect a Google programmer to understand the company’s entire technical landscape, I would highly recommend that you do your utmost to understand the neighboring software around you—do not silo your expertise.
Nevertheless, understanding the technical nuances— even at just an interface level— across applications will be a high-leverage activity.
If you work at a small company, the system will be small and you will have an in-depth knowledge of the various subcomponents. If you work at a larger company, there’ll be too much technology for one person to track. In these scenarios, you must mentally encapsulate functionality into black boxes and trust the system. Nevertheless, understanding the technical nuances—even at just an interface level—across applications will be a high-leverage activity. You’ll realize the fruits of your labor when it comes time to collaborate with other developers and teams. Armed with a solid understanding of their systems, you’ll be able to architect something much more robust than if you had limited yourself by hiding in your cave.
Conclusion
For any assignment, always ask yourself the two high-leverage questions: Does this benefit something bigger than me? Is this going to last a long time? Before you get too eager, remember that there will invariably be times when you’re pinned down under a mountain of work. While there’s no escaping coding crunch times, the best thing you can do is to periodically brainstorm ways to add leverage wherever you can. A quick document or a simple graph can go a long way. Soon, you will develop a sixth sense for leverage and you will easily uncover and make the most of it.
23: There Is No One-Size-Fits-All [Learning]
For people starting their journey into software development, the road can be daunting. There’s a lot to learn, a lot of different ways to learn it, and a lot of endgame scenarios that you’ve painted for yourself. Many people at this level suffer from learning-paralysis. In their minds, they have created black-and-white paths for learning: Should I take this Udemy course or this Coursera one? As they become preoccupied with choosing the best path, they become indecisive with their actions.
If you’ve ever struggled with these kinds of choices, I can empathize; the number of courses, blogs, evangelists, and JavaScript frameworks makes my head explode too. If there’s one thing to remember though, it’s this—no matter what anyone claims, there will never be a one-size-fits-all plan for learning.
I’ve been asked countless questions about educational choices: Should I major in computer science or computer engineering? Is Python better than Ruby? Is learning C worth it? These questions are ultimately shortsighted and can pigeonhole you into a limited set of options that you have arbitrarily created for yourself. For example, let’s consider this question—will learning C make you a better developer? If you’re just trying to become technically literate, there is no reason to learn C. If you’ve decided you’re going to get into enterprise software, then a quick Intro to C course wouldn’t hurt, but you don’t need to get into the weeds of bit shifting. If your end-game is to write device drivers or contribute to the Linux Kernel, then learning C is critical. Getting clarity in your long-term goals will enable you to ask yourself better short-term questions.
…no matter what anyone claims, there will never be a one-size-fits-all plan for learning.
The tried-and-true way of learning is no secret—foundation. Elon Musk relates this to a tree. If you try to reach out to the branches without the tree having a strong trunk, you will fall. But if you develop fortified roots and a sturdy trunk, the branches you reach out to will be firm and steady.
Don’t go off and learn about the nitty-gritty details of the latest web framework before you understand the basics of the Internet. Imagine a standard breadth-first-search. You start by performing a well-rounded foundation traversal. After one level, you dip your toes into some intermediate topics. Before going too deep, make sure you come back up a level to reinforce the basics—then dip your toes back into the deep end when you’re ready. Before you know it, your baseline level will have elevated and you’ll be conquering advanced topics. Perhaps this is how Elon Musk went from programmer to rocket-builder.
There will never be a silver-bullet path to learning, programming, dating, politics, or life. Be wary of the strong opinions of others; it is impossible for anyone to tell you what is best—there is no best language, there is no best framework, there is no all-or-nothing, there are no absolutes. Everything in life comes with pros and cons that you should judge for yourself. When you’re a beginner and deciding how to learn, do not trap yourself with learning-paralysis. If you catch yourself looking for The Best Way, stop.
You will only frustrate and disappoint yourself if you believe in absolutes.
Keep your mind open and be receptive to different perspectives. Don’t trick yourself into believing you need to learn one specific language. Learn as many as you want. Don’t think you have to learn React because everyone else is. Try it out yourself and see if you like it over Angular. You will only frustrate and disappoint yourself if you believe in absolutes. This mindset is the root cause behind most of the questions I’ve received. I’m always happy to guide people through these questions, but the essence of my answer will never change. The answer is for you—and only you—to decide.
24: Your Boss [Career]
Throughout your career, you’ll find yourself working under many different people. Some you may hate with a fiery passion, some you will show great deference to, and some you will consider to be incompetent.
If you end up with the perfect boss who respects you, is pleasant to work with, delegates wells, acts as a mentor, provides challenging work, pays you well, and looks out for you—then you have struck gold! For the individuals who truly have no boss, who own their own companies, owe no debts, and have shared no equity—this chapter might not be very relatable. For the rest of us, we answer and are responsible to someone else, and that person isn’t always perfect.
Always Respect Your Boss
This has happened to me, my parents, and to all my developer friends at some point in our careers. There is always a boss who we believe to be a bumbling idiot. He or she has no insight into the code, isn’t managerially or technically competent, and seems to have the easiest job in the world.
For some toxic organizations, these unfortunate situations may be a reality, but for the majority of cases, these feelings are rooted in your personal perspective. It’s easy for us to judge someone based on the criteria of our own job rather than theirs. As a software developer, you cannot judge an engineering manager by their familiarity with the code—that’s not their job.
Your position is no harder or more important than any another position; it is just a different one.
In any organization, each person has a unique role. There are people with boots on the ground and there are the middle managers overseeing execution. Directors manage big budgets, while executives play a game of thrones. Every position is important and has its own problems to deal with. Your position is no harder or more important than any another position; it is just a different one. Your boss’s role in the company is different than yours. You must respect that.
It’s easy to label someone incompetent if they don’t know the ins and outs of your job. This is naïve and unfair. I’ve been guilty of this on numerous occasions, and when I’ve recounted my experiences to friends and family, they’ve all shared similar feelings. Catch yourself early if you’re guilty of this.
Always Make Your Boss Look Good
As mentioned earlier, the vast majority of us answers to someone. You answer to your tech supervisor, who answers to a VP, who answers to the CEO, who answers to the board, who answ
er to the shareholders.
The lesson here is simple—if you make your boss look good by delivering great work, you make yourself look good. This will naturally make other people notice you and perceive you as a valuable asset—someone worth having on their team. At the end of the day, consistent high-quality work trumps playing politics and schmoozing. Making your boss look good not only builds value with your immediate team, but it builds value in the perspective of people around you—that is priceless. Write some good code for this project? You’ll get asked to work on more important initiatives next year. Successfully manage and operate an engineering team? You’ll get some VC’s attention when you’re looking for funding.
This simple premise carries through at every single level. Many people who are unmotivated at their current jobs immediately look towards other opportunities. This is a loser’s mindset, a mentality that must be your last resort. Don’t underestimate the leverage you can obtain—and the dollars you can earn—through solid, consistent work at your current position.
When you start feeling the pressures of demotivation, consider everything you can do to personally steer your own ship around. Your environment and your attitude are intimately related; you’d be surprised how things start to feel better just by keeping your mind positive. In the unfortunate scenario that you really need to look for other opportunities—perhaps to leave a toxic environment—then do so cordially, burn no bridges, and give your current position your all while you’re still there.
No matter your situation, put in solid work, stay positive, and make your boss look good. Across the many chapters of your life, your good work and healthy attitude will accumulate, and this will inevitably lead to positive results.