You're just holding it wrong!

Any arrangement In India.

(or maybe China)

Seriously, if you need to worry about "seating arrangements", you probably need a housecleaning. If the work is so mindnumbing that where/how a developer sits is important, maybe offshoring it would be doing the employees a favor...

Not sure I understand the fixation w/ COBOL here...I'm well past 40, and have only wrangled a bit of COBOL in my 30 year career. Lots of C/C++, Java, Perl, Python, Javascript, etc., but damn little COBOL.

As stated elsewhere, one cause is probably just burning out and moving on to something else. Or moving to the position of manager who's making those hiring decisions. Or, if you're actually good at software engineering, moving into consulting.

ftm, if you're a great developer w/ lots of experience, you probably also have a pretty wide network. The last 16+ years of my career, CV's have been just a formality (if required at all), cuz I already knew the hiring manager.

Code reviews are highly subjective, human endeavors. I've certainly wasted more than a little of my life in "reviews" that were nothing more than personality driven, agenda laden time-wasters that usually surfaced little more than grammatical erros in comments. *If* the reviewers actually bother to look at the code before making comments.

Here's a little exersize you might want your boss to be involved in:

• Grab an arbitrary piece of code from outside your organization.
• Inject 10 or so errors or other issues into it
• Divide your usual review crew into 2 groups to review the code separately.
• Tell one group that the code was written by a new intern, so you'd like them to eyeball it.
• Tell the other group that the code was written by your most senior developer (preferably, one w/ a big ego), and they need to review it "cuz the boss says we have to"
• Compare how many issues each group finds/reports.

I suspect you already have a good idea what the outcome will be. That should be enough to tell you how effective code reviews are.

Automated code formatters/code inspectors, along with decent compilers/linkers (or interpreters) will surface most of the issues that code reviews find.

Instead of pissing away valuable developer time, put those reviewers to work writing and executing tests. Right away, you'll discover whether the code is testable. And then you'll discover whether its actually correct.

Tests don't have egos, agendas, personal axes to grind, or coworkers they don't want to piss off. They don't take vacations or sick days. They don't have opinions about the author of the code. They usually don't leave the company. They generally don't have an opinion about how many/few comments there are, or if the code has been formatted to corporate spec (unless those tests are executed as part of the automated tools mentioned above). Sure they can be drudgery to write, but its the only real way to know if the code actually does whats its supposed to.

A leisurely stroll through Freshmeat should be sufficient.

Of course, TFA's author apparently couldn't be bothered to do that either...

...then open source is in deep trouble.

Clue for the TFA'a author: there are lots of very interesting open source projects that don't have a damn thing to do with Linux!

Doh! Mea culpa...I guess 4 pages of CIO.com clutter left me cross eyed. Or maybe its the holiday weekend Friday afternoon.

(Note to self: use Edit->Find... before commenting)

But I still think its important enough to deserve more than a single passing comment.