What are You Looking For?
Trending Now
Search

📘 Learning

My personal roadmap from mid-level to Staff Engineer — built to master systems, design, and technical leadership.

⚠️ Living Document Disclaimer
This study plan is a living, breathing beast. I’m constantly refining it — sometimes through major updates, sometimes in quiet 3am tweaks. New resources get added, stages evolve, and priorities shift as I grow.

If something looks different the next time you check in, that’s intentional — growth is iterative.

For transparency, a full update log is maintained at the end of this document so you can track what’s changed over time.

🟢 Active Focus

✝️ Nave’s Topical Bible

  • Focus: Studying the Bible by topic to understand what Scripture says across books and verses
  • Approach: One topic per day, guided by the Holy Spirit
  • Purpose: To deepen scriptural understanding and anchor faith with clarity and context
  • Start Date: June 23, 2025
  • Last updated: June 22, 2025

🚧 Study Plan

🌱 Stage 0: Mindset, Growth, and Career Strategy

Becoming a Staff Engineer is 50% technical skill and 50% vision, leadership, and decision-making. This stage forms the foundation.

🧭 Must-Reads on Growth & Seniority

🔁 Career Navigation & Strategy

📖 books

  • [ ] The Pragmatic Programmer – link
  • [ ] Code Complete – Amazon
  • [ ] Release It! – Amazon
  • [ ] Scalability Rules – Amazon
  • [ ] A Philosophy of Software Design – Amazon
  • [ ] Software Engineering at Google (free) – SEAG

new mentorship & influence topics

  • [ ] Code Review Culture,
  • [ ] Constructive Feedback,
  • [ ] Async Communication,
  • [ ] 1:1 Coaching,
  • [ ] Setting Team Standards.

🖊️ writing (communication, blogging)

⠀Guides & classes about technical writing:

If you’re overthinking, write. If you’re underthinking, read. – @AlexAndBooks_

⠀Personal knowledge management (PKM)

🧮 Stage 1: Math, Programming Fluency & Algorithms

Build solid foundations in computation, logic, math, programming fluency, and algorithms.

elementary math

college math

calculus

Supplementary Material

linear algebra

Required Reading

Supplementary Material

discrete math

proofs and logic

Proofs, Set theory, propositional logic, induction, invariants, state-machines

number theory

Number theory is fundamental in reasoning about numbers as discrete mathematic structures with applications in cryptography and efficient numerical computation.
By the end of this sub-module you should be very confident proving and reasoning about concepts including: divisibility, bezouts identity, modular arithmetic, eulers totient theorem, fermats little theorem, integer factorization, diophantine equations, the fundemental theorem of arithmetic, chinese remainder theorem, RSA and the discrete logarithm problem.

Problem Sets

combinatorics

Combinatorics is a vital skill in reasoning about the size of finite sets.

Problem Sets

graph theory

supplementary material

probability and statistics

probability

statistics

key books:

[ ] Coding the Matrix – Strang et al.

[ ] Concrete Mathematics – Knuth et al.

[ ] The Book of Proof – Hammack

[ ] Elements of Statistical Learning – Hastie, Tibshirani, Friedman

🛠 Languages (Deep Proficiency in 2, Working Knowledge in 2+)

typescript (+ javascript, next js, shadcn/ui, tailwind css)

web development

Topics:

URLs:

  • [ ] The Great Confusion About URIs
    • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment>, where only <scheme> and <path> are mandatory. URL and URN are URIs.
    • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. E.g. mailto:billg@microsoft.com.
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string>. E.g. urn:isbn:9780062301239
  • [ ] Examples of Great URL Design
  • [ ] Four Cool URLs – Alex Pounds’ Blog

📚 Programming Theory

🧠 Algorithms & Data Structures

Resources

compilers & interpreters (advanced programming)

⚙️ Stage 2: Computer Systems, OS, and Architecture

Gain deep understanding of how software runs from transistors to OS to protocols.

computer architecture & databases

operating systems

networking

performance engineering

information theory

🌐 Stage 3: Databases & Data Engineering

Learn how data moves, scales, and persists. Know RDBMS internals and build ETL systems.

