Content

Me

clarity of thought
balance in everything
multiplier in teams (share and help)
sense of urgency
quick v0 and iterate with tight loop
bias towards early production and having a framework to safely improve and fix things in prod
respect for time, but value async chat, short meetings, and high level notes
safe friendly comfortable space for everyone

Goal

Technically: Distributed systems with a mix of low level systems and compilers/languages. Large scale data systems generally fit well with this.

Career: Lead projects at scale that add value to the company and align with you interests.

People: Find people who would enjoy to work with.

$$$: Money is important. Find companies that reward well.

Brand

Invest in your brand. Code quality, documentation, discipline of getting things done, reliability, professional tools (zoom av quality).

Never undersell yourself. First impressions are important. Have clarity and brevity in communication. And be professional though not boring.

Identity

“Never forget what you are, the rest of the world will not. Wear it like armor and it can never be used to hurt you.” - Tyrion Lannister, Game of thrones

Upload a cool picture. Be comfortable with: where you went to school, where you are from, what your beliefs are, what you value, what you dislike.

Secret sauce

What is that I bring on the table? What is that the team needs? And is that something that I can provide while others can’t?

Examples:

Team is confused why they are doing what they are doing. Be able to communicate with leadership and explain vision.
Team is not getting aligned on designs. Be able to moderate meetings in an objective way.
A performance problem can not be root causes. Be able to use bpf kernel tools to find the root cause.
Team needs a domain expert. You can become one if you find that domain interesting. Invest in books and practice.

In other words, find your unique selling point. This helps with promotions as well. Come promotion time, people would want to get you there, because you are the person that does things that adds unique value. No body would want to lose you.

Set yourself apart.

Problem solver

Solve problems for the team which adds value.

Fun

Be a casual and easy to work with. Learn to have fun. Learn to get things done as a team.

Story teller

Be one. That’s what most humans understand well and enjoy. And it’s not boring.

Work tips

Know the “why”

Knowing “why” gives you super powers. You can change the rules. You can align teams to the “why” if they are not working efficiently towards the common goal. You can convince leadership that another variant of the “why” is better for the organization. You can prioritize the most important things for the “why”. So, always know the “why”.

Problem solving

With more practice, you pattern match problems to elegant solutions. That comes with experience and hard work. However, the efficient way is to have a forward map from problems -> “why” of , where is a thing (e.g. technology). Try not go the other way because there are tons of technologies but a limited set of problems.

Writing is thinking

If you can’t code, you haven’t fully understood or thought through the solution. If you can’t write, you haven’t fully understood or thought through the problem.

Iterate

Learn quickly, ask questions, take regular evolving notes, practice in test environment, push small changes, do things yourself.

Having a buggy inefficient prototype is better than having nothing. So better get started. But make sure you know the “why” and “what” first. “how” is where you can experiment based on the cost of implementation.

Baby steps. One day at a time.

Important to start small and have something real, code or written text. Even if it works with small n, it is a good start. in the -rocess, you will learn about why and what of the problem, and know challenges of how and solution space. Then, you can improve, optimize, expand in baby steps using iteration – do lots of small cycles before you are where you are happy.

Cat

Think like a cat, be curious. Sometimes trying iut things is faster than spending too much time to take a measured approach. try early, fail and learn. also good tip in debugging: try removing different pieces of code before the bug is fixed, this can be quicker than breakpoint debugging.

Correctness first; optimization next

Focus on getting a correct solution that you can optimize in the future. Then measure. Then optimize the bottlenecks.

Copy

Learn from productive people on how they do things, copy and adjust to your taste.

Experiment like a scientist

Think in terms of: Hypothesis, validate, data points, percentiles, probabilities, symptoms, root causes, false positives, false negatives, correlation, causation.

Be a kid

You won’t know a lot of things. Just say it out loud if you don’t. Don’t pretend. Have a growth mindset. Learn to play and have fun. Know when to be careful.

Ask dumb questions.

Mental models

Reason and think about problems and systems by forming a mental model. This model should be simple enough to explain to others, and at the same time, rich enough to design systems. With experience, you will end up reusing these models for all sorts of problems.

Invest in productivity

Invest in things you do often e.g. editor productivity. Spending $100 on a 3 second improvement in time can scale in your favor long term.

High freq task optimizations: term tricks, copy paste easy incl term and keybindings for select, switching between apps quick, quick tab switching, …

Focus

Avoid context switches. Slack pings every 5 minutes can wait. Set expectations. Reserve blocks of time for your work.

