Code bombs and team morale

Jeff Atwood again did a good reading for us: code-bombing from the dark room. This is the essence of why the collective code ownership and even infamous pair-programming are actually helpful in shielding the programmer's ego.

It is much easier to give up on a 10-lines method than on a whole over-engineered and obtrusive application layer. I am so used to admit my ignorance very casually that it became a defensive mechanism for my otherwise vulnerable and envious soul. I like writing frameworks but majority of them have never seen light of the day. In the eyes of others exactly this practice supposed to make you a better programmer. Probably it did, because I avoided code-bombing my colleagues, providently submitting mere suggestions instead. Most of the time these fruits of weekend labor were criticized but some pieces were adopted after heavy rework, and that, indeed, made me a better developer. Critiques hurt a bit but kept me determined to go ahead and try to get those heartless bastards next time. How does a "suicide code-bombing" sound?

Software development is people's business and what comes good for a cubicle drone will go good for the whole project. Code reviews, especially if they cover results of months of work, are inefficient and leave people feeling more offended than enlightened. Daily cooperation will allow people admit and accept their mistakes with dignity and confident people are much more opened to learning. It is not even instrumental to have Jedy programmer on board as a team of generalizing specialists possess enough steam-power to self-propel the average skill level up and forward.