Read on Twitter
Question from a reader: "I've just been hired to take over frontend for a really complex application. Feeling very overwhelmed right now trying to understand the codebase. I'm really stressed out since nobody else on the team does frontend."
What would you do? My thoughts
What would you do? My thoughts
First off - it sucks that your company put you in this position. Ideally you would have a mentor/buddy to guide you through onboarding.
But things often aren't ideal in real life. Shit happens. We grow most when we deal with shit happening. Someday you'll look back and laugh.
But things often aren't ideal in real life. Shit happens. We grow most when we deal with shit happening. Someday you'll look back and laugh.
Second - it's OK to feel stressed. I would too. Anyone would. It's not you, it's them. Don't freak out, but make sure your bosses know the situation they put you in. Set the expectation that your productivity will be low while you ramp up, and document what isn't documented.
Third - Start from the outside in.
Read tests, read PRDs, read design docs. (assuming your company has them).
Having a high level mental model of the system is more impt than reading every line of code.
Breadth first, not depth.
Read tests, read PRDs, read design docs. (assuming your company has them).
Having a high level mental model of the system is more impt than reading every line of code.
Breadth first, not depth.
Fourth - If even breadth first is too overwhelming (some codebases can be HUGE), start tracing specific user journeys for a feature.
Remember the interview qtn "What happens when you type Google dot come into the browser"? ( https://github.com/alex/what-happens-when)
Do that, but for your app.
Remember the interview qtn "What happens when you type Google dot come into the browser"? ( https://github.com/alex/what-happens-when)
Do that, but for your app.
Fifth - Some code will straight up not make sense. You will want to remove or simplify it.
Be careful - Chesterton's Fence ( https://fs.blog/2020/03/chestertons-fence/) tells us not to remove things without knowing why they are there. However, some codebases TRULY are legacy/premature abstractions.
Be careful - Chesterton's Fence ( https://fs.blog/2020/03/chestertons-fence/) tells us not to remove things without knowing why they are there. However, some codebases TRULY are legacy/premature abstractions.
Sixth - Interview everyone. They know more than they're telling you. Make sure they know that it's in their interest to help you NOW as MUCH as possible. Try to understand:
- how they like to work with frontend
- low hanging fruit you can deliver
- what's NOT important to them
- how they like to work with frontend
- low hanging fruit you can deliver
- what's NOT important to them
Seven - Now that you know what the app does and how it fits in your org:
- WRITE. EVERYTHING. DOWN.
- Draw diagrams. The more complexity, the more "layers" of abstraction. (check out the C4 model https://c4model.com/ )
- Start making small changes, build momentum by small wins
- WRITE. EVERYTHING. DOWN.
- Draw diagrams. The more complexity, the more "layers" of abstraction. (check out the C4 model https://c4model.com/ )
- Start making small changes, build momentum by small wins
When people talk about the best jobs theyve ever had, they don't talk about snacks, vacation days, foosball tables.
**They talk about epic challenges they've overcome.**
You can make this the job you'll be talking about for the next 10 years, with the right mindset and support.
**They talk about epic challenges they've overcome.**
You can make this the job you'll be talking about for the next 10 years, with the right mindset and support.