Plan your day

Make todo items of what you want to do in a day. Make sure you have focus slots. Reserve dedicated time for emails, slack, helping others, following email on email etc. Main time is working on your goals and projects.

First principles

Form principles and mental models that help you reproduce a problem/solution. Learn buzz words just for communication, not for understanding. To avoid confusion, make sure that everyone shares the same understanding of buzz words.

Assumptions

Don’t assume. Ask if you are not sure.

Common assumptions that are generally incorrect:

my manager knows everything
everyone in my team totally understood that thing in that meeting except me
this tool never works for me - it must be working for everyone else

Simplify

Try to simplify as much as you can, but not more. Adding simplicity in a system can add a lot of value.

Builder

Do stuff frequently e.g. code + deploy. You need that feedback loop to be motivated.

Brevity

Don’t hand wave. Be as clear and concise as you can. Have clarity of thought.

Mo letters mo problems.

Feedback

Request feedback. If you have someone who can give you direct constructive feedback, consider yourself lucky. Then act on the feedback if you agree with it.

Want feedback and not getting much? Ask. If your manager says something generic, ask specific questions. This would also be a forcing function for you to ask the right questions.

A lot of times, people don’t give feedback unless someone asks. Set an environment where people can openly give you constructive feedback. Take action items from it. Then go do it. Then ask them again if things changed.

In some way, manager -> engineer conversation is not a push model. You have to pull (or extract) information from them.

Great managers though allocate time for this and would want to give you feedback. They want to set you up for success based on what they and you think success means (e.g. promotion, leading a tough design discussion, executing on migrating a legacy system, etc.)

A good zine from Julia explains this better: https://jvns.ca/blog/2018/09/22/new-zine--help--i-have-a-manager/.

Mistakes

Learn from them. Celebrate them – they are going to happen sooner or later. Typically, putting a “fun” spin on it helps.

Fail fast

Learn from failure. And fail fast. Slow failure is the worst.

Next best thing (to success) that can happen to you is that you fail fast. Failing slowly, or worst, not knowing that you’re failing is bad.

Love to be wrong

Love to be wrong. Think about it, if you love science and logic, being wrong would imply that you discovered something new. How exciting! This would only happen though if your quest of self development > fear of being wrong in front of others and being insecure of what they think about you. Making mistakes is the best way to learn. It is practical and takes away the initial momentum required to get started. The important bit is the ability to learn from mistakes and not repeat them. Mistakes themselves should be okay eg bad code change breaks the site indicates system issue. Be fearless and think that the worst case is fine. Be mentally prepared for it. However, in other things like driving, preparation and having 0 mistakes is crucial. So you optimize your strongnenss towards taking risks and making mistakes based on the context.

Cruise control

Don’t. Stop to think. It is okay to be slow initially. This way you’ll actually be faster long term.

Time

Value yours and others time. Don’t be late to meetings. Ask other people to respect your time as well. Add buffer times to meetings if people are always late.

Filter

Remember you have to know your audience and give them what they care about. Be yourself, but provide filtered and concise information based on:

what other person needs to know and what they care about
whether you can articulate well enough, if not, be careful not to confuse or give a wrong impression. if needed, just say I have not thought this through so let’s brainstorm together or just fyi.
at some level, match the other person’s personality. If your manager does not have people skills and is only interested in technical things, limit communication to that and don’t overshare. i guess tgis can be called “know the kind of relationship”. other than being inefficient, it could be hurtful if you don’t get reciprocation. just go technical in this example, be concise and be really good at it.

Meetings

Set structure and organization in meetings and conversation. Set agenda at the very start. Don’t cover things here and there. The exception to this is brainstorming sessions which are meant to be unstructured.

Be a thought leader.

Take high level notes. Don’t be hesitant to write for structure.

Write down action items and send them over email after the meeting. Follow up to make sure things are not forgotten.

Feedback loops

Have honest and actionable feedback loops with your boss.

Visibility

Visibility to team and seniors/leaders is important. Advertise your work to them. This becomes important in promotions as well. If people don’t know you and your work, they can’t vouch for you.

Opportunity

A pre-req for visibility is getting the opportunity to be visible in the first place. Try to gain spots in rooms where leaders are present.

Set expectations – under promise and over deliver

Do not over sell or under sell your self. Find a balance in your promises. Be realistic and add the randomness factor (discovery, on-call issues, helping others, meetings – all these things take time that you are not directly working on your project).

