Why would developers want to become a CIO?

I found these articles today:


5 Reasons why a developer would want to become a CIO

and

8 Reasons why a developer would never want to become a CIO


They are about reasons why a developer might want to or might not change his position for a position as a CIO.

Now, I'm going to discard all the financial arguments. I'm not interested in money, at least not to the level that it will make me decide in favor of or against a job. Maybe it's because I'm Dutch and not American, I don't know. But I couldn't look at myself in the mirror if I would take a job just for the money. I would deny a job if they wouldn't pay what I'm worth though, but I think that's another matter. Bottom line: money couldn't get me into a job, but could keep me out of it.

Now, for the other reasons that a developer would want to be a CIO (only 2 of the 5 arguments remain after removing the financial reasons...) #2 is bullocks. It tells us that you want to be king of the company because you will have power over the people. To me, that's not a reason to be the king. I want to have the power over the faith of the software, not the people. I want to be able to tell which directions we need to take with the software. That's the real beauty of being king, not that you can tell people they need to fill in form A,B, or C.

Reason #5 (you get tired of solving the bugs) is bollocks too. Every programmer knows solving bugs is part of the job and you want to improve your software each day to give your customers a better product and toe get you less bugs on your todo list. If you are solving bugs each and every day and nothing but bugs, you're a bad programmer and you won't survive the business. If you have to do that because you're the bug solving programmer, you probably are just starting (solving bugs is a great way to learn the software and learn programming) and chances are you're not CIO material yet.

So, a nice article that draws some attention but, IMHO of course, full of nonsens.

As for the other article: the 8 reasons why you DON'T want to be the CIO, it's much the same.

Reason #1: we live to write code. True, but I guess that CIOs that have a developer background still continue to write code, or at least will research (new) code developments. You will be the senior in the company (after all, you started as a developer) and chances are there will be some hungry young dogs trying to learn from you. You won't leave your code: you only get to pick the nice pieces to be involved in.

Reason #2: seeing the fruits of your labor. Being a CIO for once you can make the decisions that you think are good for the software and the company. If you have sound ideas, the company will improve with your leadership and you will see the best measurable results possible: an increase in turnover. The results of a days work as a programmer is a nice piece of code that makes it through the unit test cleanly. The results as a CIO will show in the daily sales of licenses and positive customer feedback. I'd rather have the latter.

Reason #3: being able to speak Java/C/et cetera is a must for a CIO. That's the only way you won't get fooled by the developers that tell you that something isn't possible (anything is!). But, sure, you need to be able to express yourself as a human too, but I require that from my programmers too! If you can't talk Dutch (or English :-)) you would have a hard time surviving in my company. It's not a CIO-only requirement: it's a human's requirement to be able to express yourself.

Reason #4: there probably are a couple of people that want to be remembered for their hacking capabilities. But, again IMHO, hacking is stupid. If you are such a good programmer that you can do some facinating stuff, apply your abilities to do some good and useful work. It's a waste to spend your talents at stuff that gets people mad. You can do a lot better in making people happy.

Reason #5: sucking up to other people with jobs beginning with C's. What nonsense. If you are a good CIO, you will be taken as an equal amongst those C's. If you're not, you're not in a technology company and/or you're no good. If you find yourself sucking up the whole time you probably did it before (and you might even have gotten the C-job for it), but you won't make it.

Reason #6: the reference in the article to point #1 is a good one, because the same counter arguments apply. As the CIO you for once get to pick the directions and you will be able to do some real innovation that has an impact in the company. As a developer you will find you write just a bit more clever code that nobody will see. You'll take pride in that, but it will only matter to yourself.

Reason #7: not liking Powerpoint. If so, use something else: easy. Use video, music, exotic dansers. You're the guy with the 'C': pick your own tools. Now you can!

And for reason #8: that will all change, once YOU are the CIO. All the other developers will think: thank god, we now DO HAVE somebody that has a clue.

Again, Just My 2Cents Worth.

