Coming from an independent consultancy to being a part of a corporate culture has it’s perks. For example, one learns how to do things the hard and slow way but to make sure your ass is covered - by creating a 5-document functional specification that lists everything  you did for a specific project, two installation instructions (one for QA and another for Production) and a list of actions everyone performed to approve this 5-document specs. For large projects this is okay and even neccessary, but I can’t help but laugh when this “War and Peace” is created every time there is a need to update two images on company’s web site or change couple of words here and there.

Unfortunately, there’s a very little flexibility built into almost any corporate culture. This stems from “dog eats dog” approach everyone is taking, since it’s enough to have one asshole on the team to convert “Happy family” into “Survival of the fittiest”.

Nevertheless, I came up to the management with the idea long known from totally different area. I suggested that management (namely VP of IS and whoever is immediately underneath him, supervising software development) would create a so-called DMZ - a “de-militarized zone” for projects.

The project would be dropped into DMZ queue (as opposed to regular software development queue) if its execution would take a significantly less time is the documentation workflow is skipped. For example - updating couple of words on web site, changing an image or something similar. There will not be many of them, so it does not pose any threat of being too large to manage and growing out of proportion. On the other hand - it will free up a lot of developer’s time that could be used somewhere else.

Popularity: 35%

Damn, just realized this blog had comments turned off all along…

Popularity: 32%

Despite everybody and their mothers getting online, the state of IT jobs market remains somewhat grim. There are just not that many interesting positions available anymore.

The problem is that large companies only want to hire either code monkeys (so that thay can outsource their jobs later to India or Romania because of budgeting issues) or gurus who are capable of replacing entire departments. Such gurus want (and deserve, trust me) huge salaries that are, however, still offsetting salaries of few average programmers. The problem, though, is that such gurus are rare and hiring them means doing things in a certain specific way.

Let’s say you hire a guru for a project, the project gets completed, your guru moves on to another project at another company. Three months later you need an update to your existing software. You can’t hire same guru - he’s somewhere else and not interested. So you hire an average Joe (after all - the job isn’t that complicated, right?) who spends three times more time trying to figure out what’s going on. By the time he’s done there’s a new update pending, so you keep paying him three times more for figuring things that were done in a certain unique way.

Personally, I am neither a code monkey nor a guru, so I am sort of in between the bandwagons here. Can’t say if it’s a bad thing or a good thing. By the way, my own dream job of the moment is some large development project on which I will be working alone with a good and understanding project manager and business clients who don’t tell me how to write the code. Oh, and I prefer free bottled water in pantry, thank you.

Popularity: 34%