Say No to Brogrammers

I have observed a disturbing trend in software circles where cocky, mean-spirited brogrammers infect development teams. Urban Dictionary defines brogrammer as:

1.	brogrammer	151 up, 47 down
	A programmer who breaks the usual expectations of quiet nerdiness and opts instead for the usual trappings of a frat-boy: popped collars, bad beer, and calling everybody "bro". Despised by everyone, especially other programmers. Oh my god, John is talking about football and chicks again. That guy is such a brogrammer. programmer frat boy bro douchebag developer by seldo Dec 2, 2010

I find the brogrammer vibe toxic for several reasons:

1. Fun dies
• Teammates dread coming to work.
• Team outings become an insufferable chore.
• Teammates can no longer laugh at themselves.
2. Innovation suffers
• Teammates fear hazing.
• Teammates are afraid to speak up.
• Teammates are afraid to fail.
• Teammates are afraid to try something new.
3. Productivity suffers
• Teammates are not forthcoming. As such, disingenuous Iteration Retrospectives stifle self-correction.
• Teammates are fearful of committing code without first performing checks and crosschecks.
• Teammates are fearful of the potential humiliation of breaking the build.
• Teammates are loath to ask questions for fear of retribution.
4. Quality suffers
• Teammates dread pair programming.
• Teammates dread the humiliation of code reviews.
• Teammates avoid questioning or debating a technical approach.
• People-Haters use metrics like code coverage to flog rather than learn.

Two red flag artifacts of the brogrammer vibe are Build Monkeys and Nerf Guns:

1. Build Monkeys - a stuffed animal, or mascot of humiliation, gleefully bestowed upon programmers who break the build (or otherwise defy bro-thoritarian rule).
2. Nerf Guns - toy weaponry gleefully deployed to pelt & punish programmers who inadvertently imperil something as inconsequential as test code coverage.

Nerf wars seemed innocuous when perpetrated by the socially inept smart people we'd all grown comfortable working with on our software teams. But now that the brogrammer boys have entered the fray, the once innocuous joviality has morphed into mean-spirited team oppression.

"Let's put the pro back in programmer...no more ninjas and definitely no more brogrammers."
~ Daniel Hamlin, 7:33 PM - 25 May 12 Twitter for Mac

I value the people I work with much more than the technology, or the software product we're building. I refuse to engage in this behavior and plan to defy Brothoritarian Rule.

Fear, hatred, and suspicion narrow your mind – compassion opens it.
~ Dalai Lama, 4:27 AM - 30 Apr 12 via Twitter

Additional Reading

• "Gangbang Interviews" and "Bikini Shots": Silicon Valley’s Brogrammer Problem, by Tasneem Raja, Mother Jones, April 26, 2012.
• In tech, some bemoan the rise of 'brogrammer' culture. by Doug Gross, CNN, May 7, 2012.
• In war for talent, 'brogrammers' will be losers, by Gina Trapani, Special to CNN, May 10, 2012.

Agile Anti-Patterns

A few Agile anti-patterns I have experienced as a developer are:

• Business Allowed to be Lazy. A counter-productive friction exists between highly productive developers (held accountable by process metrics) and largely unaccountable business proxies. Often the business proxies abuse the flexibility of discovery in Agile and some use it as an excuse to be lazy or disengaged.

Why are developers asked to estimate a story if the business can't articulate clear acceptance criteria or fail to deliver a simple sketch or wire frame?

• Over-Emphasis on Velocity. Speed is mistaken for velocity. Velocity has two components – speed and direction. I’ve been on teams who were delivering working software iteration after iteration only to find we were building a product that was unusable, inferior, or somehow missed the mark because direction from the business was misguided or lacking. We focused on delivering, not on the product.

When the burn down shows "done" and the business has a product they couldn't use or don't want, it's the business' fault. Because the only way this could happen is that they didn't show up to the demos, didn't ever walk through the lab, didn't talk to anyone building or testing the system. If there was no mechanism to make sure the blame was spread there, this is just pure corporate oncological dysfunction.
~Colonel Nikolai, post comment Oct 28, 2011 08:04AM.

• What to do with Project Managers? Traditional PMs are too often shoe-horned onto Agile teams because the organization can't figure out what else to do with them. Traditional Project Management is an extension of old-school Command & Control that savvy developers can't abide. It is based on hard estimates and Gantt charts. I have observed PMs using Burn-down charts like a blunt instrument to flog developers.

Dear PM,
When you continually ask 'Is it done yet?', the veracity of the answers rapidly degrade to pure lip service.

• Process Over Pragmatism. Teams often feel compelled to follow process for process sake or because it's been decreed by the organization. The most effective Agile teams I have been on discovered what worked in the prevailing conditions. There is no one-size fits all.

Dear Process Cop,
Developers welcome process when it makes sense, but gratuitous ceremony is a waste of everyone's time.

• Standup as Status Update. Standup meetings seem to have devolved from the imagined intent to be informative and consequential to tedious status updates.

Dear Teammate,
If you don't have something wildly informative or marginally consequential to say, please cede your turn. Standup is not CYA.

Do these seem familiar? Which anti-patterns have I missed? I welcome your feedback.