- managing projects - Alex Martelli
- www.aleax.it
- Three legs of the stool of development
- right intention
- right action
- right endeavor
- ==
- strategic leadership
- excelllent developers
- good highly technical management
- what makes a great strategic leader?
- lots of stuff...
- Boils down to:
- do their difficult job well
- let managers do *their* job
- what makes excellent developers?
- lots of stuff...
- Boils down to:
- can do their job well
- enable managers to do their job
- how do you get leaders and developers?
- what is highly technical management?
- start with manager M who is at least a technical peer of developers
- M develops mutual trust with devs. by deploying himself as a wildcard tech resource
- but M *doesn't* hog the "fun" tasks - take the grungy tasks
- But...
- what about brooks law?
- "adding progs to a late proj makes it later"
- but, that's mainly based on the extra time it takes to bring a new dev up to speed
- the highly tech. mgr is *already* up to speed on proj he oversees
- where do you find the time?
- *not* in working insane hours
- aim for 40 hrs a week
- settle for 45
- 50 is right out...
- note that this is *actual work hours*, not time spent at work reading slashdot
- "The wise general always keeps a reserve of troops"
- Always have "reserve" hours available
- *not* by telecommuting
- F2F communication is vital for SW development
- Time Management actually works!
- "Time Management for System Adminstrators" from O'Reilly
- Lots of short (20 minute) meeting, regularly scheduled
- never a prob if mtg ends early
- cancelable at the last minute in emergency
- punctuality saves time for everyone
- always be ready to snatch opportunities to do something useful (laptop, blackberry, pda, paper notebook)
- schedule 30% - 50% of your time every week for emergency work or low-priority fillers
- "A stitch in time saves nine"
- predict and prepare for emergencies
- don't let the shit get near the fan
- Make sure what you're doing is actually needed
- If upper mgmt imposes foolish BS, call them on it.
- Shouldn't a mgr always delegate?
- yes, but delegate *what*?
- delegation doesn't remove your responsibility
- need to stay up to speed on all projects anyway
- need to trust your people to do what's right, but fulfil your part by enabling them to do it.
- need to *earn* their trust, by providing good technical contributions
- Never steal credit (or be perceived as doing so)-- minimize your role when presenting the work.
- Trust is mutual
- you must earn and deserve your developer's trust every day
- They must earn and deserve yours
- but always start with trusting by default
- learn all you can about their specific, individual strengths and weaknesses
- play to their strengths, but...
- plan ways for them to outgrow their weaknesses
- making unreasonable demands on your people wil burn them out
- dissuade them from burning themselves out
- making only fully reasonable demands doesn't foster growth
- plannning and scheduling sw development
- read Joel Spolsky!
- A spreadsheet is the right level of technology (or a whiteboard)
- pick *very* fine-grained tasks
- the only way to overcome dev's natural optimism
- schedule vacations, holidays, sick days
- proactively avoid burnout
- plan in highest-business-value-first order
- If you don't know what to pick, do the hardest one first
- factor time estimates into your own units
- Appropriate methodologies
- Agile: it's not just a good idea, it's a cool buzzword!
- explore the whole space with your programmers
- strive to keep all proj. you supervise on the same methodology
- meta-adjust mercilessly
- key ideas: agile plannning, tdd, refactoring, 40hr week, pair prog, freq. releases
- high-level languages are better
- what to force toward uniformity, and what not
- YES
- coding style, naming, whitespace, idioms
- OS, test framework
- source control
- bug tracking
- Probably not
- CONTROL YOUR DEPENDENCIES!
- or they will control you.