30% feed back when 30% done.

Good article on dealing with feedback and how to give and receive it better.

Copied and pasted most interesting section. Source: http://blog.42floors.com/thirty-percent-feedback/

How to Build 30 Percent Feedback into the Culture of Your Startup

Lead by example

Duh.
Don’t worry about anything else below if you can’t there.

Ask for it explicitly

You have to be deliberate because you’re fighting against an innate fear most people have: fear of rejection.   Some of your best people are accustomed to being good at everything they do, so they may be the toughest to get on board.
You have to explicitly ask people to be on board with this concept.

Reward People with great feedback

Whenever someone comes to you for early feedback you have to reward it.  If, even just once, you reject someone’s draft because it’s not polished enough for you, you’ll teach everyone else in the organization to always be 100% done before approaching you.
Execs at big companies may want everything perfect before it gets to them, but that’s no way to run a startup.

Praise Speed

When someone takes way too long to get a first draft out because they’re being perfectionists and you praise them for their quality craftsmanship, it teaches everyone to do the same.  You should, instead, praise people that move incredibly fast.  We always strive for one week.  Even for the most complex projects, we try to see what can come out as a first draft within one week.  From that point on, they can get feedback and start iterating.

Demo Regularly

Set up the company for everyone to demo at your weekly meetings, regardless of what stage their project is in.  It’s more of a show us whatever you have.  PG would do this to us at YC, making us demo every week.  It was both daunting and humbling.  But once we got used to it, we actually got addicted to the immediate feedback.  That’s the culture you want.


One final note.  Every once in awhile you’ll still have to give someone  tough feedback when they thought they were 90% or 100% done.  It always feel shitty to have throw away work.  But hopefully with this system, it will happen much less.  And the result will not only be better products, but happier people.

Software methodologies..

"Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision."

http://typicalprogrammer.com/why-dont-software-development-methodologies-work/

Code Reviews and Bad Habbits

Quoting particular sections:

There are two fundamental problems with single-patch review systems:

1. They encourage lumping at-best-weakly-related changes together. Frequently, when I start implementing a new feature, there are at least three steps: first, refactor the existing code to make it clean to add the new feature; next, add the new feature; and finally, add unit tests. The bigger the feature, the more likely each of these steps is likely to itself consist of several logical steps. If you can store several distinct commits in a single review, then you can simply keep these commits grouped together. But if I’m in a single-patch system, I’m going to be strongly encouraged to do everything in one massive commit. That’s especially frustrating because refactoring existing code, and adding new code, get lumped together, demanding much more mental energy on my part to figure out what’s actually going on in a given review.
   You might argue that you can keep the patches split, creating one review per commit, but that’s actually worse. At best, you’re now separating the tests from the feature, and the refactoring from the motivation for the refactoring. But the real issue is that many single-patch systems make it very easy to approve any one of the commits in isolation, which is exactly the opposite of what you want. Thus, one-review-per-commit switches the balance from “annoying” to “dangerous.” Not really an improvement.
2. They encourage you to hide your history. The whole point of a source control system is to tell you the history of how code got to be the way it was. I want to be able to see what it looked like yesterday, and last February at 2 PM, and anything in between. Sometimes that’s because I know that the code worked then and doesn’t now, and I want to know why, but lots of the time, it’s because I want to know why a given change was done. What was the context? What was the motivation? When you just keep updating one single patch the whole time it’s under review, I’m losing tons of history: all I’ll get is a single finished product as a single patch, without any of the understanding of how it got that way.

http://bitquabit.com/post/code-reviews-and-bad-habits/