July 3rd, 2013

Thanks again for Dan for writing up notes.

  1. 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
  2. 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
  3. 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?
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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”