8 Good Communication Habits for Early Career Software Engineers

Communication is a superpower. As you advance in your career, you are not limited by technical expertise, but by your ability to influence other people.

You might think, “I’m bad at talking to people.” That might be true today, but you can improve your communication skills. Good communication can be learned just as much as Big O runtime analysis.

Many people think it’s weird to intentionally practice good communication. Those people are jamokes and you should ignore their recommendations. You’re not a jamoke. You want to be respected by your peers. You want people to feel confident that you have the ability to make things happen. By doing good work and communicating its value well, you become a trusted engineer that people like to work with.

Without further ado, here are eight good communication habits that you can practice early in your career.

#1 Listen

I put this first because I think many people struggle with this. Everyone wants to talk, and no one wants to listen.

When you let other people talk, they are more than happy to give you information. When you stop talking and let the other person explain themselves, you can more accurately solve their problem.

I can’t count the number of times when someone (let’s call him James) said, “It’s easy, just do XYZ,” and proceeded to detail a long solution. Meanwhile, the other person wanted to interrupt James because James was solving the wrong problem.

#2 Better to over communicate than under communicate

Working hard is important. But it’s even more important to work on the right thing. If you’re unsure of what you’re supposed to do, try saying, “You want to do XYZ. Is that right?”

#3 Express genuine appreciation for a coworker’s specific action

When you notice someone do something cool, compliment them.

One of the best compliments I received was an offhand comment. A senior engineer came to my desk to ask about a class that I wrote. I showed him, and he remarked “That’s a clean API.” He made me feel confident that I had designed the class well.

#4 Be concise

Imagine a coworker casually asks, “Is the bug fixed?” You have two ways to respond:

“You know, I was, umm, working on the database issue, and the mobile client is having a little trouble connecting to the server, and, umm, I’m talking with the backend team, and I think it’s going to be alright, umm yeah, I’ve just gotta check with them later, and yeah, I think it’s just one of those things where I just gotta put more work into it because of the protocol. So…”


“Not yet. The fix will be ready tomorrow.”

Managers especially appreciate brevity. They have a lot going on, and they can only handle the bird’s eye view of the situation.

#5 Learn other people’s names

This is pretty obvious. People love it when you remember their names.

#6 Don’t give unprompted explanations

If someone asks why, tell them. If they don’t ask, you might not need to say. You sound less credible when you constantly justify your actions and questions.

Your friends already trust you. Your manager mostly cares about the end result. Your enemies will never believe you. (Hopefully you have no enemies at work. If you do, maybe it’s time to find a new job.)

#7 Build trust by following through with your promises

Trust is an underacknowledged trait in engineering. Have you ever said, “I don’t trust him, but I’m going to give him an important feature anyway?” No!

Building trust takes time. You can get started by promising to do small, easy things. It can be as simple as saying, “I’ll send an email right after this meeting.” Make a note for yourself and do it. Do one small thing every day, and soon, people will think, “You always get things done. I trust you to handle a big project.”

#8 Eliminate complaints

If you complain a lot, people will think of you as a negative person. They’ll be less willing to share ideas with you, less likely to have lunch with you, and less likely to want to be around you at all.

You can be realistic and bear bad news without raining on everyone’s parade. Who would you want to work with? Someone who shoots down every idea, or someone who takes a realistic view of each situation?

When possible, you want to make other people feel good. Because when you make people feel good, they like you.

When people like you, they trust you.

When they trust you, they want to work with you.

And as you advance your career, you’ll realize that working with others is truly the best way to multiply your impact.

Posted in Psychology, Software | Tagged , , , , , | 6 Comments

Seven things I wish I knew my first year as a real world software engineer

I’ve been working in the industry for five years now. I’ve written about internships and promotion, but what about the first year on the job? What do I wish I knew in my first year after college?

Standard disclaimer: don’t take my advice.

1. Your job is to solve problems, not “write as much code as possible”

It took me four years to understand this.

At first, I believed that the best thing I could do was to spend time programming. Config files are boring! I want to write a clever algorithm! Documents are a waste of time! But if I could use a config file, API, or document that causes 100 other engineers to do a little work, I have accomplished my goal without personally overexerting myself. Sometimes, in a complex ecosystem, it’s the only way.

2. Take extreme ownership of problems

Most people see a problem and wait for someone else to fix it. When you take extreme ownership of a problem, you figure out how to solve it. Don’t wait for standup to raise a concern.  

Which brings me to my next point…

3. Raise concerns early

Don’t be afraid to highlight problems. If you find a roadblock, talk to another engineer or your manager. Your manager definitely wants to know about problems so they can help fix them.  They might be unhappy about the bug, but they’ll be happy that you found it earlier rather than later.

4. Ask questions

First, search the documentation.  If you can’t find an answer, ask for help. If you think you’re being annoying, talk to different engineers instead of the same person every time.  Until someone says “you ask a lot of questions” or they look annoyed, keep asking questions.

5. Collaborate

