This is a highly relevant, pragmatic question, but I think you're right it's too broad. Let me share some general principles that might help you, or others, depending on situation:

- **Broader vs. Deeper**. This is a classic engineering growth decision-point. Do you double down on something you're already very good at, to become one of the best, or do you branch out to become broadly useful? There is actually a right answer to this. It depends on two things:
  - **Personality / Interest**. Some people like mastery. Others like agility / adaptability. You should pick the path that fits you best. I, for instance, have always been a generalist, so I'm definitely better at Broad than Deep.
  - **Company / Team Size**. This often has huge impact. As a generalization, small companies need more generalists and large companies need more specialists.
- **New Tech vs. Mature Tech**. Web vs. Mobile is a great example of this tradeoff. Things have clearly gone mobile, and that's clearly where the future will be. Yet you're new to mobile, so your particular value as a mobile developer will be much lower, at least in the beginning, than your value as a web developer. At the same time, you don't want to be the last typewriter repairman in town. The question is when to jump — and jump you must.
- **Sowing vs. Reaping**. Your career should vary between periods when you sow (i.e. invest in yourself by learning something new) vs. reap (i.e. maximize your value by doing something you're great at). You never want to reap too long, because the gravy train always ends at some point. But you also need to acknowledge that when you sow, you should fully expect slower progress. In fact, it'd be an odd world if people tossed even more money at you whilst your learned a new skill. The lemma, of course, is that when you sow, you often have to take a step back (in pay, or in title, or in career velocity).

Though there's no way to debug your specific situation in a post, I'll leave you with this thought: remember that the question is never, "What is the right way for generic engineers to advance?" The relevant question is always, "What is the best way for me, in my situation, with my talents, with my interests, to advance?" The whole Temple-of-Apollo Know-Thyself business is really wise: you need to thread the needle between the principles above knowing your specific situation/talents/interests in order to make the right decision.

Lastly, also remember this — whenever a decision between two choices seems too hard to make:

- **Don't be fooled by false precision**. Some — well, most — parts of the future are unknowable. Squinting harder doesn't help. If two choices are too hard to differentiate, don't spend more time trying to tease them apart. Which leads to...
- **Remember that inaction is as bad as action**. Sins of omission are equally bad as sins of commission. There was an old lady who was proud to tell an interviewer she had withdrawn all her money just weeks before the Great Depression. When asked what she had since done with that money, she proudly answered that she still has it, all in cash. She withdrew permanently from the stock market — a sin of omission far worse than her lucky pre-Depression withdrawal. **Not acting *is* acting**.
- **Many things are anti-fragile**. That is, many things *benefit from breakage*. Whenever you're faced with a tough decision where acting leads to limited downside but potentially uncapped upside, *you should always take that route*. For instance, suppose you have a great reputation at a blue-chip company that will always take you back, and you consider leaving for a startup which might go bust in 9 months or might become the next $1T company, you should always leave. The downside risk is completely mitigated, while the upside is uncapped. A person who repeatedly makes that bet in life will come out way ahead.

Ex-Microsoft, Ex-Meta, Ex-CEO of tech nonprofit

Philip Su

**There's always room for ice cream.**

It's super-important that you always give yourself the grace to do things you enjoy. It makes work sustainable.

There's always time, but it doesn't come for free. If you need to work 55 hours this week, yet you enjoy helping others, you should work 57 and help someone for two hours. *This is always worth doing,* because it's not for work — it's for **you**. (Note I didn't say that you should work 53 and use the final two for helping others; in many cases, it's not possible to squeeze magic time out of nowhere, with literally zero consequences or tradeoffs with anything else).

Note:

- Helping others is not only personally rewarding, but it's usually a fun pay-it-forward sort of lotto system. You never know which one of those people will help you in the future.
- Sometimes you can barter. "I really want to help you because I love helping folks, but right now I'm flooded. Would you be open to tackling bug #3147 for me? That'd create room for me to help you with your stuff."
- Even if bartering isn't practical, helping others often builds a bank of goodwill that you can withdraw from later. So in a way, putting in some extra hours now to help someone may well reduce your hours down the line when they help you.
- All of that said, it's ultimately not about tit-for-tat transactionalism. The best part about helping others is the great feeling we get from doing so. That award — alone — should be enough to stretch for.

The real question is not a general one, but one specific to **you**: what are **your** outcomes if **you** work hard vs. not? For most people, the answer isn't "nothing different happens, regardless of effort." You'd have to be a remarkably terrible talent for incremental effort to yield literally zero (or negative) incremental results.

Here's the key: *If you're just as smart as everyone else, and you work just as hard as everyone else, you're average*. This is tautological, but most people don't seem to get it. It disregards luck — but then again, there's nothing to be done about luck, so you should omit that from your calculations. If you're just as talented as your peers, and you work no harder, you should fully expect to go no farther.

I completely don't buy the Ford studies around productivity going negative after 40 hours. Sure, you're going to be slower in your 50th hour than your 30th, but certainly not negative — at least not in most engineers' cases. Anyone selling a 40-hour work week with faster-than-peers advancement is just that: selling something. You either need to be much better than your peers, or you need to work much harder — or perhaps even both, if you're a rocket ship.

There is no shortcut to faster-than-average advancement. A person being lazy will definitely yield worse results than the same person working hard.

### Caveat

Now, all of that said, it's also true that working on the right things will get you farther than working harder on the wrong things. So choosing is important.

- Where to work (including which company and what team)
- Who to work for
- What to take on
- What to learn outside of work
- When to convince your team that its direction needs to change

**All** of these things will likely impact your growth more than simply working harder. But don't let any quantity of self-help Oprah Book Club books convince you that the secret to life is "work less and magically get ahead." Unless, of course, your plan is to publish such a self-help book — in which case you might have just discovered the one thing for which my entire screed is false.

Imagine an engineer who:

- sees their own flaws quickly
- accepts others' feedback readily
- implements every behavioral change instantly

Such a person should be a veritable rocketship. The question really is why we aren't all growing that quickly.

### Self-Awareness

Most people aren't self-aware. This is why I love asking the interview question, "What is the biggest thing that people misperceive about you?" Many candidates can't answer this question. In order to know how a person misperceives you, you'd have to first know how they perceive you. And most people just aren't aware enough to know this.

It can be very difficult to see your own flaws. After all, we tend to do things because they seem reasonable and right. Seeing a flaw would require that you convince yourself that some things which seem "reasonable and right" to you are actually not best. This is hard for most people.

### Accepting Feedback

If you don't at least occasionally try implementing feedback you at first disagree with, you'll never benefit from feedback. After all, if you only implement the feedback you already knew or believed, why would you need someone to tell you? To be really good at accepting feedback, you need to open your mind to the possibility that some feedback will be insightful even though it feels wrong.

### Ability and Willingness to Change

Most people succeed because of one or more of the following:

1. Luck
2. Talent
3. Hard work

You can't control the first two.

If I told you that to succeed more quickly than others, you need to work harder than others, would you be willing to do so? If I said you had to change some part of your personality which you feel is core to how you've always been, would you be able to do so? If I told you that speaking and writing better was essential to growth, would you take extra classes and spend extra time outside of work to improve those skills? The empiric answer, judging by most people's behavior, is No, No, and No.

When's the last time you read an answer on this forum and actually changed your behavior? Or took an insight from an answer on this forum and really worked on improving that in yourself? The answer for most people, once again, is Never and Never.

There's not a secret to success (i.e. it's very publicly Luck, Talent, and Hard Work). But the work is truly *hard*. And I don't mean longer hours — that'd be an easy thing to implement for many people. The actual work of improving yourself, opening yourself up to feedback and insights, deliberately changing your behavior, improving your discipline & focus, resisting the wastage of time, prioritizing what you do — **that is *all* hard**.

