- This person works without any interest in why the work is necessary or how it affects the user and system. If changes are requested they don’t have an informed opinion of whether it’s desirable. They’re not sure of how different entities on the network piece together.
- This person understands the central motivation behind a task, but isn’t aware of enough context to propose changes. They’re aware of the high level goal that this work ties into, but isn’t confident in how this feature advances those goals.
- This person is confident in the motivation behind a task and how it ties into higher level goals. They ask questions to tease out hidden assumptions and clarify parts of task that are hidden or not examined.
- This person is able to explain the motivation behind a task and how it ties into a high level goal. They see one step ahead and ask about how it could affect other parts of the product and offer potential solutions when problems exist. They work closely with design and product to offer an engineering background that helps inform product decisions.
- This person is able to clearly explain the motivation behind a task and get everyone excited about improving the overall experience. They make the team more informed and help spread knowledge about how tasks are tied to improving product and reaching goals. They bubble up issues they see related to high level goals that can be taken by product and design and worked on. They see BuildingConnected and their team’s trajectory and excite those around them to achieve it.
- This person tends to write code that is hard to understand at first glance because they take clever approaches instead of understandable/readable approaches. This person is reluctant to improve their code’s clarity when others are confused - putting cleverness over other developer’s understanding.
- This person sometimes writes code that is difficult to follow. Though they often sway toward cleverness, they are empathetic when others have a hard time understanding and are willing to change code to improve readability.
- This person has readability/clarity as a priority when writing code. Code reviewers are often able to figure out what their code is doing at a quick glance.
- This person writes code that reads like a book. The code is easy to follow, is easy on the eyes, and even developers with very little experience can understand it at a quick glance.
- This person writes code that could be used to teach how to write clean/understandable/readable code. As they write, they regularly ask “is this the clearest way to present this logic such that anyone picking this up could understand what it does?”.
- Writes code that is sometimes production ready, but tends to require many review cycles before shipping. Is building proficiency with breaking down work into independently deployable pull requests, but often times ends up with one large change to deploy.
- Writes code that usually ships with a few review cycles and sometimes thinks through test coverage before requesting a review. Understands how to identify when too many changes are bundled into the same pull request. With some assistance, can go through the process of pulling work out into smaller, independent pull requests.
- Most review feedback is at a high level, and generally requests reviews with production ready code and ample test coverage. Able to break apart work as they go and tends not to need a reminder to ship smaller changes more frequently rather than larger changes less frequently.
- Has earned the trust of their peers to produce high quality code and ship changes safely without much input. Can break down work effectively and accurately before beginning to implement. Doesn’t shy away from providing guidance to others on how they can break their work down into smaller, deployable segments of work.
- Incredibly proficient at planning large features and orchestrating an implementation phase that ships features safely behind feature flags and in a backward compatible way. Is sought after by others to provide guidance on how to best to approach implementing and deploying their own work.
- Consistently expresses frustration when given a difficult (but important) task. Blindly follows specs and fails to escalate usability issues to design/product. Their PRs are characterized by a failure to account for product edge cases and they rarely catch such issues when reviewing others PRs.
- Occasionally expresses frustration when given a difficult (but important) task. Sometimes catches usability issues and rare product edge cases when evaluating/implementing a spec or reviewing others’ PRs. Will sometimes provide suggestions for UX fixes, but the quality of their suggestions is mixed.
- When confronted with a difficult problem will default to thinking carefully about how to solve it, instead of immediately naysaying. Often catches usability issues/edge cases in specs/PRs and sometimes provides sensible suggestions for fixing such issues.
- Has an uncanny ability to find creative solutions to hard problems. Advocates on behalf of a good user experience throughout the development process. Rarely does a usability issue/edge case slip past them in specs/PRs, and when they find one they usually provide respectful, well-thought-out suggestions for fixing the issue.
- In addition to being highly skilled at finding creative solutions to hard problems, advocating on behalf of users, and catching usability issues/edge cases, they also work to install good usability habits in the wider team, through carefully considered code review, input at team meetings, and other educational opportunities.
- This person does not own up to their mistakes and often scolds others when they fail.
- This person will acknowledge their failures, but only after prodding. They often shift the blame elsewhere and are quick to point out excuses. They eventually remedy the situation, but need to be told to do so.
- This person has no problem acknowledging their failure. They make a point of identifying the underlying issue and are quick to take remedial action.
- This person openly acknowledges their errors and embraces failure as a collective opportunity to learn. After quickly identifying and remedying the situation, they partake in blameless postmortem discussions with their peers.
- This person promotes an environment that others feel safe to fail in. They openly own their own failures, and go the extra mile to put thorough tests, processes, and documentation in place to help prevent others from running into the same error in the future.