@Chris W

I'd like to work with this bloke.

When I interview people, I go for IQ, Motivation, and General Experience.

The first two are mandatory. The third one depends on the level.

First Question, "You're on a lake in a boat, with a car battery. You throw the battery in the lake. What happens to the level of the water?"

Second Question "How do you increase the M25's resilience to flow problems due to accidents?"

Third Question "Think of something that Amazon/John Lewis/Yahoo doesn't yet do that it should."

Fourth Question "What's the difference between data model architecture, and domain model architecture and what is the limitation in the mindset of domain model adherents that makes them only realise their code is so slow a week before it's due for delivery?"

Fifth Question "Describe your favourite pub."

Sixth Question "Write an imaginary postcard from a weekend away, using words only beginning with S."

And so on...

50 IQ & Porsche 911 but no people skills = Commercial Director

50 IQ & No Porsche 911 and no people skills = Head of Operations

80 IQ = Cleaner

90 IQ = Chief Cook

100 IQ = Bottlewasher

120 IQ = Tester

130 IQ = Developer, Business Analyst.

140 IQ = Architect, Project Manager etc

150+ IQ = Troubleshooter

150+ IQ & Business Ability = Enterprise Architect, Business Development etc.

160 IQ = President, Einstein

200 IQ = John Stuart Mill

It's a pity that the recruitment industry disagrees and thinks a business analyst should be some kind of admin bod, instead of an ex programmer who is bored with it all.

@Chris W

Agree with you, training will be most useful on people who have a clue to start with. However, when that is the case and the training is the the right one, benefits are immediate.

I had excellent training when I was working at Reuters, on their own systems, as well as Sybase and Sun Solaris admin. It worked because it was good training delivered by excellent trainers who were specialists in their field to skilled staff who were able to apply it in their day to day job immediately. It wasn't cheap training but the amount of time subsequently saved by the company made it more than worth it.

I also found myself on the other side of the desk, as a trainer for another company. Then again, it worked because my day job was to do the same thing as the guys I was training so I had the experience of what they needed to know in order to do their job properly.

It's like everything else: providing good training to skilled people in invaluable, provinding bad training to clueless people is like giving them paid holidays. This is why management and beancounters are often dubious about its value.

@Chris W

Mate, I don't know much about admin stuff, but I don't even need to try to hard to come up with examples when it comes to programming. Half the CS stuff I learned in university, I never would have come up with on my own.

There's a whole framework, including maths, which you need for some of that stuff. So, yeah, you _could_ spend a lifetime reinventing it all on your own, or you could spend a semester learning it from someone who already knows it. I'll take the latter, thanks.

E.g., just by banging code you'll never come up with, say, Heap Sort. And that's a simple one. You could be programming in Java and might have learned some mantra like "use the built in quicksort!" Well, try using that on a 100 GB file on the disk, and you might find it a tad less than optimal.

E.g., 1-2 times per year yet another retrained burger-flipper comes to me with, basically, "Auugh! Java's Hashtable is broken! I store a value in it, and it replaced the value for a completely different key that had the same hash code!" What really happened there? It added a new node to the front of the linked list for that bucket. But said burger flipper doesn't understand hash tables, nor linked lists, and having only dealt with Java he doesn't understand pointers either.

Worse yet, almost all of those first spent 1-2 weeks debugging a class that they shouldn't even be worrying about. And some teams even implemented comically absurd "workarounds" for that "problem." All the more comical since they invariably can be proven mathematically to be snake oil, and only masked the "problem" for the particular test case they were using.

Even worse, they often didn't just waste that time, but created a problem for maintenance later too.

That's the kind of thing I'm talking about. I'm not even talking newbies. I'm talking about people who've used a Hashtable or HashMap a thousand times before, over several years. But then something happens that's outside the usual rut. They debug something else and end up looking inside a Hashtable. And the lack of knowledge bit them in the arse hard.

Yes, you could argue that a determined individual could have learned all that on his own. Some do. Maybe you're one of those. I don't know. Most don't, until it bites them in the arse hard. And then they don't even know what to google for, and spend inordinate amount of time and work to rediscover something that a teacher could have told them in 20 minutes.

That said, though, I'd like to add the caveat that a heck of a lot of certifications _are_ snake oil. They ask trivia, but never check the fundamental concepts behind them. They're made "difficult" by asking such trivia as in what package is some obscure class, or for Unix certs, in what directory is some obscure utility found. (Never mind that there are tons of ways to find it, if you ever needed that, plus they miss such common occurences as it having been recently recompiled and residing in /usr/local/bin instead of /bin.) Briefly, they're not supposed to make you any smarter, they're just supposed to make money by also selling training and books about those trivia.