Alex's answer to this is amazing.

The one thing I'll add is that, as you progress in your career, it'll become far more important **what** you're working on, in addition to **how**. Every senior coder has seen the following two things:

1. Months/years of code down the drain because the project was misguided.
2. Hours/days of code with a fundamental architecture flaw that has to be rewritten.

It's faster to walk in a straight line than to run serpentine. In addition to building out your skills around coding quickly (which I completely agree is essential early in career), also look to learn telltale signs that a project is headed the wrong direction, or a code path you're taking will need to get ripped out.

To riff on Anna Karenina, great performers are all like; every poor performer is poor in their own way.

Somewhat tongue-in-cheek, but these things are all true of high performers:

- Higher impact than others of the same level. (Remember, all performance is relative. Any high performer would be a complete dog if you promoted them to the right level.)
- Responsible / reliable. You don't doubt they'll get done what they say they will.
- Great collaborator. Increasingly fewer companies continue to value high-impact jerks.
- Great at self-improvement. Alex's comment about taking feedback is spot-on here. The best performers are self-aware, accept others' feedback, and implement feedback effectively.

But poor performance comes in all sorts of shades:

- **Icarus**. People who ask to be promoted too aggressively will likely land at a level they can barely compete in. Since all performance is relative, getting promoted too quickly is one of the fastest ways to become a poor performer.
- **Self-unaware**. There's a t-shirt that says, "The only common thing in all your failed relationships is you." Setting the joke aside, there's some real wisdom in there. If you could instantly accept and implement any piece of feedback given to you, you'd be an amazing superstar. The fact is that people don't accept feedback half the times, and the other half, they struggle with implementing said feedback.
- **Motivationally challenged**. "There are no boring things. Only boring people." Anybody who thinks it's their manager's job to make their job interesting is going to struggle long-term. Smart people are curious and they find the interest in nearly everything. You need to have your own goals and a strong drive to succeed.
- **Lackadaisical**. *If you're just as smart as everyone else, and you work just as hard as everyone else, you're average*. By definition — not being cheeky. When I started at Microsoft, I had a sleeping bag in my office and worked ridiculous hours. While I now view that period of my life as foolish, you can bet I outperformed everyone else my level, and by a significant margin. Anyone telling you that you can Have It All™ — work only 40 hours a week, marry a supermodel husband/wife, have IPO after IPO fall on your head — is selling something. You will outperform others only through three means: 1. luck, 2. talent, and 3. hard work. You can't control 1 or 2.

