Software Development

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...

130 comments
tusu
tusu

99% of programming only ever requires mediocre skills.   But technical skill at coding, will NEVER be what makes a programmer successful in 99% of programming.   EVER.   Most of the 'really great programmers' I know are horrifically bad at everything else they need - having some common sense as to when to stop tweaking and rewriting everyone else's code, what the top priority is, putting the team first, choosing tools intelligently, following coding standards, helping others on the team to excel, putting aside their ego.....Technical skill is important, but it isn't even close to the most important thing.   The key is to have a mixed team - one at least somewhat controllable 'really great programmer', someone who's very good at remembering and understanding what the business wants and why, someone who is very good at prioritizing, etc.   The only thing more guaranteed to sink a team than 'adding more people' is having all of them  be 'really great programmers'.

wolrabs
wolrabs

Reading all this, I would be a mediocre programmer, until I delve into code that is just so bad, it is indescribable. I look on the internet, I read the manuals and the guides and never remember them. They are there for reference and I use them all them time. I will spend time 'refactoring' code and rewriting it if is so bad it is unmaintainable. I will spend time trying to make my life easier by writing reusable code. This isn't being mediocre, this is being good and doing the right thing.

loidab
loidab

You, with your roablocks, are exactly what companies don't need: people who wastes company money looking on the Internet for information your job titles suggests you should already know. Good programmers think their software design throughout and are way more efficient and thus professional. Which is simply what any worker should be. Lazyasses.

pete.bos
pete.bos

Excellent article, in which I fully recognize myself; been at it for neigh-on 25 years, Clipper/dBAse,VBA and VB6 (still) I just more or less create my own tools many of which then get adopted as Corporate standards for multi hundreds of users notwithstanding a grumbling IT department.

Jeremy19
Jeremy19

As a mediocre programmer myself, this made me feel better.

jonathan_jennings
jonathan_jennings

i love this article, as of now i am in college and would consider myself a decent programmer. Granted i still have tons to learn but the thing i like most about your article is your point about " perseverance" i admit when i see the code of the over-achievers in my class i do get a little green with envy, when i was unable to create a data set for the computer to organize i was a little embarrassed. I worked my ass off to try to do it regardless and i have gotten better at programming by doing that. i just put together my first " game" a text based 800+ line RPG and i am so proud of it. It is the culmination of most of my learning thus far. As i go onto my next personal projects and hopefully one day get paid to do this i am going to try to approach the projects as yet another challenge and maybe one day this collegiate mediocre programmer can grow into an executive Mediocre programmer. like i said thanks for the article.

nqholder
nqholder

Gr8 article. I can totally relate to this

sewa mobil
sewa mobil

thank you very much for your explanations and articles provided www.fortunerentcar.com

APBorsa
APBorsa

You are a great and very wise PROFESSIONAL, Mr. Norton! (by one considered a good programmer but lacking a few of the other profesinal gifts you mentioned).

pj.villarta
pj.villarta

thanks for writing this. i can so relate to it.. ;)

curteousdesigns
curteousdesigns

You have definitely allowed a lot of us to become a little more free... especially me. I am so glad to know that I have not been alone on that journey. I am thankful for your transparency! :o)

jose.a.nunez
jose.a.nunez

This was quite good, refreshing and relieving to read. I feel better now. Sincerely!

nqholder
nqholder

your definition of Mediocre programmer suits me 100%.

vanz27
vanz27

That was so inspiring,, I wish I could be a great programmer like norton.... Hayzzzzzzzz......

fewiii
fewiii

But, I think it all depends on your definition of "mediocre". Example: I can create a C-based Windows DLL with my eyes closed. A Windows GUI App using "raw" C/C++ (no MFC!)? No real trouble there, either, yet I find myself still learning new things, even in this day-and-age of Windows 7! A C++ class library, the implementation in a DLL? (Or, an MFC app?) I'd have to keep my eyes open on that, if for no other reason than punctuation! Recently, I've been learning Device Driver programming, and I'm starting to beleive I missed my true calling (I started out as a hardware geek, anyway, back in the '70s at 15 with my 60-in-1 Electronics Project kit). Yet, I certainly wouldn't consider myself any sort of "expert" at writing device drivers, though I love it. Connect to an SQL Database using Linq in C# for an ASP.NET web page (or, any kind of real Web Development, for that matter, beyond the basic)? I'd be totally lost, though I do know (or, should I say, am *familiar* with) basic SQL and understand C# and the .NET Framework. --End of Example-- Almost all programming in the real world is "maintenance" programming, anyway. As long as you reasonably know the language you're using/maintaining and have the ability to learn and "pick up" things in a reasonable amount of time, no one should have much trouble. That's always been my strength, and it's served me quite well. Finally, whatever I'm doing, I don't overly worry if my code is written precisely the way it "should" be written, or if it's written in the "standard" fashion. I will go over my source code, of course, cleaning it up, etcetera, but I won't lose a ton of sleep. And, of course, keep learning! Supervisors, bosses, etcetera, notice that, no matter how "mediocre" you might consider yourself.

