by David Xiang
Reduction
Always look to make reductions. You don’t need a hundred gadgets lying around collecting dust in your home, and you don’t need to keep random interfaces and layers of indirection around in your software. Extra gadgets and useless code become attachments that weigh heavily; both life and code become much easier without them.
Our code should do exactly what it needs to do—nothing more, nothing less.
Reduce your code, but maintain its functionality. Is this feature completely deprecated? Make a sincere effort to truly deprecate it instead of just marking it as @Deprecated and forgetting about it. Is your solution a little preemptive? Don’t include it yet! Stash it away and save it for later. Premature optimization and over-engineering should be familiar phrases.
As much as we love to add new code, deleting code can feel very therapeutic. Everyone loves to see a code review filled with red lines. Our code should do exactly what it needs to do—nothing more, nothing less.
Fixing Problems Doesn’t Make it Better
It’s easy to get caught up in day-to-day bug fixes and fires. If we fix problems, we feel pretty good about ourselves, but be careful—fixing problem after problem implies applying patch after patch to the codebase. Too often, we nonchalantly make change on top of change, feel content about iterative improvements, and move on with our day. If your team has been doing this, take a step back and ask yourself if fixing these problems is doing more harm than good. Chances are that you are introducing more complexities into the system, which will get in your way further down the road.
Challenge the Fundamentals
In order to simplify the system, you must challenge the fundamentals. Every software system has a custom foundation—this may be five very important classes, a specialized protocol, a colossal database table, or perhaps just a special way of writing files. You might have written this foundation yourself or merely inherited it. You start to notice that for every change introduced and for every problem fixed, you and your team rely on this foundation to behave like it always has. After long periods of time, this foundation becomes set in stone inside the company’s software and becomes increasingly intimidating for anyone to change.
None of us are fortune tellers; we can’t guess our future requirements or predict what our clients will demand of us in the next year. It’s impossible to build a system that is flexible enough to withstand every use-case with ease. There will invariably come a time when you’ll be faced with some difficult implementation decisions.
Should you really introduce that hacky code path? Should you really just add a bunch of columns to this colossal table? Remember, nothing is impossible! What if you challenged the fundamental building blocks? What if you could change something in those five classes or those shared interfaces? What if you could split apart that insane table or the monolithic Mongo collection?
The benefit of such work is hard to fathom for people outside of the software. Company executives and management will be reluctant to spend hundreds of engineering hours on something that seemingly provides no value. You can’t blame them; technical debt is hard for anyone to measure who isn’t familiar with the code. Nevertheless, it’s up to you—the developer—to be the biggest proponent of the company’s code. It’s always possible for the foundation to change, and it may be one of the most significant initiatives that the company will ever pursue. Hundreds of hours spent this month might save thousands of hours next year!
Primitive Rules
I’m constantly amazed by the raw power of primitive building blocks. Sprawling Minecraft cities are constructed with stackable rectangles, complex space theories are formulated from simple laws of physics, and a bunch of transistors and electricity can give us smartphones.
This is the magical part of technology. Every layer of tech—from hardware to software—encapsulates away the details and provides shiny interfaces for its users. Stack a collection of these layers together and you can create mind-blowing systems. In order for a system to scale and change the world, its citizens must abide to a set of primitive rules. Consider the Internet—follow its rules and you gain access to a global network, reach billions of people, and store an infinite amount of data. Whether it’s your computer, your phone, your refrigerator, or even your smart-mattress, it can get online as long as it follows the basic rules of the Internet.
A microcosm of this idea lies within the codebases that we work inside during our day-to-day. The software we craft is miniscule compared to the Internet, but it’s still a complex world that we’ve constructed. What kind of primitive rules can we establish for our software? Perhaps a strict set of interfaces must be adhered to, or maybe a complex network acknowledgment protocol must be established. Outside of software, you can also establish rules around process. Post-mortems to complete after outages or methods of managing tech debt can be great things for the team. Primitive rules can help anywhere.
I want to issue a warning to everyone. Many of your colleagues will brush off these ideas as trivial when you first introduce them. The nature of primitive rules is that they are extremely simple; other developers will inevitably label them as unnecessary procedure. Don’t let this deter you! Spend some time brainstorming these rules for your software. Always remember that it’s the simple rules that enable the mind-blowing systems.
33: Feeling Left Behind [Career]
One of the most pervasive sentiments for software developers is the feeling that they’ve been left behind by the tech industry. I received an email from a software developer in India who had been working for IBM for four years. The general tone of the email was one of anxiety; the developer was worried he wasn’t keeping his skills up to date and was stressed out from working with a codebase that dated to 1995. This chapter is a breakdown of that email.
Working on Irrelevant Tech and Falling Behind
The unfortunate news is that if you’re not careful, you will get left behind, becoming less desirable to employers, and have anxiety flood your veins. Find solace in the fact that you are not alone; millions of developers around the world face the very same challenges.
It’s a balancing act keeping yourself up to date—periodically picking up new skills is a must, but you don’t need to hop on the bandwagon of every new web framework. However, if you do absolutely nothing—if you pick up zero new languages and refuse to try anything new— then of course you will fall behind. Imagine trying to go against the direction of a moving sidewalk at the airport: sprint and you get ahead, walk and you stay in place, stand still and you fall behind.
You need to make a judgement call on how close you stay to tech’s latest and greatest. This call is yours to make and will naturally depend on your life situation, mood, and personality. If you’re young and hungry, then staying up to date with the tip of technology might enable you to hop around jobs, make top dollar, and remain a hot commodity in the system. If you have a mortgage and are looking to chill, then keeping the status quo going and continuing to do a solid job at work could be your priority; you probably don’t need—or want—to become an AI/self-driving car/Internet of Things/crypto-currency master.
In my opinion, the most practical and realistic way to stay comfortably relevant is to position yourself in the right environment. There is only so far you can progress if your job description is “maintain code from 1995.” The frustrated email author still had a major asset: he was a software developer for the legendary IBM. On paper, this is very impressive—many people would kill to be in his position.
Employment at a big corporation can be a luxury. There are many options for work across a diverse set of teams and projects. Compare that with a startup where the execution of a small set of goals takes precedence. If you don’t like the work, you’re out of luck. I am totally positive that IBM has teams in every facet of technology, from mind-numbing legacy code maintenance to quantum computing. What could the emailer do within IBM to position himself better? In the unlikely scenario that there were absolutely n
o other opportunities for more progressive work at IBM, then it might be time to look elsewhere.
The importance of environment is rooted in basic biology. You, me, your developer colleagues, Elon Musk, Bill Gates, we’re all human. For each waking day, we all have a tank of energy points that get slowly depleted until we wipe out. Despite what anyone might say, it’s not feasible to work at one-hundred-percent velocity for sixteen to eighteen hours a day. Mother nature does not work that way! One person might be more efficient than you with their tank, but at the end of the day, everyone has a limited supply of energy. By the time you get home from your regular nine-to-five job, your tank may easily be running on low. You might not have enough gas to work on those side projects.
This is why your environment is crucial. Your work situation will use up a lot of your energy. Your energy expenditure must be aligned with what you actually want to work on. Many of us will never achieve a perfect alignment between the two, but we have the power to get them into the same ballpark. The alternative scenario is very bleak—spending your energy on things you don’t care about. This isn’t enjoyable for anyone.
A switch in environment, even if it’s not perfectly aligned with what you want, can significantly improve how you feel about your time use. This may mean switching to a neighboring team, transferring departments, or moving to a brand-new company. Take drastic measures if you have to, in order to align your energy with the right environment.
There’s Too Much to Learn
In his email, the author listed over ten different technologies that he felt he needed to master. The list was a hodgepodge of languages, frameworks, and general concepts—he was paralyzing himself with so many options.
This is not ground-breaking advice: you must laser in and focus on fewer things. Humans operate concurrently. When we take on too many tasks, none of them are done well. Just like a CPU, context switching is an expensive operation for our minds.
Just like a CPU, context switching is an expensive operation for our minds.
This “option overload paralysis” syndrome is pervasive in software, due entirely to the sheer number of implementation possibilities. There are a million ways to do one thing. Furthermore, we have millions of biased opinions to accompany them. Don’t get distracted by all these learning permutations. Focus on less, get more done.
Biology
Setting yourself up to learn ten things means setting yourself up for disappointment. Often, we are the root cause of our own frustrations; we stress, over-complicate things, and make simple things difficult. As easily as we can become frustrated, we can lift our moods. You’ll be surprised by how much is in your control—it’s all about setting yourself up for the small wins.
Our emotions originate from signals and neurotransmitters in our brain. All those complicated moods and feelings are chemical reactions. For those of you who enjoy living on the wild side, you’re already aware of how that chemistry can be artificially manufactured. Be careful—borrowing energy and happy moods don’t come for free! For the rest of us conservatives, there are a number of natural ways to encourage those dopamine highs. I’m not talking about Instagram hearts or Facebook likes; I’m talking about shipping your app, passing the test suite on your coding assignment, and squashing a tricky bug—those are true moments of happiness for coders.
These wins can easily be replicated. A good place to start is with to-do lists. Besides their primary organizational purpose, I believe the main benefit of the to-do list is to give humans that warm, feel-good sensation that comes with checking something off. The progressive completion of a set of tasks is the foundation of how we execute. Everything from your coding assignment, to your workout agenda, to your weekend errands are just lists of to-do’s. That feeling of crossing off a task that you’ve assigned yourself is a manufactured dopamine injection—and it feels really good.
I receive many questions about how to handle extremely large endeavors. People are unsure how to go about learning a whole new language or how to make a 180-degree career transition into software. These tasks are way too big in scope! Our brains are not wired to fathom them, let alone complete them.
This is why we always, always have to break things down into manageable chunks. Not only is this the practical thing to do in terms of execution, but it has the side effect of providing those small wins that our brains need to keep going. Next time you feel intimidated by your own goals, break them down and enable yourself to be rewarded; it’s all engineering and it’s all completely within our control.
Imposter Syndrome
The email author showed signs of budding imposter syndrome. Let’s first give him props—he achieved his current role of IBM software developer without going through the conventional CS degree route. Software has always had its roots in academia and is often associated with higher education. This lingering historical sentiment can be at odds with the newfound accessibility of learning software; more and more people who’ve made professional flips into software feel like imposters compared to their four-year-CS-degree counterparts.
Let’s say you got a degree in civil engineering, but made the switch and are now working as a developer. Despite the job title, you feel a mental drag because your background isn’t “pure.” When these feelings bubble up, remember that the civil engineering part of your life is over! If writing code is your job, I’m assuming that software has taken precedence over anything civil-related.
The only thing you have to focus on is being the best developer you can be right now; this means focusing on the present, on yourself. You already know not to compare your progression with that of others. You can dabble a little in the past to reflect on your mistakes or a little in the future to set up your goals, but the present is home base.
Sticking to the Basics or Following Trends?
Finally, the author signed off his email without any clear ideas about the future. He was torn between two options. On the one hand, he wanted to stick to the foundation, not blindly follow the trends, and keep things basic. On the other hand, he was becoming increasingly anxious about getting left behind.
…remember that having good foundation doesn’t mean you can ignore the trends—you have to do both simultaneously.
By now you know that I always preach foundation. But remember that having good foundation doesn’t mean you can ignore the trends—you have to do both simultaneously. If your foundation is strong on computing and software, then you can afford to reach out and dabble in some trends. However, if your foundation is weak, you’ll find yourself lost and stumbling if you reach too far.
Completely ignoring the trends is dangerous. Justifications like “that’s going to die soon” are cop-outs. Remember that everything that’s considered foundation today was once a trend—C++ was not always C++. Do you think you could have brushed off Java as too trendy back when it first came out? You really don’t know what will stick around. Always work on your foundation and simultaneously pay attention to the trends. Change is a part of software and life. Trends come and go, but that doesn’t mean you can neglect them.
34: Aligning Yourself With A Startup [Career]
This chapter is dedicated to anyone contemplating joining a startup. These ideas are based entirely on the world of small companies and are mostly irrelevant when looking at huge corporations. You join big companies for the brand, the benefits, and the free food— there’s not much to think about in terms of alignment. Google has a million things going on, and a well-aligned role is waiting for you if you try hard enough.
At startups, you don’t have such a luxury. Small companies will have a certain style and certain constraints. They will be at a very particular stage of their “business life” and will be looking to fulfill specific, explicit roles. Keep in mind that an explicit role is very different than an explicit technology. For example, a startup looking to get its minimal viable product off the ground is going to need a software generalist to put the disparate pieces together. This leads to a fund
amental question—is an explicit role aligned with what you want? The answer will never be obvious, but it’s very important.
Founder Style
The style, background, and personality of the founders significantly affects the entire company.
Influence from the top always trickles down. The style, background, and personality of the founders significantly affects the entire company. When you’re applying to startups, put in the research and find out all you can about the founders. A person with a sales background will run a company very differently to a computer scientist from MIT.
Is it Tech-Driven?
My definition of a tech company is one where the technology is the product. The performance of the company directly corresponds to a technical product it builds. Be extremely strict with this definition, because many businesses will falsely advertise themselves as tech companies just to keep up with the trends.
A Software-as-a-Service (SaaS) company is a tech company. Examples include Digital Ocean, CircleCI, or Atlassian. Their top-line revenues and profits are directly driven by software—technology is what they sell. Walmart, on the other hand, is not a tech company. Walmart is a retail company. However, Walmart probably employs hundreds, perhaps thousands, of software developers and pays them handsomely. You might be working as a developer in Walmart’s engineering department, but you can’t in good faith say you work for a tech company. Make sure you clearly delineate between companies that use tech as a complementary service and companies whose core product and service is tech.