Welcome to Mushroom Kingdom, Inc. Why don’t I introduce you to some of our software engineers?
Mario is a full stack developer. He has the talent of a rock star, but he’s humble. Everyone turns to him when the project runs into trouble, and Mario always saves the day. He has good relationships with his teammates, doesn’t slack off, follows all of the company’s best practices, and somehow still has good work life balance. His favorite programming language is Java.
Luigi sits next to Mario, his brother. He suffers from severe impostor syndrome despite being a solid developer. Luigi is always second in line when it comes to picking features, and he secretly resents Mario for hogging the spotlight. Luigi only writes tests because his TL told him to, not because he wants to write quality code.
Peach is the team’s manager. She had a great career as a software engineer and has since graduated to become a professional meeting attender. Every once in awhile, she gets to write some code and everyone agrees that it’s top-notch. Peach is a very empathetic leader and she always acts in the best interest of the team. Her one fatal flaw is that she often gets dragged into conflict with her rival, Bowser.
Bowser is a mean manager. He demands perfection, starting yesterday. He hides bugs and sets unreasonable expectations. If a test gets in the way of a new feature, Bowser deletes it without question. He has a backlog of 37 different design documents that will never be reviewed. He hates Peach and Mario–since they always do good work together, Bowser looks bad.
Wario is a maverick. No one is sure why he was hired. Everyone knows he arrives at the office late because he annoyingly revs his motorcycle in the parking lot. Wario regularly insults his teammates, misses deadlines, and delivers buggy code. He refuses to write comments. He claims his “my code is correct without a test” even when it’s demonstrably false. One time, he broke the office toilet and refused to admit it was his fault.
Waluigi is an interesting character. Everyone admits that he’s competent and important, but no one knows exactly what he works on these days. He’s a gregarious guy who likes to party, submits code at odd hours, and somehow hits every deadline that falls on a prime number. His favorite programming language is Haskell. Each of Waluigi’s features has exactly two bugs at any given time. Waluigi thinks that he’s Luigi’s biggest rival, but Luigi doesn’t seem to notice him. Strangely, Waluigi refuses to write unit tests, yet he single-handedly rewrote the company’s integration test framework last year, and will brag about it to anyone who asks.
Daisy is the tech lead of a forgotten internal infrastructure team. Her favorite programming language is Python. She quietly sits in the background and keeps the show running. Every year, she has to remind management why her team exists and they shouldn’t fire her. They look at the flashy numbers from Peach’s team and order Daisy to report the same metrics, even though it doesn’t make sense for an internal service. No one realizes that development would grind to a halt without Daisy and her team.
Mentoring other software engineers is one of my favorite parts of my job.
Every software engineer ought to have an unbiased mentor to go to for career questions. Early in your career, you’re always the one asking questions. As you gain experience, you’ll be called on by other engineers.
So what do you do? I’ve talked with a few software jedis and padawans in my years as a software developer. Here are three things that mentors must do to ensure their mentees are successful.
Talking to a mentee is not a time to show off your knowledge. Before you can help your mentee, you must listen to them.
I remember talking with a highly experienced software engineer. I sat down and he started writing down a detailed a career plan, and went on a long, random tangent about how “buying a house is the best investment” that involved the engineer begging the bank to not take his house away. All the while, I didn’t say a single word.
He never asked me what I wanted out of my career. Suffice to say, I did not go to him for career advice again.
If you want to be good mentor, you have to listen. You have to understand what the mentee is looking for. Sometimes they want advice. Sometimes they need help making a decision. Sometimes they know what they must do, and they just want to feel sure about their direction.
#2 Don’t directly tell the mentee the answer
Your first instinct might be to directly answer your mentee’s questions. Don’t immediately tell them an answer. The goal here is to lead the mentee to an answer by teaching them how to solve problems on their own.
One pitfall is that the first answer you think is often not the answer that solves their problem. Or even worse, the problem that the mentee thinks they have is not the problem they actually have.
Some time ago, a mentee (let’s call her Leia) came to me for productivity tips. Leia thought she was slacking off in the past month and needed to compensate. When I asked her more, she admitted she was afraid she wasn’t making enough progress at her new job. When we drilled deeper, I discovered Leia was making sufficient progress, but she felt she had nothing to show her manager yet. Therefore, Leia felt she wasn’t living up to her self-imposed, unreasonable expectations, and she felt she was a bad person. Once Leia said this out loud, she realized what was wrong.
At the start of our conversation, Leia didn’t realize that she didn’t need productivity tips. Talking through her thought process was what she needed to get to the answer–to see she was not a bad person, and she was already making good progress at her new job.
#3 Ask Questions
Usually, younger folks come to a more experienced engineer with a question. Sometimes, the questioner must become the questionee.
Asking good questions is interesting art. Each query should let the mentee answer in their own words and talk through their thought process, step by step. It’s a conversation, not an interrogation.
One time, a mentee (let’s call him Anakin) had a tricky situation with his manager. I had an idea about what I would do in that situation, but I wanted to ask for some more details first.
“What should I do?” Anakin asked.
“What have you tried so far?” I replied.
“Well… nothing,” Anakin whined. “I don’t know what to do.”
“What are some things you could try?” I asked.
Eventually, Anakin came up with a number of options for resolving the situation. He picked one and improved his relationship with his manager. I didn’t tell Anakin a single thing. As we met over the next 6 months, Anakin had fewer and fewer questions for me, and he didn’t have to wait for our next conversation to solve his career problems.
In other words, the best mentors teach you how to solve problems without consulting an mentor at all.
If you want to become a mentor, just wait. When the teacher is ready, the student appears.
Your name is Chad, and you are a brogrammer at Big Tech Co.
You start the day by slamming a protein shake. You throw on your usual uniform: a company t-shirt, shorts, sandals, and dark sunglasses. Your biceps bulge under your short sleeves.
Your Tesla pulls into the office outside San Jose at 11am. You hand your keys to the valet and head towards the nearest coffee bar.
As soon as you step inside, your co-worker, Jimmy, sees you.
“Oh, umm, excuse me, Chad,” says Jimmy without making eye contact. “If you could just approve–“
“My dude!” you say cheerfully. “I’m so sorry about your design doc. I’ve been working from Bali the last two weeks.”
“Umm, I didn’t realize that,” says Jimmy, meekly. “Sorry.”
“I’ll get to it as soon as possible,” you say, as you stand in line for a fair trade medium roast from Guatemala. Jimmy nods sheepishly and sips a tasteless latte from the automatic coffee machine down the hallway.
You take your cappuccino and casually stroll over to team standup. Everyone glares at you for being late. Your manager assigns you a difficult task for the week. You chuckle. He thinks it’s difficult, but you have an idea.
You get back to your desk and adjust it to the highest setting so everyone can see who’s the real boss. You code up the solution in an hour.
Jimmy taps you on the shoulder.
“Hey bro,” you smile. “What’s shaking?”
Jimmy takes a breath. “Uhh, can you review my design doc now?”
“Sure,” you say. Then you phone chimes. “Hold up. The cafes just opened for lunch. Want to head over to Charlotte’s? They’re serving filet mignon today.”
The two of you walk over to Charlotte’s Cafe, a 10 minute journey each way. You overhear two other engineers passionately debating an esoteric algorithm at the next table. You do not know anything about algorithms, nor do you need to.
“Oh right my dude!” You exclaim slowly. You pull up Jimmy’s design doc. Then your phone chimes.
“Right after this meeting,” you remark. Jimmy nods. He understands. You grab your laptop and head over to the meeting room.
It’s your weekly 1:1 with your manager. You have a routine check-in. Then you ask about performance reviews, and what your expecting rating is.
“I can’t guarantee anything,” your manager says. “but I think you could get the second-higest rating in the rubric.”
“Bro, I deserve the highest rating,” you assert. You open a doc of all your achievements that map specifically to Big Tech Co’s performance review rubric.
Your manager looks it over and nods. “Chad, you deserve the top rating. I’ll bring this to calibration.”
“Don’t mention it,” you grin. “By the way, I’m going to reduce latency by 10% next week.”
“I understand. I won’t give you any extra bugs next week. Our new director is really big on engineering excellence.”
“I know,” you say. Your phone chimes. “I gotta run.”
“Meeting with our intern?” your manager asks.
“Nope. The director,” you say, and stroll over to the next building.
The rest of your afternoon passes by in a blur.
Your solution to the difficult problem causes tests to fail, so you quietly disable the tests and submit the commit. The tests were flaky anyways. Your change goes out to 100 million users later that afternoon.
You read an e-mail from the product owner. They have a dumb feature request. You shoot it down. They understand.
You crack open a cold one. Someone from HR walks by but they know who you are.
You take a break to go to the gym. You do 100 squats, 100 bench presses, and 100 sit ups. Then you start your workout.
You review another commit. You push back on the author because you suspect it will increase compile time. The author actually agrees with you. They understand.
You send an e-mail to the team proposing to use a new dependency injection system. Everyone agrees. The migration begins immediately and will finish in three days.
Then you remember Jimmy’s design doc. You pull it up on your fourth monitor. Then, your phone chimes. Another meeting.
“Right after this,” you think to yourself.
It’s time to meet the new intern.
You find the intern at her desk. She’s a pretty, young blonde from Stanford. You’re her mentor. You take a pleasant walk outside together and tell her about Big Tech Co. You give the intern some of the tips that make you a successful brogrammer. She’s a good co-worker. You think of yourself as her big brother.
Your phone chimes again. This time, it’s an urgent, ominous sound.
“Elevated error rate in cell yj” the alert reads. Surprised, you cut your meeting short and rush back into the office.
Your manager is frantic. “Can you fix this?” he asks.
“Of course, bro,” you calmly wave him off. “Go do some sprint planning and I’ll tell you when it’s fixed.”
You open your computer. The red line on the dashboard is going up. Sweat rolls down your forehead. Your mind forms an idea about what to do, but you’re not entirely sure. Your fingers dance across the keyboard in a mad whirl. You built this system. You know it better than anyone. And yet, you wonder if you can actually fix it this time. This bug is different from anything you’ve ever seen before.
Finally, you find the root cause. You roll back your commit from earlier. The error rate swiftly returns to normal.
“Chad, you’re our hero!” everyone cheers. They uncork a bottle of champagne and serve cake meant for someone else’s birthday. You spend the last hour of work celebrating your big win. Even the director swings by to congratulate you, and she’s the most impressed of all.
At 3pm, your phone chimes.
“Sorry guys, I gotta go,” you say. Everyone gives you one last high five on your way back to the parking lot.
Jimmy catches up to you on your way out.
“Hey Chad, uhh, about my design doc…” he mumbles.
“Oh dude, sorry. I’ve had a hectic day. I’ll get to it tomorrow,” you reply.
Jimmy nods quickly, understandingly. The valet pulls up with your Tesla, whose battery has been fully charged.
“Chad?” Asks the valet. You nod. You get into your car.
“See ya next week,” you say to Jimmy.
“Next week?” Asks Jimmy incredulously.
“Yeah, my girlfriend and I are going to Costa Rica. I’ll be reachable by e-mail.”
Software engineers are weirdos in the media. On screen, we’re either eccentric geniuses or socially awkward losers.
In the movies, programmers have magic powers, like they can hack the CIA in an instant. Or people see the stereotypes and think, “That’s not me, I can’t be a software engineer.”
But that’s simply not true.
Let’s debunk some common myths about software engineers we see in movies and TV shows. It’s okay to laugh about them–a lot of tropes have a kernel of truth.
#1 Software engineers use a lot of math
The first myth is that software engineers use a lot of math. People think that programming takes trigonometry or calculus.
Programmers use logic, yes, but we rarely do advanced math.
Some domains like graphics or machine learning might use advanced equations. But if you’re just building a webpage, you want to make it as simple as possible. There’s no need to use calculus to measure the position of the “send” button on the user’s screen.
In reality, most software engineers use very little math.
#2 Software engineers are all nerdy loners who live in the basement
Hollywood has created his trope of the solo hacker who wears a dark hoodie, plays World of Warcraft for 12 hours a day, and drinks copious amounts of mountain dew.
Nothing could be further from the truth.
Real software engineers are ordinary people. Moms and dads. Charismatic people, outdoorsy people, social people. They come from every continent and connect through terminals and whiteboard meetings.
Some programmers are the stereotypical white male loner type who can’t get a girlfriend. But that’s a fraction of every profession. You don’t have to be a dork to be a programmer (to be fair, I’m a pretty dorky guy myself).
#3 Software engineers never need to talk to people
There’s this idea that software engineers stare at computer screens all day and do nothing else. They never talk to other people, and if they tried, they wouldn’t know how.
Unfortunately, developers do have to talk with other people.
At the start of your career, it’s mostly your manager, teammates, and product owner. You write emails and design docs. You ask for advice choosing between solutions A and B.
Later, you talk with people on other teams, users, and customers. Junior engineers come to you for advice. Maybe you become a people manager.
Eventually, you’re not limited by your technical knowledge. Instead, you have to learn how to communicate better to coordinate with other engineers. After all, communication is a superpower.
#4 A single software engineer can build an app in a day
I remember watching The Internship and one of the characters got an idea for a mobile app. Another one of the interns said “I’ll code it up on the bus ride back”.
Hold up. You’re telling me you can code the model, the view, the view controller, the networking classes, and add in the system API calls, all in 1 hour? I’m guessing you’re going to skip UX design, architecture, the settings page, accessibility, color blind mode, privacy, security, authentication, error messages, low-connectivity edge cases, on-device storage, cloud storage, and bugfixes. And don’t even think about unit tests.
Oh, and if you want it for both Android and iOS, double the time commitment.
So, no, it’s not possible to build a full app on the bus ride between San Francisco and Mountain View. Once the app gets big enough, it’ll take one hour just to compile. (I wish I was joking.)
It is possible to program a simple app in a weekend. But it has to be simple. Building a high quality piece of code takes effort. If you rush, you’ll end up with the a buggy product that no one wants to use. To build something more complex, you’ll need more people or more time.
#5 All software engineers know how to hack the government
In every movie with a hacker, there’s a scene where the action hero tells a programmer to “hack” the government. It happens instantly and flawlessly.
Pardon my language, but that’s a load of baloney.
First, you have to be specific about what you’re trying to do. Are you trying to modify some rows in a database table? Are you trying to read from a file you don’t have permission to? Are you trying to take down a website?
Additionally, if you really want to hack a well-defended system, the job would take weeks. Governments and corporations spend billions of dollars securing their data with professional engineers who know the tricks of the trade. The hack might take longer than expected, or it might not succeed at all.
Being a real hacker is hard. But if you want to pretend like you’re in a movie, there’s always hackertyper.net.
One-on-ones… Everyone has them. Sometimes they feel like a waste of time. But it doesn’t have to be that way.
What if 1:1s could be a tool to further your career? What if they could be more enjoyable to both you and your manager?
1:1s are more important than most people realize. Your manager is not responsible for your career, so you need to take the initiative.
A manager is like a raid leader trying to shepherd a party through a dungeon. They are trying to communicate to a lot of people under pressure. Their attention is divided. They have many party members with distinct talents and personalities.
Yet if you want to get promoted, your manager is the most important person in the world to get on your side.
No one really teaches you how to have good 1:1s, so this is where I come in. I’ve been in plenty of meetings, both good and bad. I want to share my secrets of how I have awesome 1:1s, and how I used these golden meetings to get promoted faster and easier than my peers.
Let’s get started.
What do you want?
The place to begin is the end. What do you want?
Do you want to get a raise?
Do you want to get promoted?
Do you want to work fewer hours?
Do you want to change projects?
Are you looking to leave the company with a new skill?
Decide what you want. Then, structure your 1:1s to further your goals.
Most people don’t think about the structure of their 1:1s (nor their presentations). They mumble and ramble and give a 30 minutes status update. Status is fine, but you don’t need 30 minutes to talk about status.
Instead, we’re going to use our time wisely. 1:1s are a time for you get the attention of your manager.
That means we’re going to put the most important thing first.
Write down what you want to talk about ahead of the meeting. My manager and I have a shared Google Doc. You can use paper or attach notes to the digital calendar event. Find something that works well for collecting your thoughts.
Then, make a list of the things you want to talk about. For me, this usually looks like
Perf (performance reviews)
To me, perf is the first thing because it is the most important thing. Every week, I ask my manager questions like:
What is my expected rating for this cycle?
What do I need to do to get to the next level?
What evidence do I need to prove that I’m performing at the next level?
I wanted to get promoted so I could get a raise. That was the first thing I talked about in each 1:1. This reminded my manager every week that promotion and a raise were my goals and I needed his help to achieve it. After each meeting, I would take the answers to these questions and implement them, and report my progress in our next 1:1.
Second, I asked strategic questions. These are high level questions about our team, our projects, and how my work fits in with the big picture. Some weeks, I don’t have any strategic questions.
Next, I had bullet points for the major projects and features I’m working on. I mentioned difficult bugs, recently completed work, and blockers. My manager usually has a few questions about specific tasks.
Note: I tend to report very few new blockers in 1:1s. If I see a problem, I aim to resolve it without a meeting. I send an e-mail, ping my manager, and generally use my common sense to figure out "How do we move the project along?" I don't wait until our 1:1 to get an answer.
Finally, I ask low priority questions. This could be questions about new teammates or smaller bugs that don’t need to be urgently fixed. Also, here’s where I ask general, open ended questions like:
What am I doing well?
What can I do to improve?
What else can I do to help the team?
I write down the answers to all these questions in our shared Google Doc. Then I cause these action items to get done over the following week. The cycle repeats again.
Having a structured agenda keeps the conversation on track. We are more likely to cover the important stuff than if we had no plan.
You might not like this structure. Your manager might not like this structure. That’s OK. The point is to intentionally find a format that works for you.
1:1s are valuable time to develop your career. I have a recurring calendar event with my manager every week.
I recommend meeting at least once every two weeks. Anything less and your manager will forget about you.
Sometimes, we have very little to talk about, so we can cancel the meeting or end early. Other times, my manager and I have high level career discussions where we spend most of the time on the bigger picture.
The important part is to have a recurring block on your calendar dedicated to your career development. Without an automatic reminder, you’re likely to forget.
You might be worried that you’re annoying your manager with frequent 1:1s. You’re not. If they say you’re meeting too often, then reduce the frequency. Otherwise, you’re fine.
Good managers want to help develop their team members’ careers. Bad managers are indifferent (or downright hostile).
What if my manager is the problem?
Your manager might not be supportive of your career development. In that case, I would ask, “What do you want to do?”
I can’t recommend what to do for your particular situation. However, I can brainstorm a naive list:
Find a new manager, a new team, or a new company
Try to change your manager
Accept it and stay in your current position (sad!)
You have common sense. You can solve problems. You have people you can talk to for advice. At the end of the day, you can think about the pros and cons, decide, and put your plan into action. I’m just an ordinary software engineer that’s been working in tech for awhile.
And when you put it all together, you realize that you have the power to make your next 1:1 better than before.