Programmer burnout

February 9th, 2003 Comments Off on Programmer burnout

Some days ago, James Robertson briefly commented on programmer burnout resulting from the improper choice of technology in projects — in that specific case, Visual C.

Although I never experienced such level of stress, I can easily identify myself with those programmers’ predicament. In some days, the frustration that comes from using flawed technology in my daily job is almost as maddening.

I work in a Windows-only shop, which means the chosen platform for most applications is an ASP + SQL Server combo. To be fair, this choice is in part dictated by the Brazilian market conditions. Almost all companies working with technology here use the same technologies, and the prevalent mentality is that nobody was ever fired for opting to use Microsoft products. Nonetheless, knowing this does little to mitigate my frustration.

In my particular case, part of the problem is that I got spoiled. In my previous job, I was in charge of choosing the company’s technological direction. I have always been a Borland fan, and the obvious decision was to use Delphi. So, in the three years I spent there, I used it for almost all majors projects. The few exceptions were some virtual stores done with Microsoft’s Site Server Commerce Edition — an experience I hope I can forget someday.

Delphi is both a mature environment and a powerful language. I’ve been using it since its first release, and now I have little patience with inferior solutions. At the time, I developed a lot of object-oriented libraries for various common tasks, especially those related to the applications’ data layer. That libraries ranged from simple units comprising lightweight classes for database access to complex frameworks dealing with every aspect of an application including automatic SQL generation, XML serialization, and user interface modularization using XSLT transformations.

After that kind of experience, ASP is a step back. Grouping functions in some include files is the best you can do in ASP projects to achieve some kind of isolation between the application tiers. Of course, you can use COM objects, but they are pretty limited, and — however incredible this may sound — some clients actually forbid companies from installing COM libraries in their servers. If a company can manage to persuade its clients, the libraries usually must be developed in Visual Basic, which is not so far from ASP.

Obviously, all those facts imply in longer development cycles. Still so, most companies keep trying to deliver their products in unrealistic time frames. That imbalance is what causes the referred burnout. Especially because programmers know that things can be done in a better way. As the delivery date approaches, the stress level is guaranteed to shoot through the roof.

The obvious options to solve the problem in the programmers’ side, which is trying to change the corporate culture, is an inglorious effort that will certainly result in more frustration and stress, and has few chances to succeed. With respect to the companies themselves, the corporate inertia that denies every possibility of finding effective solutions is proportional to the size of the company multiplied by its Dilbert coefficient.

So, I fear to say that there’s no simple solution. Ironically, the market itself is responsible for blinding companies to the losses that result from continuing in that suicidal path. Companies that go under when programmers finally get so fed up with mismanagement that they leave are pretty common. The case Robertson cites in which the company realized its mistakes and started searching for solutions is exceedingly rare. So, I believe programmers must find their own defense mechanisms to avoid getting burned out. After all, I’m just stating the obvious when I say that there’s no point in wearing yourself out because others are failing to realize their errors.

Comments are closed.

What's this?

You are currently reading Programmer burnout at Reflective Surface.

meta