PostgresSQL Internals

  • [ ] The internals of Redis
  • [ ] RDBMS (PostgreSQL, MySQL): joins, indexes, query plans
  • [ ] NoSQL: MongoDB, Cassandra, Redis, DynamoDB
  • [ ] Consistency models: eventual, linearisable, quorum reads/writes
  • [ ] Search systems: full text (BM25), vector (ANN)
  • [ ] DDIA, Database Systems (Ramakrishnan), Transaction Processing Concepts
  • [ ] Berkeley paper on FNTDB, SQL style guides
  • [ ] RDBMS: Postgre/MySQL: joins, indexes, query plans
  • [ ] Internals: Postgres Internals, Redis, DynamoDB consistency
  • [ ] NoSQL survey + DynamoDB docs
  • [ ] CAP, PACELC, zero-downtime migrations

databases

⠀Scaling databases:

NoSQL

Postgres

⠀Supplementary

sql proficiency

data engineering & pipelines

🕸️ Stage 4: Distributed Systems & System Design

The cornerstone of Staff Engineering. Learn scale, fault-tolerance, consistency, and tradeoffs. Master building large-scale, fault-tolerant systems.

core concepts & resources

systems design

  • [ ] DonneMartin Primer, dancres pages, murat buffalo list
  • [ ] HighScalability blog, Martin Fowler’s patterns, Conways Law
  • [ ] Microservices: Sam Newman, Uber, Google engineering culture
  • [ ] ADR practice, designing for scale/disaster

Reading lists:

Blogs:

  • [ ] High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.

Books:

Articles:

Architecture patterns
BFF (backend for frontend)

Microservices/splitting a monolith

reliability (site reliability engineering – sre)

  • [ ] 📖 Site Reliability Engineering
    • Written by members of Google’s SRE team, with a comprehensive analysis of the entire software lifecycle – how to build, deploy, monitor, and maintain large scale systems.

Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST Reliability is the one feature every customer users. — An auth0 SRE.

Articles:

⠀Resources:

infrastructure resilience

scalability

papers & blogs

  • [ ] MapReduce
  • [ ] GFS
  • [ ] DynamoDB
  • [ ] Spanner
  • [ ] The Log – Jay Kreps
  • [ ] Martin Fowler on distributed patterns

☁️ Stage 5: Cloud, DevOps & Observability

Know how to deploy, monitor, debug, and scale systems in production. Ship, operate, and automate software at scale.

  • [ ] Production Ready Microservices — Susan Fowler
  • [ ] Google SRE Book

🔧 Cloud & Infrastructure

  • [ ] Terraform Up & Running – Yevgeniy Brikman
  • [ ] Learn Kubernetes the Hard Way
  • [ ] Open Guide to AWS, Google CRE guide, customer reliability foundations
  • [ ] AWS Well-Architected Framework
  • [ ] Multi-region + multi-account AWS Architecture
  • [ ] CI/CD: GitHub Actions, CircleCI, GitLab CI
  • [ ] VPC, IAM Secrets Management
  • [ ] https://github.com/open-guides/og-aws
  • [ ] https://martinfowler.com/articles/continuousIntegration.html
  • [ ] Terraform: Up & Running
  • [ ] Kubernetes the Hard Way
  • [ ] OpenGuide to AWS
  • [ ] Google Cloud Architecture Framework
  • [ ] AWS Well-Architected Framework

ci/cd & devops

  • [ ] GitHub Actions, Terraform, Docker, Kubernetes, CircleCI, GitLab CI
  • [ ] AWS/GCP: IAM, S3, Lambda, EC2, RDS, CloudWatch
  • [ ] CI/CD, Infrastructure as Code, Monitoring
  • [ ] Continuous Integration (Martin Fowler)
  • [ ] Docker internals, secrets management, VPC, IAM

🔍 Observability

  • [ ] USE Method – Brendan Gregg
  • [ ] RED Metrics – Weaveworks
  • [ ] Structured Logging + Sentry + Grafana Docs]
  • [ ] Google SRE Book: monitoring, SLOs, error budgets
  • [ ] Logging: Do not Log, Lies My Parents Told Me, OWASP logging cheat sheet, structured logging
  • [ ] Monitoring: USE, RED methods, SQL anomaly detection, golden signals, health checks

