The Art of the Stretch

Many things that contribute toward a successful software-development career have nothing to do with people skills or even with technical knowledge. A larger part of accomplishment than you imagine simply has to do with being comfortable with the physiology of an “office job.”

Essentially you sit in a chair a couple feet away from a screen with your hands on the mouse and keyboard all day. Folks euphemistically call this a “sedentary” job. Don’t think for a moment this implies that you lie in a hammock twirling a double mocha cappuccino.

Due to constantly changing tools and requirements the job is full of stress. Other stressful factors include too much work, frequent interruption, unclear or late information, career and job politics, and the pressure to outperform associates. Programming can feel as if you have five pots on the stove, the microwave whirring, and both ovens going, all while you are mincing onions.

So although the job is sedentary in the strictly physical sense it is far from stress-free. To really succeed you need to develop a strategy that fully mitigates this stress; here are some techniques I have used to good effect. First, why do you need to pile additional stress onto your work from commuting? When you drive your car to your job listen to something enjoyable or motivating. Or better yet ride public transportation to work and multitask your relaxed commute with some reading. When you do drive experiment a bit to discover which routes are the most scenic and least crowded.

Learn how to organize and plan at work. This mostly relieves stress by a process of self-education: once you get a good concept of how long things take you can also plan for your own personal slack time. Heck even back in school they allowed for “recess.” Pace yourself: avoid back-to-back scheduling and trying to fit too much into one single day.

List the things that you have to complete by priority; by accomplishing what is most important you will feel more serene. Don’t fret over finishing every last thing: modern lean-running offices always have more to do than the time available. Rest assured that most certainly your boss feels the same overwhelming inflow.

Laugh! Don’t overdo the clowning around, but when you find something appropriately humorous share it with your friends at work. Try to leave earlier in the morning. Even 10-15 minutes can make the difference between a frantic rush to your desk and having time to ease into your day. Stop adding to your stress levels by running late.

Finally, exercise. Every couple of hours take a brief break from your work to walk around outside, thus allowing your eyes a varying distance of focus. Do some carpal tunnel stretching at your desk and during your breaks. Pay attention to your sitting posture and consider the ergonomics of your work environment. Every so often sit quietly, turn on relaxing music, breath slowly and deeply, and stretch.

The Art of Debt

I am often surprised how frequently developers fail to make database modifications simply out of laziness. Say you have a customer identifier for favorite color, and the values tend to be either blue, yellow, or red. Now say you add a new attribute to a customer and this attribute only applies to one existing subset that already exists.

Say only customers who put red as their favorite color also like beets. Should you add a new field (named beets) or should you split the "red" values in the existing field to "red likes beets" and "red dislikes beets." All too often I see folks go down the path of trying to squeeze additional information into the existing fields, "red likes beets."

Sure this requires changing less programming logic immediately but it also builds up "technical debt" by increasing the analytical complexity in the future. In short it trades elegance for immediately impressing the boss.

And this really gets to the crux of the matter in the Art in software development: do you shoot for pleasing the boss, or do you aim for a pleasing future?

Artistic Ownership

The managers at many places I have worked confuse the fruits of our work (lines and lines of programming code) with “intellectual property” and with knowledge. It is a convenient deception, but it ultimately causes more problems than it solves. Let’s take a look at precisely what these concepts are, why code and knowledge get conflated, and the problems that ensue.

This is somewhat akin to confusing traintracks with a railroad. A manager walks in and says “oh, that guy is a direct path to Denver, that guy goes to our hub in Chicago.” But a railroad is a whole lot more than traintracks. It is also the locomotives, semaphore crossings, stations, leased rights of way, you get the idea.

“Lines of code” is a semi-fluid corpus of rules and instructions that implement business logic. These change as customer or management needs allow and they also get modified in reaction to bug fixes and refinements in technology. They are like traintracks. In nearly all cases the software code is the property of the owners of the company. So sure the railroad owns the traintracks. Yet there is so much more.

In the context of software development “Intellectual Property” is actually a narrowly defined term. Occasionally it may be a patent, but for commercially marketed software it is more likely a copyright. Most internal-use software (the bulk of what we create) is Intellectual Property by means of “trade secret” and employment work-for-hire agreements. So these are like the leases held on the rights of way.

The code isn’t an “asset” in the sense that a physical piece of property is an asset; it lacks a particularly liquid “market” and the rules and peculiarities it encodes keep little value when transferred to a non-related owner. Selling your traintracks to Australia doesn’t do them much good.

“Knowledge” in this context encompasses three overlapping concepts. First it is a domain-specific understanding of how things are supposed to work conceptually or legally. Second it is the cultural understanding of who is proficient at maintaining what. And third it is the historical insight into how things evolved to reach their current state. Software developers employ this knowledge (which resides primarily in their heads) to produce lines of code from the influx of rules, regulations, requirements, and bug reports. So the knowledge is the locomotives, semaphore crossings, and stations.

It is convenient for a manager to jump from the work-for-hire agreement to the (mistaken) impression that he “owns” the knowledge in developers’ heads. In this way he conflates the human “resources” through the midpoint of Intellectual Property to the endpoint of an “asset” that he owns and manages. He confuses the traintracks with the railroad. Although convenient, it is wrong in that it loses pieces in the translation, creating dangerous side effects. It is like thinking you can pick up the traintracks, move them to India, and suddenly have the Southern Indian & Pacific railway.

Knowledge isn’t transferable nor is it intellectual property. And if you move people from their areas of expertise the company effectively loses their knowledge. Sure it still owns their code, but after the company saddles somebody new with maintaining the code they have to reacquire the knowledge of how to do so. They have to relearn how to run the railroad.