There are way too many other ways to be a poor performer to continue listing them. But I hope this is a helpful start.

This is a super-common experience, so I'm glad you brought it up. I worked in six different teams at Microsoft, and then on many teams at Meta (where the challenge was not only the codebase, but the fact that I had never done Javascript or PHP).\
\
My main advice on this feeling is to:

1. get more comfortable with working under ambiguous circumstances, and
2. focus on the zen of learning how to understand a given codebase

### Obligatory Ambiguity

When I joined Windows in 2000, it was already perhaps 50M lines of code. In such a world, it's impossible to understand even 5% of the codebase. At the time, even understanding *just the DLLs* would have been too much to ask. Most large corporations you join will have legacy codebases that are large (perhaps not as large as Windows, but large).

So here's the deal: most engineers in such codebases are operating with very limited knowledge of the actual codebase. What becomes important then is to be able to be comfortable working with limited knowledge, and to also know what things are most important to know.

Comfort at working with limited knowledge depends on a few things. The existence of thorough tests makes things easier. The factoring of code to have loose coupling / strong cohesion also helps. The discoverability of all code (e.g. monorepo) is huge. But personality is also part of this. Some people can't go on vacation unless every day is already booked and all activities are accounted for. Others arrive at some location and just free-range. The key mindset, in a large codebase, is to embrace that you'll never know even a significant portion of it. The skill becomes how to operate under such circumstances.

### How to Understand

- Learn which questions to ask. Diving into new codebases is like sight-reading sheet music -- the more you do it, the more your mind develops mental models of where the key questions and pitfalls are. Seek opportunities to dive into new code, unlike people who avoid going into dark corners because they're scared to. The latter sort of person stays scared for life.
- Fix lots of bugs. Bug-fixing hones your discovery skills: what code calls what, which tools make it easier, etc. Bug fixing also allows you to interact with *far* more of a codebase than if you write new code in it. It's the fastest way to cover a lot of ground.
- Don't look for documentation. Unless you're working on a miraculous team (which btw wastes a ton of time keeping documentation updated instead of writing code that impacts customers), you should assume documentation is outdated or non-existent. Code is like Shakira's hips: it never lies.
- Meta learn. Learn how to learn. You'll develop strategies... like if you're confused about a component, look through *git* history to figure out what changes last touched it. Then look at those commits, which'll tell you exactly which other components interact with the current component. Using source code history is just one meta-learning; there are many other ways. The key is to practice (i.e. dive into new code a lot), and to be observant about which behaviors of yours lead to faster/better outcomes.