One element of the modern web development movement that has long bothered me is to see how it ignores long established software development principles. Some act as though the only way to be “modern” and use modern technologies is to throw out the old and come up with all new. While development languages might improve, and we certainly learn new things over time, I don’t believe that these important software development principles, that have been figured out over years from trial and error, even from extreme failure, suddenly become invalid because of new technology developments.

The implementation of these principles may need to change, but never the underlying principle. Sadly, I would estimate that a majority of those calling themselves “developers” today don’t know the first thing about development. They have studied a language, whether it’s Rails, PHP, whatever, and they have learned it well enough to develop an average application that works. But without learning important software patterns and processes of development, all their skills with a particular language are built on a very shaky foundation. One that crumbles underneath the weight of a full size, heavily used application, and one that deteriorates over years of iterations on the same software code base.

Most developers today have never maintained the same application for years and have no concern in ensuring they can. They build it to get it out the door and get it online. They get paid. They close out with the client, and they move on. I see these apps on a regular basis and I have to fix them. Sadly, it’s usually at considerable expense to the owner, often having to start from scratch because the application’s fondation was so poorly constructed.

It’s far more important to understand these basic software engineering principles than it is to “master” a language. It’s great to think “outside the box”, but never just for the sake of doing it, or for the sake of being the person who came up with a great new concept. Solve problems that still exist, don’t solve problems again and again that already have a sound, established solution. Learn from others, particularly those who have more experience than you. Find out why senior developers work a certain why. Don’t assume that because they are “senior” their ways are the old, outdated ways, to be ignored and replaced. Sound principles and wisdom based on experience never lose their value.

As I transition from full time employment to being fully self-employed (starting in September), I’ve had the wonderful opportunity to talk with a number of potential clients from all industries, with all types of past experiences and varied budgets. In the last month alone, I’ve talked with over 20 different companies. During these talks I’ve learned one major thing that surprised me. I suppose because I’ve been working for individual companies for so long I didn’t realize there were so many misconceptions about developers, web development, and productivity out there in the business world.

Read More »

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“.

Or at least that is what Money magazine claims. I’m not sure I agree with their ratings in each of the categories.

Low Stress?
I suppose compared to being shot at, or having someone’s life in your hands it’s low stress, but I’ve experienced plenty of stressful situations in my career, including going through two mass layoffs (both of which I escaped without job loss, but not without stress), countless overtime hours, ridiculously imposed deadlines, outrageous client demands, writing software that is vital to a company’s daily success where one bug can bring it to its knees, poor Project Management (ie. micro-management), and constant shifting skill sets required to maintain “hirability”.

Flexibility
I don’t know what they mean by flexibility. I see they say, “Telecommuting is quickly becoming widespread.” However, I have found extreme resistance to telecommuting. Ten years ago I thought by now most Software Engineers would have the option to work from home. But old habits die hard, and human psychology changes much slower than technology does. While countless studies have shown that working from home improves productivity and reduces employee stress, many old school managers are still resistant to it, and somehow feel you aren’t working if they can’t see you in front of your computer in your cube. Thankfully, I’m currently enjoying telecommuting, and as long as it lasts, I plan to stay on my current contract. I have as flexible hours as I could want, so for me, right now, yes flexibility is a benefit. But, from past experience, and hearing from others in the field, I’m surprised a study would show this to be a strength.

Creativity
This category has been one of my biggest complaints over the years. It really depends on your management. In many environments you are told exactly what to do, how to do it, and when to have it done by. That doesn’t leave much room for creativity. I have had the good fortune to be on some projects, including my two year project at IBM, that gave me great freedom for creativity. But I have also had many projects where I was completely constrained to follow antiquated architectures, development methodologies, and project management styles, that squashed any hope of thinking creatively and allow for problem solving. Tip for IT managers: Software Engineers will work harder and with more passion if given the chance to be creative!

Ease of Entry
So on this category they give it the worst grade and yet this is the one category I’d give an A to. Why you ask? No, not because I think its an easy to skill set to pick up, but because IT managers seem to think it is, and hire just about anybody. They either hire because someone memorized an API (but can’t use the API, learn on their own, problem solve, etc), or because they seem to have great potential (aka. they came cheap). This field should be a lot harder to get into than it currently is.

I thoroughly enjoy my job, when I’m on the right project, but I’m not sure the grades from MONEY magazine are accurate, but this is what so any are told in high school, so its no surprise that seemingly millions and millions get into this field every day.