The document summarizes advice from two tech leads, Chris Riccomini and Dmitriy Ryaboy, on things they think engineers know but were not explicitly taught, including how to properly ask questions, handle on-call responsibilities, understand software dependencies, and discuss promotions with managers. Specific tips are provided in each area, such as doing research before asking questions, setting time limits, tracking work while on-call, pinning dependency versions to avoid conflicts, and assessing one's own skills and accomplishments when considering a promotion.

1. What Your Tech Lead Thinks You Know
(But didn’t teach you)
Chris Riccomini & Dmitriy Ryaboy
2021/11/18

2. Chris Riccomini
● Engineer, investor, advisor, writer
● PayPal, LinkedIn, and WePay
● Open Source (Airflow, Samza)
● Co-authored The Missing README
Speakers
Dmitriy Ryaboy
● Engineer and manager
● LBNL, Ask.com, Cloudera, Twitter, now VP
Software & DS at Zymergen
● Open Source (Apache Parquet & others)
● Co-authored The Missing README

3. Agenda
● Asking questions
● Going on-call
● Understanding dependencies
● Talking about promotions
● Q&A

4. Asking Questions
● Do your research
● Timebox
● Show your work
● Avoid interrupting
● Multicast & Asynchronous

5. Asking Questions // Do Your REsearch
● Documentation
● Wikis
● READMEs
● Source code
● Issue trackers
● Mailing lists
● Chat history
● Experiment!

6. Asking Questions // Timebox
● Set a time limit
● Then ask for help
● Or set a new limit (if you’re making progress)
● Then ask for help (no matter what)

7. Asking Questions // Show your Work
● Give context
● Describe the problem
● Say what you’ve tried
● Note the impact and urgency
● Ask a specific question

8. Bad
Hey Alice,
Any idea why testKeyValues is failing in TestKVStore?
It really slows down our builds to rerun this.
Thanks!
Pankaj
Asking Questions // Show your Work

9. Asking Questions // Show your Work
Good
Hey Alice,
I’m having trouble figuring out why testKeyValues is failing in TestKVStore (in the DistKV repo). Shaun pointed me
your way. I’m hoping you can help.
The test fails for me about every third execution; it seems random. I tried running it in isolation, and it’s still failing, so I
don’t think it’s an interaction between tests. Shaun ran the test in a loop on his machine but was unable to reproduce
it. I don’t see anything obvious in the source code to explain the failure. It seems like some kind of race condition. Any
thoughts?
There is no terrible urgency around this as I’m told this is unlikely to be affecting production. Still, the flapping test
costs us 20–30 minutes every time this happens, so I’d love to figure out how to fix it. I’ve attached logs that show
failures and all of my current environment settings, just in case.
Thanks!
Pankaj

10. Asking Questions // Multicast & Asynchronous
● Ask questions to groups (channels and mailing lists)
● Ask questions asynchronously (chat - not DMs! - and email)
● Batch synchronous questions

11. Going on-call
● What is on-call
● Be available
● Pay attention
● Track your work
● Handling an incident

12. Going on-call // What is On-call
● Handle support requests and operational issues
○ “First line of defense” - try to solve the problem yourself!
● Usually weekly or bi-weekly rotation
● Sometimes…
○ Primary/secondary on-call
○ 24/7
○ Tiered (support -> operations -> developers)
● “Shadow” on-call rotations

13. Going on-call // Be Available
● “Your best ability is availability.”
● Responsiveness is a virtue
○ “Let me look into this” is a valid response.
● Over-communicate
○ Don’t wait until you have a solution.
○ “Update: still looking into this” is a good practice.
○ “We’ve narrowed down the problem to 3 possibilities, expect another update in 1 hour”
● Know what’s expected
○ 24/7? “Follow the sun”? Near computer?

14. ● Email alert groups
● Operations chat channels
● Operations meetings
● Phone calls
● Text messages
● Metrics dashboards
● Monitoring tools
Going on-call // Pay Attention

