GTK+, XML, XUL, HTML, MFC, VB, SQL, UNIX, Windows, VIM, PHP, CSS, C, C++, Ruby, Perl, Assembly, the list goes on and on and on. I’ve dabbled in various technologies throughout my career as a programmer. I actually learned programming logic in my TI-85. From there I started in on PHP with MySQL and Apache as the backend. Why, you’re asking now, do you care?

I just finished reading an excellent article at Joel on Software about how becoming completely proficient in a coding environment is taking longer and longer. I can agree with this. I’ve been programming complex PHP/MySQL applications for over 3 years now and I’m only recently beginning to realize how truly scalable and complex applications are built within this environment.

Joel points out that more and more of the memorization is in how to utilize the various API’s programmed in the language, not the actual language. Since I’ve built an extensive library of code in PHP and utilize other libraries written in PHP, most notably PEAR, I can agree with this.

Joel also makes a great point that learning a language is compounded by the fact that you must also learn that languages environment. PHP’s main environment is UNIX, thus you need to know that Apache barfs on missing directories or that certain shell commands require environment variables to be set properly before they will execute. You need to know how tr, sort, uniq, STDIN, and STDOUT work. If you don’t understand bitmasks and permissions you’re going to spend days figuring out why you can’t write and read files and when you DO figure out how to manipulate permissions you’ll most likely just chmod 777 because it works without any regards to security.

The outline above has largely deterred me from expanding my horizons into new languages. Sure I can hack Perl and I know how to use Visual Basic, but am I proficient? Hardly. Anyone who has looked at any of the open source PHP projects lately will agree with me on this one.

I’m the first to admit that I don’t think about User Interface design. In fact, I’m of the mantra that everyone should be as technically savvy as I am. This changed recently when I worked with a newly hired UI person at Care2. A lot of the stuff that seemed like annoying “features” made a lot of sense in the terms she used.

This experience has led me to search around the web for articles on UI techniques. I found an excellent article at Joel on Software called User Interface Design for Programmers. This is the best hands on article I’ve seen so far. Here is a brief overview for those too busy to read the entire article:

1. A user interface is well-designed when the program behaves exactly how the user thought it would.

   If you think about it this makes a whole lot of sense. If you can learn one thing from this article this is it. Users get frustrated when they encounter programs that don’t perform the way the expect them too. This is why Windows users hate Macs and vice versus, because the UI doesn’t perform the way they are used to UI’s performing.

2. Every time you provide an option, you’re asking the user to make a decision.

   Programmers love to make extremely flexible programs. The author makes a good point about providing options: Most users do not change the default settings and when they do there is no propagation of those changes in settings. This means even if user does change their settings they have to make those same changes on every computer they use.

3. Good computer UI uses affordances

   Simply put make your controls appear to be controls. Doors have large bars that afford to be pushed. You should make the buttons and text on your site afford to be pushed.

4. Users don’t have the manual, and if they did, they wouldn’t read it.

   This is very important for everyone to remember. How many user manuals have you read? I can honestly say I’ve read none. I’ve read tech books, etc., but I have not read a user manual per se. Your program should work as expected and with very little effort on the user’s part.

The articles is much more in depth with perfect real world examples. There are lots of big pictures as well. The article is overall thoughtful and well written. If you program applications for a living this is a must read.

As a programmer the bane of my existence is the dreaded bug. As a PHP coder what I despise most are people who submit inadequate bugs. At my previous place of employment there was very little buffer between the enduser and the coders. The channel tended to be enduser -> support personnel -> either a.) my boss or b.) me. My former boss, bless his heart, did all he could to shield myself and others from the onslaught of dupes, etc.

The worst part was that there was absolutely no buffer between the dev team and those who worked in the office. This meant that the dev team would regularily get bugs like this: “Login not working!” Really? We have 10’ish domains all with separate login scripts. What browser were you using? What OS? What username did you try? Have you logged in successfully before? After much back and forth you could possibly fill out half of the required material in your average Bugzilla bug posting. After many failed attempts to teach the team how to correctly report a bug and a few ignored requests to either build or implement a bug tracking system, I gave up.

At my new place of employment I’m one of two developers. The bosses give us a lot of range in developing various technology policies. These two facts have lead me to develop a new system called “Bugger.” It’s not an amazing piece of software, but it’s tailored to my liking and specific to web programming. With a little tweaking of my php.ini file I can have users and or employees easily submit bugs that have all the info I could want (Browser, URI, etc.).

My only complaint about it is that I won’t be able to release it. I was paid to create it so it is property of the company I work for. I could probably make the case that we should open up the source, but I should probably make sure it’s complete first.

I’m a coder. I have endusers – roughly 2 million of them. Do I think about them when I code? No, we pay an outstanding and invaluable person to do that – I incorporate her changes as I go along. I usually don’t question her changes because she’s the expert when it comes to UI and enduser experience. I just ran accross this thread from a KDE developer responding to this article from an endusers point of view.

Here’s a few choice quotes: “She raises many interesting points although I don’t think all recommendations
are that great. (Auto-disapearing menu-options? *yuck*) On the bright side,
we can pick the ones we do like :-)” and “I really wonder whether we should
waste CPU cycles on making the zooming more smooth.” The first one is just dumb – if enough users want it to justify coding it then do it and put it in the control panel for people to turn on/off as they please. The second one isn’t something I deal with often because I code applications for the web (therefore everything should be blazingly fast and we can’t program stuff that will bork our servers). On the desktop side of things it should be up to the user if they want to waste CPU cycles (afterall it’s the enduser’s CPU cycles not the developer’s that get wasted). This is another thing, if justified by enduser’s desires, should be added as an option to be turned off/on at will. This topic is a HUGE beef I have with OSS developers and one I’m guilt of as well.

As many of you know programmers sometimes get bored and program little nuggets of fun into their programs to amuse themselves. Recently, I stumbled upon this site that aims to be an online archive of easter eggs. Not only does it have computer ones (ie. BeOS’s kernel has functions called “is_computer_on()” and “is_computer_on_fire()”), but also movies, tv shows, etc.