My name is Phil (@pliao39) and I’m a software engineer.
I spent about 5 years working in software in SF and picked up a lot of lessons along the way. I’ve mentored my fair share of interns and junior engineers - and looking back, I wish I could’ve mentored myself as well.
My goal for this newsletter is twofold:
Accelerate the career of junior engineers: I’ve seen people get placed on great teams early in their careers and watched their careers take off. I’ve seen others get stuck in a “lord of the flies” situation, where the blind lead the blind. Not pretty. I believe juniors should have access to good mentorship regardless of what team they’re on.
Share the burden of mentorship for senior engineers: It’s exhausting being a mentor. To properly mentor a junior, you need to provide instruction, give constructive feedback, offer (some) emotional support, and possess a deep reservoir of patience (juniors are often smart, but overconfident and under-skilled).
There are a lot of topics I want to write about. Here’s a list of potential ones:
What is it like to be let go in a layoff? How do you manage the emotions? How do you get another job?
Should I be working on side projects while I work a day job?
What makes a good side project? Revenue? Users? Learning?
What languages should I learn?
Rust sounds cool. Go sounds popular. Dart + Flutter are growing. How should I choose?
How to tell if my manager is good or bad (for me)
Will my career grow or stagnate under my manager and how can I tell early?
What does a good 1-1 look like?
How important are peer relationships (people who are within 3-6 months of experience as you)?
How can I position myself in my company to take advantage of growth opportunities
Not all projects are created equal. 1 year of experience on a good project != 1 year of experience on a bad one
How do I navigate technical debt
Corollary: is the technical debt at your company basically a ponzi scheme or is it some strategically deployed AAA debt?
Beware of egos
Is it useful to learn how to clean up technical debt?
Which books should I read?
Should I be leetcoding even if I'm happy at my job?
How can I effectively use code review to grow?
There's getting a "quick stamp" - and then there's quality control. But you need to first determine who knows quality - and that can be hard to judge as a junior engineer.
Shit, I have to do something in X, but I don't understand it at all. Is there a quick guide? (Some examples of X)
IAM, SAML, and SSO
Databases, Queues, and Caches
Replication lag bugs
Client-Server, APIs, and IDLs (including GraphQL)
Metrics and Logging
ElasticSearch and Lucene
Serialization and Networking
Command Line basics
Cookies and Sessions (possibly AdTech)
Email Protocols (IMAP, POP3, SMTP)
Subscribe and get a short story in your inbox every week!