_If_ your mate was going to that kind of snake oil courses, well, I'm not going to argue with you that he probably didn't learn anything useful :P

DotBO

As folk have already mentioned, it only seems obvious. It seems obvious to the IT staff, and very probably to their managers.

The real problem occurs when said manager goes to the Finance Director and says : "I need an additional 25k in my budget next year so we can send ten of our staff on three day courses."

And the FD replies with something along the lines of :"AAHAHAHAHAHHAHAHAHAAAA."

In big orgs with internal markets and cost centres and all that jazz, I've seen it even worse. In a multinational with USD 26 Billion turnover, developers were unable even to obtain technical books. They weren't authorised to spend anything, and nor were their team leaders. And even if they had been, they would have had to charge back to the 'client', because there was literally no budget (outside of headcount) for the dev team.

The departmental higher ups wouldn't order books either, because "If we do it once, we'll have to do it for everyone". Well Duh! At the same time, this org regularly fed it's visiting external clients a buffet that included caviar. Yes, you read that right. From the cube farm where the dev team sat, they could quite literally sit and watch through the glass wall as the directors and their high value clients stuffed their faces with caviar in the meeting rooms. But somehow these same people couldn''t pony up a few quid for a few decent manuals. Try, if you will, to imagine that as a motivator. * This may seem hard to credit, so I have to reiterate that they really did buy shed loads of caviar, which staff were able to verify because after these meetings were finished, the leavings would be placed in a staff common area for people to pick over. How thoughtful.

I blame the metrics personally, most places don't know how to measure what IT does.

There's no direct bottom line number for the bean counters to grasp. And that's about the only thing they care about. Lets say your dev team work unpaid overtime for two months and deliver a really good system that makes your sales team 50% more efficient. Where does that number go on the spreadsheet ? Under "Sales", obviously.

Bonuses all round for the sales droids, on top of their generous commission, and the IT team get bought a pint out of their managers pocket. w00t!

There is a solution to this, also sponsored by the DotBO, and also so "obvious" that no one ever actually bothers to do it, which is to measure user experience (quarterly, or oftener, survey which you will have to design very carefully) and follow this up with frequent, formalised contact with stakeholders from your user base.

Every time I've implemented this, the result is a steady increase in the overall figure for "user satisfaction" or whatever you want to call it. (Seriously, you'll score points just for asking). It hasn't, yet, resulted in what the IT people always fear when you suggest this to them, e.g a crowd of angry users wielding pitchforks and a huge backlash against the IT function. Yet. But let's face it, if your org is likely to go that way anyway, you really NEED to be doing this.

In addition, you get to go the FD and say things like "Deparment X is going to want to implement a [some kind of system] next year" (remember you know this because you've been talking to them about their future plans and likely requirements), "we don't currently have the skills in house to do that, so as part of the project budget there will be a requirement for training in [some system]"

And this works, because you have also communicated this need to whoever goes into bat for Dept X, and who is now your best buddy, and will therefore push for the budget to be allocated because it's now her pet project, and she doesn't want her critical path being b0rked.

Of course it's not always quite as easy as I'm making out, but at least it gives you a metric that actually means something, and a stack of numbers which you can make pretty charts and powerpoints from, these are always helpful when dealing with bean counter types. You also build meaningful relationships and channels of communication with the people who matter most. Your users.

As an extra bonus, you get to write the process up using all the buzzwords that pointy hairs like, "empowerment", "ownership", "buy in" and all that bollocks. You can probably even get away with using "leveraging" and "synergies", possibly even in the same sentence.

While I'm busy pontificating, a handy hint for IT management types is that most decent IT folk (not the paper tigers, I suspect) are actually quite good at educating themselves. But you need to give them time to do it. Fridays are good for this, especially Friday afternoons when everyone would otherwise be slacking off and posting lengthy flames to El Reg in any case. Make every friday, or every other friday or whatever you can spare (rotate people if you have to) a Skills Development and R&D day, and watch your team's productivity go sky high.

Getting this past your next layer of pointy hairs will be the single most politically difficult task you will ever face, though. You may well have to settle for less, or something a little more flexible. That's OK.

* In case you're wondering, every single developer in that department applied for voluntary redundancy in oh, about the second round of "rightsizing". None of them were granted it. All their jobs were subsequently offshored to an Indian contractor. Nice.