Software Engineering

Generally accepted career ladder levels. Varies by organization.

• junior software engineer.
• mid-level software engineer.
• senior software engineer. can lead projects independently
• staff software engineer. influences the direction of their whole team
• senior staff software engineer. influences direction across teams
• principle software engineer. influences and drives direction company wide
• fellow/distinguished software engineer. influences the industry. maybe a few per huge company

Numbers that are useful for software engineering self-reviews. Numbers can help put your achievements in context, and make them comparable to others, during e.g. performance calibration. All numbers are for achievements within the period under discussion.

• Money
  • Revenue generated
  • Incremental revenue generated
  • Costs saved
• Business results
  • Business results generated (as KPls)
  • Results where your work directly/indirectly overachieved results set
• Reliability
  • SLAs increased from X to Y
  • Number of highest-level outages
  • TTR, TTM average times.
  • TTR, TTM reduced
  • Number of outages avoided by doing work ahead of time
• Engineering productivity
  • Person hours/days/weeks/months saved by a certain project
  • Reducing time to do (a common enough developer task) by X%
• Code & architecture
  • Number of PRs done
  • Number of code reviews
  • Listing out planning documents
  • Number of planning documents you had input on (and listing these)
  • Examples where you helped others ship something in production
• People
  • Number of people onboarded
  • Number of people mentored
  • The results of mentoring (e.g. people promoted, growing professionally etc)
• Recruitment
  • Number of interviews done
  • Number of hired made on loops you were
• Other
  • Number of internal events organized (eg knowledge sharing in your team)
  • Number of external events organized or participated in (events where you helped the business achieve outcomes)

By Robert Martin

1. I will not produce harmful code.
2. The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
3. I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
4. I will make frequent, small, releases so that I do not impede the progress of others.
5. I will fearlessly and relentlessly improve our work at every opportunity. I will never allow it to degrade.
6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
7. I will continuously ensure that others can cover for me, and that I can cover for them.
8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
9. I will never stop learning and improving my craft.

• Bikeshedding: Discussing details too much, missing the main objectives.
• Rice Spreadsheet: Ranking items by evaluating the formula: reach * impact * confidence / effort.
• Yak shaving: Being repetitively sidetracked, such that the current task has little to do with goal.