Sunday, February 24, 2008

A Moment of Frustration

"Software is a place where dreams are planted and nightmares harvested, an abstract, mystical swamp where terrible demons compete with magical panaceas, a world of werewolves and silver bullets." -Brad J. Cox
There are many schools of thought about how to go about programming. We call them things like Object Oriented, Dynamic, Functional, Pragmatic, and Agile. Eric S. Raymond has written eloquently about one of these, which he refers to as the Unix Philosophy. I've spent my few years as a professional programmer wishing I could work on a project that followed the tenants Raymond sets forth. These guidelines appeal to me. They encapsulate a type of openness, brevity, simplicity, and interoperability that match with the kind of creations I want to generate. And that makes total sense when you think about it: I'm a programmer, and the Unix Philosophy comes from a culture of programmers. Unfortunatly, real life has a tendency to get in the way.

"With any creative activity come dreary hours of tedious, painstaking labor, and programming is no exception." -Frederick P. Brooks Jr. "The Tar Pit" (essay collected in The Mythical Man Month)
One of the quiet frustrations of being a working programmer is that you are almost never free to follow your own coding styles and methodologies. Legacy systems must be maintained and enhanced. Customers and management want their software developed cheaper and faster. Security and performance concerns necessitate inelegant solutions. Regulations and external interfaces can be labyrinthine. There are very good reasons for keeping programming patterns homogeneous within your team, department, and even company. But just as some comic strip artists feel constrained by the standardized newspaper format, some programmers feel constrained by external forces. Turns out I'm one of those. Perhaps you will find that you are too.

"No matter what the problem is, it's always a people problem." -Gerald M. Weinberg
Don't be too alarmed yet. Programming is all about working within constraints. Programmers juggle memory footprints, processor time, network bandwidth, and external resource availability all the time. Handling a little difference in philosophy should be no problem, right? Unfortunately, it depends. Problems with politics, philosophy, and team chemistry can't be solved using the same approaches that solve programming problems. People aren't ever entirely rational. Sometimes, you will face moments in your professional career when you have to decide if you can live with the frustrations, conform to the external expectations, or if it is time to move on. What you move on to could be a different team, a different company, or a different career altogether.

"When you find yourself perpetually angered by little questions in your professional life, perhaps the problem is some big question you answered wrong earlier." -Gerald M. Weinberg Understanding the Professional Programmer

How we face those moments defines a large chunk of our lives. You should put in the work to figure out what makes you happy before you get stuck in a quicksand of frustration. It will pay off in the long run by allowing you to stay sane. And it really isn't all that hard to do. After all, if there's one thing us programmer can do, it's identify patterns. It helps that we aren't the first ones to face the insanity that is inherent to the job. You may notice professional programmers tend toward a wry sense of humor. There's a reason for that.

"while(true) keep programming" -Assaad Chalhoub


Gerald M. Weinberg said...

Lovely essay, Brian. We need more like this, addressing the emotional aspects of programming. In my experience, way more programmers fail because of reacting badly to these frustrations than fail because of inadequate brainpower. Maybe what we need is more emotional intelligence and fewer smarty-smarts.

Brian said...

Why, thank you. I find it somewhat ironic, given the typical stereotype of the programmer, that once you get past the mechanical aspects of writing code, things become much more about feelings and emotions. Team chemistry, customer satisfaction, usability, and aesthetics (UI or code) have more to do with psychology than they do with engineering. And that stuff didn't show up in any computer programming class I ever took. I wonder how big the market would be for "Zen and the Art of C++ Legacy Code Base Maintenance?"

Gerald M. Weinberg said...

Actually, Brian, I think Zen is exactly what you need for C++ Legacy Code Base Maintenance.

And perhaps some proud relative might buy copy to show off to their friends.