Skip to content

A few things about me and about working with me

Notifications You must be signed in to change notification settings

spmaniato/about

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

13 Commits
 
 
 
 

Repository files navigation

About Spyros

Table of Contents

What I do for a living

I'm currently a Senior Software Engineer at Cruise.

For more information, please check out my résumé or LinkedIn profile.

Communication & Collaboration

The tl;dr is that I prefer asynchronous communication (e.g. Slack) over tapping me on the shoulder or calling my name from across the room. The same goes for collaboration. I would rather discuss work matters in the comments section of a Jira ticket, Google doc, or GitHub pull request than in person. Team chat would work too in this case, but the conversation would ideally take place in a channel specific to the project, not via direct messages (DM).

When you do ping me, please don't ask to ask, just ask.

These are just preferences, not rigid rules. And there are exceptions. For example, brainstorming, design reviews, and retrospectives are better done in person. However, someone should be taking notes when meeting in person to discuss work matters, answer technical questions, make decisions, etc.

Pull Request & Code Review manifesto

As PR author I will

  • Keep my pull requests (PRs) small but self-contained
  • Write meaningful commit messages, PR titles, and PR descriptions
  • Include ticket number in PR title and link to the ticket in PR description
  • Include links to any additional documentation in the PR description (e.g. design doc)
  • Ensure that diff / patch coverage is close to 100% and that overall project coverage doesn’t decrease
  • Use a multipart (or equivalent) GitHub label to indicate a PR is one of many parts
  • Limit the rate at which I open new PRs to match the team’s ability to review them
  • Ensure that CI (both build and automated tests) is green before requesting reviews
  • Request reviews and post links to PRs on team chat when (and only when) they are ready for review

As PR reviewer I will

  • Make an effort to review as soon as I get the chance (assuming the PR is small)
  • Approve the PR, as long as the state of the code base is better than before
  • Prefer opening a new ticket or requiring a follow-up PR over rejecting the PR
  • Favor suggestions over rejections, particularly when multipart PR indicated via label
  • Review the PRs of others before opening a new PR that would exceed our WIP / PR limit

References

About

A few things about me and about working with me

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published