I’m a big fan of Jeff Atwood’s “Coding Horror” blog – and I’m certainly not alone in that respect! A recent entry “Sorting for humans” talks about how the default sorting algorithm that most programmers use for sorting text doesn’t lead to a “natural” sort order. When sorting Alpha-numeric entries, you end up with an apparently illogical jumbled order – where “z10″ appears after “z1″ but before “z2″.
Anyone who knows anything about ASCII charts (and Unicode ordering!) will recognise what’s going on. For those of you who don’t, have a look at Wikipedia’s entry on ASCII character encoding.
I read through the comments on this particular blog entry, expecting to find some clever ideas for “natural sorting” algorithms. – At this point in time, I don’t need one, call it part of my “Professional Development“. Whilst there were a few implementations with good ideas, the thing that struck me were comments like this:
I’m sorry, but I don’t agree. Let’s call it alphanumerical.
z100 should always go BEFORE z2, the same way that table goes before tar.
Also, anyone naming their files *name*-*number* and not putting in the extra digits should not order by name, but by date.
And I take offense at Kate Rhodes’ comments. It’s yet another case of stupid users.
This admittedly, was the harshest comment I saw and you’ll be pleased to note that there were other commenters politely suggesting that an attitude adjustment may be in order. But the sentiment (that the “strange” ordering was correct) was echoed several times by other commenters. I’m not saying there weren’t valid points listed in their objections – some commenters noted that Internationalisation (I18n) made the task of natural sorting more difficult. What I am saying is it’s not good enough to justify your approach and think the matter is resolved.
I’ve programmed for long enough to remember times when I thought differently to users. – I still do at times. I also know that I can be a persuasive arguer. Programmers using their logic skills can be like that… But, no matter how logical or compelling my argument is, if it’s not what the user was expecting, it’s called “a bug”. If (or when) this happens to you, swallow your pride and alter the program. Either make it behave the way people are expecting it to, or make it such that users are expecting it to behave the way it does.
After I left university and started work as a support engineer, I found myself living in share accommodation with a civil engineer. I remember thinking to myself: “I’m glad I’m not him. His profession dictates that he must constantly study to remain qualified.” It’s fair to say at that stage in my life, I wasn’t the most conscientious of students.
I can’t quite fathom why I thought that I would never need to learn anything more about computing. Did I honestly think the computing field was sitting still? Moore’s Law had been around for over twenty-five years and I had witnessed it first hand. But somehow, I hadn’t quite made the logical jump in conclusion that the skills I’d learnt in university would become out-dated…
These days, I take my own professional development quite seriously. My day job doesn’t see me needing most of the skills I’m currently learning. As a developer it is a constant struggle to stay abreast with current technologies. Chances are, if you are developing a commercially successful application, you are committing a lot of your effort to maintaining a legacy code-base that (at best) was developed with the technology that was prevalent at the time the initial version of your application was written. At times in my career I have suffered from this myself, and witnessed others do likewise. This has led me to the conclusion: The longer your software product remains a success, the more your programming career will suffer. But, you can do something about it: “Professional Development”.
Chances are, if you are a software developer reading blogs about programming, then you already know the benefits of Professional Development and actively do “PD” yourself. But, if you’re only half-way (i.e. reading blogs but not doing the “PD” thing) here are a couple of guidelines.
- Keep it fun. Work is the serious bit. – If that were fun, they wouldn’t have to pay you*. If you get bogged down trying to nut something out, chances are you will give up on the project and learn very little. If you can think of something you’d like to do, rather than something that could be considered “important”, the pressure to succeed will be less, but the motivation to will be more.
- Set aside some regular time. – I use the time I spend commuting on the train for the vast bulk of my PD time. It’s consistent and neatly fills in time I’ve already committed to spending, getting from A to B. Apart from making your PD a habit, if you share your life with a partner / family then they can respect your need for “quiet solace” as you study…
- Don’t go it alone. – If you can, join an open-source project such that your skills can be honed by other professionals. Of course, this infers that you can find an open-source project that appeals to you and only requires the amount of time you can afford to spend. This point is one of those: “Do as I say, not as I do” type edicts…
One important thing to remember though: Chances are, you signed an “Intellectual Property Agreement” of some sorts when joining your employer. If you’re thinking about writing your “Get Rich Quick!” application for your PD project, you may want to make sure you are not violating your agreement…
* I’m sure I got this from a Scott Adams’ “Dilbert” book… But I couldn’t find it, so I can’t give you a proper reference.