Logging

  • [ ] Do not log dwells on some logging antipatterns.
    • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
    • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
    • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
  • [ ] Lies My Parents Told Me (About Logs)
    • Logs are cheap
    • I can run it better myself
    • Leveled logging is a great way to separate information
    • Logs are basically the same as events
    • A standard logging format is good enough
  • [ ] Logging – OWASP Cheat Sheet Series
  • [ ] The Audit Log Wall of Shame: list of vendors that don’t prioritize high-quality, widely-available audit logs for security and operations teams.
  • [ ] Guide on Structured Logs

Error/exception handling

Metrics

  • [ ] Meaningful availability
    • A good availability metric should be meaningful, proportional, and actionable. By “meaningful” we mean that it should capture what users experience. By “proportional” we mean that a change in the metric should be proportional to the change in user-perceived availability. By “actionable” we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
  • [ ] 📃 Meaningful Availability paper.
    • This paper presents and evaluates a novel availability metric: windowed user-uptime

Monitoring

incident analysis & debugging

  • [ ] Debugging zine and rubber duck topics
  • [ ] 5 Whys vs narrative technique, bounded rationality, codinghorror
  • [ ] Netflix Linux Perf in 60s, root cause guides
  • [ ] JVNS tcpdump, falsehoods, minimal reproducible example
  • [ ] Good questions, downtime, SLO incident write-ups

incident analysis

Alerting
  • [ ] My Philosophy On Alerting
    • Pages should be urgent, important, actionable, and real.
    • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
    • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
    • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
    • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don’t go so far you can’t sufficiently distinguish what’s going on.
    • If you want a quiet oncall rotation, it’s imperative to have a system for dealing with things that need timely response, but are not imminently critical.
    • [ ] This classical article has now become a chapter in Google’s SRE book.
  • [ ] 🏙 The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.
Postmortem

“Let’s plan for a future where we’re all as stupid as we are today.”
– Dan Milstein

Example outline for a postmortem:

  • Executive Summary
    • Impact
    • Root cause
  • Impact
    • Number of impacted users
    • Lost revenue
    • Duration
    • Team impact
  • Timeline
    • Detection
    • Resolution
  • Root cause analysis
    • E.g. with 5 whys method
  • Lessons learned
    • Things that went well
    • Things that went poorly
  • Action items (include direct links to task tracking tool)
    • Tasks to improve prevention (including training)
    • Tasks to improve detection (including monitoring and alerting)
    • Tasks to improve mitigation (including emergency response)

debugging

testing

⠀Why test:

  • [ ] Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
    • Even if you don’t, someone will test your software
    • The majority of testing should be performed by development teams
    • Manual testing should not be the majority of your testing because manual testing is O(n)
    • Tests are the critical component that ensure you can always ship your master branch
    • Tests lock in behaviour
    • Tests give you confidence to change someone else’s code

⠀How to test:

⠀Test pyramid:

⠀End-to-end tests:

🧠 Stage 6: AI, ML, and Deep Learning

Build intelligence-powered systems and become ML/AI fluent.

[ ] https://www.coursera.org/specializations/aml

  • [ ] Coursera AML Specialization
  • [ ] ML Foundations, Regression, Classification, Clustering Specializations
  • [ ] Deep Learning.ai Specialization (NN, CNN, Sequence, Structuring Projects)
  • [ ] CS231n (Stanford), Fast.ai, RLL Berkeley, neuralnetworksanddeeplearning.com
  • [ ] Books: Deep Learning by Goodfellow, Grokking DL, Matrix Calculus explained
  • [ ] Applied AI Tools: Vector DBs (FAISS, Milvus, Pinecone, QDrant), semantic/hybrid search, RAG
  • [ ] Libraries: LangChain, LlamaIndex, Haystack, HuggingFace
  • [ ] Full Stack Deep Learning; MLOps; course on TensorFlow without PhD

artificial intelligence

