What's it all about, Alfie?

There's been a lot of talk about the Rock Star programmer on the web these days. Several very interesting articles about it. Today I had a run-in with a new guy at work, and I have to say, while not a Rock Star, he's certainly got several of the worst qualities of a Rock Star, and I'm trying very nicely to point out to him that they really aren't very useful here.

I try to ask people in interviews what they think their most important job is when first coming to a new place. There are a lot of different answers, most of them very political or very technical, but every so often I find someone who understands what it means to be a good developer, and they give me the answer: learn.

That's when I know I have a 'keeper'.

If the smartest person in the industry came into a shop and started changing things, or building things, it would only be by the greatest feat of luck that it actually worked and worked well - with the existing systems. Anyone can build an app. OK, almost anyone. It takes a skilled developer to see the right way to buld the app so that it fits in nicely with the existing apps and services in the organization.

For instance, if a new app is built that needs to make a copy of the accounting data in order to function as built, then it's bound to fail. Or worse, cost excessive manpower to make sure that it's always kept in sync with the real repository of the accounting data. Making copies of critical data is almost always a mistake. But if you don't know how it's stored (because you're new and don't take the time to learn) then you'll build something that has to have lots of scripts for copying, checking, back-filling, etc. all because you didn't learn before you built.

So today I had a visit from a new developer - been here a few weeks. We'll call him Skippy. Skippy wanted to have a new method put on a Java table object that is widely used in the organization: renameColumn(String, String). I pointed out that there already exists the method setColumnHeaders(int, String) that can rename the column header, but he pointed out that if he didn't know the column number, the setter wouldn't really help. Agreed, then use the method getColumnForHeader(String) to get the numerical column and then use that in the setter. Still no good, says Skippy. It's too long.

Too long? I pointed out that it was one line:

  setColumnHeaders(getColumnForHeader("old"), "new");

and he said that even that was not as clear and concise as the rename method he proposed. I agreed that the 20 (or so) extra characters make the existing method invocation technically longer than the other, the point was really is this the best thing to be spending time on right now?

We are, after all, understaffed for the workload, which means that things are always getting rearranged on the priority list, and many are just not getting done. This means that we need to be very efficient with our time. While I don't disagree that adding convenience methods to classes makes them easier to use, my question is does this addition benefit the users in a material way? And to that question, I am fairly confident, the answer is 'No'.

Now I'm trying to put this in as non-confrontational a manner as possible, but Skippy is still being quite insistent that this change is significant and warranted. I'm trying to tell him that it's not an issue of the individual change, it's about a balance of the workload and the cost/benefits of each thing that we do. I can see his eyes glaze over... his head turns away... and I know I've lost him. I say as much and we're done.

Later, as I try to use an example of something I had done for him the day before to show him that I'm not against his ideas just because they aren't mine, he told me that he was adding the method in his project. As further evidence of his thoroughness, the feature I added for him wasn't going to be used because he hadn't checked with the Team Lead beforehand, and when he told the Team Lead about it, he directed him to do it another way entirely. Effectively wasting my time the day before because he hadn't learned what was needed. He acted on what he thought was needed.

Rock Stars - more hassle than they are ever worth.

Today has been a bit of a slow day - the data is good, trades are flowing, things are really humming along - all of which makes for a slow day for me. Not a tragedy - I had time today to mess around a little with the CSS on the server editor. I had picked up the CSS for tabs from WebFX and the 'winclassic' version was as close to Windows as I could have hoped. The problem was, it used the Windows-defined colors for 3D objects, and while that's really nice on IE, it's a mess on Firefox as those aren't globally defined in Firefox like they are in IE. So I set out to clean up a few things and in the same way that the fonts were cleaned up a while back, by specifying the RGB components, I was able to get IE and Firefox to match exactly. Nice.

I'm sure that if I had the time, energy and interest, I could look at the CSS stuff and make something really spiffy. I've seen very nice scrolling tables in CSS, and lots of other stuff, so I know it's possible, it's just that this kind of fiddling is something I really hate to do. It reminds me of the time when coding Windows apps that you had to layout your GUI components in code - moving things over 5 pixels, saving, recompiling, testing... it got old very fast. Someone is going to make this processes with CSS faster, and when they do, it'll catch on a lot better than it has up to now.

Interestingly, Apple's stock took a hit from the Keynote. I know it wasn't earth-shaking stuff, but it's really interesting to see that perception is far more important than reality in the markets. People expected something wild... something very Steve, and what they got was a developer's conference keynote - talking about the upcoming OS features. I guess even The Steve needs to watch out for his own distortion field... if he doesn't have the batteries freshly charged he can get himself into trouble.

