25 software engineer goals examples, counted in work you control

Software engineer goals examples for performance reviews

Performance review goals are counts you can show at the end of the year, each one about your own work.

• Write one design doc a quarter and get comments from 2 people before you build.
• Review 5 pull requests from other people every week for 6 months.
• Take 3 features from first commit to production this year and write a short note on what each one changed.
• Keep a work log with one entry a week, with links to your pull requests and docs.
• Ask 3 teammates for written feedback 2 months before your review.

Code quality and reliability goals for software developers

Quality goals count tests, reviews and fixes. Google's public guide to code review says one business day is the longest a review request should wait for a reply.

• Reply to every code review request within one working day for a quarter.
• Add tests to 20 functions that have none by the end of the quarter.
• Keep 8 of every 10 pull requests you open under 200 changed lines for 3 months.
• Fix one flaky test a week for 10 weeks.
• Write up every incident you work on within 5 working days, with at least one follow-up task filed.

Software engineer career goals examples: promotion and scope

A promotion is decided by other people, so break it down into the proof you can build yourself: projects led, docs written, a service you own.

• Read your company's career ladder and write one example of your work under each line of the next level.
• Lead one project that needs 2 or more teams, from the first plan to launch.
• Take official ownership of one service and write its runbook by the end of the quarter.
• Ask your manager once a month, for 6 months, what is missing for the next level, and write the answer down.
• Write a one-page promotion case with 5 pieces of proof before review season.

Personal development goals for software engineers

Personal development goals are what you choose to learn. If you are still learning to program, coding goals start one step earlier.

• Pass one cloud or security certification exam this year.
• Read one engineering book a quarter and try one idea from each in your own code.
• Solve 30 small exercises in a new programming language in 6 weeks.
• Watch one conference talk a week for 12 weeks and write 3 lines of notes on each.
• Use the debugger, not print statements, to find your next 10 bugs.

Team and mentoring goals for software engineers

Team goals count the help you give, the part of the job that never shows up in a commit.

• Mentor one newer engineer for 6 months, with a 30 minute chat every 2 weeks.
• Welcome 2 new people to the team this year and help each one ship a change in their first 2 weeks.
• Pair program with someone on your team for one hour a week for 10 weeks.
• Interview 10 job candidates this year and send your written notes within 24 hours of each interview.
• Record a 10 minute walkthrough of one system you know well, for new people on the team.

What is a good software engineer goal?

A good software engineer goal counts work you control: design docs, reviews given, tests added, people helped. A review of 35 years of goal research found that specific, hard goals lead to higher performance than being told to do your best. "Write better code" has no finish line. "Add tests to 20 untested functions by 31 March" does.

Team numbers are a different thing. The DORA research program measures how a team ships software with five metrics, grown from its original four keys. They count how often a team deploys and how long a change takes to go from commit to production. They count how many deploys need a quick fix or a rollback, and how long it takes to recover from a failed one. The fifth counts deploys that were never planned, made because of a problem in production. DORA built them for one app or service and the team that ships it. It lists setting them as a goal as a pitfall, because it makes teams more likely to game the numbers. The point, it says, is to improve your own team over time, not to compete.

So keep the team's numbers as the direction and put your own counts under them. DORA's guide names two more specific measures a team can add: how long code reviews take and the quality of its tests. It also says small changes help speed and stability at the same time. The same rule works far from code, in goals for nurses and real estate agent goals: count the work, not a result other people decide.

How to track software engineer goals

Log each review, doc and test in the week it happens. A review of 138 studies found that people who monitored their progress reached their goals more often, and that writing it down beat keeping it in your head. Your log is also the first draft of your self-review.

Reviews given and tests added are amounts that add up toward a total: 120 reviews in 6 months is a number you fill. A day with one hour on a new language is a day count, and 60 of those days is a goal.

Much of an engineer's year never lands in a commit: the design talk, the hour of pairing, the new hire who shipped on day 5. A grid that fills with every doc, review and hour of help keeps that work in view.

Frequently asked questions

What are some software engineer goals examples?

Review 5 pull requests a week for 6 months. Write one design doc a quarter. Add tests to 20 untested functions by the end of the quarter. Mentor one newer engineer for 6 months. Pass one certification exam this year.

What are SMART goals for software engineers?

A SMART goal is specific, has a number and has a date. "Write better code" is not one. "Add tests to 20 untested functions by 31 March" is, and so is "Reply to every review request within one working day this quarter".

Should DORA metrics be my performance goals?

Use them as your team's direction, not as your own score. DORA built its five metrics for one app or service and the team that ships it. It calls setting them as a goal a pitfall, because it makes teams more likely to game the numbers. Set your own goals on reviews, tests and docs.