Presentations

Learn presentation skills and tools. Less words and more pictures. In general, try to tell a story using pictures with minimum words.

Impact

Impact is adding value to a individual/team/company. It is subjective because it varies on a case to case basis. So the question is how do you do it? Well, this is my general framework:

Answer the question: how do i make someone’s (individual/team/company) life easier/better? Ask them about it. Sometimes they won’t know it. In that case, predict and then ask them “if i do , will that be helpful for you?”
Before starting to based on above, set your success criteria e.g. if i am doing right, should increase. Have a measurable infrastructure setup.
Incrementally do things (what/how can be hard) in order to achieve . Measure at each step. Make sure you are going in the right direction. You can also ask the individual/team/company directly, but make sure metrics like are there because ideally you should couple yourself to those and others should agree that is the right measurement.
Feedback: When done, do a final analysis by asking if impact was created.

Technical understanding

Understand something properly.. only then you can possibly enjoy it.

Promotions

If you are at level N, see what N+1 people do. Then do N union N+1, and better. Easier said than done. But the easiest way to promotion is to already demonstrate that you’re at the next level. That, and don’t be replaceable (i.e. provide unique selling point and value to the team).

Some times, what you or your manager tell you != what N+1 requires. Be cognizant of that. If that ends up being the case, have an honest conversation with your manager. Either what you are doing is (or leading to) N+1 level, or your manager can explain how this is short-term. Make sure it’s not long-term.

Confidence

Don’t know something? Say “I don’t know”. Partially know something? Don’t ramble and say that your understanding is .

Details

Once you know the WHY and WHAT of something, the HOW (details) are as important. People underestimate execution.

Quality

Learn from high quality content (mostly books and experts). Youtube videos are great for introductory stuff, but generally not more than that.

For example, reading man page > stack overflow. Reading book on perf > reading blog posts. This is especially important for fundamentals. Once those are solid, then stack overflow and blog posts help – you’ll also notice that you can find and improve their answers/content.

Clarify

Clarify by listening, repeating your understanding, and summarizing (concise) in your own words.

Time and Prioritization

Time is the most scarce resource – use it wisely. Also, if you spend your brain cycles on non-important stuff, then you’ll be mentally tired when you get to the important stuff – so, focus on things that are important first – you’ll realize that once you do that, you won’t have time for the non-important stuff.

Time box day to day tasks.

Data points

Back your opinions by data. If you don’t have it, do a survey. Use descriptive and easy to digest graphics.

Examples:

Want to show value of something? Make a table of problems as rows, and before/after experience as columns. After should be better overall, given the goals of the something that you are showing value for.

Sauce

Learn how the sauce is made. Learn how managers think and why. Learn how orgs plan. Learn how decisions are made at the highest levels.

Ask questions about visions and whys. Then contribute to those discussions as an engineer. Ultimately, engineers know most about the systems. So there’s a lot of value in engineers doing directional stuff, especially in infra orgs.

Ideas

The best ideas should win. Strive for creating and discovering amazing ideas. Think out of the box and cross disciplines. Ideas set apart visionaries from others.

No

Learn to say no when you have to. Prioritize what’s important, and focus on that. For rest, say no respectfully.

Ideal company

More to fill here but generally a function of:

engineering quality
challenging work (should provide growth opportunity)
bottoms up engineering – ownership, power (and hence accountability) given to engineers
“culture” (to define)
compensation, perks, etc.
reward high performers

Nature

Stressed? Can’t figure out solution to a problem? Talk a walk and connect with nature – it’s amazing how doing that can unclog your brain and make you more creative and confident.

Ideal team

Mission

Team has a mission statement. All goals map to this high level mission. Everyone knows the bigger picture and why they are doing what they are doing.
Team is adding business value to the company.
Team has senior mentors that can actively help you in your career. This is vital and can accelerate your growth significantly.

Communication

There are healthy debates and in general, a balance of opinions. People disagree but are open to listening and changing their views. There are no “groups” – it’s a “team” overall.

Manager

Not micro manage. Manager’s role is like a doctor and not a trainer. Doctors help you when you need it to help you where you want to be. Trainers may also want to help, but they do so by driving you. That shouldn’t be the case. Instead, drive yourself. You should own your career.
Manager’s goal is for the team to be self healing. This also means team members help each other and work together towards a goal.
Managers should know how to manage people, emotions, expectations, and growth. In addition, if you are new to the team, you really want your manager to be technically sound and know the stack/systems – this is because for them to give you good advice on things like planning and expectations, they need to know the technical stuff themselves.

