As a new engineer, you’ll ask tons of questions. Mentors want you to succeed, but providing quality mentorship is difficult and time-consuming. If you can meet them partway in getting you the help you need, they’ll love working with you.

Here are 3 things to keep in mind when you ask questions:

1. Start with the problem
2. Show your work
3. Think it through yourself

We’ll go through each one and talk through a scenario where you ask a suboptimal question, what you could do to improve it, and example conversations before and after applying the improvement!

## Start with the problem
### Scenario
You need to get the path from the URL of the page the user is on.

You know how to get the full URL: `window.location.href`, e.g. `https://yourcompany.com/widgets/127`, and you want `/widgets/127`. You’ve heard regular expressions might be a good way to deal with this.

You ask your mentor: “How do I write a regular expression to match the `/widgets/127` in `https://yourcompany.com/widgets/127`?”

### Improvement
This regular expression is both hard to write and not what you’re looking for. You’re trying to get the path from the page you’re currently on, so that’s what you should ask about.

It turns out there’s a straightforward solution: `window.location.pathname`, something your mentor could’ve steered you towards if they knew the exact problem you were dealing with.

This misdirection has a name, [the XY problem](https://en.wikipedia.org/wiki/XY_problem):

1. You run into a problem
2. You come up with your own solution
3. You ask how to accomplish your solution

When starting out, you won’t have the breadth of experience to know if the solution you came up with is optimal. So don’t start with your solution; start with the problem.

Your mentor might appreciate that you came up with your own solution, so it doesn’t hurt to include it when you ask the question. Just make sure you include the problem too.

### Examples

#### Before
__You__: How do I write a regular expression to get the `/widgets/127` part of a string like `https://yourcompany.com/widgets/127`? 
_Them_: Hmm that’s tricky, I might need to play around with it. 
_Them_: (A few minutes later) You could try something like `string.slice(3).join(‘/’)`. 
__You__: That works, thanks! 
_Them_: What are you trying to do? 
__You__: Get the path of the current page the user is on 
_Them_: Oh! You should use `window.current.pathname` instead

#### After
__You__: I’m trying to get the path of the current page the user is on. How do I write a regular expression to get the `/widgets/127` part of a string like `https://yourcompany.com/widgets/127`? 
_Them_: Oh, you don’t need regular expressions, you can use `window.current.pathname`

## Show your work
### Scenario
You need to query some data from the backend and render it to the page.

It’s not working: the page is blank. You tell your mentor: “I can’t get this data to render. I’m stuck”.

### Improvement
If you start with a vague problem statement like “It’s not working”, you’re guaranteeing your mentor will need to dig to figure out what’s going on.

This tip ties into a general principle about being a good communicator: minimize the amount of back and forth needed to resolve your issue. This principle applies even moreso in async communication like Slack, but it’s helpful even in person.

A better way to phrase the question “X isn’t working” is “X isn’t working. I’ve tried W, Y, and Z. I think it might be because Q. What do you think?”

### Examples
#### Before

__You__: My data isn’t showing up on the page, I’m stuck! 
_Them_: What are you seeing? 
__You__: The data’s not rendering onto the page 
_Them_: Can you try logging the `data` variable on this page? 
__You__: Already did, it’s null 
_Them_: Did you check your browser console? 
__You__: Already did, no errors 
_Them_: Did you check your server log output? 
__You__: No, how do I do that? 
_Them_: Look at the terminal you’re running your backend in 
__You__: Oh, I see an error there. I’m having trouble reading it though, can you help? \[Pastes error\]

#### After
__You__: My data isn’t showing up on the page, I’m stuck! I logged the variable `data` on the frontend. It’s null. I also checked the browser console and there are no errors. Seems like the data might not be coming back from the backend, but not sure. Any ideas? 
_Them_: Did you check your server log output? 
__You__: No, how do I do that? 
_Them_: Look at the terminal you’re running your backend in 
__You__: Oh, I see an error there. I’m having trouble reading it though, can you help? \[Pastes error\]

Note: you still didn’t need to know how to check the server log output or read the error message. This isn’t about knowing more: it’s just about telling your mentor what you already tried.

## Think it through yourself
### Scenario
You’ve built a new page to filter and display users of your app.

It’s one complicated gigantic React component right now, and you suspect it makes sense to break up into smaller sub-components. You ask your mentor: “How can I break this component up?”

### Improvement
The question “How can I break this component up?” is a great question to ask your mentor. Eventually.

Before you do, stop and think through it yourself. There are two key benefits to doing so. First, you’ll demonstrate your initiative to your mentor. Always a plus.

More importantly, you’ll have something to compare your mentor’s approach against. Presumably you’re trying to learn how to think like your mentor. It’s much easier to compare your thinking with theirs and figure out where yours diverged vs. learning how to think like them from scratch.

### Examples
#### Before
__You:__ Done with this feature! It’s one huge component. How do you think I should break it up?

#### After
__You:__ Done with this feature! It’s one huge component. I’m planning to break it up. The filters definitely feel complex enough to be their own component. Not sure what else though, maybe each card displaying a user? What do you think?

Again, the goal is not to figure out the answer on your own! It’s all about trying and communicating your attempt.

## Wrap up
In many of these examples, the outcome will likely be the same, but the process of getting there will be a lot smoother. Communication is tiring. Mentors will appreciate any effort you put into reduce the energy required.

Asking good questions is a skill that you can develop, one that’s worth the effort, even as you move out of the new engineer stage. You’ll be asking questions your whole career, whether you’re talking to engineers, designers, product managers, or other stakeholders. Let your mentor know this is something you’re working on.

Thanks for reading! If you have any follow-up questions or would like to connect with me, feel free to do so on [my Twitter](https://twitter.com/genericmikechen). Happy asking!

3 tips for asking for help that will make mentors love working with you

How to ask questions as a new engineer

**I could erase all but two of the jobs in my entire career history with no substantial impact on my engineering skill.** These two jobs were my 10x jobs.

Silicon Valley has popularized the concept of the 10x engineer: an engineer that does in one hour what an average engineer does in ten.

Similarly, my 10x jobs had a disproportionate impact on my skill development. They challenged me, but not in the traditional sense of long hours and burnout. Instead, they demanded that I bring my all my focus to work and to scrutinize my beliefs and decisions. They're the growth spurts of my career.

## What made my jobs 10x?

> My 10x jobs combined mentorship and ownership to create an ideal learning environment

### Mentorship

To start, in both roles, I had a mentor. The fact that this was rare makes it easier to believe most jobs had little impact on my skill development.

Both my mentors gave me copious and direct feedback on my work. One of them constantly asked me "why do you think that?" with genuine curiosity. I often didn't know, and I loved being forced to think about it.

### Ownership

I was on small teams for both these jobs and I had broad ownership over everything I touched. At larger companies, if I ran into an issue not directly related to my day-to-day, I could find another team to look into it.

At my 10x roles, I was responsible for fixing pretty much any problem I came across. This responsibility exploded the breadth of my expertise.

---

It's worth saying I don't regret my non-10x jobs. They helped me achieve financial goals or meet great people. They just didn't move the needle much on my skills.

If you're looking for a 10x job though, seek mentorship and ownership. You may find yourself growing much faster than you thought you could.

10x jobs

My journey in the tech industry began with a tiny salary at my first programming job where I was barely making rent. When I left, I found a job that tripled my salary.

I moved to Silicon Valley, where my salary increased 50-100% each time I changed jobs, depending on whether I moved up a level.

During my Silicon Valley years, I was promoted once. It was a brutal process, and my salary increased 25%.

> Job hopping, especially in tech, is the single best way to improve your salary.

## Why not job hop?

There are a lot of good reasons to stay at a company for a long time. It’s rewarding to build deep, long-lasting relationships with your team and see the impact your work long-term. Just don’t do it as a financial choice.

## How do you job hop effectively?

> Learn how to interview and negotiate well.

Both skills are learnable; here's what I found most valuable:

### 1. Interviewing

Tech interviews are [truly terrible](https://www.tiktok.com/@shmemmmy/video/6880323857903799558). Most of them don’t test you on anything remotely related to your day-to-day. Preparing for them takes a long time and typically doesn’t make you a better engineer.

Many of my peers refused to learn how to interview because interviews are so stupid. I agree in principle, but this stance is costly.

For self-taught programmers like me, I found 3 resources particularly helpful:

1. a 2-part data structures course on Coursera ([part 1](https://www.coursera.org/learn/algorithms-part1) and [part 2](https://www.coursera.org/learn/algorithms-part2)) — helpful for learning fundamentals if you went straight to the practical
2. [Cracking the Coding Interview](https://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/0984782850) — widely considered the bible of tech interview prep
3. [Leetcode](https://leetcode.com/) — platform for practicing technical challenges

### 2. Negotiating

For a long time, I never negotiated. I took the first offer I got. Good enough, I thought, better than my current salary. I never even knew how much I was leaving on the table.

There are a whole host of tactics you can use (e.g. using market data, negotiating other perks), but the two I needed to hear most when I was younger are:

1. **Get comfortable doing it**. It's not rude. Most recruiters and hiring managers expect you to negotiate.
2. **Interview at multiple places simultaneously**. With Big Tech, all negotiation tactics pale in comparison to having multiple offers in hand and igniting a bidding war. I’ve had initial offers increase 30-60% by the time the dust settled.

**Note**: #2 applies even if you’re asking your current company to increase your salary. Many tech companies only believe you’re more worth more than your salary if another company tells them.

## Wrap-up

At this point, you may think all I care about is money. In reality, I always  left my job for non-financial reasons. I just left in a way that maximized my salary bump.

Ultimately, this one of the most frustrating aspects of the industry and contributed to me leaving Big Tech. I wish companies rewarded loyal, skilled employees more freely than they do new recruits who interview well, and that I wouldn't have to write posts like this.

But everyone should get the most out of their time working, and I hope these tips help you do just that.


You're in the game already, why not play to win?

The two most lucrative skills in the tech industry

For years, I seldom posted on social media platforms: nothing beyond random questions I had for niche subreddits or tweets to companies asking for customer service.

If this describes you too, we’re in good company. There's a principle in internet culture called **the 1% rule**: in any internet community, 99% of people lurk and only 1% add content. Researchers have studied this concept and found it to be consistent across many internet forums.

I started doing Ship 30 for 30 to force myself to publish more. It’s helped, but the real value from the course has been internal. From having to hit the “publish” button a bunch of times, I’ve had the opportunity to reflect on the fears that used to hold me back:

### 1. No one will engage with my content

The thought of pouring my soul into an insightful (to me) blog post only to watch it get 0 upvotes/hearts/unicorn points was tough to stomach. I know there are some people who naturally don’t care about this, but I’m not one of them, as much as I’d like to be.

#### The mindset shift

Not caring about engagement is a trainable skill. I’ve posted with the explicit focus on ignoring engagement, and I’ve noticed the sting of disappointment fade with every post I publish.

Also, if I never post, I’m **guaranteed** to get **zero** engagement with my ideas.

### 2. I’ll be wrong publicly

One of the toughest habits I’ve fought in writing is eliminating the phrases “I think”, “I believe”, or “I feel”. My writing implicitly reflects my opinions. I feared writing authoritatively because many of these opinions were possibly wrong, the result of either narrow experience or flawed thinking.

#### The mindset shift

Keeping my wrong opinions to myself doesn’t make them less wrong. And finding out they’re wrong is the first step towards correcting myself.

At work, I encourage people to be wrong openly and accept correction. Why wouldn’t I do the same on the internet?

### 3. Someone out there will judge me

I used to compose blog posts or even just comments on threads, only to hesitate and close my browser tab before posting. I constructed a narrative of someone:

1. disagreeing with me
2. posting a scathing reply
3. going through my post history, continuing to judge me

#### The mindset shift

I guess I’m still scared of the off-chance of becoming [Twitter’s main character](https://knowyourmeme.com/memes/twitters-main-character). Barring that, there’s a tiny contingent of people who would bother judging an internet stranger based on a few opinions. Even if they do, **why does it matter**?

I’ll always have detractors even if I have good ideas. Might as well get used to it now!

## My current fear

I’m still fearful when I hit publish, but it’s a fear grounded in reality. It’s that **I am irrelevant and no one cares at all who I am and what I have to say**. If I care about avoiding this fate, I **have to keep hitting that publish button**, putting myself out there, and figuring out what resonates with people.

If you’re like me, from one lurker to another, I hope you will too.


From internet lurker to content creator: 3 mindset shifts that helped me overcome my fear of publishing

## Then

I don’t know how relatable this is, but I have two deeply-ingrained habits when it comes to communicating online:

1. I relentlessly edit all forms of written communication, such as Slack messages, Github PR comments, and email. Immediately after I send something, I go back and apply little irrelevant edits, even though the original message communicated my point just fine.
2. I’m a hyper-lurker in all my online communities. Even in the rare cases I have something unique to contribute, I generally start typing a response, get halfway through, then close my browser window.

I suspect that these habits stem from an insecurity around publicly looking stupid, so I censor myself as a defense mechanism. After all, if I never express my opinions, I can’t be wrong! Flawless logic.

These habits had a toxic influence on this blog’s sad 6-year history. When I started writing, my hope was to become a superb teacher. I carefully considered my “target audience” of programming newcomers, only posting things I felt they would find helpful. This mindset produced three bad outcomes:

1. I didn’t write unless I had something truly insightful to say. Note that my standards for “insight” were nothing more than a stab in the dark since I had no readership.
2. I seldom wrote, so I never hit a stride, nor did I improve in proficiency or comfort with the process.
3. What little writing I did was almost entirely devoid of my personality and inner life.

A few years ago, I read James Clear’s book *Atomic Habits*, and [his story about the proven relationship between practice and art](https://jamesclear.com/repetitions) struck a chord with me. A photography professor at University of Florida divided his students into two groups, a “quantity” group and a “quality” group. The quantity group was graded solely on the amount of photos they produced and submitted. The quality group only needed to submit one photo as close to perfection as possible.

In the end, most of the best photos that the class produced came from the quantity group. So it seems great art is about consistent producing and iterating rather than obsessing about perfection.

I struggle to relate this story to writing, since writers have a limitless capacity to edit their work. Indeed, this used to be my writing process:

1. I brainstormed ideas, rejecting 99% of them as too unoriginal or trite
2. I produced a rough draft for my 1% idea in a day or two
3. I edited it for several days, sometimes even weeks, after that, trying to get as much feedback as possible from friends and family
4. I got in my head about whether anyone would find anything I say valuable
5. I scrapped the post

There’s not enough motivation in the world to keep me going through a more than a cycle or two of this process.

The questions I want to answer going forward are: when am I done with my posts? How do I best improve as a writer and teacher? I’ve seen enough to believe the answer involves caring less that I’m being insightful, unoriginal, or uninteresting.

## Now

I’m making the priority for my blog the practice of sharing my thoughts. Someday I’ll need to find a better balance between editing myself to produce premium-quality work vs. getting used to sharing my thoughts publicly. For now, I’m going to optimize for the latter.

Who is this blog for then? Who’s my “target audience”? There’s value in the answer primarily being “me”. I love the idea of capturing my beliefs about life and work, being able to look back later at the way I’ve grown in my thinking and skills. Someday if I ever develop a readership, which no longer matters to me much, I hope it’ll give my readers a connection to who I am.

Before I redesigned my blog, I toyed with the idea of removing publication dates. I was embarrassed by the infrequency of my writing. I see now that was simply another way of censoring myself. I’m choosing to leave them up as a means of honesty, and I’m betting on a more consistent and fruitful future of writing.


My struggle with perfectionism, i.e. how to publish a blog post once every 3 years.

Starting over

A few people on Twitter have expressed interest in hearing my story about how I went from doing research at a pharmaceutical company to working at Google within the span of 3.5 years. I'm more than happy to relate my experience for anyone else who might want to make a similar leap. However, keep in mind that my experience of learning may be very different from the ideal path now. The rapid growth of web development has led to an enormous proliferation and abundance of learning resources, and these days there are many guides for you to follow that didn't exist when I started. I want instead to tell you my own story, provide some general guidance about the process, and to convince you that now more than ever, anyone can learn to program.

#### In the beginning…

At the time I started learning how to program, the only prior exposure that I had to the subject was a C++ class I took in 7th grade at a summer school I attended. As some of you may imagine, programming is a bit intense and obtuse for a typical 7th grader, and on top of that C++ isn't as accessible as the vast majority of languages available today. The whole experience was frustrating and managed to convince me for a few decades that programming was just not for me.

I started to explore other options when I became dissatisfied with my career path in biotech research. I talked to a few programmers I knew and figured out that web and application development were diverging fields. I hadn't really figured out which of those I wanted to explore more, so to start somewhere I chose Java. I felt (and still feel) that Java offers the best balance between allowing a new developer to learn the basics about what is going on under the hood while not getting bogged down in the details that made C++ so not fun all those years ago.

I picked up [Head First Java](http://www.amazon.com/Head-First-Java-2nd-Edition/dp/0596009208) and started studying and practicing. Being unhappy with your career really lights a fire under your ass as far as getting started with a new one. I remember coming home from work many days and studying non-stop until I went to sleep, pausing only to eat. For anyone attempting to do this now I'd strongly recommend deciding to build a project and using that goal to guide your learning. I committed to building a flash card app for my wife (then-girlfriend) who was studying for the GREs. Even though the app sucked and was pretty useless for studying, I'm not sure how much would've stuck if I hadn't built something myself using what I learned.

#### My first development job

Around 7-8 months after I had decided to leave my field, I decided that I was also ready to take a shot at finding a real job. I was referred by my friend to a programming internship at a startup. Since this was a web development position, I knew I had to do a blitz to learn HTML and CSS well, so I read [CSS: The Missing Manual](http://www.amazon.com/CSS-Missing-David-Sawyer-McFarland/dp/B00D1GHTIG) and [HTML and CSS web Standards Solutions: A Web Standardista's Approach](http://www.amazon.com/HTML-CSS-Standards-Solutions-Standardistas/dp/1430216069), both amazing resources at the time, but outdated now (already!). I sent the company my resume. However, my credentials were such a terrible match for the job description that the company assumed I must have applied for the wrong role and screened me for a different job instead.

Luckily, I got that sorted out and they scheduled me for an in-person interview. I learned that the company used PHP and not Java, so I bought a copy of [PHP 6 and MySQL 5](http://www.amazon.com/PHP-MySQL-Dynamic-Web-Sites/dp/032152599X) to study for my interview. I saw that the constructs of programming (e.g. if-else statements, loops, variables) are the trickiest parts to learn, and that the particulars of the language are mostly just details, at least for a beginner. However, I did the interview and walked out feeling like I had bombed it, but the interviewer (who would be my supervisor and mentor) saw potential in me somehow and the company still gave me an offer. The only issue was I would have to take a huge pay cut: the job paid basically minimum wage.

I know that some would argue that taking the job for that salary cheapens not only my skills, but also the entire industry. I definitely understand the concern, but I think in the end, you have to decide what makes the most sense for yourself. If you can afford to take a huge pay cut to learn what you have to learn to be marketable in your target industry, I believe in most cases you will find that you got a bargain. The difference between trying to cobble together an education in your evenings vs. being thoroughly entrenched in programming problems 40 hours a week should be fairly obvious.

#### Leveling up

I was one of only two full-time developers at my company, and being a part of such a small team required me to learn a broad range of topics very quickly. I started to learn concepts I hadn't been exposed to before. I learned about databases and MySQL (partly from that book I bought, but mostly on the job). The tech stack featured [Symfony](http://symfony.com/legacy), a PHP framework, and I finally got a handle on the Model-View-Controller paradigm, a cornerstone concept for organizing your code. I began my journey to learning the command line and the vim text editor, among many other things. It's really difficult to overstate the difference between my time of self-study and my time of learning on the job. My supervisor was an incredible, albeit sarcastic mentor, and through his frequent berating of my work he taught me the difference between working code and good code.

I was taught that much of programming is spent maintaining and modifying existing code as opposed to creating new code. I quickly realized that it was vital for me to learn the best practices in this industry in order to improve as a developer, and I knew I had to improve quickly to impress my company and get out of this minimum wage business. I had enjoyed the Head First Java book, and to study the concept of good, maintainable code more, I picked up [Head First Object-Oriented Analysis and Design](http://www.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/) and [Head First Design Patterns](http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124). I also bought the classic [The Pragmatic Programmer](http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X). These books all taught me some tried and true ways to design my code to allow future developers to understand my intent and to change my code to suit their new use cases easily. In short, I kept studying in the evenings, almost as urgently as I had before I got my first job.

After six months, my company promoted me from an intern to an actual web developer and I started making a livable wage. However, the pressure wasn't quite off yet. By this time, I had started to read about what big companies like Microsoft, Google, and Amazon look for in their job applicants. It exposed a huge gap in my knowledge, namely in data structures and algorithms, concepts that should be deeply drilled into any Computer Science student's brain. I knew I still had a long way to go. I'll share more about how I filled in this gap, and how I eventually specialized in front-end development in my next post.

How and why I abandoned my degree and took a job that quartered my salary

How I learned to program - part 1

It's my first-ever annual retrospective!

Parenthood and COVID have obliterated my sense of time and memory, and I need to start doing these, at least for myself. I want to capture both the joys and lessons from my time on this Earth before they slip from my mind forever.

## Highlights of 2022

### Moved to Seattle

This year, we chose family, leaving a place we loved to be closer to my brother and parents.

Leaving the Bay Area wasn't easy. I was absolutely spoiled by the weather. I miss being able to feel the sun on my face almost year-round. All the places I loved and needed to get to regularly were easy to access. I left behind several amazing friendships.

But overall I'm grateful for the move, and for my family's help facilitating it. I live in a nice quiet neighborhood near a bike trail where we take frequent walks. It's quite beautiful here, and I feel way more connected to the outdoors on a regular basis (at least when it's not too rainy or dark to go outside). Above all, it's wonderful to have my son get to know his grandparents, uncle, and aunt.

### Accepted my limitations

One of the most impactful books I read this year was *Four Thousand Weeks: Time Management for Mortals*. My main takeaway: I'm going to die before I can achieve many of my creative goals and ambitions. [I've written about similar realizations before](https://mikechen.io/posts/productivity-as-fantasy), but sometimes I need reminders and validation.

When I first became a parent, I thought I could focus on 2-3 projects, carving out 30 minutes a day for each of them. In theory, this is plenty of time to make good progress on those projects over the months and years. I quickly discovered how unsustainable this is in practice.

I'd internalized the idea that not achieving all of your goals is a time management problem. I've fully realized now that it's an energy problem. It's impossible for me to accomplish anything substantial for multiple projects at the end of the day, even if I have a solid 3-hour block of time after my son goes to sleep. I'm completely wiped out then, and having to context switch between projects wipes out any hope I have of being productive.

Keeping too many goals in mind created massive problems at every single point of the creative process:

1. Before I start working, deciding what to do with my limited free time was a constant struggle
2. While I was working, any sign of difficulty or boredom made me question whether I should be working on something else
3. After I was done working, even in the rare case I made progress on a project, rather than being proud of what I've accomplished, I thought "what about all my other projects?"

What all this means is that I'm saying no to a few things that I love that I no longer have space for right now: namely music and drawing. I'm going to just have faith that I'll make space for them again sometime in the future.

A younger me would've viewed this resignation as profoundly sad. However, it's clear to me now that realigning my beliefs in this way isn't objectively changing anything about my circumstances. It's just accepting a reality that I denied before: I can't be all the things I want to be. And I'll be happier in the long run to live in reality than to live in fantasy.

## Biggest challenges entering 2023

### My inability to be bored

So much of parenting is essentially just sitting around doing nothing, i.e. watching my son play and making sure he doesn't try to dive headfirst off the couch or walk backwards down a flight of stairs.

Taking care of my son has strongly highlighted my inability to be bored. When I'm watching him, I feel the need to check my phone every 5 seconds, even when I don't have anything to look at. I just want to read something, anything.

But parenting is only the most obvious indicator of this problem. Any time my side projects get hard, I start browsing Reddit or Hacker News. When I have to wait more than 5 seconds for something, e.g. in line at a store or at a crosswalk, I feel the itch to reach for my phone.

I'm sure a lot of people can relate to this, but my situation feels dire. This issue is certainly preventing me from falling far short of my potential as an attentive parent and a creative person.

### Losing faith in myself

In 2009, I was overweight and hated the career path I was on. Within a year, I lost 50 pounds and began my software engineering career. I've always leaned on that transformation as evidence that I can do anything I put my mind to.

These past few years, those achievements are no longer making me feel better. I've broken too many commitments to myself. I told myself I would dedicate time to writing and creating, and I haven't. My self-confidence to draw from my own motivation to accomplish my goals has hit an all-time low.

## What I want 2023 to look like

### Theme

I abandoned New Year's resolutions long ago, looking instead to concepts that are far more like [wayfinding](https://en.wikipedia.org/wiki/Wayfinding) than specific goals.

This year, I discovered [CGP Grey's yearly theme concept](https://www.youtube.com/watch?v=NVGuFdX5guE) — a single word or phrase that encompasses what you'd like your year to look like. A simple theme is compact enough to keep in your head, and can be enough of a guiding principle to make choices that improve you on a day-to-day basis.

My theme this year is __consistency__. I believe both my current challenges can be solved by finding a consistent routine:

1. My inability to be bored got way worse when my meditation practice fell off a cliff. I'm certain bringing it back will help me be more present.
2. My lack of faith in myself will certainly be resolved by more consistency. What more is consistency than honoring a series of tiny promises you've made to yourself?

### Goals

I have concrete goals too!

1. Write at least one weekly post for my Substack. I've created [Stuff They Don't Teach You In Bootcamp](https://mikechen.substack.com/), dedicated to helping new engineers navigate a variety of technical and career topics.
2. Launch a developer Discord community. I've wanted to create a friendlier, more conversational StackOverflow for a while now. 2023 is the year I hope to make it a reality.
3. Develop [frontendeval](https://frontendeval.com/). Add more questions and create a better user experience.

My plan is to hold tightly to my theme and loosely to my goals. If I end 2023 having been more consistent than I was in 2022, I'll be thrilled. If I accomplish these goals (which will only be possible if I am more consistent), even better.

## Art that impacted me in 2022

### 🎥 Everything, Everywhere, All at Once

I'm kind of convinced I will never see a movie as good as this one again. This movie was an amazing blend of philosophy, action, and emotion. *Everything, Everywhere, All at Once* spoke to me as an optimistic nihilist, showing how our choices don't seem to matter at all at the scale of the universe (or the multiverse), and yet they are still critical.

On top of being thought-provoking and entertaining, I felt super seen by this movie. It perfectly captured the first-generation immigrant experience. I don't think I've felt so emotional watching a movie in quite some time.

### 📚 The Three-Body Problem

This is a sci-fi classic, soon to be a Netflix show. I devoured the entire thing in a few short weeks.

My main takeaway: the universe is a cold and dark place, and mankind's chapter in the cosmos will almost certainly just be a fart in the wind.

This can be interpreted as a depressing and dark take. Instead, I view it as freeing. People devote so much time to making their lives significant, while it's actually impossible to amount to much in the grand scheme of things. It motivates me to create meaning only in the ways that matter to me.

### 📚 Good Inside: A Guide to Becoming the Parent You Want to Be

I've read many parenting books both in preparation for and in the course of becoming a dad. None have impacted me like this one. I got two major insights from this book, both of which I feel apply to all my relationships, not just parenthood.

First, everyone is inherently good, including my son and me. When my son is throwing a tantrum or being cheeky, he's not "being bad". He's a good kid having a hard time. Similarly, I am a good parent who has a hard time sometimes. When I find the space to take a step back during hard situations, this truth grounds me.

Second, two people can have competing views and both can be true and valid. My son wants to play with the stove burners. I obviously can't let him, but that doesn't invalidate his desire to play and explore. Acknowledging other people's viewpoints is vital even if you make decisions they don't like.

### 📚 Four Thousand Weeks: Time Management for Mortals

Mentioned earlier, this book confirmed my suspicions that I need to learn to let some things go. Four thousand weeks, if you haven't guessed already, is the average lifespan of a human. Life seems pretty damn short when you put things that way.

There were more lessons I took from this book than I can convey here. If you struggle with overwhelm, perfectionism, and overachieving like I do, I can't recommend this book enough.

---

It's probably optimistic to wish for this these days, but I hope everyone has a safe and stable new year of becoming who you want to be!

2022

Life has been a blur since having my first child 13 months ago.

I’ve had little bandwidth to document how I’m changing as a result of being a parent. I’m grateful for my brother ~~forcing~~ encouraging me to air my thoughts on [our podcast](https://thenextcheneration.com/), but I don’t always have my thoughts organized when we record. It’s time to reflect.

My parenthood journey has congregated into a few major themes:

## The bad
### Exhaustion
It took no time to agree in full with other parents’ accounts of how brutal the first 3-4 months of parenthood are.

Parenting unlocks a new tier of tiredness. I didn’t even know humans could survive on such little sleep for such a long period of time.

The newborn stage nights were the worst of it. I had a true rookie moment at the hospital where I believed he was an exceptionally calm baby. Apparently newborns just don’t need to eat that much, and he evolved into a normal screamy baby when we got home.

Months later, long after we sleep trained him and he started sleeping through the night, I’m still tired. It’s draining to be “on” for so many hours a day, watching him to make sure he doesn’t unplug anything and stick his finger in the outlet, or eat whatever he finds under his crib.

Part of my exhaustion is also self-inflicted. I’ve been subjecting myself to something called “[revenge bedtime procrastination](https://www.verywellmind.com/what-is-revenge-bedtime-procrastination-5189591)” for months. I stay up quite late working on all the projects I no longer have time to work on throughout the day and sleep ~6 hours a night. Months after understanding this phenomenon, I’m no closer to stopping.

My son’s at a great age where I feel like he’s the least tiring he’s ever been, but I’m still worn out. I hear this is nothing compared to later stages of toddler-hood though. Can’t wait!

### Anxiety
At the time of this writing, we’re in year 3 of a pandemic. Russia invaded Ukraine a few weeks ago, threatening the rest of the world with nuclear annihilation. The effects of climate change become more obvious every year. Housing prices and college tuitions are completely out of control. Authoritarianism threatens to take over most western democracies.

This is the world my son is growing up in. Whenever I have a good experience, like taking a walk in nature, looking at the ocean, or quietly enjoying a cup of coffee at a coffee shop, I wonder what the world will look like when my son is old enough to do the same.

Maybe the worst of the effects are closer than I think, but I’ll likely be gone when they happen. My son will be here. Feels really dark to think about, but more on this when I talk about [hope](#hope).

## The good

### Mindfulness

Right before my son was born, I listened to a lesson on mindfulness in the *Waking Up* app. In it, the author Sam Harris talks about his daughter mispronouncing “animals” as “aminals”. He doesn’t correct her, instead choosing to enjoy every step of her development.

He points out that someday I’ll pick up my son for the last time, that my time when he’s this small is precious. Picking him up is indeed getting harder and harder. I remember this often: every day is the youngest and smallest he’ll ever be, and whatever stage he’s in is never coming back. It helps me savor the days and be present, even when they’re long and difficult.

### Gratitude
One of my greatest fears leading up to parenthood was that something would go wrong during childbirth or that my son would be born with health issues. Despite a fever during labor, a few ER visits his first week of life, and a bad case of reflux, his biggest health problem is a flat-ish head. He’s developing well.

It’s easy to forget to be grateful for things not going wrong. I won’t forget how on-edge I was about worst-case scenarios when I was at the hospital during my wife’s traumatic labor, and how lucky we are that my wife and baby are both safe and healthy.

### Joy
My son’s personality is coming out more and more every day. He’s a total jokester. He makes us laugh and laughs a lot himself. He’s outgoing, much more than his mom and dad. I love seeing him excited about meeting new people and try new things (as much as one can during a pandemic). Lately he’s been throwing things on the ground and saying “Uh oh”. It’s still cute for now.

Pretty much every night after he goes to sleep, my wife and I spend a bunch of time watching videos from that day or from when he was younger. Never thought I’d be one of those parents but here I am.

### Hope
Without my son, I had a strong chance of becoming a nihilist. The world I described in my section about [anxiety](#anxiety) felt inevitable. Instead, I have no choice but to believe there’s a chance my son will grow up safely and  experience much of the wonder and beauty of life that I have.

I’m going to choose to believe humans can figure out a way out of this mess. And I’ll live like my actions make a difference. I’ll do what I can to model doing good and to teach my son to do the same.

---

It’s still so early in my parenting journey, and I haven’t even gotten to the stages of life with endless choices about education, values, and discipline. I imagine every year will be a whirlwind of learning more about my son’s personality along with finding more clarity about the kind of person/parent I want to be.

I’m hoping to look forward to it while enjoying where my family is right now.

A year of parenthood

## My journey with productivity and optimization

I got my first taste of my productivity obsession right out of college with the (in)famous *Getting Things Done* system by David Allen. I had lived my entire college career a minute at a time: zero time management skills, no routine to speak of, frequent cram sessions or all-nighters to wrap up problem sets or study for exams.

*Getting Things Done* taught me how to capture my random thoughts and surface them at the appropriate time. I bought [Things](https://culturedcode.com/things/) — to date, the cleanest and simplest implementation of *Getting Things Done* I’d ever seen — and rigorously adhered to a routine of documenting my life. I felt, for the first time, a sense of control over a life that had been utter chaos up to that point.

Ever the engineer, I sought to further optimize my life. I read all about the power of habits and routine in [The Power of Habit](https://www.amazon.com/dp/B0055PGUYU/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1), [Atomic Habits](https://www.amazon.com/Atomic-Habits-Proven-Build-Break-ebook/dp/B07D23CFGR/ref=sr_1_1?crid=1GHH659NU53GP&dchild=1&keywords=atomic+habits&qid=1633795573&s=digital-text&sprefix=atomic%2Cdigital-text%2C228&sr=1-1), and many others.

I developed my own habit system: a group of colored stones I’d move from one box to another daily, each one representing one of my habits I wanted to develop — e.g. write, meditate, draw, do something nice for my wife.

I’ve attempted plenty of other convoluted micro-optimizations as well throughout the years:
1. I tried to program my Google Home to add tasks to my Things list by connecting it to automation software that sends an email.
2. I bought an Apple Watch in part to give me ubiquitous access to my todo list (spoiler alert: it didn’t work because Siri sucks).
3. I built a Chrome extension version of [this calendar](https://www.kickstarter.com/projects/simonegiertz/the-every-day-calendar) to track my daily progress.

In short, I spend a lot of energy to feel like I’m bettering myself, meeting the goals that I set, and generally being in control of my life.

## Is there such a thing as too much productivity?

I’m now wrestling with some beliefs I picked up from my immersion in productivity culture, no longer certain they’re serving me.

First is that all goals are within reach given proper time management. Many productivity systems care little about human limitations. Every hour has the same potential productivity so long as you plan.

Second is that consistency trumps all else. Thirty minutes to an hour a day of deliberate practice produces great results you need in the long term.

When I combined these beliefs, I concluded that I should be able to pursue all my goals simultaneously. Just give a bit of time to each every day. However, when I write all my goals down in one place, it feels a little absurd:

1. Be a great husband and father
2. Achieve fluency in Mandarin
3. Play more music: practice guitar fingerpicking and piano improvisation
4. Pick up drawing again: pencil sketches and pixel art
5. Create a videogame
6. Get better at writing
7. Build a startup
8. Become a better leader and engineer

In theory, I **could** make progress on all of these ambitious goals with just a few hours of dedicated time per day.

In practice though, my time investment produces uneven results. It took me so long to accept an obvious truth: there are occasions I have all the time in the world for my goals but lack even an ounce of energy. Pursuing 8 ambitious goals simultaneously consumes tons of energy, and doing so for a meaningful stretch of time is unsustainable.

Ultimately, these goals are more than things I want to do; they define who I want to be: creative, artistic, and entrepreneurial. Even if I were able to “time manage” my way to doing everything, I would be mediocre at best.

The challenging part is I’m approaching an age where letting something go feels like — with every-increasing job and familial responsibilities — I may never come back to it. I’m learning that I need to be okay with that. Unrealized goals that I cling to take up a lot of mindspace, even if I’m not actively pursuing them.

## So where am I now?

I realize now that I had assumed a concept in productivity culture that may not have been there: unlimited human potential. I wanted to believe there was no limit to what I could accomplish with the right tools. But everyone has limits, whether they acknowledge them or not.

I’m instead focusing on a few of the above goals that have an immediate impact on my career and family life. And I’m going to think of productivity for what it is: a means to achieve a few goals at a time.

I hope I’ll get to do all that I want to someday in this life, but trying to force it seems to guarantee I’ll accomplish little of substance. I’m excited to see where recognizing my limits gets me.


My learnings about the limits of productivity and time management

Productivity as fantasy

## What’s a postmortem, and what makes it blameless?

Many engineers are familiar with the concept of a [postmortem](https://sre.google/sre-book/postmortem-culture/). Postmortems are a tool used to examine mistakes engineers make resulting in a severe problem, such as an outage or data loss.

In these situations, the most common alternative to the postmortem is scapegoating the person who made the mistake and punishing them.

The logic behind punishing people in these situations is unclear to me. It feels to me like it’s so management can feel good about saying they did something to address the issue.

This approach is short-sighted though. Where human error is possible, it’s inevitable given enough time. Punitive action assumes that people are only trying to avoid mistakes to avoid getting punished, not because they want to do a good job. If the former were the case, maybe the company’s hiring process is the problem?

In contrast, blameless postmortems focus on the system or process surrounding a human mistake rather than the mistake itself. Barring rare cases of malice or gross negligence, the engineer was applying their skills to their problem in a way that made the most sense to them at the time.

For example, say an engineer at your company deleted a huge chunk of data. Nightly backups were running but no one had ever tested them, so the data loss was catastrophic. Here are some questions that might come out of the postmortem process:

1. Were there any guardrails on the engineer being able to delete a massive amount of production data?
2. Why was the engineer doing any work on the production database directly? Why wasn’t there a UI where they could get that work done in a less dangerous way?
3. Why weren’t backups routinely tested?
4. Was the engineer aware of the inherent danger of what they were doing?

The ultimate goal of the postmortem is to produce a list of corrective actions. These actions should prevent similar mistakes from happening in the future for anyone in the errant engineer’s position.

## The principles behind blameless postmortems

While companies’ implementations of postmortems are often far from perfect, I’m completely aligned with the principles behind them. I often wonder why other disciplines don’t adopt similar principles.

In engineering, the postmortem-worthy problems might look like outages, data loss, and data breaches. In other disciplines, there are lost sales, bad hires, and PR disasters. Many of the reasons the postmortem is such an effective tool have nothing to do with engineering.

### Transparency

To me, the most valuable element of postmortems by far is the level of honesty required to conduct them. Everyone involved is allowed to be 100% forthcoming about their roles knowing their jobs are safe. Without the honesty piece, engineers (and everyone really) would default to an approach of hiding mistakes, and teams would inevitably repeat them.

### Grace

Blameless postmortems emphasize that you can make mistakes and still be competent. We’re all just doing the best we can with the information we have. The goal of the process is continuous improvement, not perfection.

### Thoroughness

Many postmortems ask a chain of [five whys](https://en.wikipedia.org/wiki/Five_whys) in order to get to the root cause of a mistake. This root cause analysis is critical to treating the underlying issue instead of the issue’s symptoms.

## A postmortem for my behavior

I’ve become fascinated by the theory behind human behavior and motivation in recent years. My interest started with Daniel Kahneman’s terrific book _Thinking Fast and Slow_, which discusses the competing priorities in two different parts of your mind.

This was a startling revelation — I’m not a single coherent self. I’m just a bundle of competing priorities with the illusion of being in total control of my actions.

Armed with this realization, I’m able to step back from my problem behavior and see it for what it is: a mishmash of conflicting emotions and goals rather than a “self” deciding what I’ll do. In other words, there are broken systems informing my behavior. As the postmortem process has taught me, broken systems can and should be repaired.

## An example: analyzing my sleep habits

I’ll use my constant battle to get to sleep at a reasonable hour as an example. Since becoming a parent, 6:30 AM is the latest I can wake up and be on track for my family’s morning routine. However, I routinely find myself sleeping near or after midnight and feeling guilty about myself when I eventually go to sleep, then again when I wake up feeling like a zombie.

Guilt has been a bad solution. It’s roughly the same concept as a company reprimanding someone for making a mistake, and it’s equally ineffective. I thought about how to reconcile the inconsistency between how I treat problems at work vs. problems in my personal life.

When I apply the postmortem to my life, it’s more of a mindset shift than a full process. I don’t produce any written documents or go through the issue to the level of depth I would at work, but the exercise is helpful nonetheless.

First, I admitted this was an issue and that I wasn’t going to solve through willpower alone. Jury’s very much out on [whether it’s possible to increase willpower as a long-term solution](https://hbr.org/2016/11/have-we-been-thinking-about-willpower-the-wrong-way-for-30-years), or [whether it even exists at all](https://nautil.us/issue/45/power/against-willpower).

Next, I committed to stop being annoyed with myself. The negative feelings weren’t actually changing my behavior, so they weren’t worth keeping around. This is easier said than done, but I’m able to ignore them more easily after noticing how unproductive they are.

Lastly, I examined the emotions surrounding my decisions that lead to late bedtimes. I noticed a strong sense of urgency around finishing up some personal projects (like this blog) or having some time to decompress. This led me to two sub-problems:

1. I have a 7-month old and the time after he goes to sleep is the only real free time I have. Apparently this mindset is common enough that it has a name: revenge bedtime procrastination.
2. I lose track of time, possibly because I’m sleep-deprived from the previous night
3. I’m overcommitted on projects and want to get too much done in any given day.

Each of these problems has its own set of potential solutions. For now, I’m working on the first issue by using a gratitude journal to cultivate my sense of thankfulness for having a healthy child that I get to spend a lot of time with. For the second, the solution involves changing my environment by setting reminders and alarms. I haven’t quite figured out the issue yet, but I’ll get there!

I’ve experienced a surprising amount of success with my strategies so far. In particular, the connection between gratitude and my late bedtime would have been totally opaque to me if not for this exercise.

## Stop feeling bad, start solving the problem

If you’re anything like me, your bad habits impose a great deal of guilt on you. Rather than unproductively trying to change yourself through guilt or blame, give this process a try. It works for many tech companies. Maybe it can work for you too.


How to use the tech industry’s greatest contribution to corporate culture to fix your bad habits

Blameless postmortems and personal problems

Software developers who aren’t familiar with the name Linus Torvalds are almost certainly familiar with his work. He’s widely regarded as one of the most prolific software developers in the world due to his authorship of the Linux kernel and Git, two of the most important projects in modern software and computing.

Unfortunately, he is also well-known for his abusive language towards colleagues. In September 2018, Torvalds announced that he is taking a break from his leadership of the Linux project. [In an apology email to fellow maintainers](https://lkml.org/lkml/2018/9/16/167), he mentioned that he will “get some assistance on how to understand people’s emotions and respond appropriately.”

Torvalds’s behavior fuels long-standing stereotypes that leads to questions on social media such as “[Why are most programmers weird? They just seem to not have any social skills.](https://www.quora.com/Why-are-most-programmers-weird-They-just-seem-to-not-have-any-social-skills)” and “[Why does programming have so many negative stereotypes associated with it?](https://www.reddit.com/r/AskMen/comments/1wxzkx/why_does_programming_have_so_many_negative/)”. If you look at most of the negative images surrounding software developer stereotypes (antisocial, overly technical, condescending), many of the bad qualities stem from a lack of empathy.

At a high-level, empathy is simply the ability to put yourself in the shoes of another human being, to feel their feelings and to imagine what it would be like to have their problems and their goals. With rare exceptions, we as humans are wired to feel empathy instinctively, but by being mindful of situations where empathy is important, we can all develop this vital quality.

From my years working at major Silicon Valley tech companies as a software developer, I observed empathy to be among most underrated and important skills. Here’s what empathy might look like in your career as an engineer:

### Empathy for other engineers

<figure class="post-image">
<a href="https://xkcd.com/1513/">
<img src="https://imgs.xkcd.com/comics/code_quality.png" alt="XKCD Code Quality comic" />
</a>
<cite>XKCD // <a href="https://creativecommons.org/licenses/by-nc/2.5/">CC BY-NC 2.5</a></cite>
</figure>

Unless you’re only engineer on your team, you’ll almost certainly be spending a lot of time communicating with other engineers in the form of technical discussions, design docs, and most of all, code reviews. Depending on the size of your team, all this interaction can easily be one of the most time-consuming parts of the job.

Be mindful that even though responding to your comments and doing code reviews for you is a part of your fellow engineers’ jobs, asking for their input is essentially asking them for their time. You’re asking not only for their time, but for them to take their mind off their project, which can be exceedingly disruptive to their day. Consequently, it makes a lot of sense to minimize the amount of time and number of back-and-forth interactions that it takes to help you out. How can you best accomplish this?

#### 1. Be your own critic first

You’ve just finished writing some code, and you’re about to request a review. But wait, who should be the first one to review it? You!

I can’t count how many times someone has sent me a code review and there are obvious glaring issues in the first few lines of code that I read. Issues that would most certainly have been caught had they done the very thing they are asking me to do (read their code). Before you send any code review, take the time to scan through your code for clear issues. Avoiding the need for someone else to point out obvious issues in your code is one of the key ways you can be respectful of their time.

#### 2. Anticipate your coworkers’ questions

We’ve all had to commit code that we're not proud of — maybe an impending deadline or working with a rough API made you do some questionable things. This is something of a corollary to #1, but read your own code with not only a critical eye for issues, but things that will confuse the crap out of your coworkers.

Be proactive in documenting the sacrifices in code quality you’ve had to make, and why. In other words, leave comments (in the code or in the PR, however your team decides to deal with comments) with answers to questions that you know your reviewers will have.

#### 3. Seek first to understand

It’s safe to consider it reality that other engineers in your organization are going to disagree with you. Unless you are able to get to a point where you make all your technical decisions unilaterally, you simply have to accept this fact and learn how to deal with it productively.

Earlier in my career, I would view disagreement and debate as personal attacks. Those who have worked with me know that I hold strong opinions. As I matured in my career, I realized that it’s actually quite harmful to identify with your opinions (not only about technology, but really anything) to the point that you feel attacked when someone disagrees with you. This feeling is all about ego, for which a healthy engineering culture has little room.

Nowadays I still hold strong opinions, but I try my hardest to view disagreement as an opportunity to learn from someone else. Make every effort to understand your disagreeing coworker’s point of view. Underneath the surface is likely a goal or a premise that the two of you can agree on. Ask (as non-confrontationally as possible) why they hold their belief. Do you agree with that? If not, keep asking why until you can agree on what you’re trying to accomplish, and figure out where the disagreement stems from there.

This process almost always yields a wealth of information from your coworker’s experience that you wouldn’t be able to get if you kept your disagreement at the surface level. If you work in an environment where ideas can compete openly and the best ideas win, this means the eventual outcome will be best for your team, even if it’s not your idea. That is, unless your coworkers are just dogmatic parrots repeating something they read in a blogpost somewhere on Medium, in which case I’ve never quite figured out how to deal with that and I have no idea how to help you ¯\_(ツ)_/¯

#### 4. Be positive

Programming as an industry can be regarded as one of the most critical. You’re constantly putting your work out there to be judged by your teammates. If you’re like most engineers, myself included, your code reviews will be littered with nitpicks and things you need to improve, and rarely will you find a word of encouragement. In many ways, handling this criticism is just part of the job. We want to constantly be learning, growing, and pushing ourselves towards excellence.

However, pushing others towards greatness and providing positive reinforcement are not mutually exclusive. Is your teammate killing it with this feature they’re working on? Did they clean up some part of the codebase as part of their PR that they didn’t have to? Did they slog through your 800-line code review with you? Tell them you appreciate it!

There has been plenty of research on how the ideal ratio of positive comments to criticism should be at least 5-to-1. Building trust by offering genuine praise can help constructive feedback land much more effectively. When people know you care about them, they’ll know that your criticism comes from trying to make them better rather than trying to tear them down.

Some people in this field legitimately don’t really care about stuff like this, and that’s okay — but many do. I would be even prouder to work in an industry where we all actively work to create a culture where it’s okay or even expected to encourage one another sincerely.

### Empathy for other teams

You’ll invariably end up spending a lot of time with cross-functional teams as well, e.g. coordinating with design teams to provide constraints and direction for their mocks, working with product managers to understand specs, working with marketing to build a landing page, etc. When someone makes a request or asks you for something, put yourselves in the shoes of someone who doesn’t know all the terminology and details of the issue that you might. How might they want their engineer to respond?

I find that the most valuable concept during this communication is the level of detail that your audience is interested in. Avoid technical details and jargon as much as possible. It’s typically not their job to understand the details — it’s yours.

As engineers, we tend to be in the weeds of a problem, and it can indeed be hard to zoom out a bit when explaining issues to other people. Sometimes people are genuinely interested in the details, but if that’s the case then they’ll let you know. I’d recommend starting high-level and explaining more if they express interest (and always let them know that you’re willing to talk more about it).

Above all, remember that you’re all in pursuit of the same goals. Hopefully, if someone is asking something of you, it’s in service of building a better product for your users. Remember this as you communicate with the people around you.

### Empathy for your users

<figure class="post-image">
<a href="https://xkcd.com/1172/">
<img src="https://imgs.xkcd.com/comics/workflow_2x.png" alt="XKCD Workflow comic" />
</a>
<cite>XKCD // <a href="https://creativecommons.org/licenses/by-nc/2.5/">CC BY-NC 2.5</a></cite>
</figure>

Last and certainly not least is that you should ideally feel the pain of your users as much as possible. Our users can often be an abstraction to us, hidden away by several layers of communication (e.g. customer service -> product managers -> us). This abstraction makes sense for many reasons — imagine trying to get anything done if customers had a direct line of communication with engineers all the time. However, it’s easy to lose sight of what we’re doing when we are allowed to avoid thinking about our users for too long.

#### Your users are not just metrics

Imagine you deploy a bug that breaks a critical flow, e.g. downloading a spreadsheet of the data in your app, for a tiny fraction of your users, let’s say 2%. If you’re a data-driven company, you and your team might look at the metrics and see that people have stopped being able to complete this flow. You look at usage and you say “oh people weren’t using this very often, just 2% of users. We’ll get around to fixing it sometime soon, but we have other priorities now”. However, this flow might be the thing that allows these 2% of users to do their jobs, and you might have completely ruined their ability to use your product effectively in the meantime.

I know it can be impossible to put the pain of the few before the desires/needs of many, and I’m not suggesting that your team needs to completely change their approach. The point is never to forget that there are human beings behind those screens. Maybe your team’s goals will change as a result, and maybe they won’t, but you’ll be a better engineer if you keep this in mind.

Prioritizing eliminating customer pain isn’t just an abstractly good thing to do — products live and die by advocacy. If you broke this functionality and didn’t care that much, what do you think these users would say if their friends or colleagues ask them what they feel about your product?

#### User experience is empathy

I won’t go into this much because User Experience (UX) is an entire field and job function on its own, but it’s worth mentioning here that cultivating your empathy will also lead to a better product for your users. Our software tends to exist to make our users’ lives easier. We should all strive to make it as simple and intuitive as possible.

Remember also that your users are likely quite different from you. How could you build your product differently as you imagine some of the following scenarios:

1. You’re a user in a developing country that pays for data by the megabyte
2. You’re a sight-disabled user who can’t see color contrast well, or a mobility-constrained user who can only navigate with the keyboard
3. You’re a user who isn’t very tech-savvy and have a hard time navigating complex interactions

It can be exceedingly difficult, if not impossible, to truly put yourself in the shoes of people who are so different from you or anyone you know. That’s why a lot of these issues are often addressed by different fields such as user research and UX design. However, even if you are lucky enough to work with people in these fields, it doesn’t let you off the hook. I guarantee that your product would be better if you take responsibility for these problems as well, rather than just letting your cross-functional partners think about them.

### Conclusion

This post contains just a few examples of how you can express empathy on the job. My encouragement to you, however, is to make it a mindset rather than just behavior. Throughout your day, ask yourself about how people are experiencing your work and your actions. Make a habit of thinking about others, and you’ll do your part in creating better products, a healthy workplace culture, and a rich and fulfilling career for yourself.

Tips on mastering one of the most underrated soft skills you need to succeed in your career

Hello! I’m Mike Chen, software engineer, father, and recovering Big Tech company employee.

Popular tech/career posts

How to ask questions as a new engineer

10x jobs

The two most lucrative skills in the tech industry

Popular personal posts

From internet lurker to content creator: 3 mindset shifts that helped me overcome my fear of publishing

Starting over

How I learned to program - part 1

Latest posts

2022

How to ask questions as a new engineer

3 tips for asking for help that will make mentors love working with you

A year of parenthood

From internet lurker to content creator: 3 mindset shifts that helped me overcome my fear of publishing

10x jobs

Not all jobs are created equal

The two most lucrative skills in the tech industry

You're in the game already, why not play to win?

Productivity as fantasy

My learnings about the limits of productivity and time management

Blameless postmortems and personal problems

How to use the tech industry’s greatest contribution to corporate culture to fix your bad habits

Starting over

My struggle with perfectionism, i.e. how to publish a blog post once every 3 years.

Building empathy as a software developer

Tips on mastering one of the most underrated soft skills you need to succeed in your career