I was just pointed to an awesome link, Things Everyone in IT Should Know. The tone is rather snarky, but that gives it its punch. And the author has obviously been in the trenches.
At first, I was expecting the usual "you should know DNS", "you should understand threading", "you should know [this technology that's indispensable to me]". That's what I'm so often seeing, but the author didn't go there. Instead, s?he writes stuff like this:
Some of the most disastrous projects come from teams of "Seniors Only" because they trust too much or too little and are too afraid or arrogant to ask stupid questions like "Why?"
Most seniors know how to do something, but it's amazing how many can't articulate why they are doing it. Unless you can articulate why, keep your sippy cup close by. You're not grown up yet and you are limiting yourself.
All potential is wasted. It just means you're capable of something you haven't actually done. So do it and prove it! You must allow juniors into the mix and allow them to fail. It's part of the price you pay to keep getting them to ask "Why?"
Experience trumps experimentation, but "Let the Wookie win," is a recipe for disaster more often than not.
That's a bulls-eye with a side of snark. Lovely. I remember being the "junior". I was put on a project to write some code that was way over my head. I told my boss that I didn't know what everyone was talking about and he told me to schedule time with the other parties to ask them how their systems worked. The project failed miserably. As far as I know, mine was the only piece of the project which worked right the first time.
I also loved the DBA comments. A good DBA is a worth their weight in gold. I can't heap enough praise on them. Incompetent DBAs who can't write efficient queries, don't understand indexes or how to analyze performance problems or, worse, don't understand how to normalize a database will usually cost you more than they're worth. Pay for a good DBA. They'll still be making less than they're worth.
The manifesto makes clear that good business decisions and good technological decisions do not always overlap! This is unfortunate, but true. Any IT professional who insists on The One True Way without considering the business ramifications should be labeled a "junior". For every professional who insists that only Oracle should be used, I can find others who will insist that only Postgres should be used, regardless of what they're building. Those who feel that everything should be done in C++ will be stumped on problems requiring the predicate calculus. Those who insist that everything must be "test first" may not appreciate the benefits of exploratory prototyping of poorly understood problems.
Notice a pattern to any of this? Here's my abstraction of the manifesto and my personal observations:
Which just goes to prove that abstraction is not always a good thing.
Re:Bruce Mau's manifesto
bart on 2006-02-15T12:03:27
Heh, I read that URL too quickly and I had turned it into "bureaudesign".
