Thanks again for Dan for writing up notes.
- Naming is hard (how to)
- “2 hard problems in CSc: naming & cache invalidation”
- very important
- names that are wrong are like an itch you can’t scratch
- naming conventions
- language conventions
- help you things if names are good
- happy collisions
- project glossaries
- organizing iterations when team has multiple responsibilities
- operations
- support
- dev
- multiple projects
- individual may not have anough info to prioritize
- protocols to deal with unexpected incidents (prod)
- different colors on the task board
- fudge factor in estimating
- being able to deal with this is a sign of maturity
- Ageism
- larger companies tend to have a bigger spread
- some people devalue older coders who don’t know the lates/greatest
- maybe pair younger coders with older experienced ones
- “don’t type as much, but get stuff done”
- some older people can be set in their ways
- broader toolkit
- younger consultants, don’t say no for themselves
- “how important is that work?”
- sometimes it’s good to step back
- is capacity for work changing with age?
- Where innovation happens?
- tech, edu
- startups, small companies, garages
- education is socially very conservative
- lots of regulation around schools
- charter schools – not very different from a conventional school
- tweaking the classic formula
- technology in schools isn’t disruptive by itself
- khan academy
- still doing the same basic formula: tests, homework, course materials
- locus of control is far away from the classroom, has different goals
- Retrospectives
- what makes a retrospective good?
- post-mortem is different, after a large project ends
- “teachrospective”
- recognition, prime decision making
- why do things go wrong?
- ask the right questions
- retrospective is a steering activity
- followup on past issues
- not just a bitch session
- Dealing with a dominant team member
- might be very good
- might just be pushy
- needs to be a team solution
- peer pressure
- they may think that they are doing what is best for the team
- need to have that “a ha” moment when they realize that they are hurting the team
- PM with good facilitation skills can help
- behavior profiles, analagous to Meyers-Briggs
- strengths-finder
- Dealing with a weak team member
- not getting work done, passive
- what motivates them?
- they do have strengths, find them!
- how does the team approach it?
- give them a mentor
- career level may not be the same as their skill level
- autonomy, mastery, purpose
- let them pick first
- Group size
- past 12 or so you can’t make a decision
- 5-6 can get a lot done, larger needs more coordination
- how fungible are the tasks
- “moving a house” works well with big groups
- making a decision
- spread ownership
- optimum team sizes from the group?
- 5 ish for software
- larger teams work well if they know each other well and collaborate well
- Burnout
- it can grow
- can’t sustain work at a high level
- getting tired a few times a year can be good. More than that can wear you out.
- Not enough “no”
- beating your head against the wall
- get fresh ideas, read more
- “the progress principle” book
- “frustration is the opposite of progress”