Developer

Confessions of a mediocre programmer

Alan Norton reveals how he makes the best of his average coding skills to survive as a mediocre programmer.

 

I have always enjoyed writing code, not because I was good at it, but in part because it was such a challenge. I found no thrill in commanding a personal computer to display "Hello World!" on a monitor. Seeing three red cherries or the Ace and Jack of spades show up on a monitor is a different matter entirely. One of the first programs I wrote out of college was a slot machine program written in Northstar Basic for the Northstar Horizon, followed by a graphics-based Blackjack program written for the Northstar Advantage.

As much as I enjoy programming, I must in all honesty admit that I am a mediocre programmer who has always found a way to get to the big payoff — that is, when the program ran without syntax errors and something magical happened. It is not too surprising then that I never worked as a programmer per se; I found my talents more in line with those needed to be a good developer. But before we go any further, I'll give you my definition of a mediocre programmer.

Mediocre programmer - A programmer who has a limited toolset. He knows the syntax of only the simplest commands, but he knows where to find the syntax for more complex commands. He doesn't know how to write the most efficient code, but he knows how to rewrite and test the code for greater efficiency if he must. He runs into more roadblocks along his passage to success, but he views each as a challenge and is confident that he will find a path around each roadblock. He may take longer to get there, but he always reaches his goal. He doesn't know how to create a DLL, but he knows he can if necessary. Like most programmers, he doesn't particularly like documenting his work but does so anyway because he is a professional.

The job dictates the skill set

While I would have loved to continue writing games, the desire to eat led me to the local job market; companies have this strange requirement better known as real work that must be accomplished. Production, human resources, accounting, inventory tracking, and metrics reporting are just a few of the necessary evils of doing business — you know, the really boring stuff.

My skill set changed dramatically when I was actually paid to program. It doesn't take a lot of advanced coding skills to move data around and magically turn it into information.

I was hired by Hughes Aircraft to support its Production Control department with IT services. My job required developer/analyst skills, and I loved my work. Programming was but a means to an end.

A developer has to wear many hats

Programmer is but one of the many roles of a developer; you often have to wear the following hats as well:

  • Buyer (with budget)
  • Scavenger (no budget)
  • Analyst
  • Designer
  • Planner
  • Programmer
  • Coordinator
  • Tester
  • Documenter
  • Support technician

It is not too surprising then when a developer is not considered an expert in one or more of these roles. For me that job function was programming.

How I survived

Even with my less than stellar programming skills, I was very successful as a developer. Here are some tips I learned over the years and how I survived as a mediocre programmer to make the best of my average coding skills:

  • Requirements — I got a complete and accurate list of the system requirements up-front. Waiting until you begin coding means that you haven't based the system design on the requirements.
  • Analysis and design — I got the analysis and design right. An average programmer has an advantage over a great programmer if the former gets the analysis and design right, and the latter gets it wrong.
  • Project plan — I confess that I didn't use a formal project plan early-on in my career. It wasn't until I joined CSC, and I had to use more formal documentation techniques, that I began using project plans. It was then that I fully realized the advantage a mediocre programmer has when using a well thought-out project plan.
  • Well-thumbed manuals — I always kept the manuals close at hand. I also invested in additional reference materials.
  • Copy-and-paste programmer — I don't mind admitting that I was a copy-and-paste programmer. Over the years, I wrote a lot of code that could be reused in a new project. I always took the time to write the code at least once so I had some knowledge of how the code worked. However, I never copied code written by someone else while on the job, and I never used code I had developed at another company. The golden rule and copyright laws apply to intellectual property: You may not copy and use someone else's code unless expressly permitted, or you are granted special permission.
  • Perseverance — I never gave up, and I always believed I could accomplish any programming task.
  • Tools — When I needed a faster computer but it was not budgeted for, I found a manager who was willing to give me part of their budget in trade for my computer. Beg, borrow, or trade to get the tools you need to accomplish your task and always ask your manager; a good manager will do his or her best to find a way to get the software, hardware, manuals, or help you need if it is justified.
  • Serendipity — Also known as the "Just write code and it will get done" strategy. There were times as a junior programmer that I just wrote code, and it all came together. I liken it to that game of chess that you play and suddenly discover that you have given yourself the opportunity for checkmate in two moves. This isn't how programming should be done, but since I am confessing my professional sins, I have to include this item.

The bottom line

I have one final confession to make: I don't appreciate being thought of as a second-class team member. I have known superb but rather naïve programmers who really believed that if you can't write "sophisticated" code, you are worthless to the team and company. This elitist belief that average programmers are inadequate and incapable of producing high-quality code is almost always wrong and offensive. I am somewhat amused and amazed by the notion that you aren't a good programmer if you can't ________ (fill in the blank).

You don't have to be a whiz-bang programmer to be a great developer, particularly if you are developing business-related systems. Yes, I am a mediocre programmer, primarily because I never needed to be a great programmer.

I am not condoning mediocrity; you should always do your best in whatever you do — including programming. It can be difficult to identify the "best" code, however. Code that is more efficient may be harder to maintain. It can be argued that any code that gets the job done is good code. Code is like a Soma cube; there are 240 ways to solve a Soma puzzle and many ways to write code that accomplishes a task. The bottom line is to get the job done as best you can — which even a mediocre programmer can do.

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Alan Norton began using PCs in 1981, when they were called microcomputers. He has worked at companies like Hughes Aircraft and CSC, where he developed client/server-based applications. Alan is currently semi-retired and starting a new career as a wri...

Editor's Picks