15. ● Log what you do
● Everything should be in an issue tracker (or on-call log)
● Update issues as you work
● Always include timestamps
Going on-call // Track your work

16. 1. Triage
2. Coordinate
3. Mitigate (most important)
4. Resolve
5. Follow-up
Going on-call // Handling An Incident

17. Understanding Dependencies
● Dependencies
● Semantic Versioning
● Transitive dependencies
● Dependency hell
● Managing dependencies

18. Understanding Dependencies // Dependencies
dependencies {
compile 'org.apache.httpcomponents:httpclient:4.3.6'
compile 'org.slf4j:slf4j-api:1.7.2'
}
● Defined in setup.py, requirements.txt, package.json, Gemfile, go.mod, ...

19. Understanding Dependencies // Semantic versioning
● Most common versioning scheme
● 2.13.7 (major.minor.patch)
○ patch: backward-compatible bug fixes
○ minor: backward-compatible features
○ major: backward-incompatible changes
● 1.4.0-alpha.2 (prerelease)
● 4.3.3+1945 (build number)
● Allows for wildcarding (2.13.*) and ranges [1.1, 2.0)

20. Understanding Dependencies // Semantic versioning
● Most common versioning scheme
● 2.13.7 (major.minor.patch)
○ patch: backward-compatible bug fixes
○ minor: backward-compatible features
○ major: backward-incompatible changes
● 1.4.0-alpha.2 (prerelease)
● 4.3.3+1945 (build number)
{
>>> def auth(user, password=None):
... pass
...
>>> auth('criccomini')
>>> def auth(user, password):
... pass
...
>>> auth('criccomini')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: auth() takes exactly 2
arguments (1 given)

21. Understanding Dependencies // Transitive Dependencies
dependencies {
compile 'org.apache.httpcomponents:httpclient:4.3.6'
compile 'org.slf4j:slf4j-api:1.7.2'
}
compile - Compile classpath for source set 'main'.
+--- org.apache.httpcomponents:httpclient:4.3.6
| +--- org.apache.httpcomponents:httpcore:4.3.3
| +--- commons-logging:commons-logging:1.1.3
| --- commons-codec:commons-codec:1.6
--- org.slf4j:slf4j-api:1.7.2
● Dependencies of dependencies (... of dependencies)

22. Understanding Dependencies // Dependency Hell
compile - Compile classpath for source set 'main'.
+--- com.google.code.findbugs:annotations:3.0.1
| +--- net.jcip:jcip-annotations:1.0
| --- com.google.code.findbugs:jsr305:3.0.1
+--- org.apache.zookeeper:zookeeper:3.4.10
| +--- org.slf4j:slf4j-api:1.6.1 -> 1.7.21
| +--- org.slf4j:slf4j-log4j12:1.6.1
| +--- log4j:log4j:1.2.16
| +--- jline:jline:0.9.94
| --- io.netty:netty:3.10.5.Final
--- com.mycompany.util:util:1.4.2
--- org.slf4j:slf4j-api:1.7.21
● Conflicting library versions or incompatible changes

23. Understanding Dependencies // Managing Dependencies
● Isolate dependencies
● Be deliberate
● Pin versions (or at least ranges)
● Strive for builds to be reproducible

24. Talking about Promotions
● Know the promotion process
● Assessing where you’re at
● Tips

25. Talking about Promotions // Know the Promotion Process
● Career ladders
○ Google “Square engineering ladder”
● Ask manager
● When are promotions done? Annually? Semi-annually? At-will?
● Who evaluates?
● Do you need a mentor, sponsor, or promotion packet?

26. Talking about Promotions // Assessing Where you’re at
● Do a self assessment
● Solicit feedback
● Review with your manager
● Work out plan to fill gaps

27. Talking about Promotions // Tips
● Work on what’s valuable and visible
● Speak up (early)
● Promotions are not time-related
● You are responsible for keeping track of your accomplishments
● Finish projects
● Demonstrate your skill for 3-6 months

28. Q&A