This morning has been a very hectic morning. Some new instruments were traded and they weren't feeding properly into one of my systems so while I was trying to handle the production problem of halting the trades and manually amending positions, I was also trying to find the place in the code where I could augment the search symbology so that the instruments would feed. That, on top of trying to make an app that I didn't write a little more visually obvious that one of the instruments you have up you are not permissioned for from the exchanges. I got the guts of the fee-liable blocking done, but the app wasn't being a visually clear as the project manager wanted.

What a morning, indeed.

The second app had to wait as I feverishly tried to get things in production straightened out. Trades were backing up, things weren't looking good. Lots of stress if I have to restart the server... not fun. Amazingly, when the trades were pulled from the retry list and the positions manually updated, and the trade feed restarted, things started to work. This was major lucky break. With this, I had time to work on the solution. It took me another half hour to code the solution, test it in the development environment and then get it ready to deploy, but I had breathing room. The fix is a simple fall-back one - if the original symbology isn't found, try this other kind and see if it's there. It works cleanly without breaking anything else and it just plain works.

Once that was done I could focus my attention to the app with the visual issue. I'm not a big fan of Win32/MFC GUIs, and certainly when I didn't write them in the first place. Comments in this app date it to 1998 - that's almost a decade old, and the code shows it. There are a few comments, but not many. Trying to get things figured out is a process of tracing the logic through different libraries, different directories, it's a mess. But in the end I was able to get what I think the users will find reasonable. We'll have to see.

Most importantly, I'm out of the woods and things have calmed down. That's a major relief.

These past few days have been very up-and-down for me. Typically, that means I'm getting closed to burn-out as my tolerance for idiots is at a low point and they effect me more than usual. OK, that's harsh, but it's not that far from the truth. Today I had to dig into code that I told the management was a mess from before Y2K, and hasn't gotten any better with age. It may have been sleek and nicely designed at one time (for a Windows app) but now it's just a mess. There's too much business logic in the GUI and there's no clear pattern for the design. What part is doing what? Where's the documentation? All these are good questions that go completely unanswered. This makes for long, stressful, days. But it's a job.

Summer Time is here for the kids... today was the last (half) day of school and that means that they'll be doing a lot more things - running here, going to Band practice, Karate, etc. It's a hectic time and it's always nice when they go back to school in the Fall. But for now, it's time to enjoy the first few days of Summer and have a few cook-outs. Maybe a good burger with a slab of onion will pick up my spirits...

It's for sure, I need to find something.

Oh... MarsEdit's ability to include these images is amazing. I just can't believe how easy they have made it to include a little picture with a blog entry. I've been slapping them on the last few, and I really like the look of this. This is way better than my own on-line Journal... WordPress and MarsEdit are pretty impressive.

Today I saw a chunk of code that was checked in and had a very hard time understanding exactly what it was doing. The comments didn't really help, and the variable names weren't a lot of help either. I actually had to walk through the code a line at a time to understand what it was doing. Now I'm no paragon of design and coding virtue, but there's a point where you really need to hold yourself - and the folks you work with, to some bare minimum standards in this area. A 20-line method in Java should not take someone to walk through the code to understand what it's doing. I read Kernighan's quote: Debugging is twice as hard as writing the program, so if you write the program as cleverly as you can, by definition, you won't be clever enough to debug it. and agree with it 100%. The extension of that might be: If you have trouble understanding what you just wrote, the other guy, six months from now, will have to re-write it.

So I figured out the code and started cleaning it up. It didn't need the functionality changed, that was fine. It was the variable names and the flow, and more than anything, the lack of comments saying what was going on and why. I know these are things that aren't popular with a lot of developers, but they make the job of maintenance and extension a lot easier. It also won't hurt to spend just 15 or 20 minutes looking at what you need and trying to see if there's a better way than your first cut. Don't spend the entire day, but spend a little bit of time to make sure that you're putting down something that the next guy will be able to pick up easily.

I'm as excitable as the next person. I get whipped up about a lot of things. Development languages are not among them, and I have to wonder at professionals that call themselves developers that do. I was talking to someone the other day and they wanted to add a Java 5-ism to the existing library that was 1.4.2. I said that there are lots of projects that use this, and many are 1.4.2 still and may not change for a long time - if at all. If they work, there's no reason to update them. They might be updated at some point in the future, but this one feature that was being discussed was certainly not a business-justifiable reason.

But that wasn't the end of it. I had to ask this person "Why?" The answer was exactly what I expected: they wanted to type in three lines instead of the existing way of using indexes which might take six lines. So we're talking about saving three lines each time we run through a certain object's elements, and this is the reason for updating working projects? I think not, and I'm be stunned if the users thought so, either. I have met many Java Evangelists, and it's not just that they know, and promote, the newest features of the language, they condemn those that might say they follow the faith, but don't push as hard as they personally do. For instance, if you're developing in Java, you almost have to consistently push to the latest version or you're "outdated", and therefore "don't get it". Still using Enumerators? You just don't get it. Like we're all still coding in COBOL, for instance. I mean it's silly.

