Learning Plans and Skill Assessment
Software changes constantly, and every developer faces the same question: what should I learn next, and how do I know it worked? Without a plan, learning drifts toward whatever is trending, half-finished courses accumulate, and progress is hard to see — for you and for the people deciding on promotions or hiring.
An effective learning plan is small and concrete. It starts from an honest assessment of where you are against what your role or next role requires, picks one to three outcome-based goals, practices them deliberately on real work, and ends with evidence: something built, shipped, reviewed, explained, or measured. Plans like this are easy to discuss with a manager or mentor and easy to adjust as priorities change.
TL;DR
- Assess skills against role and level expectations, using feedback, self-assessment, and a skills matrix.
- Choose one to three goals described as outcomes ("design and ship a service with SLOs"), not topics ("learn Kubernetes").
- Learn by deliberate practice on real problems, supported by courses, documentation, and reading good code.
- Use spaced repetition, explaining to others, and learning in public to make knowledge stick.
- Budget regular time, and use AI assistants to accelerate — while still understanding what they produce.
- Measure progress with artifacts and feedback, and review the plan every month or quarter.
Quick Example
A skills matrix for a backend engineer aiming for senior level (1 = aware, 2 = can do with help, 3 = independent, 4 = can teach and lead):
A 90-day plan built from the two biggest gaps:
Core Concepts
Assessing Skills
Self-assessments are biased in both directions, so combine them with external evidence.
Outcome-Based Goals
Topic goals ("learn Rust", "understand Kubernetes") have no finish line. Outcome goals name something you will be able to do and show: "build and deploy a service to our Kubernetes cluster with health checks and autoscaling," "contribute a fix to an open source Rust library." Limit yourself to a few goals at a time; spreading attention across many topics produces shallow progress everywhere.
Deliberate Practice and Real Projects
Skills grow fastest through deliberate practice: working slightly beyond current ability, on specific sub-skills, with fast feedback. For developers, that usually means real work — volunteering for the task that stretches you, pairing with someone stronger, reviewing others' code carefully, reproducing a production issue — supported by structured input:
Retention
Spaced repetition (flashcards for commands, concepts, and APIs you use rarely), explaining concepts to others, writing short notes or blog posts, and learning in public (sharing what you learn) all improve retention and create visible evidence of growth.
AI Assistants
AI coding assistants accelerate learning when used to explain unfamiliar code, generate examples, and answer questions — and slow it down when they replace understanding. Ask them to explain their output, write the important parts yourself, and verify against documentation. See AI Coding Assistants.
Measuring Progress
- Artifacts: merged pull requests, design documents, runbooks, talks, open source contributions.
- Feedback: review comments and peer feedback on the targeted skill.
- Performance on real tasks: time to complete, fewer review iterations, incidents handled independently.
- Reassessment: update the skills matrix at the end of each plan period.
Review plans with a manager or mentor regularly; they can help find projects that provide practice and remove goals that no longer matter. See Mentorship, Sponsorship, and Feedback. New team members can use the same approach during onboarding; see Onboarding Engineers.
Best Practices
Fewer Goals, Finished
Pick one to three outcome goals and complete them before adding more.
Learn on Real Work
Align learning goals with projects so practice and delivery reinforce each other.
Protect Time
Schedule regular learning time and agree on it with your manager.
Collect Evidence as You Go
Keep a record of artifacts and feedback that show what changed.
Common Mistakes
Course Collecting
Learning Without Feedback
Letting AI Do the Learning
FAQ
How do I figure out what to learn next as a developer?
Compare your skills with the expectations for your current and next role, gather feedback from people who see your work, and choose the gaps that matter most for your goals and your team.
What is a skills matrix?
A table of skills relevant to a role with current and target proficiency levels, used to identify gaps and track growth over time.
How much time should I spend on learning?
A sustainable, regular amount — often a few hours per week — plus learning built into project work. Consistency matters more than intensity.
How do I show that I have improved?
With evidence: shipped work, design documents, reviews, incidents handled, contributions, and feedback that reference the specific skill.
Do certifications help?
They can provide structure and signal knowledge in some fields, especially cloud platforms, but demonstrated work usually carries more weight with engineering teams.
Related Topics
- Developer Career — Growing as a software developer
- Mentorship, Sponsorship, and Feedback — Support for learning goals
- Engineering Levels and Career Paths — Expectations to measure against
- Technical Interviews — Skills employers test
- Onboarding Engineers — Structured learning for new team members
- AI Coding Assistants — Learning with AI tools