Members

People trust each other.
Team members feel the obligation to be honest but respectful. They can have discussions on hard topics in a mature way. For example, if a team member is struggling with their project, others can help in identifying why, or help if possible.
Everyone is respectful and empathetic. No brilliant jerks.
Team has “fun” together. You spend up spending a major percentage of your life with your team – it’s vital to ensure that you have a good time!
Very important: team has high EQ, or atleast most people have it. This means not getting defensive, or not associating your ego with your technical opinions. It is very hard to converse with people who (1) don’t listen, or (2) do listen but don’t give weight to your thought. Having these conversation in a calm, friendly, objective way is a very important trait. It is the balance we need in this polarized world.
The best people to work with are smart and compassionate.

Diversity

Diversity in cultures and opinions are welcomed as long as everyone is respectful. Team has a spectrum of seniority levels: interns, fresh grads, senior engineers, tech leads and staff engineers, and ideally a very experienced engineer.

Opportunity and Visibility

Will I get chances to show my skills to my peers (and leaders)?

Team questions

For manager

How would you describe your role?
What do you value in an engineer? Describe your ideal engineer.
What are the kind of engineers that will find it hard in the team? Let the other person talk about traits that will make things hard for you. And then make sure how don’t have those traits.
What does the team need? I want to (or have experience in) – do you think this would benefit the team? See alignment in your interests and team needs.
How much time do you spend on average at work?
How much time do you spend in meetings?
How much time do you spend with the engineers?
How involved are you in engineer’s day to day?
How many people have you promoted in the last 2 years? From what levels? What were some of the challenges?
How do you handle team members going through personal challenges in the lives?
What kind of opportunities and visibility will I get? Can I be in rooms where high level strategy is discussed? Can I be in rooms where I can present my work to a broader set of people? Ideally, this should be bottoms up i.e. the engineers drives this. But even in that case, there should be no obstacles for the engineer.
Who can I mentor and who can mentor me?
How do you do performance reviews? Have there been any surprises? Tell me the perf process.
Your team has X (high/low) attrition rate – why? Look out for high attrition teams. There could be a red sign if people are leaving and not staying with team/manager.
Tell me the process for making the sauce: from planning (who does it) to prioritization all the way to final design and implementation. Examples of bottoms up initiatives would be nice.

For members

Good strategy: ask how you “feel”? Get a pulse on what people think overall and what they focus on when they answer. If they say things like: the technical work is exciting, the team is fun and helpful, the manager is supportive, then that’s a good sign. To dig in further, ask them about examples without making it sound too robotic.
Do you have fun? Do you feel comfortable? Do you feel you can be yourself?
What do you think the team’s mission is? What are you doing or have done to progress towards that mission?
Give an example of when you were having a work related issue. How did the team help you?
Do you mentor others? Are you mentored by someone?
Are you looking for a promotion? Do you feel there is structure around you to guide you to get where you want to be?
How’s on-call?
How’s wlb?
Did you go through a life event recently? How did the manager and the team help?
What are things you think the team should work on? Look for improvement areas. If they say something like everyone is too stressed about work, then take that as a potential warning sign.
Do you like working with others in the team? What do you feel about them?

Onboarding and ramping up

Productivity tips

Fast keyboard repeat rate
Big mouse cursor size
Fast internet connection – those msecs add up
Keybindings for common/hot tasks (e.g. closing tabs in browser, switching to previous file in editor, etc.)
Terminal smartness for small scripty tasks
Terminal management (tmux)
Window management (e.g. tiling)
Mechanical keyboards for getting good feedback and for enjoying to type
Anything that reduces context switches – those kill productivity and focus, which in turn makes you confuse and demotivated or essentially out of control of what you are doing
Minimize your dependencies and hence the initial surface area you have to explore to get something done.

Knowledge channels

Find where to search for stuff. This can be a combination of:

slack channels (async)
find interesting internal groups: tech/languages, team, ex-<your_prev_comp>, housing market, personal finance, productivity, perks, techlounge, etc.
email threads, mailing lists (offline)
code reviews & comments
central drive (e.g. gdrive) if any
internal wikis, internal docs (e.g. gdocs)
internal code search tool

History

Learn history to understand context. Don’t be the wise guy immediately after joining a team. Talk to people first.

Take notes

You are going to forget the thousand and one things. Write stuff. It doesn’t have to be super structured or well thought out. If you want to, you can do that incrementally later.

