Tuan Tr's Key Ideas from The Staff Engineer's Path
by Tanya Reilly

"Nines don't matter when users aren't happy"

                Charity Majors, CTO of Honeycomb

"SLOs are useful but they don't tell the whole story"



You need to measure success from your users' point of view. Users/Customers could be everyone who uses your service/product.

Don't forget seeing a problem doesn't necessarily mean you should jump on it.

Choose the opportunities where your help is most valuable and then take deliberate action, with a plan for stepping away again afterward.

"be autonomous and never have to think about each other's work" ... many many ideas about your current team when you are new or you are "flying in sky" with some good moods.

In reality, any big project is going to span multiple teams, departments and job functions ... Many unexpected problems (procrastination) will happen leading to miss an important deadline.

• Understand and explain: "debug" to understand the current circumstances and "fix the bug" by make sure everybody understand the same (what's happening) 
• Make the work easier: workaround by not need as much from the people you're waiting for (the procrastinating component) (reduce your expectations)
• Get organizational support: demonstrate the value of the work to get support from organization --> sometimes you need to escalate to bypass the blockage.
• Make alternative plans: change the current (origin) form of (blocking) tasks by creatively create another solution. 

Blocked by coding, configuration problem ... and couldn't solve it immediately, may be give you some relax could help:

• Sleep is amazing
• Vacations can do the same thing
• Take a few days (break time) (totally) away from a problem

You will almost come back with better ideas even if you haven't thought about it in the meantime

Trying to solve a problem in a narrow space between meetings maybe limit your ideas -> schedule yourself some dedicated time to (really) unpack the situation (this takes time).

Bring your best brain to that meeting with yourself:

• Good sleep
• Non-stodgy food
• Plenty of water
• A room with good light and air

...

"You should know your own problems, do whatever makes you smart"

Even you created a "best" software in the world but if users don't know about it or aren't convinced it's worth their time --> you need to do the "marketing" for your software (even internal organization)

So farming, creating software may be the same, we all need to "sell" our products.

Don't just tell people about the existing of your solution, you need to "keep" telling them:

• Don't assume that users will find the your product (even after you tell them about it). You need to "help them to find it".
• "Advertisement": Send emails, do road shows, get a slot at the engineering all-hands, posters.
• Support & Get feedbacks: Offer special (support) services to specific customers who are likely to advocate for you. And then get feedbacks, testimonials to understand their experiences about your products and do upgrade.
• Persistence: keep telling until they start telling each other. 

"Whatever you've created, make it easy to find"

• Put your product at anywhere its intended users are likely to look for it.
• Make the search results on any searchable platforms reach to your product at the right place. (plan for likely names, including misspelling, mistyping and any hyphenations people are likely to guess)

"The healthy balance of feature work and maintenance work and teams build the time for high quality into the cost of their projects."

• Make sure the user stories for the project include any cleanup work that need to do (a part of user experience or laying foundation for the next feature)
• Use related bug reports or action items after outages to justify the cleanup work.

Need a dedicated time to do necessary engineering work.

"There's a healthy balance of feature and maintence work, and teams build the time for high quality into the cost off their projects"

Building demo versions / lightweight first verions / prototypes to get early user feedback .... take technical debts always needs us to return to improve whatever we've just bypassed.

Clean up tasks should be apeared in your projects if not, it's the time to dedicate resource/plan for these tasks.

"Software has an extraordinary number of technology areas, each with its own specialized knowledge and vocabulary. Knowing mobile development, algorithmic computer science... doesn't prepare you for a frontend UX project"

"... You may find that you're learning from the junior engineers you work with. (This is a good thing!) Here is where your technical knowledge provides a foundation."

Even when you cannot recognize the specifics of the problems in a new domain, your general experience should help you recognize their shapes.

You can pattern-match the new problem to something you recognize, so it will not be completely "new" now.

The broader your scope of experience, the more "hooks" you'll hang new knowledge off and the faster you can learn new things.

"Know what high-quality work looks like and aim for that standard in everything you do, not just the parts you enjoy most"

It means:

• Writing the clearest documentation you can.
• Be the first person to know if your software breaks.
• Know the trade-offs: accept quick fixes (when needs) but focus on long-term solution

How to: 

Having High Standards = making your work as good as it can be

• Seek out constructive criticism - put aside your ego and ask someone else to help make you better (review, evaluation...)
• Take your comments seriously .
• Own your mistakes: admit what happened and fix , apologize...