machine learning

machine learning specialisation by university of washington on coursera

others

deep learning

Deep Learning by deeplearning.ai on Coursera

Goals:

data mining & recommenders

nlp & computer vision

nlp

image & computer vision

electives

Resources

applied ai systems

  • [ ] Vector DBs: FAISS, Milvus, Qdrant
  • [ ] Hybrid Search: BM25 + Vectors
  • [ ] RAG Pipelines (LangChain, LlamaIndex)
  • [ ] Full Stack Deep Learning
  • [ ] LLM Ops Playbooks (Haystack, LangChain)

Tools

🧭 Stage 7: Staff Engineer Influence, Docs, and Architecture

Learn to drive alignment, lead with documents, and scale your impact beyond code. Influence systems, architecture, and culture beyond code.

📚 Core Reading

leadership & management

  • [ ] Staff Engineer – Will Larson, Tanya Reilly
  • [ ] Staff Engineering Guides (StaffEng.com)
  • [ ] The Manager’s Path – Camille Fournier
  • [ ] The Art of Leadership – Michael Lopp
  • [ ] Will Larson’s “Staff Engineer: Leadership Beyond the Management Track”
  • [ ] Tanya Rilley’s “The Staff Engineer’s Path”
  • [ ] https://github.com/charlax/engineering-management

architecture & documentation

  • [ ] Building Microservices – Sam Newman
  • [ ] Google Eng Practices Writing
  • [ ] ADRs, RFCs, One-/Six-pager docs, design templates (Stripe, Google AIPs)

documentation

The palest ink is more reliable than the most powerful memory. — Chinese proverb

api design & development

General REST content:

⠀Example guidelines:

⠀More specific topics:

design (oo modelling, architecture, patterns, anti-patterns)

Here’s a list of good books:

Articles:

  • [ ] O’Reilly’s How to make mistakes in Python
  • [ ] Education of a Programmer: a developer’s thoughts after 35 years in the industry. There’s a particularly good section about design & complexity (see “the end to end argument”, “layering and componentization”).
  • [ ] Domain-driven design, Wikipedia.
  • [ ] On the Spectrum of Abstraction 🎞, Cheng Lou
  • [ ] The “Bug-O” Notation, Dan Abramov
  • [ ] Antipatterns
  • [ ] Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
  • [ ] Composition Instead Of Inheritance
  • [ ] Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (e.g. Google Apps Suite vs. Microsoft Office).
  • [ ] The Architecture of Open Source Applications
  • [ ] The Robustness Principle Reconsidered
    • Jon Postel: “Be conservative in what you do, be liberal in what you accept from others.” (RFC 793)
    • Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
  • [ ] Basics of the Unix Philosophy, Eric S Raymond
  • [ ] Eight Habits of Expert Software Designers: An Illustrated Guide
  • [ ] No Silver Bullet – Essence and Accident in Software Engineering, Frederick P. Brooks, Jr. (1986)
    • There are four properties of software systems which make building software hard: Complexity, Conformity, Changeability and Invisibility
    • There are ways to address this:
      • Exploiting the mass market to avoid constructing what can be bought. (“Buy vs. Build”)
      • Using rapid prototyping as part of a planned iteration in establishing software requirements.
      • Growing software organically, adding more and more function to systems as they are run, used, and tested
      • Identifying and developing the great conceptual designers of the rising generation.
      • (also included in The Mythical Man-Month)
  • [ ] Out of the Tar Pit, Ben Moseley, Peter Marks (2006) introduces the distinction between essential and accidental complexity
    • Complexity is the root cause of the vast majority of problems with software today. Unreliability, late delivery, lack of security — often even poor performance in large-scale systems can all be seen as deriving ultimately from unmanageable complexity.
    • Quoting Djikstra: “testing is hopelessly inadequate….(it) can be used very effectively to show the presence of bugs but never to show their absence.”
    • Functional programming goes a long way towards avoiding the problems of state-derived complexity, thanks to immutability and clear separation of state and logic.
  • [ ] A Note on Essential Complexity
    • The goal of the software engineer is to minimize accidental complexity and assist with essential complexity.
  • [ ] Software Design is Knowledge Building
    • Programming should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.
    • The building of the program is the same as the building of the theory of it by the team of programmers.
  • [ ] Cognitive load is what matters
    • A well-crafted monolith with truly isolated modules is often much more flexible than a bunch of microservices.
    • Three decades on, microkernel-based GNU Hurd is still in development, and monolithic Linux is everywhere
    • “Reduce cognitive load by limiting the number of choices.” (Rob Pike)
    • The same rule applies to all sorts of numeric statuses (in the database or wherever) – prefer self-describing strings.
    • With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (Hyrum’s Law)
    • DDD is about problem space, not about solution space.
    • Familiarity is not the same as simplicity
    • The more mental models there are to learn, the longer it takes for a new developer to deliver value.

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