Technical projects

Read design docs. Go through recent changes. Treat code as the source of truth though.

High to low level: Play with the code. Step/debug through it. Run end to end tests and learn the code flow. Form a systems picture in your mind.

Low to high level: You should have deep knowledge of your main system and surrounding systems. Know the internals. This can be the differentiating factor between okay engineers and awesome engineers.

Combination of above: middle out. The best engineers can go high to low level and back with ease.

Architecture diagrams

Find high level architecture diagrams. If you can’t find them, create one, and share with the team. It’s immensely useful.

Onboarding guide

Find onboarding guide for team. Use it. If you can’t find, create one. It’s really useful for the team.

Relationships

Form relationships by:

going to lunch
taking interest in other people’s lives
listening to others
common projects in small tightly knit groups
participating in design discussions
volunteering to help someone in need e.g. covering someone’s on-call shift
provide constructive feedback
take notes for someone in a meeting

Eventually, gain trust of people by being consistent over time.

Dev cycle and tools

Learn the typical cycle:

checkout: source control
develop diff: code editing, ide tricks, etc.
test: testing (unit, end to end, or anything in between)
debug: print statements, breakpoints
review: send diff for review and address comments
deploy: check in to deployment system. Continuous test/integration/deployment (CT/CI/CD).
verify: make sure things work in prod

Your code/changes -> test -> failure -> debug -> code/changes (back) local dev cycle should be extremely fast. Why? Because iterative development means trying and experiment in quick steps while converging to a final stable state. Once you have reached this state, your review + deployment cycle should ideally be fast as well – probably won’t be as fast as local cycle because of human involvement plus distributed build, test, and deploy system delays.

Do it as quickly as possible. You want to get this out of the way asap to get to the real stuff. These are just tools – important, but means to an end.

Always have reproducible steps. Writing a python script or a docker container. Software is hard, and you will forget the thousand steps you had to take to get something to work. Best way to document that is to write a script.

When debugging, quickly write down high level possibilities / hypothesis. Take short notes. Try to structure your thoughts. As a tip mentioned earlier, don’t cruise control. Take control and ownership of your thought process. This is also useful if later you have to explain all this stuff to someone else.

Debugging dev

1st step is always to have a reproducible script/test that you can run over and over again in a deterministic way. As part of this, you also understand the issue.

Then apply the quick dev cycle (develop fix (code) -> test -> test failure debugging -> code -> … (build system)). In above, “test” is essentially a version of the script s.t. it showed issue before and now doesn’t.

Bug fixing

Different strategies to utilize:

Change stuff and see what happens. Great way to observe close system and hypothesize its behavior.
Delete code until you no longer see the issue. Do a binary search (adding back chunks of code) to see when the problem is fixed – this isolates the code change that introduced the issue. Super useful for regressions, and some tools automate this process. Notice that, for this to be successful, you need a reproducible script as mentioned in the debugging section above.
Put on your data exploration hat, and explore avenues (code search, task system, bug system, wikis) to search for a similar issue. See what other people did. If you find a task/bug, see the corresponding code change and the review comments. Then make that change to see if that also fixes your issue.

Principles:

Ensure that you fully understand the WHAT of the issue.
You’ll get a lot of information as you are exploring, and so it’s easy to get confused because a spider of mental model dependencies. Defeat that spider by writing down to think as you are fixing a bug. Think like a scientist: be precise, measure, hypothesize, verify, and keep repeating this loop.
If you are still getting confused, that either means you didn’t do (1) or you don’t have a process (see strategies above).

Perf dev

Steps of fixing perf issue:

First step is always to measure quantitatively. Ensure correctness of measurement.
Once measured, ask yourself, do I need to do better? Don’t micro optimize if you don’t have to.
If you still need to optimize, next step is to improve perf. Generally, you profile your code to do this.
Profile: find hotspots in your code. once you know where more time is spent, you understand why that’s happening and try to fix it. This is where you need your CS knowledge and industry experience.
Once you made the code change to fix the issue, the next step is to verify. Make sure you can no longer see the hotspots in your profile. At this point, you can measure the quantitate diff in measurement, and talk about “X% improvement”.

While profiling is about understanding the perf characteristics of your program, benchmarking is setting a “standard” to use a baseline to improve your perf. Both involve “measuring”. But benchmark is about comparing: I get 1K write IO/sec on HDD vs 10K write IO/sec on Flash/SSD. Assuming everything else (see rules of measurement) is the same, benchmarking a new SSD (or a new software) shows a 10X improvement. A lot of times, benchmarking is capacity of something – more specifically, you can use to compare capacity diffs of two versions of sw/hw.

