Programmers should learn to fly

• Posted by Brian
• Posted on September 4th, 2007
• View Comments

In college I had an English professor tell me that there are no original story ideas, and that it is only the personal interpretation of familiar themes that brings forth the illusion of originality. I am beginning to feel the same way about software development. Not a day goes by without another CMS rising to meet the needs of publishers, and I wonder, have we not perfected this yet? Too many programmers are riding on the coattails of the those who have gone before, and the results are staggeringly unimpressive.

Whatever happened to the excitement of developing novel software that enriches the lives of the users? How is it that so many programmers begrudgingly work twelve hour days in order to the meet the insane budgets and timelines for project managers who fail to understand the technologies? It could be because we let it happen. For those who try to break free of the cycle, they are labeled miscreants who are trying too hard to reinvent the wheel. Well, maybe we should not reinvent the wheel. Maybe programmers should instead learn to fly.

Although we should learn from past mistakes, as well as others more knowledgeable than ourselves, there is a creeping codependency sweeping the field that deters independent thought. Ignore that movement, and take some time to consider the following points. You could say this is me pushing you out of the nest.

Question established norms

When I was a junior copywriter for the interactive arm of an ad agency, a senior copywriter once told me not to rewrite what had been provided by the catalog group. This copy was “blessed” by legal, the VP of creative services, and management, and it needed no tweaking. I was disgusted with his complacency, but was uncomfortable questioning the practice. Another more experienced free spirit ignored this warning, and her fresh writing style was met with high praise. He was envious of her success, and his childish insecurities were viewed as petty by others in the group.

Do not be afraid to question these sort of established norms. Although you should be respectful of veteran programmers, constantly lining up like sheep to the slaughter leads to apathy in software development. You do not have to shirk every design pattern you come across, but before you adhere to conventional practices, you had better understand why you are doing so. If you fail to see the worth, then take the risk and in the very least raise the question.

Drop the inferiority complex

Have you ever been awe-struck by the A-list at a conference? Do you hang on every word uttered from the mouths of industry experts, treating every panelist’s speech like a life mantra? Are you resigned to accept your lot because there are too many other talented programmers to compete with in your space? You may have an inferiority complex. If you suspect this is the case, then take a moment to realize the obvious. Every guru was once where you are now, and every programmer worthy of distinction still has several critics crashing the party.

Learn to be objective when listening to others in the field, no matter their stature. An exceptional, yet under utilized technique, is the ability to siphon out the fact from the fascination. If a topic is interesting and a speaker inspiring, then you should pay special attention to detail. You need to become a critical thinker, analyzing every recommendation, technique and tutorial. The bottom line is — accept nothing at face value, regardless of the face.

Do not be afraid of rejection

There are two sides to every coin. Unfortunately, this parable of wisdom is often interpreted as follows: there is a right way to do something, and there is a wrong way. In software development, the way which is untried is not true, and therefore, the wrong way. Do not be distracted by project managers or architects who scold your initiative and who subscribe to that theory. Even if you must fly beneath the radar, be willing to take a risk and suggest something completely new. You may not be understood, but at least you will be heard.

It can be healthy to get a dose of rejection to accompany your new outspoken voice. Even a little constructive criticism can be beneficial. This rejection helps to improve resolve, and it will help you to more easily pinpoint strengths and weaknesses.

Reverse engineer everything

In the 1950s television gameshow Name That Tune, contestants would bid for the lowest number of music notes they needed to hear in order to guess the title of a song associated with a tune. Every time you read a tutorial, or stumble across a new programming technique, you need to be bidding, too — not for notes, but for lines of code. You should ask why it took twenty or thirty lines of code, and consider whether or not it should be ten instead. You should also analyze how much memory is consumed in those lines of code, and be willing to reverse engineer and rewrite it. You might discover that this is the only way to uncover flaws, and to understand the language itself.

Regardless of how reputable the source, if it is new to you, then the first thing you should do is strip down the code to the bare essentials. Force yourself to reference several other sources, as well as the API, and you will improve your deductive reasoning skills. This process can expose untapped efficiencies, and help you to acquire alternative methods of programming.

Create software that you would love to use

This might seem obvious, and for many of us we may not currently have a choice in the matter. Yet, it should be said that at some point, you need to create software that you would love to use. If you are dispassionate, then you are more likely to accept the status quo. Especially for developers who are thrown into an enterprise software project midstream, you can be tempted to simply weather the storm. You still need to concentrate on the contributions you have made, knowing full well that the sum of your efforts will result in a small difference in the software.

Eventually, you may need to join an open source initiative, or develop your own commercial software. If you find that your day job will not present you with an opportunity to fly, then the best place to begin your journey is with your own idea.

Tags: fail, failure, programmer, programming