Good Shoes and Microsoft Outlook

I think I've found my favorite pair of shoes in the latest black slip-on Florsheim shoes that my wife picked up for me a few weeks ago. At this point they are still not broken in and rub my ankles raw if I have them on for any length of time, based on past experience I'd estimate I have a good 4 weeks before they are "comfortable" enough that my feet won't hurt after wearing them. So you may be asking yourself, why is this guy think these new shoes are so great? Because they look awesome, mind you I'm not saying they make ME look awesome. They are simple with clean lines, they have a nice shine, and I really like the way they look. The reason I like the way they look is because I like anything that has a minimalist feel. I enjoy pieces that don't attempt to look good by having tons of extra "stuff" that just isn't needed. This is also something I've found very appealing in the UI for the 2010 version of Microsoft Outlook. In particular to be able to shape the UI so that you only need what is necessary while performing various tasks.

Below are the two views I switch back and forth between while using Microsoft Outlook. Since using e-mail at work is synonymous with breathing it goes without saying that I spend a substantial amount of time using outlook; however, I would guess (meaning I haven't done any actual measurement/testing) that I spend far less time looking at my e-mail. The reason I believe this to be true is because I do not fear my inbox. It is NOT a source of stress for me.

Default view with menus expanded

Reading view with menus collapsed

One way I accomplish "conquering my inbox" is by switching to the "reading view" (as the name implies) when I need to focus on responding to messages. This view allows me to focus on reading my e-mail and responding as needed. When I to organize, archive, setup tasks, manage my calendar, etc. I switch to the default view. However as a rule I DO NOT leave outlook in the default view, so as to encourage focusing on messages as they arrive and not the other tasks as listed previously. This often results in my being able to read and absorb more information from my e-mails.

Just as with code, if the viewing area for displaying lines of code is larger you tend to get a better "overview" of what the code is attempting to do. The same holds true (at least in my case) of the reading pane in Outlook. If you can see more of the e-mail thread at one time you tend to absorb more of what has transpired, this is often helpful when you are looped into a discussion after it has been initiated.

Reading and default view in MS Outlook
To toggle between the two views there are two tiny icons located in the bottom right corner of the window next to the scale slider as depicted in the image here.

Don't leave your users hanging

command prompt can show actions as they are taken
If you create software one of the worst experiences you can create for your users is the "hanging" dialog. Recently I obtained a somewhat older MP3 player; to be specific it is a SanDisk Sansa Express 2GB. The device itself is on pair with most MP3 players that are not an iPod. One interesting feature is that you can record from the radio and it just so happen that the weekend past I had a need to record some audio from an FM station being used to broadcast at an assembly I was attending. To skip to the interesting point I found myself attempting to install new firmware to make it possible to listed to the WAV files created from the recording. After installing something to install something else (can you say inception) I found myself in a state of frustration because it "seemed" like the firmware update was going through just fine; however, the dialog box which indicates the progress had been "seemingly" stuck for quite a bit of time. So as any rational person would do I ignored all the warnings on the screen telling me NOT to remove the device while it is being updated, I yanked the cord out of the plug and started over, after turning my computer on and off again at least twice as any good technician will tell you is critical after just about any action you take. After attempting to install the firmware the "easy" way (using other software from the vendor) I again got "stuck" and gave up. At this point I believed I could overcome the problem by "manually" installing the firmware.

Sansa Updater dialog without any progress (in oh so many ways)
Sansa Express - SanDisk (c) 2006-2008
After jumping through the seemingly random steps of extracting the various ZIP files and installing different drivers and ensuring I held down the "volume down button" (a.k.a. -) while plugging in the device I managed to get back to the same install screen that had haunted me before. Oh, and somewhere along the way I had to format the drive to continue so I lost the file I was attempting to use in the first place.

While weaving through the various steps I realized that I may have cause myself a great deal of frustration simply because I was impatient, but is that really my fault? Well in some small way yes, after all patience is a virtue. However, I tend to think most of the blame rests with the software developers who created such an uninformative update process. If this had just been a command dialog via dos and they just listed of each file being impacted or perhaps a list of actions being taken I may have been more patient. Now to be fair this is a simple firmware update for a seemingly simply MP3 player and so the thought put into making sure a progress bar was accurately capturing the progress of the installation may have been a lower priority, but if there is nothing moving, no blinking indicator that something is still happening it is easy to expect that a user will abandon the cause and move on to something more shiny.

So don't leave your users hanging. Give them the ability to peer into the goings on and inform them of what to expect in terms of responsiveness.

UPDATE: After 10 minutes after writing this post I came across additional information that outlined that the underlying issue with updating the firmware was it had to be done using a windows XP machine. Fortunatlly I have an old laptop with the legacy OS (along with various versions of Ubuntu) so I was able to get everything working and update the firmware, I did mange to lose a recording that I didn't have a back-up of, but such is life.

Why we have to "Ask Why"

I'm always interested to find personality traits that seem to be common to "smart" people. When I use the term "smart" I don't mean to imply that they have some knowledge that is unattainable by others, also I don't mean to imply that they are more intelligent than the average person (although I suspect that if we were going off IQ that could be true). To be clear, I don't typically include myself in the "smart" category, I tend to think that I just happen to have a good memory which gives the impression of being smart, as well as being prone to asking the question why, which I have observed as being a trait of "smart" people.

When people passively accept information that is given them without asking the question why, the result is often that the person receiving the information winds up with only a cursory understanding of the subject matter. In some cases I would completely agree that the "right approach" is to only obtain the cursory overview so as to be able to quickly dive into whatever task prompted obtaining the needed information in the first place. However, it seems to be that too often this cursory understanding becomes the default level for most persons even after the use of the information becomes more critical. To put it another way, after a person gets the "minimum" information to accomplish a given task there is no further effort put into obtaining a better understanding of why "things work the way they do".

In a large enterprise (such as the one I spend my days currently) the end result of NOT asking why is that people go about their jobs doing completely unnecessary tasks simply because the default understanding is to "do it the way the person before me did it". I'll admit that this is probably easier in terms of the mental energy needed to have someone learn a set of tasks; however, I'd argue that anyone who has to complete a particular task repeatedly over the course of many months and perhaps years would benefit from a deeper understanding of what is attempting to be accomplished.

In the case of a developer the need to ask the question why, IMHO, is NOT optional. If you are a developer and you DO NOT ask "why" at least once a day there is a good chance that you are NOT a good developer. It is easy to fall into the snare of believing that getting a good requirement document means that the "why" question has already been asked and answered and you simply need to implement the technical aspects of the requirement; however, this is almost never the case (except perhaps in the most fundamental of features).

At every level of the development process all parties involved will be benefited by having a deeper understanding of asking the question why at each step along the way. In fact there is even a "method" called the 5 whys which shows how asking the question 5 successively (at least 5 times) will help to uncover the root cause. It would be good to note that as quoted by Jeff Atwood (of Coding Horror fame) if you ask why too many times the answer winds up "because there are people on the earth" which is a good indication that you may have dived too deep.

So if you are a developer don't forget to ask why, in fact in life in general it's probably a good idea to remember to ask why, just to keep things interesting.

Perspective and Puzzles

Reversible figures and vase. From Wikimedia Commons
I recently remembered a ted talk from a while back about optical illusions and how our eyes can be heavily influenced by the context of what they see, or as mentioned in the talk, "the light that hits our eyes is not what is important, rather it is what we do with the information once it hits our brain that matters." To help illustrate this point the image here shows a famous "illusion" in that depending on your perspective the black area is the silhouette of two faces, or the white area forms a vase, in reality both are true and it is a mater of perspective on which view is "correct". FYI, I believe depending on how my day is going one or the other is true. :)