Bye,
Bart

I don't get anonymous methods...

Today I watched a presentation by Adreano Lanusse and David I on Tiburon. Nothing really new was shown from the things we already know. Luckily there were a couple of exceptions showing up as my installation does from time to time :-) And I now know that showing recorded videos using Microsoft Live Meeting is not a very good idea. The upload speed of the host was just not good enough. The rest of the presentation was pretty good to watch.

During the presentation we could ask questions and mine was: what's up with anonymous methods?

We've probably all seen the example of anonymous methods shown at http://blogs.codegear.com/davidi/2008/07/23/38915.

I just don't get why you want to use anonymous methods and I'm afraid Adreano and David were not able to explain it to me.

Why wouldn't you use a private class method? Or an local procedure? I really tried but I can't think of a situation where you want to use an anonymous method.

Who can explain this to my satisfaction? Why would I be happy with those???

Bye,
Bart

What are those prizes in the race - (part of) part 3

You might be wondering what's keeping part 3 of the reviews on the prizes in the race. To be honest: I started looking at RemObjects'  DataAbstract but business has kept me from looking at the software properly. It's not your daily component pack that your can write a quick review about. It's a proper software framework that needs a good looking at before coming up with an impression. So, please bear with me, the review will come, but it may take me a bit of time.

Bye,

Bart

Impressions from the webcast by Embarcadero

Yesterday I attended (half of) a webcast by Embarcadero presenting their products. Everytime I attend such a webcast I am amazed that it actually works. LiveMeeting (and all their competitors for that matter) really work and help to do a presentation from a distance. 

But, the presentation itself gave me some strange feelings. I must tell you that I am probably not in the target group of Embarcadero of their ' original'  products. I only have one database to maintain (the one that is used by Sevensteps' software) and that is not a complex one at all. That's also why I only saw half of the presentation: I realized that I probably won't use their products and will look at the Tiburon presentation later today. That's more my cup of tea.

There's another thing that I noticed in the presentation: the user interfaces that I saw were terrible! I saw an enormous amount of cluttered screens, about a trillion buttons in toolbars, 'old fashioned' icons and very complex dialogs. There was one tabbed dialog that had about 20 pages with numerous controls on each page. There were also wizards that help you do some complex work, but the wizards themselves were very complex and did not have a clear and clean design.

I probably understand were that's coming from. From what I saw the software can do a lot of complex tasks for you and you can pick from a large range of database (formats) to choose from. That probably is the reason why the user interface is so complex: there is a lot to do on a lot of database formats.

If I were to redesign the user interface I would start with one option screen where you can pick the database formats that your are interested in. Probably there's only one or two formats that you will be working on (in that session). Based on that choice I guess you can lose half of the buttons, options and windows

Also, in a dialog or wizard, when an page is not available due to previously made decisions: hide the page, don't just make it disabled. It will clean up the windows a lot and will make the software a bit easier to use. There was a wizard with a couple of tabbed pages which only had one active page of the 10 available. That's not a good design. If you only have one page available: lose the tab. There is no point in showing the other, disabled tabs.

That's just my 2 cents worth for now. I only hope that we get better user interfaces in Tiburon...

Bye,

Bart

And the winner is: Werewolf

The results are final. Werewolf, our superfast, late entry, has just won the race by a couple of votes from Jan Wicher. Werewolf, Jan and third place Tom Glenn will pick their prizes from the prizes made available by our sponsors.

First and second prizes were won with Delphi programs. Third place Tom Glenn made a fine contribution using C#.

Congratulations to them and thanks a lot to the contenders that didn't win a prize. To me, it was a lot of fun to be involved in this, albeit not as a contender. Who know, this might become an anual event. I will keep the website alive for the next year or so.

Bye for now,
Bart

Two days of voting left...

It is becoming a very tight race. There are three contenders for first place and the are only seperated by a couple of cotes. If you want to be the deciding vote, go to the site now and pick your winner.

Bye,
Bart