Continuous Learning & Growth
Technical knowledge goes out of date quickly. Staying effective is not about already knowing everything. It is about being good at learning, willing to be wrong, and generous in helping others grow. Keep building your skills over time, instead of treating them as fixed.
Continuous learning is part of the job, not a hobby. The tools, threats, regulations, and best practices around us change all the time. A skill set that has not changed in two years is a risk. The engineers who stay valuable keep asking questions, reading the manual, and updating what they thought they knew.
Growth is also a team activity. The fastest way to raise the whole team's ability is to share what you learn and to help others. Do this through code review, mentoring, and writing things down. A team that learns together gets stronger over time. A team that keeps knowledge stuck in people's heads stops improving.
Keep learning
- DoStay curious and up to date. Make time to learn the tools, patterns, threats, and regulations relevant to our work before you need them.
- DoRead the source, the docs, and the spec instead of guessing or copying without understanding. Learn why something works, not just that it works.
- DoTreat being wrong as useful information, not failure. Change your view when the evidence changes, and say so.
- DoLearn from incidents, reviews, and other people's code. Every bug and every PR is a chance to get better.
- ConsiderChoosing work that stretches you from time to time. The work that challenges you is where most growth happens.
- Do notPretend to understand something you do not. A quick question always costs less than a confident mistake.
Grow others
- DoShare what you learn. A short write-up, a short talk, or a good PR comment spreads one person's learning across the team.
- DoMentor generously and patiently. Helping someone improve is one of the most valuable things you can do.
- DoMake it safe to not know something. Answer questions without looking down on people, so they keep asking instead of guessing.
- ConsiderUsing code review to teach, not just to control quality. Explain the reason, so the lesson lasts beyond this one change.
- Do notKeep knowledge to yourself or make people feel small for asking. It only drives questions out of sight and mistakes into production.
Self-review checklist
- AskAm I keeping my skills up to date, or relying on what I knew two years ago?
- AskDid I really understand this, or did I just make it work?
- AskWhen I learned something useful, did I share it or keep it to myself?
- AskDo people feel safe asking me questions?