EE > Learning from Other People

While there are no stupid questions, you can get much more from your colleagues by asking good questions well.

You want to show that you value their time: demonstrate that 1) you did your research, 2) show what worked and what didn't; 3) and minimize the time they need to answer your question – but still get the most information you can.

If someone hands you a fish, also follow up on how to fish – "How did you solve this?", and try to never ask the same question twice. If you must ask the same question again, explain what you understood the first time around.

Of course, there's also a cost to spending too much time digging before asking questions. A rule of thumb along the lines of "one hour of digging" before reaching out can be very valuable instead.

I'll also bring up a pet peeve: if you're reaching out asynchronously, please include the question as part of the initial message to save on a lot of unnecessary back and forth.

Setting and updating expectations constantly as you ramp up can be one of the most valuable things you can do. Explain how far you've gotten, how long you think it'll take and why.

Writing down and sharing (much more on this in a minute) what you've found will also help validate that you're building a good understanding of the system and act as a bridge for whoever happens to come after you.

Regular communication on an automatic cadence: as opposed to self identifying specific milestones also significantly reduces pressure on sharing updates: if you do it every week, then people can rely on understanding your progress regularly when you push the information; instead of having to pull it when they get worried.

More recently I've been experimenting with a single status doc anyone can use to quickly catch up on the status of the projects I'm driving directly, and it seems to work well. A lot of color helps.

(This section is also an example of Do as I say, not as I do because I regularly forget to make timely updates.)

Never under-estimate the value of shipping several small wins quickly: you'll build momentum and confidence in yourself, and inspire confidence in others at the same time.

You're also actively fixing and improving the project you're working on, doing good work sooner along the way.

As satisfying as it is to rant about past design decisions – and they may definitely be horrifying – the engineers before you did the best they could with the constraints they were working under.

You need to figure out which of those constraints still apply and which ones are obsolete, and do this without running headlong into them. Try to understand the rationale behind questionable design decisions to make sure they weren't solving a problem you just haven't faced yet.

Once you're sure you have context on past decisions, you should feel empowered to go and change them. It can be just as damaging to blindly accept past decisions as it is to change them without thinking through the consequences.

As someone new to the system, you're more likely than most to have an opinion on what doesn't work at all.

Learning from the engineers who came before you isn't necessarily restricted to directly talking to people. There's a lot of information available in any reasonable code base.

Most obviously, you should quickly navigate and understand the documentation that's available: particularly valuable is documentation that explains the why. I should emphasize that I generally recommend reading or running the code itself to understand the how; documentation describing the how tends to bit-rot the fastest and is often the least reliable.

It can be both inspiring and extremely informative to simply shadow others who are comfortable with the system. You can see what it's going to be like once you build mastery, and ask live questions along the way. Pay attention to how they think, the tools they use, and the order in which they explore different avenues. Ask for historical context – particularly for systems that don't yet match your mental model.

If pair programming isn't feasible – try simply shadowing experts at their work. Take notes along the way, and try to follow along on your own computer if you can. There's also the pleasure of watching masters at work.

This may or may not be possible depending on your setup, but can be one of the fastest ways to get better at ramping up and solving problems.

See if you understand things if you can do it in a way that fits in with the rest of the system. I try to write code that blends in comfortably with all the other decisions taken along the way: following naming schemes, unit tests, but also the look & feel of the code (respecting Chesterton's fence).

Once you have a good feel for how things are done – and can demonstrate your familiarity with them – you'll also be able to make a much stronger case if you plan to change them.