- Can you articulate what problem you are trying to solve and the relevance of it needing to be solved ( how does this roll up to our OKRs and overarching goals for this sprint ? )
- Can you articulate your proposed solution before coding it?
- What will the be result of delivering this card?
- Distill acceptance criteria into task list. ( The most important question that you should be able to answer when you've created this list, Is when they are all checked off, will that mean that his card has been delivered to spec in FULL.
- Does this ticket require an inclusive approach to my design (Should I include team into implementation process? If so, provide a list of options, never ask how, always present options).
- Revisit check list in ticket and ensure that all items are complete.
- If applicable run the code and use it in the real world. If not applicable run a mental simulation and ensure that everything checks out.
- If any unexpected cases are encountered, verify whether or not it was something that you missed or the card missed. If the former, fix and go back to step above. If latter, bring up to the team, and verify whether not edge case should be addressed in card or if a new card should be created. Think about this one and offer it up as a suggestion rather than a question.
- Does your code require any documentation?
- Did you rebase?
- Did you add test coverage
- Did you add negative test cases
- Re-review for syntax
- Re-review for readability
- Re-review for grammar and spelling
- Re-review for performance
- Test coverage at 100% for new code
- Existing and new tests all pass
- Is it Dry
- YAGNI cases? (PS: Fowler said "Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify".)
- ARCHITECTURE & BEST PRACTICES
- If applicable did I employ the correct design pattern?
- Proper error handling & logging?
- Add comments where you think clarity might be needed
- Are all forks of logic addressed in tests
- Fill out github template in full detail
- TESTING
- If applicable describe how to test pr. Prove any relevant information.
- Test integration points ( ex consumers of api )
- Testing a production only bug ( Do you know how to reproduce that environment locally and for pr instances?
- Lastly, think about any cross cutting dependencies, any implicit changes to the way this application will function or interact with other systems?
- Write summary of solution. Explain why and how the solution solves the problem and what assumptions were made if any
- Update state of ticket and add relevant reviewer to ticket.
- Notify team of any stories that might of become unblocked?
Note Given the thoroughness and granularity, it's obvious that I'm optimizing for accuracy and integrity and not speed. It shouldn't be about how quickly I can bang out tickets, but about how solid and reliable my work is.
- Review ticket and ensure that I fully understand the work being presented, and if not available, write my own checklist.
- Review the architecture (In the interest of time this should probably be first. Order of subsequent items is arguably debatable).
- Re-review for syntax
- Re-review for performance
- Re-review for readability
- Re-review for grammar and spelling
- Test coverage at 100% for new code
- Is it Dry
- YAGNI cases? (PS: Fowler said "Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify".)
- Run code and use it as the end user would. Does it work and meet the spec of the card? Did you catch any edge cases?
- Leave positive comments when something was done well, or you learned something new.
- Avoid selective ownership of code ( using words like mine, not mine yours, etc )
- Decide on whether or not your changes require a change or is a nit.
Note: When reviewing pull requests it shouldn't be about speed and frequency, but PRIMARILY about comprehension, and SECOND to that, reviewing the work for any imperfections. There will be instances where work will be reviewed and merged in before you give any input. In those cases, investigate whether or not there is any known blocking comments and advise owner to hold off on merging.
- Review deadlines
- Reflect on what's been done, what's in flights, what's coming up and ask are we on track
- Prep 30-60 minutes before the meeting
- Make note about anything that you think you'll need clarification on
- Make note about any risks, or cross cutting dependencies.
- Review OKRs and deadlines and review what stories should be in order from highest to least priority.
- Are there any stories that can be broken up?
- Identify product led meetings ( iteration planning meeting for example ), and set blcoks on calendars a day before to review the next batch of work that may be coming up and review tickets.
- Configure all notifications settings across all productivity applications
- Set up DND schedules
- Set up desktop notifications ( what should be an alert and what should be a banner )
- Establish relationships with stakeholders and keep front of mind what is it that they want, daily, weekly, monthly, quartyly
- Possibly look at productivty metrics as an individual contributor ( jira control chart for example )
- Identify the teams, products, services that affect your team & product and insert yourself into communication channels and check up daily
- Create daily routines
- Create tab folder for all relevant monitoring
- Identify mission critial components and plan.
- Confirm that note taking platform is approved and if not is there an org specific one that is available (Security implications due to storing company sensitive information)
- Store important but used infrequently commands as shortcuts in bash file
- Obtain architecture diagrams or relevant documents that give a high level overview of the application that you will be working on and review, weekly and monthly until it has been fully internalized.
make sure to notate everything
- Maintain a log of parts of ecosystem and/or company products that you can familarize yourself with further when you have downtime during workiing hours.
- Maintain a running document of team processes, general gotchas, how to's, etc
- Create personal calendar that captures deploys, product deadlines, and information that might affect process (Like QA team being OOO and having to rely on eng and product).
- Project offramp:
- Get a list of routes that you developed and track performance, response times over time.
- Microsoft REST API Guidelines
- JSON:API
- Node Best Practices
- System Design
- Golang Study Guide
- Terraform @ Google
Search & Replace
- https://www.youtube.com/watch?v=q7gr6s8skt0
- https://github.com/neoclide/coc.nvim
:Ag --hidden [pattern]--hiddenflag will search dotfiles- vim bootstrap
Surround
scaffold
- https://github.com/rhysd/vim-go-impl interfaces (included in vim-go)
https://github.com/git-tips/tips https://github.com/wfxr/forgit