Profiling vs Benchmarking: https://stackoverflow.com/a/39381805

Rules of measurement:

Always know what you are measuring. You may think you are measuring disk, but because of caching, it’s possible you are actually measuring memory.
Always know how your tools are doing the measurement and what data source they are based on. For example, is my data being sampled (pull) or pushed based on event triggers or something else? Knowing this helps in understanding and reasoning about the measurement. For example, if with sampling profilers you see functions that are not part of your program, you know that is because of OS/kernel scheduling other processes (main threads) when you were sampling on that cpu/core.
Make sure you have an accurate (correctness property) and reproducible way to get measurements.
Your measurement tool (e.g. profiler) and what you are measuring (e.g. hw counters via kernel perf) are bound to have accuracy constraints. There are generally tradeoffs between those two spectrums.
As a good scientist, have a control and treatment when doing fixes. Treatment should be concise and scoped to change. Everything else should be the same. This “everything else” broadly includes: 1) environment: same os, same hw, same kernel version and settings, etc., and 2) workload: applying a different workload can change the performance characteristics of a program significantly.

So, overall, measurement = f(environment, workload), and it is bound to have finite precision. Be mindful of that. You will never get truly accurate numbers, and in some cases, misleading numbers (e.g. if you are using sampling profiler that happens to miss the infrequent event).

Dev tools and systems

Experimentation: how do i ramp a feature incrementally? how do i do a/b testing? what statistics can i get?
Profile (perf): measure performance and bottlenecks. flamegraphs, perf tool, bpf tools.
Benchmark (perf): what’s the limit? ensure you don’t regress from there.
Observability: metrics, logs, tracing
Alerting: email, messages, calls, priorities

It is CRITICAL to understand (bottoms up) these tools. Profiling and benchmarking tools are generally tricky because:

there is some estimation going on. e.g. perf tool uses polling at a fixed frequency. cz of context switching, you’ll see stack frames (functions) not relevant to your program.
fluctuations in measuring tool and/or the code/executable
hard to pin point exactly what you are measuring because of layers of abstraction

Distributed system engineers

For distributed system engineers, make sure you learn the following things, especially if you are on the more senior side:

rough list: dev env, build system, cicd, deployment and dc, failover and traffic shifts, monitoring and observabilty, configuration, alerts, testing, capacity planning, availability, cluster management (containers, Tupperware, zookeeper, etc).

Process

Technical

Emails. Have filters. Try to focus on only the important stuff.
Calendar. Meetings.
Async communication: slack, messenger, etc.
Social: slack, internal tool.
Bug tracking system
Project management system (for tracking work and dependencies)

Example: https://www.phacility.com/ “Phabricator is a set of tools for developing software. It includes applications for code review, repository hosting, bug tracking, project management, and more. Phabricator is powerful, fast, scalable, and completely open source. You can download and install it on your own hardware for free, or launch a hosted instance with us.”

HR

Reimbursement system.
Payment system. How is my pay calculated?

Leading big technical projects

People

Task management

Principles

Always know “why” and “what” first
Iteration is important, prototype something (“how”). Otherwise, if you wait too long, you’ll have spaghetti in mind and nothing (code) to show for it.
More on iteration: stacked diffs and quick reviews

Misc

Ramping (tech stack, process (team, company, code, observability, alerts, feedback loops), project)
Communication + Search (tools)
Manager, expectations, goals, feedback loops, measurement
Personal life (health, relationships, finances)

Imagine you join a new project, a new team, or a new company altogether. What are some of the patterns you can use to effectively get ramped up? Working on new projects or teams can be hard, especially if there are lots of people involved and the codebase isn’t well documented or tested.

Over the years, I’ve found myself to use similar patterns to overcome this issue. In this post, I aim to enumerate those patterns. I’m writing this for myself, so that I can evolved this over time and reference it if I forget. But I’m hoping others can find this useful as well.

Before we get started, a final note: there will be some hand waving here, and that’s intentional. That’s because the problem is not specific to a project, team, or company, but more in general about ramping up effectively. You’ll find that some of these work for you, and some don’t. That’s okay, and actually quite expected, since your learning process can be very different from mine.

DO – Iterate: Design -> Code -> Test -> Deploy -> Monitor — Small cycles (one step at a time) — Local iterations (code, test) — integ test and line debugging helps
Middle out (need both HL and LL)

