Friday, December 5, 2008

OSDC liveblogging: Your code sucks and I hate you

Your code sucks and I hate you

First time patch submitted to OS project:
- nerve-wracking experience, judgement
- having people look at your code, give feedback etc is very powerful and important, best tool we have to get better as programmers

What's a review?
- Anyone even just talking about code
- A few types
- Involuntary review
- Random inspection
- Post-merge
- Pre-trunk (really good way of working, how bzr works)
- Pre-merge is the new hotness
- Enforces conformity (style consistent, ensures quality, enhance clarity)
- Moves from 1 person who understands code to 2 people

A few things in code review than can cause social problems
- Being told your entire approach is wrong
- Better to have a conversation before coding starts
- While you're there, totally do something else also
* need to be allowed to fix small incremental issues
* unclear outcomes (ie "this is bad", not what about it is bad)
- Name-calling is bad, doesn't help, talk about code not people
- Confusing personal preference with objective worth
- Filibustering -- what happens when you are outnumbered, but can win an argument by talking lots
- Lag is bad, reviews need to be fast, lag builds up
- Need to know who are the reviewers

Good things (how to do good reviews)
- Specific feedback
- Be thankful for code submits
- Ask questions where you don't understand stuff
- Before you start coding, talk to someone about it. Anyone.
- Decide to who gets the final say to head off future conflicts

Questions:
- Worst have experienced professionally is "that's a stupid idea"
- Language barriers can be an issue
- What happens if there are not enough developers for review?
- Generally in favour of doing code reviews in public or opt-out forum
- Be specific regarding thanking people also i.e. "I'm looking forward to using this feature"