Development is mostly prototyping -- you may work on a big project but you end up prototyping a solution to each of the small problems that happens (you know ex

Development is mostly prototyping -- you may work on a big project but you end up prototyping a solution to each of the small problems that happens (you know exactly how to solve a problem? great it takes little time to actually write the code, which means you will spend most of your time working on what you don't know) during the development. There's a difference between hacking it and doing it right. You hack something to see if it works, and if it does, you discuss it with others and decide the best way to do it right. One of the largest features I wrote for x264 took 80 minutes to prototype, but a couple weeks of on-and-off work to make it work in all cases, find most of the bugs, and make it efficient. This involved discussing it with other people! After you have tryed different approaches to solve a particular problem and selected the best one, you want to hand the authority to decline that solution over to somebody who hasn't worked closely at the problem and has looked at only one solution for a few minutes? That can only end badly. No, that can only end well. If you think that changes to code are better if you don't discuss them with other people, you're simply a terrible programmer. Programming is a team activity, and if you don't trust the other people on your team to read it over and talk about it with you, you or your team are completely dysfunctional.