An Improved Skill level indicator

With reference to my previous post on skill level indicators, I have come up with a new version... which I think is better...

It works in terms of "problems", since when employers ask for skill what they're really asking is, how useful are you to me with this technology?

1. Problems, what problems? (iow, I haven't had any problems because I haven't used it enough)
2. Somebody else solves my problems
3. I solve my problems but have to sometime ask someone else to help
4. I solve other people's problems, sometimes someone comes with a new problem
5. I solve other people's problems and there is never a problem that I don't know how to solve immediately

A working definition of the skills scale

Have you ever done a "skills matrix"?

It entails writing down all your "skills", i.e. API's, technologies, languages, whatever might be relevant and putting a number from 1 to 5 next to them, and maybe a time length in years of your experience on the topic.

It is to get a prospective employer and idea of how valuable you could be.

The problem however, has always been, what does "1 to 5" mean. What is the reference point? You might regard yourself as an expert in Swing because you've built some funky table structure where you can edit the cells and render the cells according to their contents, you might put down 4, maybe if you're brave 5. But then what if one of the interviewers is a contributer to the swing API? In comparison to them you're only a 2...

I have thus always been skeptical of someone who puts down 4's and 5's. I'm going to make sure they're backing that up with something real. In fact, I'd love to interview someone who puts 4 or 5 for hibernate, it could be fun to show up their lack of skills.

Now what about if we come up with a more absolute definition of what the numbers 1 to 5 actually mean. So they're more than just mere numbers. Here is my stab at it...

1 – only read about and played a little with. I have indirect knowledge or experience (was on a project where they used it but I was not involved).

2 – shallow understanding, worked with by duplicating other work.

3 – becoming familiar, able to work with and beginning to understand what is going on. Extensive experience programming with.

4 – Understand the inner workings of the technology. Thus can solve problems where they appear. Extensive deep experience in working with.

5 – Extensive understanding of the whole technology. Totally knowledgeable and experienced with everything about the technology. Possibly spotted and fixed bugs in the API if applicable.

Is this helpful, or relevant? If you apply this grading system to some of the technologies you know would that change your score? I don't think any ranking method would be perfect, maybe people can comment on how it can be improved. Maybe there's a totally different solution.

Technorati Tags: employment, grading

Open Source and the cost you don't see

The story on the register about Sun moving towards charging customers for certain enterprise features included the following quote from research house "The Standish Group"

"Open Source software is raising havoc throughout the software market. It is the ultimate in disruptive technology, and while it is only 6 per cent of estimated trillion dollars IT budgeted annually, it represents a real loss of $60bn in annual revenues to software companies."®

The full report is available here.

This supports something I've been saying for a long time and that is that companies who use open source should not, in fact, see it as a free ride. They are getting a significant amount of value out of the open source software they use, $60bn worth. Personally, I think that is under what the real value is - think how many versions of apache are running out there (compare the price of an IIS license and its features).

I'm not demanding however, that companies start paying for the open source software they use - that would be like the good guy (open source) becoming the bad guy, just not on the outside. The open source community is not in it for the money.

Companies should give back to the open source community, they could donate cash if they so wish, but a better idea is for them to let their developers work on open source projects, on company time. Those very companies are using the open source software and will thus benefit from the work their developers do on it, because the developers will work on features that they require, and on bugs they have found.

The company at large will not see money going out to open source projects, even though value is being added to the open source project. There will thus be no nominal effect on the "bottom line". They will have a happier developer (what developer does not want to work on an open source project), they will gain a lot more street cred and the open source software they use, will be improved.

It's a win-win situation.

Programming: where Humility is a genuine virtue

You often hear of Sports players as being arrogant, and typically, it is not a compliment. The phrase is "He's an arrogant, good sports player". You do not hear the line, "He is not good sports player, pity he is not arrogant."

The point I'm getting to, is that the sports players arrogance or lack thereof, does not make a material difference to his performance on the pitch. Compare two top football (soccer) players. Thierry Henry and Christiano Ronaldo. Both artists on a football pitch, the one, Ronaldo, supremely arrogant (IMO) and the other the picture of sophistication, humility and just plain decency (he's got that thing that only Frenchman can have).

But, the arrogance or lack thereof does not make a material difference to their performance. No one ever said about Henry that he needed to be more arrogant in order to improve his performance on the soccer field.

However, it is not like that in software development.

In software development, humility is a virtue that can make a good programmer into a great one.

The other day I had to make some changes to improve performance on the application I work on, and then once those changes were made I deployed them to the clustered WAS server to test them. Quite an involved process this is. I figured, it's okay, there won't be errors in them so I didn't bother to test them on my own development machine.

Well, turns out, after many tries and many days of pain when only after I got the code onto the clustered server did I discover that it did in fact have bugs, that I finally got the code to run.

So my time saver at the beginning in not testing locally turned out to be much more time wasted in the long process of getting the buggy code onto the clustered environment to test it.

I was arrogant to assume that my code changes would be bug free. I thus lost more than a day because of this. If I had been humble then I would have checked myself before deploying to the server and thus saved a lot of time.

So unlike in sports where arrogance does not make a difference to performance, in software development, being arrogant is a liability. In a sense, it's counter intuitive. Even the best make mistakes (they've said as much).





Technorati Tags: software, humility

Is Software Art?

I was reading a post the other day, can't quite remember where the issue was "is software Art?".

Probably the typical response to that is no, computer software is utilitarian and thus cannot be construed as Art. But that approach belies a limited view of Art and what constitutes Art. To say something is functional and thus not art is to limit the world of Art significantly, but also to limit the potential and possibilities of the functional world.

Let me explain... take a knife. You can create a knife the "cuts", i.e. is fulfills its function. However, you can also get a knife which _really_ performs its functions. i.e. it is well balanced, has a sharp true blade, has a firm easy to use handle and is aesthetically pleasing. Now, this better knife was not produced only by an engineer using his "engineering" faculties but possibly by an artist type person as well (could have been the same person). Thus artistic elements were introduced. Furthermore, on use, though the simple knife that "cuts" would also fulfill its function - as does the more "arty" knife, anyone who uses both knives would admit the latter knife is better, and not necessarily for a reason that can be defined in merely utilitarian terms - they both "cut".

And to my mind, a similar dynamic occurs in Software.

Have you ever presented your end product to the client and been frustrated that they don't truly appreciate the elegance of the application. Why not? They are simply looking at the software from a functional point of view, i.e. the non art point of view. However, you know that the software is a lot more than just utilitarian. It has an elegance that is hard to explain to people that don't "get it".

The question is, is that elegance non functional? If a picture is beautiful, it does not have any functional value, however, what is interesting about computer software is that elegance follows function. That elegance may not be leveraged now, but in the future, the good design decisions that were taken earlier can easily lend to better functionality later. When I look at a good program, I respond to it the same way as I'd respond to art. It activates the same receptacles. Furthermore, there is truth in that the way to write good software is to study good software, similar to the way to paint well or write good poetry.

Very often I have struggled to sell the benefits of a particular approach to non techies. For instance, the benefits of refactoring to your manager. When your manager looks at your application they just see a bunch of brush strokes, when you look you see a Rembrandt.