Guidebook Engineering Values

October 12, 2015 - management

Below are the characteristics the Engineering team at Guidebook value. Competency and growth around these characteristics allow the team to move swiftly, build trust and guide success.

This (living) document was shaped by the team to articulate the ideals that we expect from ourselves, our teammates and potential candidates looking to join the team.

They’re shared publicly here to provide a framework for others to use as a jumping off point for setting their own direction with their own teams.

Communication

  • Writes clear and concise commit messages and pull requests. Communicates intelligently within the team and outwardly to cross functional employees.
  • Maintains a positive attitude through adversity.
  • Communicates blockers early and demonstrates the ability to provide alternatives to roadblocks.
  • Asks for feedback/accepts feedback.
  • Knows what channels of communication to use when appropriate.
  • Trusts co-workers ability to execute and doesn’t micromanage.

Ownership

(Thoroughness/Quality/Attention to Detail)

  • Works through problems until they are completed.
  • Unblocks themselves from issues that arise during the development process.
  • Searches for answers on their own prior to asking others for help.
  • Makes a conscious effort to reduce technical debt.
  • Adds features/logic that solve the immediate problem and does so with an eye towards future growth.
  • Takes the time to review their own pull requests before formally opening them to the rest of the team.
  • Opens pull requests with a minimal amount of bugs and need for iteration.
  • Makes a conscious effort to minimize the scope of proposed changes (both in commits and PRs).
  • Actively reviews other people’s PRs.
  • Cares about details and implement features that align with the spec before asking for review.

Knowledge/Growth

  • Demonstrates the ability to look up from their current task and understand how it fits in with the rest of the project; ie: can see the forest through the trees.
  • Makes intelligent, proactive architectural decisions around the product and the codebase.
  • Stays up to date with team discussion and architectural decisions made within the scope of the project.
  • Recognizes when the code one is writing no longer jives with the rest of the project and refactors it. – having a difficult time articulating: “A developer who builds round pegs when the rest of the team is building square holes.” … follows decided patterns/paradaigms when building functionality.
  • Emphasizing readability over purity of class design … building something that is easily grokable by the entire team as opposed to esoteric solutions.
  • Being restrospective about features/code/architecture decisions that one makes and thoughtfully sharing with the rest of the team. Demonstrates the ability to mentor and disperse knowledge — and is gracious about sharing information with the rest of the team. Blogging/BrownBags/etc.

Execution

  • Accurately scopes and timelines features; eventually demonstrates the ability to do this with larger and larger projects.
  • Communicates missed deadlines before they happen; and demonstrates the ability to offer alternatives (coupled with “communication section above”)
  • Consistently delivers stable features within the estimated timeframe.
  • Effectively balances speed of development with quality of code.