For LL:

Code reviews (do yourself, even small to get familiar with codebase and dev process) – Look at other code reviews, discussions, (same for slack and email discussions)
Run local tests (either automated ones + debugging, or your own: deploy locally and curl for web services).

For HL:

Read design docs

For both:

Talk to people! (ask questions) – Regular sync ups – Slack (time to think if not comfortable to directly call) – Think what questions to ask
Search is a super power (slack, email, wikis, gdocs, stackoverflow, google, …)

Form mental model of concepts. (HL) Systems thinking.

Map code to that model.

Communicate with your managers.

WRITE!!!! Very important. Think through things. If good, you can even share your writing!

Understanding concepts and mapping code to mental model very important. It increases your confidence. Know how things work. Problem has “why”, “what”, “how”. Why should be extremely clear to you. What should be somewhat clear in terms of requirements. How the same, should be clear at a systems level.

If you don’t have a good understand, don’t claim like you do, directly or implicitly (talking to junior engineers). Accept you don’t know, learn, and once confident, claim such things. Everyone needs time to learn, take yours.

Don’t estimate or make promises without a clear understanding of a project/issue’s: WHY, WHAT, HOW. Just don’t.

having quick and frequent iterative feedback loop very important. increases your confidence, you get to learn the process (dev/test/deploy), know common issues, talk to people, feel like in the shoes of someone who has done things.. be patient here..

WHY, WHAT, HOW.. LL/HL.. what’s important? everything! clarity and honesty is the key here. If i had to pick one, WHY is the most important for senior roles. A lot of times, WHY doesn’t match with WHAT, and WHAT doesn’t match with HOW. That’s where seniority comes in, you can take in complex stuff, break it down into digestable simple components, be able to effectively communicate that.. talk to both product and engineers… Think simple. Have a clear thought process. Keep repeating until you achieve that.

Map your code to mental models, map your answers to mental models..

Engineer’s guide to ramping up

if you don’t know anything (terms, concepts, tech), ask/read, and then write! write for yourself to begin with. make things simple, things should be simple. if you cant grasp the thing, the thing is not simple. make it simple in your head by using systems thinking. code doesn’t lie, and even a bad system has some design. explicitly capture that in your system mental model.

TIME BOX!

Code and computers don’t lie. They are logical (but layers of abstractions don’t help but still at the core, it is 0/1’s). That’s the beauty of computing. Trust code, not words. But know WHY and WHAT, because code is as good as the human writing it. If they didn’t have the right understanding, code wont magically be what it was supposed to be.

communicate.. skills, patience, respect, acceptance, also confidence, know what questions to ask, gauge and limit your question space.. try to be organized but there will be brainstorming sessions

Look at other resources (lak twitter bookmarks knowledge)

Mistakes are good. Repeating mistakes is what you should avoid. You wont learn without making mistakes. Use your best judgement, be careful, but don’t be afraid of making mistakes. They will happen. That’s the game you are in. Learn from them, move on. Don’t take it to heart, but goal should be to avoid it in the future.

Have a workable sandbox. Local playable sandbox. Play! Explore. But time box. Form mental model of concepts and their relationships.

Don’t go for perfection. Take thing slow, and then once you’ve a solid fundamental ground, exponentially increase velocity. Perfection is goal, not journey. Enjoy the journey, have fun. Make sure you’re in the right direction. Have feedback loops and success criteria (against your goals) to validate.

Contribute early on. Be a builder and a designer. Wear both hats.

Form relationships. Know people. Talk to them. Listen. Be opinionated, but respectful. Don’t accept just because someone says so. Convince yourself first. Prioritize though, don’t apply this to things you don’t have high priority for). But if asked about them, use the same principles. If you cant understand someone, ask them why they think something, understand their thought process, be ready to accept that not everyone thinks like you. Accept different tastes. Make sure people have reasoning behind their decisions though.

Example: Netflix culture guide. Good/Bad debatable, that’s fine. But imagine if they don’t have that guide and still have those rules. I do respect that they explicitly mention this guide. You can disagree with them, but you’ve to recognize that they have their reasons according to their thought process. They’re not throwing darts in the air. They’re aiming. Agree/Disagree separate. Whatever you do, that’s fine. Just make sure you’ve your own reasons behind it. Otherwise, confusion will increase. Clarity and simplicity over everything.

Don’t hand wave that much, be clear. But accept/recognize when you don’t know.

