Team Management
Articles
- The Quiet Crisis unfolding in Software Development - by Bill Jordan
- Agree
- Judging performance
- Be wary of high performers who may just be focused on looking productive over developing good solutions
- Watch out for misleading metrics
- The team will self select their technical leaders
- Code reviews - need to have - should involve significant discussion
- Limit interruptions
- Encourage experimentation - ex: 20% time
- Let employees leave
- Never turn down small requests
- Avoid yearly and bi-yearly performance reviews
- Don't discount younger or older devs (diversity in general is good)
- Judging performance
- Less convinced
- Encourage code ownership - I agree in encouraging passion, but don't like the idea of silos of knowledge or preventing a dev from working in some area (especially if they are passionate about that area)
- Prefer private workspaces - I think it depends on personality and culture of team - not sure on the absolute merits of each option. Private somewhat discourages collaboration. I've seen pair programming be *very* effective, but it's hard to recreate the culture
- Agree
What would I put in an article on recommended team practices?
- efficiency
- quality (internal and external)
- code reviews
- shared ownership - without discouraging developer passion
- Mind the culture
- helping others / collaboration
- the right amount of concise internal documentation
- Pair Programming (if possible)
- Hiring practices are very important
- TDD
- Internal openness can be a pretty powerful thing. Getting access to the code/documentation/systems you are actually supposed to work on can be so difficult sometimes. In todays era of public open source on github with the ability for anyone to post a pull request, harnessing the same energy and power inside an organization should definitely be a positive thing
page revision: 4, last edited: 30 May 2016 07:21