Resources:

Design: database schema

  • [ ] A humble guide to database schema design, Mike Alche
    • Use at least third normal form
    • Create a last line of defense with constraints
    • Never store full addresses in a single field
    • Never store firstname and lastname in the same field
    • Establish conventions for table and field names.
  • [ ] YAGRI: You are gonna read it: store created_at, created_by etc.

Design: patterns

Design: simplicity

  • Simple Made Easy 🎞, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

coaching & culture

  • Mentoring strategies, code review frameworks
  • Inclusive teams, feedback, performance coaching, async culture

strategic vision

  • Technical debt frameworks, vision roadmapping
  • Staff roles: Tech Lead, Architect, Solver, Right-hand
  • Conference talks, strategy presentation skills (C4 Model)

career growth

About senior engineers:

Choosing your next/first opportunity

Getting to Staff Eng

design docs & influence

mentoring, communication, culture

strategy & vision

  • [ ] Technical debt management
  • [ ] Leading architectural change
  • [ ] Staff archetypes (Tech Lead, Architect, Solver, Right Hand)

technical debt management

  • [ ] TechnicalDebt, Martin Fowler.
  • [ ] Fixing Technical Debt with an Engineering Allocation Framework
    • You don’t need to stop shipping features to fix technical debt
    • Communicate the business value
  • [ ] Ur-Technical Debt
    • Today, any code that a developer dislikes is branded as technical debt.
    • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
    • Ur-technical debt is generally not detectable by static analysis.
  • [ ] 3 Kinds of Good Tech Debt

🔨 Stage 8: Mastery Projects & Public Work

Turn knowledge into tangible systems. Prove staff-level capability through impact. Apply knowledge gained to deeply engineered, demonstrable projects.

Personal Projects

read list

Random

📱 Mobile Development

  • Goal: Build and publish native iOS and Android apps with modern UI and production-quality architecture
  • Technologies:
    • Swift + SwiftUI (iOS)
    • Kotlin + Android SDK
  • Projects: Personal productivity app, Bible study app, or dev tools

🇪🇸 Spanish (with Lingoda)

  • Goal: Reach conversational and eventually fluent Spanish through structured, CEFR-aligned immersion
  • Platform: Lingoda (live classes + full curriculum)
  • Focus Areas:
    • Speaking confidently in everyday situations
    • Listening & comprehension at native speed
    • Grammar, pronunciation, and vocabulary expansion
  • Timeline: To begin once schedule allows more time

🇩🇪 German (with Lingoda)

  • Goal: Learn German up to B2/C1 level with focus on clear speaking, reading, and cultural understanding
  • Platform: Lingoda
  • Focus Areas:
    • Daily conversation and travel fluency
    • Reading German technical and cultural materials
    • Accent training, grammar, and listening
  • Timeline: Starts after completing Spanish Sprint

🙏 Acknowledgments & Thanks

This study plan stands on the shoulders of giants. Most — if not all — of the resources and structure within this roadmap were inspired by or directly sourced from the incredible work found in:

I’m immensely grateful to the creators of these resources for sharing their wisdom so freely. This study plan wouldn’t exist without their contributions.

📅 Update Log

DateUpdate
July 3, 2025Fully expand study plan to include staff engineer roadmap, ai + ml + deep learning and personal projects
June 22, 2025Page created. Rust learning active.