Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.

We are all used to seeing the traditional UML class diagram, and while quite boring aesthetically, it still serves its purpose (if you can keep it updated). But, for some fun and an interestingly new visual perspective, try the Relief 3d model view of your application. It only takes a few minutes to setup.

All you need is a JRE version 1.5 and up, the Java3d library, the Relief jar, and the project description.

The project description takes the most amount of time because you must list all dependencies of your project. You also have to properly set the jrePath and the basedir path. Once you’ve done this, and saved the project.xml into the Relief directory where you unzipped it, you can start the 3d model viewer with this command:

java -jar relief.jar projects.xml

When the view comes up there are different options. You can zoom in and out, rotate in 3d, double click on a class opening a new window to isolate it.

Hmm. According to Ajaxian, there are approximately 210 Ajax frameworks available. Is that really enough? Come on, let’s at least have one for each day of the year.

Now my question is, do you have to know all 210 in order to get a job as an Ajax developer?

Read 210 Ajax Frameworks and Counting.

If you love Firefox as much as I do, you may find this list of 15 ways to improve firefox, including increasing performance and decreasing memory usage (a big issue for me on my work laptop). And if you don’t use Firefox, it’s time to start!
Read the 15 Coolest Firefox Tricks Ever.

Here is the first of four videos produced by Jason Hawkins, using the style of the famous Mac vs PC ads to humorously, and dare I say, oh so accurately, compare Rails to Java.

Note: Ok, its not completely accurate. If it were, there would be another tray full of jars stacked on top of the existing one, supported by the first layers of jars, such that if one were removed the entire stack would collapse.