If you ask someone coding in C++ they aren't going to ask you the version of the compiler you're using. They may ask you about the features you're using, but not the compiler tricks. Yet that's just what these Java zealots are doing. If you're not on the latest and greatest - and using the latest and greatest, then you might as well be coding in Visual Basic.

What's funny is that many of these people probably haven't spent a lot of time with different languages. They might have learned Java in school - if they took a class in programming there, and they think that's all there is. But I know differently. I watched the industry move from big iron to PCs. And then with PCs to networked apps. Then to Windows. Then to Web. I know Java is not the final language - it's the current language for a lot of people, but it's not the end-all-be-all, any more than COBOL or FORTRAN were. Don't get me wrong, it's a nice language, and it's got some nice features, but not everything is a nail, so you need more than a single hammer.

Yet you'll never be able to tell these people that they are missing the point. That a language is just that - a language. It's a tool for expressing what you want a machine to do for you. Maybe the most expressive way is with Java - maybe not. Maybe the difference in the expressiveness of Java 5 to 1.4.2 is big enough to warrant a move. Maybe not. The fact is there are no universal truths in development. There's a lot of professional development still being done in FORTRAN. That doesn't make it any less useful or usable. It's a set of tools. But I got tired of tilting at windmills and walked away.

I spent time today speeding up one of the tools I deliver that is a support web system for one of my major applications. It's a perl CGI app, and there were a lot of things that it was doing that were inefficient. For a single page I was grepping the same file four times for four different sets of data. When I realized that I could grep for any one of the four conditions and then separate it out in the perl to the four cases, it made it use more memory, but was much faster. Typical trade-off: memory for speed, and I wanted to move it as much to the "memory" as possible to get the speed up.

Then I thought that it was possible that there were sections of the web page for certain instruments that some folks don't really look at. If I made those optional, with a checkbox to maintain the state of whether or not to do them, then I could get even more speed out of the system. Nice.

It's nothing that's earth-shaking... but it's nice to get the support guys the best tools I can as they make the app look good.

I was chatting with a friend of mine this morning and he told me that the unix admins at his place unilaterally decided to place machines on a weekly reboot list rather than figure out a problem with the automounter. While I understand the need for triage, and dealing with a production problem in the short-term different than the long-term, it's sad to see highly-paid unix admins stopping with the short-term fix ("reboot it!") when the real solution may be difficult to find, but the right thing to do.

I had a recent run-in with a unix admin in the Far East who thought that I needed to logout each night because excessively long logins consume inodes that aren't returned to the system except on logout. This was filling up the /var partitiion on a box. Now, I'm no dummy... and while the /var partition might have been full, I can't imagine how the length of a login has anything to do with it. I can imagine processes that generate a lot of messages for /var/log/messages might be an issue, but that's got nothing to do with a single login.

It's these kinds of "excuses" that make it hard to defend my industry and career to others not in this industry. I'm sure these kinds of folks are everywhere - Dilbert has legions of fans that claim that the same thing was happening to them just the other day. But there's a pride in your profession that it's hard to maintain when you realize that your profession is really no better than Dilbert's.

I'm sure there must be hundreds of Dilbert strips about this one fact - the people you work with need to be treated as totally independent from the work that you do. There's no two ways about it. If you confuse the two, most often times, you're going to pay for it. And unfortunately, it goes both ways... think your boss is your friend? He probably is... until the budget cuts come and he has to make the tough decisions. Think your boss is your mortal enemy? He might be... but it's your work that makes him look good. So either way, it's important to remember that the work is what you do, and the people are just those that you share space with.

This came up in the recent days for me when a friend talked about the grief he was getting from the folks he worked around. No two ways about it, these guys are not nice. I can remember dozens of times when I'd be in a work environment and find out that people found it funny that I was as passionate as I was about the work. So much so, that in one place, I found out they were taking bets as to who could get me upset about something the quickest. Nicely done, guys... Nicely done.

You can't control these people. If they are going to be insecure enough to see your passion and commitment to the work as a threat, and therefore have fun poking you in the side, well... there's really nothing you can do, and doing anything just makes them feel more important as they were able to draw your focus away from the task at hand. So you have to let them be exactly who they are. Maybe they'll grow up, but most likely not. Not your concern. Life goes on, and there are enough things to worry about that this doesn't need to be one of them.

Tonight I have releases of several components of a large app that I deliver, and since multiple pieces are changing, it's a good idea to make today a slow day so that I don't move the codebase in case something comes up regarding the releases.

I spent time helping track down a few issues... configuring a few boxes... doing my part to increase the Corporate Red Tape... all things that needed to be done, but have been put off as they aren't that important. But today was their day.