Notes on best practices. This is a work in progress and suggested guide lines, not a rulebook to follow like slaves.
Testing
If it isn't tested, it doesn't work. Period. All new features require appropriate unit tests and integration tests as part of the development process. Passing tests should be checked in the same time as new code, and are fully in the scope of code reviews.
Code Reviews
Let's do code reviews for all code changes.
- When possible, let's try to keep them small -> more review requests, less files to review per request.
- Don't spend too much time on each review -> the main purpose of our code reviews is communication (not finding bugs).
- Assign each code review to one person in particular and expect a response from them. CC as many other people as you like (to keep folks in the loop) but those folks do not need to respond.
Regarding rigor, I don't expect the reviewer to scrutinize the code (the burden is on me to test it) but instead to:
- get the gist of what I'm trying to do or let me know if its confusing (because I haven't done a decent job if the code change is confusing)
- let me know whether the approach I've taken seems reasonable or if there is a better way to do it
- give me a clue if the way I am testing it is missing major important cases
- point out any dependencies of which I might be unaware (e.g., if I change the REST API in a particular way, who might that change impactand is that okay?)
Meetings
Driving considerations
- Cost of a meeting is #min * #num people… adds up fast
- But… more efficient than N*(N-1) individual meetings
- Goal: minimize meeting time, but give us set times when we know we can address full team
- 2nd Goal: Give us check-in periods smaller than a sprint to help us plan realistically
Meeting Schedule
- Stand-up status meetings
- M, W 11:45 --In hallway / my office if phone needed
- Three questions:
- What have you done since last meeting?
- What are you going to do before next meeting?
- What are you stuck / blocked on?
- Identify issues and mechanism to solve them, DO NOT solve issues (unless can be done in ~3 min).
- I will time the meeting… am serious about the 15 min.
- Friday demo meeting
- 4:30, 30 mins
- Same general format, but a bit more time to actually demo progress
- Will time meeting, serious about sending you home for the weekend by 5
- Design / Code review meetings
- Engineers continue to call as needed
- Try to stack up (M,W?) to leave some long blocks of coding time