Biggest mistakes that junior makes is senior people know everything. They don’t. Next biggest mistake they make is thinking that there is magic. There is none. Understand the magic. E.g. compilers are actually relatively easy to understand because they’ve a very theoretical mental model.

Initially, realize that you’re like a kid, although probably more trained. But still, in terms of knowledge, you’re a kid. Treat yourself, and others, like a kid. Go slow, take small steps, monitor each step, improve gradually.. then take bigger and bigger steps.

Nurturing yourself and others around you really important. Celebrate mistakes, learn from them. Be kind, be compassionate, be empathetic. Help a team member in need like you’ll need their help one day. If someone is struggling but trying hard, be there for them. Being there is the most overlooked trait in a leader. If someone is acting malicious, or not working hard, creating problems, investigate and think why. Some people are bad. It’s important that you find a way to deal with it. Don’t accept toxic cultures. Run away. If you’re in a tricky situation where you’re in a tricky situation (need money for family), be smart and find your next play. Leave respectfully.

Know your value. If not don’t recognize it, try to make them respectfully. If still don’t, leave.

Focus, so much going on.. prioritize your work, try to help as much as you can.

2 types of people: Story tellers, Math/Tech

How is important. Ask people how. But code is the SoT. Be able to dive into code. Have tools for easily navigating a large codebase. Be able to parse the code.

Different types of people you will:

Sayers, Doers Yes Yes GOOD No Yes OK+ Yes No BAD No No OK

Do one thing at a time. Ability to focus.

Work is important. Esp at a young age, when are building a stable financial portfolio, work is important. Or if you are starting a business, that is important. Either way, it is important to prioritize your work over things in your life.

Although, keep in mind, that as humans, some things are equally important.

Stick to the basics at the very least.

Physical health: eating, exercising
Mental health: mindfulness (meditation), info you take in (quality > quantity, ~ junk food)
Meaningful relationships (Parents, siblings, spouse / partners, friends)

1,2,3 are extremely important. Balance them with your work. Don’t let work eat up any of these three things. You don’t have to spend too much time, but atleast spend some regularly and consistently.

Practice systems thinking. Break down problems and systems into small chunks. Ask why/what/how for each component, and overall. Goal of each component in addition to f(i,o,state).

Finances: necessary but not sufficient. Know your value and optimize for it early in your career. WLB is important. Burn out is real. Invest, build a diverse portfolio. Grow your money over time. Note happiness/$ graph is not exponential, it taper of i.e. at some point when you have enough wealth, don’t go for too much by sacrificing 1/2/3. Tempting but not worth it. Have enough to live a decent life (home, car, family support, retirement)

Try and see things for yourself in practice. Don’t wait too much. Don’t get too theoretical. Keep a balance. Once you have your hands dirty, incrementally ramp up your theory and mental model.

Start small (e.g. small data), and then ramp up. Small is faster and easier to debug. So iron out basic issues before going big, where even small mistakes will get amplified.

Start, then keep improving.. important to have a quick feedback cycle to add new stuff (small things like typo fixes, and big things like features). important here that there’s a quick feedback loop.

Write, write, write. Min heap K largest example. Didn’t know why we need min heap. Wrote down example. Then worked through it. Realized it’s because we’ve to pop minimum at every iteration, and for efficiency, we want pop to be O(1).. which data structure to use? Min heap.

Debugging Styles ** Remove stuff and see what happens .. surprisingly good way to learn about something as a black box. Play with inputs/state, and observe outputs. Come with hypothesis, and verify. Scientific approach (separate post).

** Prints

** Breakpoints

importance of getting the interface right!

Things not to forget

Ask the stupid questions. They’re much easier to ask earlier rather than later.
Participate early in team discussions. Be street smart and not interrupt too much, but if you or the team is sitting in a 1 hour meeting without full understanding of something, then we’re wasting everyone’s time.
Don’t stress too much. Communication is key. Talk to your manager and set expectations if it’s taking time to ramp.
Think from first principles so that you can replicate decision logic. Buzz words are there for communication, but not more.
Form a mental model. Apply systems thinking to your technical problems.
The biggest problem we have today is the volume of information. It is a good problem to have. So Write. Take notes. Have a centralized place for your notes. Even a plain text file works wonders.

Tools

Codesearch
Build system
Source control system
Communication system: email (offline), slack (near real-time), meetings (online).
Systems to use for searching stuff: slack, mailing lists, emails, internal wikis, etc.