Switching from web to desktop application development

Switching jobs and making a career change is a big challenge. New problem domains to learn, new working relationships to build, new brand of instant coffee to get used to. For a programmer one of the more interesting changes can be moving from working on web applications to desktop applications. Here are a few points that i've picked up having made the plunge a few months ago.

  • Control of environment. As a web programmer you have a lot of control of the environment your application runs in. Browser issues aside, once a HTTP request hits your servers you have complete control over what happens next. A desktop application has little control over where it is being run, what software is installed with it etc.
  • Managing performance. A desktop application performing poorly can be a nightmare to diagnose. The characteristics of the users machine and currently running processes are completly foreign. If your web app is running slowly you not only have the program available but intimate knowledge of the hardware and architecture it is running on. You can make tradeoffs on the servers that your users may not be willing to do for your desktop application.
  • 24/7 operations. Most web developers will not only have to create the application, but support it as well. These problems that occur on live systems are usually given high priority pushing more long term work to the back.

I had no idea how narrow my knowledge was. I'd be interested to hear your thoughts. Have you made the switch from web to desktop, or in the other direction?

Posted by Lang Sharpe
Mon, 26 Jul 2010 21:20:53 GMT

My Widescreen Desktop

This is how I organize my widescreen desktop.

My Desktop, with the taskbar on the left hand side.

The main feature is moving the taskbar over to the left hand side. When editing code or reading a website I would rather have more space vertically. It is also easier to select a window when you have a lot open. The Quick Launch toolbar is more useful, because you can have a lot more shortcuts without taking away taskbar space.

Posted by Lang Sharpe
Tue, 01 Jun 2010 11:00:00 GMT

How to be a programmer - circa 2002

While looking through some old files I found this gem. It's an essay written seven years ago by Robert L. Read called "How To Be a Programmer: A Short, Comprehensive, and Personal Summary". It covers a what the writer feels are the most important skills to learn across beginner, intermediate and advanced skill levels.

I remember being heavily influenced by this as it appeared a short time after I first had a real job. seven years is a long time in technology and I was wondering if the advice in it held up. Here are a few excerpts.

2.9 How to Deal with Intermittent Bugs
The intermittent bug has to obey the same laws of logic everything else does. What makes it hard is that it occurs only under unknown conditions. Try to record the circumstances under which it does occur, so that you can guess at what the variability really is. … Try, try, try to reproduce it. If you can't reproduce it, set a trap for it by building a logging system, a special one if you have to, that can log what you guess is what you need when it really occurs.

When I first read this many years ago I was relieved. It's not just me that has these problems. I've used this formula too many times to count.

6.7 How to Know When to Apply Fancy Computer Science
There is a body of knowledge about algorithms, data structures, mathematics, and other gee-whiz stuff that most programmers know about but rarely use. In practice, this wonderful stuff is too complicated and generally unnecessary.

It's the biggest contradiction in our industry that a lot of importance is placed on solutions to complicated problems when most of the time simple solutions to simple problems are needed (and more desirable).

4.1 How to Stay Motivated
It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. … There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end fun will make the most money for the company.

I'm not sure where I stand on this one. As much as I'd like to believe that fun is always the way to go I'm not sure that it will always pay the bills.

Overall it is still a relevant and important essay for any programmer at any level.

Posted by Lang Sharpe
Wed, 30 Dec 2009 09:00:58 GMT