I've also been rediscovering the fun I have playing Sudoku. It's interesting how organizing numbers into patterns according to rules fosters a sense of accomplishment. Probably informs my career choice of "professional geek" (a.k.a. programmer).

Sudoku Puzzle. From Wikimedia Commons
That's not to say that enjoying puzzle games and being a good programmer are inextricably linked, in fact I'd dare say that in some sense, being fascinated with solving puzzles can be a detriment to being a good programmer. For example, solving a sudoku puzzle requires a very strong adherence to the rules of the game so that you can "predictive" the combination of numbers in the correct sequence to solve the puzzle. This same strict adherence to the "rules" of programming will result in the idea that given a particular situation there is only one solution which will work; however, as has been proven time and time again in the world of software there are plenty of choices to solve any given problem and often the "right" choice is more influenced by perspective.

I often find that at one level a programmer is a plummer. You connect the pipes and/or tubes if you will. (You didn't know that the internet is a series of tubes?) Then turn on the information faucet and have the data flow from point a to point b and then it all goes down the drain. From this vantage point programming would seem like it's just a puzzle, if only all problems could be that simple. The reality is that the issue is not moving information through tubes, the issue is figuring out if you even have the right information in the first place.

This is where perspective comes into play. You have to be able to obtain the context of a problem and appreciate the subtle shades of gray that come into the black and white world of programming. Who are your users? What are their objectives? How do you want them to feel after they use your software? And a hundred other questions that even make me cringe when I think about attempting to answer these questions for all but the simplest of problems.

If you do figure out what the right "perspective" is then you can dive into the "fun stuff", where you get to enjoy the straightforward challenge of programming and relish the sense of "solving the puzzle, the right way".