Unlike competitive programming and many university classes, you’re encouraged to collaborate in the real world. One of the secrets of software engineering is copying and pasting from StackOverflow–AKA worldwide collaboration.

6. Communication is a superpower

There’s a reason engineers are stereotyped as being dorky, shy, and unable to talk to VIPs.  But you don’t have to live up to the stereotype.  Communication in all its forms–talking, emails, design docs, presentations…  They’re all useful ways to supercharge your learning and influence. 

7. Optimize your finances

No one is going to manage your finances for you. Spend some time learning about personal finance from reputable sources like The Bogleheads’ Guide to Investing and I Will Teach You To Be Rich (ok, that title sounds fake, but the info is genuinely good). A few hours and $10 spent putting your finances in order will be one of the best ROIs you’ll get in your entire life.

I could write a whole other article about personal finance and why it’s important. In short, max out your retirement account each year. In the US, this is your 401(k). Your future self will thank you when you wake up one day and realize you’re a multimillionaire.

Posted in Software | Tagged , , , , | 2 Comments

You are an Engineer at Big Tech Co. (Humor)

You are an engineer at Big Tech Co.

You send a commit to Humayun for review. He says you need to wait until the IK4 migration is complete. You do not know what IK4 is, or how it relates to your service.

It has been a year and you still don’t know the difference between a PM and a PgM. Someone claims to be a tPgM.

You see the same guy in the microkitchen at 10:07 AM every day. You do not know his name. One day, he is gone. You miss him.

You attend the All Hands meeting. The CEO is confident and visionary. After you leave, you’re not sure what any of it actually means.

You meet another engineer. “What do you work on?” he asks. “Content quality,” you respond. “Cool,” he says.

You ask Jesse about IK4. He gives a very hand-wavy explanation. You nod. You do not understand.­

Another commit is causing tests to fail. You spend three days debugging. You quietly disable the tests.

There is one woman on your team. You wonder if she feels strange or lonely. You are too nervous to ask.

It is 6:00 PM on a Friday. Everyone is still at their desks working furiously, but you do not know why.

The cafeteria is serving your favorite thing today. You wait in line patiently. When you reach the end, they are out of your favorite thing. You have to take the vegetarian option instead.

You have a 1:1 with your manager. “What can I do to improve?” you ask. “Keep doing what you’re doing,” he says.

You compile the project. It is broken. You are perplexed because you haven’t made any changes. You press “build” again. Build successful.

It is 11:58am. The cafeteria is empty. You use the bathroom. When you return at 12:01, the cafeteria is completely full.­

You restart your computer.

Steve reports that IK4 migration is blocked by RH. There are too many people in the meeting so you don’t have a chance to ask more.

It is 2:00 PM on a Friday. Everyone is missing, but you do not know why.

You meet another engineer. “What do you work on?” you ask. “Project Zebra,” she responds. “Cool,” you say, even though you’ve never heard of Project Zebra.

You meet this year’s interns. You like them. They do a good job. Then they are gone. You miss them.

Your manager asks why your commit has been stuck in review for two weeks. “RH is blocking the IK4 migration,” you say. He nods.

You are an engineer at Big Tech Co.

Posted in Other | Tagged , , | 2 Comments

Is Objective-C Still Relevant?

In the world of iOS development, Swift is on the rise. But what about Objective-C? Is ObjC still relevant? Are Objective-C fans clinging onto a band that broke up 20 years ago?

This next song is called TheVariableThatTookUpMoreCharactersThanTheLineLimit

My take: Objective-C is not going away anytime soon. But if you’re just starting iOS development, learn Swift.

Objective-C is so pervasive in iOS that it’s impossible to completely remove it. Apple continues to maintain libraries written in Objective-C, so we should expect Objective-C to be treated as a (mostly) first class language in iOS.

At other companies, legacy code remains. Some of Google’s iOS apps are completely written in Objective-C.

Further proof that there are still opportunities for diehard Objective-C fans: StackOverflow conducted a survey in February 2020. On average, Objective-C developers make more money than Swift developers ($64k vs $58k).

But for new apps, Swift is the future. I bet a Swift developer could outpace someone writing in Objective-C. Furthermore, features like SwiftUI are exclusively for the new kids.

If I was building an app from scratch, I would choose Swift.

Posted in Software | Tagged , , , | Leave a comment

How to Get Promoted as a Software Engineer (Even During Tough Times)

“Congratulations,” my manager smiled. “You’ve been promoted.” Despite the toughest job market since the Great Depression, coronavirus, working from home, two reorgs, and two different managers, I finally succeeded at getting a promotion (and a raise).

Many people assume, “I’ll work hard, keep my head down, and eventually The Company will recognize me.” Other people believe getting a raise is impossible. They blame anything and everything, repeat the same anecdotes, but never ask “What if I…?”.

When you work hard but get a 0% raise

I did not get promoted for working 80 hours a week or for being a yes-man. I was promoted for prioritizing the right projects and making them succeed.

