by David Xiang
If you find yourself stuck on a particular concept, ask yourself: is there a simpler concept beneath this that you do not fully understand?
How Does A Computer Work?
I often meet developers who can write code but don’t understand the basics of a computer. It’s easy to get your program up and running and have the system do its thing, but it makes a huge difference if you understand what the computer is doing with your software. How does the operating system switch over to your code? What kind of resources is your software utilizing? Software is the highest interface we have to computers. There is a colossal stack underneath it which controls how electrons flow through metal and travel around the world. The more you understand that, the more empowered you will be as a developer.
Conclusion
Throughout your progression, stay true to your level. Not only is this a good practice in humility, but it is also good training for your brain. When you’re at a low level, you should be eager to ingest more knowledge and level up. When you’re at a high level, you should be eager to accept re-affirmations to reinforce your foundation. Learning is meta—there is a lot to learn about learning itself. Stay humble and open-minded and the world is your oyster!
3: Writing Emails [Daily Life]
Every position has a set of ideal traits. The relentless salesperson makes 9,000 calls a day, stays positive through endless rejections, and burns the midnight oil prospecting. The pixel-perfect designer mocks out every edge case, stays aligned with the vision, and keeps up patient dialogues with impatient customers. And what about the developer? We think clearly, communicate effectively, and build mission-critical applications. Sound a little too good to be true? Well I did say they were ideal.
Let’s dissect one of these attributes—clarity of mind. Every trait we possess is ultimately measured by the external perception of others; your self-perception and self-confidence can only validate your skills up to a point. To put it simply—what your colleagues think of you matters, a lot. This is our personal brand.
Wait a second. Doesn’t this idea of personal branding go at odds with the age-old lesson of not worrying about what other people think of you? Be careful. Not worrying about what others think of you does not give you a free pass to do as you wish and behave haphazardly. In our professional and personal lives, we must put our best foot forward, and then let the people around us settle in with their own conclusions. You’ll never be able to control the judgements of others so don’t get attached to it. Keep things simple and you will surprise yourself with its positive results. Put in work, add value, and there won’t be anything to worry about.
Not worrying about what others think of you does not give you a free pass to do as you wish and behave haphazardly.
Our personal brand is rooted in two things: raw value and how we express ourselves. Your value as a developer is easily measured. Code well, execute consistently, and be a team player. We’ll talk more about coding later, but for now, let’s focus on personal brand. Your brand is developed through how you express yourself. One of the most overlooked forms of expression is how you write emails. Emails are pervasive and directly showcase one’s clarity of mind. Just like your code, everything you write must be done effectively, thoughtfully, and with intention.
Context
The context—or Slide 0—must be presented first. Don’t make any assumptions about your recipient’s understanding of what’s going on. Paint the picture for your audience and do it in less than three sentences.
Formatting
The power of visual formatting must not be underestimated. There’s a reason why we’re picky about diff tools, enjoy JSON parsers, and code up pretty() functions. With emails, formatting is essential and must be used purposefully; basic grammar, spell-checking, newlines, and text-modifiers are necessities.
There are no hard rules. Your style of writing, coding, and thinking will always be your own.
There are a few techniques that are worth mentioning. Underlining is useful for creating contextual titles, breaking up long text, and providing helpful highlights. Bold is an amazing modifier that can direct attention, emphasize points, and create clear call-to-actions. Finally, let’s not forget about the versatile and ubiquitous list. Lists are universally understood, flexible, easy on the eyes, and automatically organize your thoughts. What are the potential solutions for this new authentication feature? Well, here are three options: A, B, and C. Lists also give your recipients a convenient way to respond quickly to your suggestions:
“Joe, I think option C is alright, B is subpar, and A is money!”
There are no hard rules. Your style of writing, coding, and thinking will always be your own. As you develop and write your thoughts down, stay conscious of formatting; it’s one of many tools on your belt for effective written communication. Develop your style, be consistent with it, and make your work an easy read for everyone.
Expectation
All your emails must have a clear expectation. If you need a specific response, ask politely and directly. If it’s an FYI email, clearly put [Memo] in the message so there isn’t any awkward obligation for a response. What are you looking to get out of this email? Just checking up on a deadline? Disseminating critical information? Simple status update? Looking for feedback? An expectation must be set.
Stay Warm
“Hope you’ve been having a great week” goes a long way.
Appropriate Usage
Email is one of many mediums of communication and has its own time and place. When do we not use emails? If you need a simple response, send a direct message, or take a walk across the office. If you expect heavy discussion, organize a meeting instead of starting a snowballing thread. If you need something ASAP, make a phone call, leave a message, and contemplate why anything would need to be so urgent. Appropriate discretion and tact should surround every form of communication.
Add Value to a Thread
If you work at a large company, you’ll witness the phenomenon of the snowballing email chain. These are giant threads where employees play hot potato and respond with convenient one-liners that add zero value:
+Bob. Bob knows about this module. Cheers,
—George
Cheers for nothing, George. Do not do this. If there’s an expectation for you to respond, then do so with value. If you have to pass the potato, pass it with class. Do the homework and explain why Bob is better suited to answer the question. Furthermore, give Bob the context and information he needs to respond. Bob will appreciate the gesture and won’t have to scrub through the massive chain. Eighty-five percent of people on these threads add nothing to the discussion; do not be one of those people.
Real-Life Alignment
Keep the tone of your emails aligned with your real-life behavior. Your word is your word, and your offline and online personas must be consistent. Acting boisterously in emails only to become passive aggressive in real life is a bad look. People’s digital perception of you must make sense when they speak with you directly. If you really feel the need to anonymously troll, Reddit will always be there for you.
Conclusion
Emails are a low-pressure, asynchronous way to communicate. Use them to generate thoughtful responses that do not require immediate action. Emails allow people to read, digest, and respond in their own time. Compose emails well, use them appropriately, and remember to give your Slide 0 context. Everyone will nod their heads at your well-organized thoughts and you will earn the respect of your colleagues.
4: The Angry Guy [Coding]
One person’s beloved design pattern is another person’s hated anti-pattern. For everything that you believe is awesome, there is a person out there who thinks it’s garbage. Opinions aside, the number one complaint among my friends in software has always been the same—the aggressive, angry, big-headed developer. There’s always one wherever you work, and the character attributes are almost always the same. This is someone who has a wealth of knowledge and possesses awesome
technical chops, but stays stubbornly bullish about their way being the best. At best, they become an inconvenience to work with, and at worst a genuine reason to quit the job.
For everything that you believe is awesome, there is a person out there who thinks it’s garbage.
As developers, we must strive to write exceptional code, keep an open mind towards others, and not become the aggressive developer. Software development is hard, but most of the time the hard part isn’t the coding—it’s working with other developers. Dealing with big egos and rigid personalities can be stressful for everyone. Luckily, there are strategies to handle such challenges.
Fighting Fire with Fire Never Works
An ancient Taoist teaching says it best—you never fight fire with fire. It’s a very simple lesson that is easy to follow as long as you control your emotions. If a boisterous developer enjoys yelling, you’ll achieve nothing yelling back. One of these personalities is difficult enough; having two of them can be disastrous. There are other ways to deal with this.
Let Them Talk with The Right Questions
It’s smoother for them to re-rationalize their argument rather than accept an unwelcome critique from you.
An aggressive developer will be bullish with his or her opinions. It might be a naming convention, specific third-party libraries, a language, or tabs versus spaces. Stubbornness tends to follow the aggression. These developers aren’t ones to easily back down from their opinions, even if you’ve spotted legitimate cracks. When you’re on the receiving end of this, clarifying questions work well to gain insights into the other person’s thoughts and can potentially disarm their position peacefully.
A great question to ask is, “Could you help me understand this part better?” Two things happen in this question. First, you showcase humility by qualifying the question with your mental slowness. It’s not the aggressive developer’s opinion, it’s just you not being able to keep up. Second, no one minds explaining their own thoughts further to help someone else understand them better. If someone takes offense to this question, you have met a true jerk.
Another similar question to ask is, “Could you clarify this part?” This is slightly more direct than our previous example, but its purpose is the same. The goal here is for you to selectively direct the developer’s attention to the cracks. It’s smoother for them to re-rationalize their argument rather than accept an unwelcome critique from you. You might not have to do any arguing at all.
During Disagreements
Inevitably, any software development team will have some conflict. When this happens, your approach is very important; you must never disparage the opinions of others. If you talk another’s opinion down, you’ve bought yourself a one-way ticket to a grudge. A dispute over a software design pattern should never turn into resentment between colleagues.
During a technical disagreement, there will be a con for every pro you’re fighting for, and the same goes for your counterparty. You can’t target the bad parts of someone else’s opinions, only to stay conveniently unaware of the bad parts of your own. Your opinion has its own flaws and a technical decision will never be black-or-white, it’s merely the best choice you can make to solve a particular problem given a particular circumstance. Disagreements are productive conversations in disguise—use a peaceful approach to uncover them.
Do Not Silo Them
Do not isolate the aggressive developer! I made this mistake when I was managing a hot-headed programmer at my last job. It was the easy—but incorrect—way of handling the situation.
One of our star developers was getting out of hand, forcefully pushing his design principles onto his fellow developers. The team had become frustrated and our collaboration was slowly deteriorating. Instead of solving the issue as a team, I decided to silo the aggressive developer. My thinking was that I would minimize his interaction with the team, keep him producing code, and enable a safer atmosphere for the other developers.
Unfortunately, the developer took this as a green light to start doing everything his way. He no longer felt any obligation to sync up and used this new independence as a trump card for technical decisions. He proceeded to re-write people’s code out from under them and wreaked havoc across development.
The team was now even more frustrated. Someone they had zero contact with was hindering their development. Before, they could at least interact with him! Eventually, we had to let that developer go, even though he was one of the strongest technologists at our company. As the manager at the time, I take full responsibility for that unfortunate outcome. It was a great learning experience for me, and I hope this mini-story can show you what not to do if you’re ever in this situation.
Keep Your Mind Open & Watch Out for the Halo Effect
The big-headed developer that you can’t stand might inadvertently be caught in a vicious psychological cycle by his or her peers—you. This can be caused by a phenomenon known as the Halo Effect. This is when your initial impression of someone influences every single thought you have about him or her thereafter. For example, someone rubs you the wrong way during their first month on the job, then all of a sudden everything they do starts to annoy you. You had one heated argument over table schema, and all of a sudden, this person seems grossly incompetent.
Always be aware of your bias and remember that no one is all good, or all bad.
If this sounds familiar, take a step back and keep your cognitive bias in check; that aggressive developer is not a bad person. Keep an open mind at work because it’s extremely easy to develop a Halo Effect for everyone around you. Always be aware of your bias and remember that no one is all good, or all bad. You yourself might be seen as that huge incompetent fool at any time in any position throughout your career.
Dynamic Relationships
Every relationship has a different tone. This is a natural part of life; your dynamic with your sorority sisters isn’t going to be the same as the one with your office colleagues. While it’s normal to switch up your tone, your core personality must remain consistent.
A recurring theme with angry developers is the personality switch. They might be very warm towards you, but then quickly change personas and disparage another colleague. They are cordial in a meeting with the boss, but rudely criticize code behind closed doors. This looks bad in any professional setting. If this sounds like you, be careful.
Conclusion
You will encounter many unique personalities in your career; the angry and bullish developer will show up all over the place. Remember that it’s unfair to typecast anyone as the bad developer—every situation you encounter will be different, with different people, under different circumstances. Even though the technology will always be your craft, you can’t neglect the inter-personal aspects of working in software. Behind all the code, there are the people that wrote it, and behind every person, there is an ego.
5: Into The Deep [Stories]
This story was told to me by my friend Patrick, a mobile developer and fellow CMU brother-inarms. Patrick is two years my senior and made the switch from mechanical engineering to software development shortly after graduating. Pat is known for throwing himself into new environments. His free-spirited nature applied to engineering classes as well as our social life; parties were always more fun when Pat was around. Patrick’s unfettered approach to the unknown inspired me to push myself harder at CMU.
When you read about Pat’s learning style, you may find that it goes at odds with my previous championing of basics, fundamentals, and foundation. If you find yourself paralyzed with next steps, a full-force jump is a great springboard into learning something new. However, this is only the entry point. It is not—by any means—a substitute for the basics; it is just a start.
The pressure is on, crashing and burning is a possibility, and leveling up is a certainty
The easiest way to learn is to jump into the deep end without knowing how to swim. This is the WordPress veteran signing a contract to write a Rails app for the first
time. This is you stumbling into a new job that you are grossly unqualified for. The pressure is on, crashing and burning is a possibility, and leveling up is a certainty.
Back during CMU, I went through this repeatedly. I have vivid memories of every engineering class. If it wasn’t the excruciating amount of work, it was the eccentric professor, the jerk teaching assistant (TA), or the progressively challenging exams—there was always something. However, these sensations of drowning would inevitably turn into a dawning realization that I’d gained tremendous amounts of knowledge. I call this forceful learning. It’s an amazing way to grow as long as you can deal with the high levels of stress that come with it.
As a mechanical engineer, I decided to take a class in computer-aided design from the Computer Science (CS) Department. The class description had something about 3-D modeling in it. I signed up with the support of some rational logic: 3-D modeling kind of sounds like 3-D printers, and 3-D printers are related to mechanical engineering, right? Sounds reasonable—sure. I had no idea what I was getting into, but I wasn’t going to leave CMU without taking at least one CS course.
First day of class rolled around and the professor handed us the syllabus. It turned out that we’d be developing a full suite of 3-D modeling software from scratch. Immediately, I realized I was in way over my head. I hadn’t given the course description more than a cursory glance; I wasn’t expecting there to be that much coding involved. I was hoping for some nice hand-holding like the tutorials I found on the Internet. This class had barely any lectures. The semester was going to be dominated by coding labs. Luckily, I had been through these enough times in the past and my engineering mindset kicked in.