chrisfalter
chrisfalter

Most of the bugs I've been fixing in our product recently are the result of copy-'n-paste gone wild. Instead of obeying the DRY rule ("Don't Repeat Yourself") by consolidating into a single method or class, a programmer decides to save 2 minutes and 17 seconds by doing the copy/paste operation. Very frequently something goes wrong, or a bug in one location gets copied to many, or the assumptions that are true in one location are not quite true in another (and the assumptions didn't examined bc/ the copy/paste programmer just wanted to get in and out as quickly as possible). That 2 minutes 17 seconds you saved by copying and pasting just resulted in hours of QA and bug fixing.... Another problem with copy/paste programming is that it becomes difficult to introduce changes in your code, when you have to find all of the various locations where the copied code has been pasted, and then change all of them in the same way.

danielperez597
danielperez597

Hey man you have inspired me to carry on. I am computer systems & software engineer just graduated and going for my first job for a software development company. My ultimate goal is to become a software developer and or a database designer/developer and some day even forming my own little company. I am good at programming although not an expert its good to know that you don't have to be extremely expert programmer to eventually become a developer.

david.lloyd
david.lloyd

I have been inspired by your article and Osiyo53's life story to get back on the programming horse, after a long break, thinking I wasn't whizz bang enough to make it as a programmer. I realise I have what it takes to be a mediocre programmer and that's OK! :)

rcarpenter
rcarpenter

Loved this article! I'm one of those that learned out of necessity, on the fly...through determination...by the seat of my pants and it still never ceases to amaze me when the magic happens...my efforts pay off... and it all comes together. Appreciate that there are kindred spirits out there.

dnewman20
dnewman20

I am a web developer who in 1996 worked through the inconsistencies of browsers and renditions of javascript to make things happen. I used tables with clear images to get things to fit just so. Before there was AJAX I was using 1 pixel frames with javascript to run routines on the server in the background and populate form fields. I was not the top of my game but I was above mediocre. I left the business and went into non-tech work for 10 years. Now I am back and my advanced age and my lack of knowledge has put me at a disadvantage. What I used to be able to figure out with a view source now requires hours of research of multiple javascript files and css files. I have to admit that I sometimes now give up when I can't get it. I think I am technically minded. I am good at specing out and understanding the capabilities of the trade. But now I need to get back into it. I am not a thumb through manuals type guy. I learn from experience and possibly good mentoring. I never took a programing class (well maybe Apple Basic in High school). So what to do. I want to be a mediocre programmer. Can I take a class in mediocrity. I don't want to be great, I don't want to be detailed. I just want to be quick and dirty and feel accomplished. Alan, any suggestions for a shlub like me?

jon_bachelor
jon_bachelor

Thanks for writing this... I identify wholeheartedly, as a self-taught and admittedly mediocre programmer who absolutely loves the field, but did not have the foresight to major in CS back in the days of college. It's nice to hear I'm not completely alone in this situation!

Osiyo53
Osiyo53

I read your definition of a mediocre programmer and immediately felt like I should jump up and wave my hands and yell, "Me ! Me ! He's talking about me." I first got into learning about and working with computers way back when. In the days of the room sized main frames. (1966) Back then, when I applied to Control Data Institute, they made a series of tests. One of which was an aptitude test. A counselor reviewed the results and asked me field I wished to get into. Programming? Operator? Repair/maintenance tech? Etc. I didn't really know that much about computers and the various types of work. But did know that programmers were supposedly the "Brains" behind making things work. They were at the top of the heap and pecking order and held virtual "Star" status. So I answered, "Programming?". Tentatively. Because in truth I thought there was no way anyone would think I was good enough, talented enough, or smart enough. The counselor replied, "Well, to be honest, I won't prohibit it if you wish to try. However all your scoring on the aptitude tests tell me that the odds are that at best you'd be a mediocre programmer. But those same tests indicate you have the talents, inclinations, and thinking patterns that are of the types to strongly suggest you could be a GREAT hardware technician." He went into more depth about all that. But the upshot was that despite anything he said, I figured he was just trying to make me feel good about going into the technician side, while avoiding telling me I just wasn't smart enough to be a programmer. Which is what I suspected, deep inside, from the beginning. So I sucked it up and smiled and said, "Great !" and told him I'd take technician training. I wasn't really disappointed. Somewhat, but not a lot. In fact I was surprised that he felt I'd scored well enough in that battery of tests to become a tech. Keep in mind the year, and the fact that I was a youth. Computers were things most people had never seen, knew nothing at all about, and virtually their only exposure to the term and idea was when watching or reading science fiction movies or books. In any event, I took and passed the course. Finished at the top of my class actually. Which surprised the heck out of me. I was born to a poor dirt farmer family way back in the back hills. Think hill billies. Didn't even have electricity until I was 9 years old. Or indoor plumbing. I was in the big city now and sort of expected that most all those folks were brighter than myself and knew a lot of stuff that I didn't. The only thing I had ... was the willingness to learn. And a certain amount of hard headed stubbornness. Or stupid persistence. Whichever description fits best. I'd faced daunting tasks before. Like when the family decided to clear some extra acreage, to be farmed, which was thickly covered with trees. And all we had to get it done was hand axes, hand wood saws, shovels, and muscle power. Yah just stopped worrying about the thought of how much work it was or how long it'd take ... and commenced to getting it done. Thinking of only one tree at a time. And no further ahead than that. From can see to can't see. Then the next day you did the same. And kept going until you were done. So while there was a lot for me to learn, and it all looked far too advanced and complicated for me to understand, I just kept working at it. I just didn't know any other way than to keep plugging away at it until I got to the end. I won't bother listing the sequence of events that lead to it, it'd be a long story. But my career as a computer tech got cut short and I ended up in the Navy as a small boat engine mechanic and part of the crew of a PBR (Patrol Boat, Riverine) in Viet Nam. In fact, did three tours there, all volunteer. Then went on to spend a career in the Navy as a ship's mechanic/engineer. In the 80's, the Navy started experimenting with PLC's (Programmable Logic Controllers) for controlling mechanical and electrical equipment of many sorts. And started testing the practicality of usefulness of installing general purpose desktop computers aboard ships to be used for general administrative purposes and such. They published "want ads" to fleet personnel, asking that anyone who might know about computers, digital logic, etc ... especially those in non-computer specific jobs ... to notify the Bureau of Personnel. Because they were looking for folks who might know how to help them figure out and develop systems that'd be employed for purposes other than the massive data processing chores for which computers had traditionally been used up to that point. Thus I got into a program where I found myself learning about early PLC's, developing and testing and debugging control programs. And when I wasn't working on that, I was learning about the early word processors, spreadsheets, data base apps, and this programming language called "Basic". And developing little apps that's be of use to shipboard mechanics and electricians for various administrative purposes. In the tech school, the techs were taught SOME programming. Not a lot. Just enough to write routines to run hardware through tests, to be able to read source code written by real programmers so one could figure out if they'd made a mistake. Etc. Anyway, that's how I got back into the computer world. Today, I work in what's called the Building Automation Systems (BAS) or Energy Management Systems (EMS) biz. We install hardware and write custom control programs to run all the mechanical and electrical systems in large buildings and facilities automatically (or mostly so) so as to achieve the most efficient operation possible, while also maintaining occupant comfort. Such programs vary from being pretty simple, to very complicated and complex. Especially these days as such control systems often include not only the actual control functions for the equipment involved (a single building may have a few hundred programs operating concurrently, while sharing info with each other) in a single, large commercial building. But might also be a matter of numerous building owned by a single customer, scattered around the world, sharing info. And involves creating custom web pages, dedicated web and database servers, interaction between numerous types of networks, and so forth. And so these days, I am a programmer. But a very mediocre one. That's not modesty speaking. Its simple truth. Our true programming wizards and gurus do that chore all the time, full time. And, trust me, they're way above my level. But I've found my niche, where I'm useful and productive. I test and debug their stuff. It doesn't get final approval until I say so. As it turns out, I do know more about the actual systems that'll be controlled by those programs than the programmers do. And I also know more about what the customer (end user) wants, needs, and expects. So I get their apps, and put em to the test. Then fine tune and tweak things, make changes, to ensure the items being controlled are being controlled properly and adequately, with appropriate safeguards so that things don't go into a state of what we call "catastrophic, autonomic dis-assembly" ... think BOOM. Or just roll over and play dead cockroach. I also pour over the plans and specs of the job and ensure the final products, the physical controls and the programs behind them, meet all ... ALL ... of the specifications and expectations. The spec books are quite typically 2 to 4 inches thick, of very small print, with thousands of items spelled out and defined. One of the problems with our top whiz programmers, is that while they know more about programming than I probably ever will ... they tend to skip over or flat ignore small details they don't consider important. Not to mention, they sometimes have this idea that they know what the customer wants or should have ... better than the customer does. BTDT, many a time. Super programmer insisting his ideas and ways are the better way. Customer doesn't need that, he needs THIS. Etc. I've even had programmers argue that the customer's preference for screen layout or the color of buttons is the pits and HIS, the programmer's, ideas on this are better, I do listen to the REAL programmers. And sometimes even run those by the customer, along with the justifications or thoughts behind them. But only sometimes. They'd better have a darn good argument. But my primary job is to ensure the customer gets what the customer wants and expects ... and what we said they'd get when we signed the contract and a price was agreed upon. And that everything work just EXACTLY as we said it would. I'm certainly no wizard of a programmer. When I find something not right, and am in debugging mode, I'm slow. And sometimes have to spend considerable time just grasping how the programmer is doing this or that, and why THAT method. Sometimes have to pick up the phone and ask the guy to explain, please. Mostly, they have excellent answers, once I understand. They are good at what they do. But while slow, and having to often refer to help files and manuals, and while my corrections are often not as elegant as those of the original programmer ... I am thorough and meticulous. When I'm done ... its gonna work right and IAW the specs. And since I'm so slow, in comparison to the REAL programmers, and can't always instantly remember the proper syntax, etc of every possible command, statement, function, etc that I run across or need ... I use cut and paste extensively. Drawing upon past code I've come up with and proved for doing this or that. Because, unlike the real programmers we have (that is NOT meant as a snide remark) I'm not good at just knocking out complex code off the top of my head. I've gotta think about it, long and hard. Then find myself checking, rechecking, triple checking anything I just did ... looking for errors and assuring myself that its right. I liked your comment about documentation. That's one of my duties. I'm the guy who has to, in the end, SELL the final package to the customer. That is, make em satisfied with the results so they'll sign that final check, declaring the job done adequately and satisfactorily. As part of that I produce a Owner's Manual. They're digital these days. And include not only the expected stuff like instructions and directions. But also complete copies of all source code. In our biz, customer owns that, not us. Its a typical part of the contract, comes under maintenance. They want the source code so that in the future either they can make changes, or they can hire someone else besides us to make changes. Thus, source code needs to be commented adequately. Chuckle, our very best Gee-Whiz programmer,a guy I admire a LOT ... is very bad about that sort of thing. Either next to non-existent comments, or comments so brief and terse as to be near worthless ... unless you can read his mind. He's like that in real life, face to face also. Ask him to explain something and you get an answer that presumes you know exactly what he meant ... instead of only what he said. He leaves out huge chunks of his thinking process. So I am a programmer, technically. But a mediocre one at best. However, the company for whom I work seems to think I make a valuable contribution to the team and process. I've been working for them for 10 years now. Survived the hard financial times when others, far more talented at programming than I, have been let go ... for no other reason that business has slowed to the point where there was no work for them. (My paycheck is as large as theirs was, in some cases larger.) So there must be a place in this biz for folks who may be mediocre programmers, but who bring other skills and talents to a team which are needed, and which the real programmers may not be so good at.

santeewelding
santeewelding

Your skill at programming attention is anything but mediocre. This was a think-piece that has stayed with me.

gelliott
gelliott

Enjoyed the article. Cleared up some misconceptions for me.

oldbaritone
oldbaritone

It's always a tough call - "build vs buy." I've bought some canned routines that I ended up regretting, and re-writing because they were so horrid. OTOH, I've ended up buying some canned routines and using them because I thought I could do it better, then proved myself wrong. Re-use code? Heck yes, all the time. I don't try to "pretend" that I'm re-writing something that I have already done, if I need it again. Use somebody else's code? Heck yes, all the time. There's a lot of free source that the author publishes and asks only credit in the comments. I respect that. But I only use code that I can understand; if it's obfuscated, forget it. I've done all the jobs you mentioned, plus - Trainer - Training Developer - Field Troubleshooter - Re-designer (the chump who tells the engineers what needs fixing) and of course - Whipping Boy (the chump in the field who gets beat up while the guys in home office sit in their mahogany-lined ivory towers and laugh) Great article.

nyteshades
nyteshades

Wow, this is a great article that hasn't come at a better time for me personally. I have been in IT for 11 years, and have been a Sys Admin for 10. I've worked in 3 or 4 different industries, supported windows, linux, unix, and mainframe systems over that time. In the last 4 years while working towards my bachelors I have found an interest in development and regularly enjoy writing code. In fact I enjoy it so much that I am currently trying to find an entry level coding gig. One of my biggest concerns has been that, for me...it takes a while for me to write the code. Having spent years in IT, the rest of it comes easy. The analysis, identifying the requirements, and research (google or manuals) has been part of my job for years. This post, and comments, has given me confidence that I don't have to be a l33t programmer to get the development job done. Thank you!!!!

jsayyid
jsayyid

Excellent is the only way to describe this article. I'm IT student learning programming c++ and I have many set backs with code. And I read the part on perseverance wich was big upleft, also that a developer wear many hats, I'll past this article on to my fellow students Please start addressing more IT student concerns.

Suzie B
Suzie B

I really enjoyed this article because I work alongside some great programmers. I get to read the code that our programmers write when working through production errors. It is the simple code that is most beautiful. In 20 years of this type of work, I've found the preference today is to make it easy to understand. The things that allow a mediocre programmer to survive are precisely the skills and attitudes that my brilliant colleagues have over others. At times there would be more of that and less of the actual programming.

iShango
iShango

Not everyone is brilliant. Not everyone is stupid. On a bell curve of skill we mostly sit somewhere in the 'Average" range. I currently work as a Sys Admin for a largish company where there has been a drive to recruit people on the outside edge of the bellcurve. We have a team that has acheived Million dollar solutions with 70K software. We regularly stump vendors with the performance acheived with their poor software that they did not dream possible. In the middle of this is me. I came to IT late (48) and after two years of full time study and 6 years of experience hold down a position in this team of high performers. My ego has taken a battering on many an occasion when I realised that I was not seeing the 'obvious' things that other team members saw. I see things differently and gather thoughts slower than the others but... 1. I have never 'accidentally' restarted a production server 2. I have never trashed a production database 3. I have never 'broken' a production application 4. I have never wiped the wrong backup tape. Each of my brilliant colleagues has done at least two of things each. Impetuosity and hubris can be good things when used the correct way but my cautious approach has steered me around these. I am aware of my limitations and like you, always strive to improve my game, my skillset and my performance. Sometimes not so successfully other times with gratifying results. I play to my strengths , relationships, and help the team to aceive great things with my contribution to team building. I'm not always happy with my realisations but the pragmatist in me recognises the battles that can be won and when to withdraw. A great column Alan and thanks for the insights.

Tony Hopkinson
Tony Hopkinson

is finding expedient ways through a maze of barely justifiable constraints and technical debt. Google can be a must. There's always something that you don't know and rarely enough time to intuit it from first principles...

Osiyo53
Osiyo53

If one is using copy and paste as a substitute for developing suitable, reusable subroutines, functions, classes, methods, etc. (Exact terms and ideas depending upon the programming language being used.) Speaking only for myself, that is not what I meant when I said I used copy and paste routinely. And I find that I have to agree with Tony Hopkinson, I have also seen people get carried away with the DRY principle. In particular I dislike things like the example he gave of functions designed to do 20 things which have a tediously long number of arguments. (Change wording to overly complex classes/methods designed to "do it all" if those terms better fit the programming language you're using at the moment.) They tend to be just a mistake or bug waiting to happen. Or, in some cases, so obfuscate the code as to make it just that much more difficult for someone else who later comes along to make changes or debug.

Tony Hopkinson
Tony Hopkinson

Some seem to feel well this ais sort of vaugely simlar code so I'll resuse it. They do a bit of work a few tests, check it in. And break the crap out of everything that did use it before. Not to mention bottlenecks, functions that do twenty things have a set of qarguments longer than the f'ing code... I've seen people go to the well once too often with DRY, get scared of changing it, then start of copy N' paste just because they daren't change the common code, again.....

Alan Norton
Alan Norton

I used copy and paste coding to get the syntax right. That meant I wasn't introducing syntax errors that had to be debugged. It wasn't just the two minutes saved typing the code it was also the debugging time saved.

toms45
toms45

the same code in multiple places in a program, then why oh why did you not make it a sub or function? That way, change it once in one place and that's that!

Alan Norton
Alan Norton

Daniel, I am pleased to hear that you found the article inspiring. I wish you well in your job search. Edit: Fixed unforgivable sin of getting Daniel's name wrong.

Alan Norton
Alan Norton

I don't get a chance to write those three letters very often. I have a strange sense of humor. Thanks for the laugh.

Alan Norton
Alan Norton

David, That's great. I will tell you my story. Between 2001 and 2009 I did NO programming at all. I had no projects that needed to be done so, unfortunately, I did none. Try as I might I couldn't come up with any interesting coding project ideas. And then something totally unexpected happened last year. I wrote an article for TechRepublic about using the Reverse Integration process to integrate the latest service pack into Windows Vista. http://blogs.techrepublic.com.com/window-on-windows/?p=1249 I realized during the process that I could write an app to automate part of the process. I had my programming project. It took two full weeks to get back into the swing of coding again. But here is the good news. I was almost as good at coding in 2009 and in some ways even better though I had been off the horse for eight years - and I am no spring chicken. I'm not saying that your experience will be like mine just that it can be done. If I can do it I'll bet you can too.

Alan Norton
Alan Norton

Project development is the most rewarding job I have ever had. I guess that is the exhilaration that Jim was talking about - when it all comes together and you deliver a system that works as promised and as designed. Thank you for the kind words.

Alan Norton
Alan Norton

I don't really feel qualified to give advice to you. Please take what I write as comments rather than advice. "I am a web developer who in 1996 worked through the inconsistencies of browsers and renditions of javascript to make things happen." I understand the inconsistencies of browsers. What a nightmare. Talk about a productivity killer. "I was not the top of my game but I was above mediocre. I left the business and went into non-tech work for 10 years. Now I am back and my advanced age and my lack of knowledge has put me at a disadvantage. What I used to be able to figure out with a view source now requires hours of research of multiple javascript files and css files." Please read my post here: http://techrepublic.com.com/5208-12845-0.html?forumID=102&threadID=327102&messageID=3261637. You have just had a decade long sabbatical. :-) "I have to admit that I sometimes now give up when I can't get it." Yeah, that can be a problem. You have to find some way to power through roadblocks. I always found expectations of a paycheck or lack thereof to be good motivation for me. But then I always thought of each roadblock as just another challenge. I don't need to tell you that your day can be sometimes filled with 'challenges'. "I think I am technically minded. I am good at specing out and understanding the capabilities of the trade. But now I need to get back into it. I am not a thumb through manuals type guy. I learn from experience and possibly good mentoring." Learning from experience is fine but unlike my situation as detailed in the link above, the Web development world has changed dramatically in ten years. It's going to take a lot more than a few weeks to get your skills up to date. You don't have to read through manuals to get up to speed but you need some manuals close by that you can reference when needed. There are some excellent tutorials online at w3schools that I have used that you might find helpful though some of the tutorials might be too basic for your needs: http://www.w3schools.com/ "I don't want to be great, I don't want to be detailed. I just want to be quick and dirty and feel accomplished. Alan, any suggestions for a shlub like me??" It is attention to detail that often differentiates a mediocre program from his or her peers. Look at your skills realistically and rate them. No need to give yourself a moniker like 'shlub' though. You are what you think you are and I seriously doubt if you are a shlub. There is no quick and dirty. It's going to take some hard work and commitment to be successful. I am starting to sound like Yoda so I'll stop now. I hope you can find a way to become a Web developer again - even if only a mediocre one.

Alan Norton
Alan Norton

Jon, You are welcome. I am somewhat surprised by the number of mediocre programmers who have been able to identify with my programming skills or lack thereof.

dltaylor
dltaylor

I just want to thank you for your story and say that I remember when Control Data Institute came to Dallas Tx. I always wondered about attending and thought that it would be so cool to work with computers. Thanks again for your story!

Alan Norton
Alan Norton

I really enjoy hearing stories about experiences from the early days of computing. I can only say I am very grateful that you took so much of your valuable time to write down your experiences and share them here. Your experiences will no doubt be encouraging to others who may not have the aptitude to be a great programmer but can still be a valuable asset in the IT world. You may be a mediocre programmer but you can be proud of what you have accomplished.

Alan Norton
Alan Norton

Build vs. Buy - Interesting discussion. As a developer I always preferred to build. ;-) My managers preferred the buy option whenever possible. Sometimes it came down to which bucket had the budget. I have used code copied from the Internet on my Web site and have no problem at all doing so or with the attribution sometimes required. The programmer should get credit for their work even if it is only a comment included with the code. You do at a minimum have to understand what the code you are using actually does. Whipping Boy? Sounds painful! Thankfully I have avoided that hat. Thank you oldbaritone for the comments.

Alan Norton
Alan Norton

...to be a good developer. I am glad to read that you found the article helpful to you personally. If you enjoy coding don't be overly concerned about how long it takes this early in the game. The interest, enjoyment and some basic skills and aptitude are the important prerequisites. Thank you for sharing and good luck getting that Bachelors degree.

Alan Norton
Alan Norton

I was a student once a long time ago... It's good to hear from a student. Learn as much as you can now because no matter how much you learn as a student you will almost certainly learn more on the job. The editors and writers at TechRepublic often use ideas suggested by TechRepublic members. If you have an idea for a article that would be helpful to students, send the suggestion to one of them. I can only speak for myself, but quite a few of my articles have been inspired by requests from TechRepublic members and I always carefully consider each suggestion. Thank you for passing the article on to your fellow students and for the kind words. Don't ever let an old curmudgeon like me discourage you from reaching your goals simply because you are inexperienced.

Alan Norton
Alan Norton

I can't even begin to imagine starting an IT career at the age of 48. That takes some real guts. My hat (or hats :-) )are off to you! Thank you for the comments.

Brandon_Forest
Brandon_Forest

I'm a member of the Mediocre Majority, and proud of it. I know of many people who are better at programming than I am, yet I don't despair and in-fact thrive because I don't have the hubris of some of these "Guru" level programmers. My key to success is that I actually listen to my customers and my peers. I constantly learn from beginners and advanced developers, programmers, managers, analysts, and in fact anyone who has built something cool. I am not a great creator, but I am a great innovator. I don't ever want to be on the bleeding edge of development, I would rather learn the lessons from those who have already been-there and done-that. Somehow, I've been able to keep it all together and earn a living like this for 25 years. Brandon_Forest@sbcglobal.net

dltaylor
dltaylor

I am 47 and just getting my degree and wanting to join the programming field. I was so over stressing myself about what would be required on the job in the real world and, you all have helped my stress level tremendously. In the newspapers and online all the jobs talk about requireing a bachelor's degree and at least 3 years experience in the field, and, these post' have made me feel so much better about my possibilities of finding gainful employment somewhere. Thank you, thank you, thank you!

Alan Norton
Alan Norton

Brandon, Sounds like a new movement or support group! We can call the members M&Mers. Alan: "I am a mediocre programmer." M&Mers: "Hello Alan!" "My key to success is that I actually listen to my customers and my peers." That is a great quality to have. There are a lot of IT professionals who go in with preconceived ideas, already knowing the solution when that solution may not satisfy the customer's needs at all. Thank you for the thoughtful comments. Edit: Added comment

Tony Hopkinson
Tony Hopkinson

for a living, might be wise to take your address out the post.

Alan Norton
Alan Norton

My hats are off to you too! I always found my stress level reduced by being prepared before the big interview. I remember hearing once about a guy who wrote his resume as an app. Very clever. He gained valuable knowledge and skills in the process and he was able to show those skills to his prospective employers. Good luck getting your degree.

Realvdude
Realvdude

The trouble is that I don't think any of us need a support recovery group, because we know how to deal with life's struggles already.