I wish I had a nice little story that goes from point A to point B.  Instead, promo was a compilation of many behaviors and small accomplishments over the years. I hope that engineers can learn from my good behaviors, and senior engineers can correct me when I focused on the wrong thing. I recommend these behaviors in both easy times and tough times.

Standard disclaimer: don’t take my advice.

My Strategy

My promo journey began two years ago. Google has a rubric about the behaviors and accomplishments it expects from its engineers. I looked at the rubric and thought to myself, “What would it take for me to do those things at the next level, L5? And how do I prove that I did them?”

Every week, I had a 1:1 with my manager. I told him that I wanted to work towards promo. And every week, I would ask questions like:

What things should I keep doing?

What should I do differently?

How can I help the team?

How can I help you?

How can I help our product area in general?

What would it take to get to the next rating?

In other words, I was saying both directly and indirectly, “If I did X, would that give me a promotion/raise?” Then I got my manager’s commitment to proceed, and I aimed to make those things happen.

Make It Happen

I use the phrase make it happen deliberately.  It doesn’t have to be me that works on a specific project. Ramit Sethi says you have two options. “You can do it, or you can cause it to get done.”

For example, the Snapshot page has 65 engineers that have contributed a small amount of code. All their features need tests. Most did not have any. Over time, the bug list grew longer, and I realized we were driving down the road to disaster.

Since it’s infeasible for me to manually fix everyone’s bugs, I built a framework and provided guidance. I followed up by asking everyone to take responsibility for their own code (and their own tests). Thanks to the framework, the system began to scale without any single engineer being the bottleneck.

Sometimes, this “glue” work involved working outside my main codebase. Sometimes it meant non-coding tasks like documentation, attending meetings, and writing emails. A beginner programmer would think, “That’s not my job.” In contrast, I thought, “This is necessary for the ecosystem.”

With extreme ownership and a “make it happen” philosophy, I became an engineer that others trust to handle important projects. Managers love being able to hand off an important project and trust that the engineer independently makes progress.

In general, a good engineer can unblock themselves and get things done without needing constant micromanagement.

A good manager notices this behavior.

In case the manager doesn’t recognize this, a good engineer makes sure their manager understands the truthful difficulty and impact of their work.

Communication is a Superpower

I believe communication is a superpower. I can’t be the most knowledgeable person on every topic. But, if I could convince the smartest people in the room to be on my team, we would be unstoppable.

Not all superheroes wear capes.

Despite my start as an ordinary, computer-loving programmer, I became known as a strong communicator. If a project involved talking with many people outside the immediate team, I was the go-to guy. I felt surprised when my manager complimented me on my communication skills. I simply used Dale Carnegie’s “How To Win Friends And Influence People” to guide my interactions.

Thanks to Carnegie, I have good relationships with my colleagues. When we had disagreements, they were always resolved amicably. I made positive impressions on other teams. Instead of criticizing, I suggested ways they could improve. I aimed to make life easier for my client teams and I genuinely wanted them to succeed.

Finally, I put a 30-minute weekly block on my calendar.  I devoted that time to thinking about perf and the bigger picture. I compiled a little bit of evidence every week in the 6 months leading up to promo. When it was time to write performance reviews, I was ready to go.

The Outcome

I was not nervous when waiting for my promo result. The result was uncertain, but I had done everything necessary, and I did not worry about the outcome. Worst case, I apply again in six months with a stronger review packet–or even appeal immediately.

When my manager told me I was promoted, I felt more relief than excitement. I had planned to take a nice vacation after promo, but Coronavirus held off a big celebration.

But it’s a pandemic? What did you do differently?

Tough times make getting promoted harder. However, the core principles remain the same. Understand what your team and organization needs. Tell you manager what you plan to do (and confirm it’s the right path). Then hit a home run.

Who will your manager promote when budget is limited? The person that proves they have helped the organization.

If you continue to think about the bigger picture, remain a trustworthy person, bring projects to completion, and make the people around you happy, you’ll be a level above everyone who keeps their head down and wishes for a raise.

The Downside

One of the worst parts about working at Google is “perf driven development”. You can get rewarded for solving a problem, but it’s harder to prove that you prevented a problem from happening in the first place.  A focus on metrics means activities that are hard to measure won’t get rewarded.

In my case, I chose projects that would look better for perf. There were some cleanup tasks that I wanted to do, but they kept getting de-prioritized.

Additionally, I could have bit off more than I could chew. I learned an effective tactic to avoid overcommitting. When my manager asked me to take on a new task, I would check my notes and reply, “That will require me to push X to next week. Is that OK?” We understood prioritization. Not all work has the same urgency and importance.

Promo is Easy (For Some)

Another engineer didn’t think much about promo. One day, his manager asked, “Do you want to go up for promotion?”

Engineer: “No”

Manager: “You are doing valuable work. I think you should apply.”

Engineer: “Okay.”

A few weeks later, the engineer was promoted to the same level as me without doing much differently.

So who knows if my intentionality and focus were necessary.

Posted in Software | Tagged , , , , , , | 5 Comments