Why In the world do you want to be a programmer?

| 3 Comments
After getting into work this morning at 5:00 A.M. waiting for someone else to do their part in a system upgrade, I thought a post about the cons to being a programmer would be appropriate.

Lets face it, being a programmer isn't always fun and peachy. Sometimes it really sucks, and lets face it, there are days you go home and just dread working the next day.

If any of the following are intolerable to you, then you should think carefully about being a programmer.

  1. If you cannot stand seeing your work thrown away.

    This one is probably the biggest surprise for new programmers. The majority of programming is 'Do it once', and then 'Do it right'. I have found that working for a University that there are customers that demand that specific features get put into code and then that feature is NEVER used. Sometimes the code never makes it to a production environment. Sometimes entire projects are scrapped before you can even have the satisfaction of seeing code that runs half way properly.

    I have seen many new programmers, both young and old, get frustrated by this. You need to understand that the first draft of any program is just that: A DRAFT. BETA SOFTWARE! I usually find that the customer didn't artculate what they really wanted, and now that there is something to look at, the customer can more easily describe what they want.

    Just understand that you did your best to meet their requirements, and now they better understand their requirements and can better meet your needs for requirments after seeing a running version of the program.

  2. I goofed up, and now you have to fix it.

    I used to get this all the time. A customer would screw up a process, or put bad data in, and it would become my problem to find and fix the problem.

    For about 3 years one of my tasks was to run a report every month, to find the mistakes that were entered into our PBX database that affected our export to the police for E911. The process to enter the numbers in, never changed (I think it is still the same now two years later even), however, there were a few individuals who couldn't follow the process and would consistently mess up the E911 export and I would have to find/follow up on the fixing of this data.

    Another example of this comes not from customers but other programmers. Once there was an application that had a University wide user base. When some programmers/admins decided to replace the vendor that ran the backend software/hardware. They neglected to consider this University wide front end. As a result I had to throw together a CGI program that duplicated the essence of the first application. One day later I had an application that is embarassing to re-read, but it worked, and did the job.

  3. Deadlines.

    Sometimes projects have a deadline. A lot of my deadlines are related to the fact that students are not on campus but on August 15th, they start coming back. This cannot get pushed back, no matter how much I want it.

    Sometimes this deadline is artificial, and unreasonably set. Sometimes managers don't understand the amount of time needed to do certain things is not easily guessable. Sometimes they guess themselves and make bad decisions that come down hard on you.

    Given that I work in Academia meeting deadlines is less of an issue for me, but I was moved into an ISO group that needs to break even when looking at the books externally, so I am getting a better feel for what this is like lately. My managers have been very good at including the developers in the estimation process, so I cannot complaint too much about this topic.

  4. Customers that don't understand what you do, or how you can help.

    This requires patients on your part. YOU need to teach the managers/customers exactly what you are capable of, and YOU need to be willing work with them. This type of problem if allowed to persist, can leave you watching too much youtube, and not enough programming, and may leave you without projects/jobs.

  5. Working off hours to do upgrades/deployments.

    Updating a system usually requires you to wait until there are nearly no users on the system. This can mean working on weekends or like me today, showing up to the office at 5:00 A.M. This is usually a planned event, and can be forseen, but sometimes vendors put out emergency security patches, so sometimes they are unavoidably unplanned.

  6. Reading someone elses code.

    Lets face it, this can really suck. However, if you cannot read someone else's code you really cannot be any use on a team. Reading someone elses code, is sometimes like untangling six strings of Christmas lights you bought at a garage sale for $.25. Sometimes it is no fun at all, but you are getting paid to do it ...

  7. Spending days on problems before making progress.

    This one really sucks sometimes, however you hopefully have something/someone to help you beside the internet. Sometimes you can spend days working through problems, one baby step at a time, and never seem to get anywhere.

    This can happen when joining into open source projects that have a very fluid code base, and everything is in flux. I spent a month trying to get the bleeding edge of MojoMojo installed.

    Everyday was the same:
    Run 'svn up'.
    Run the catalyst server,. find (some of) the missing/out of date modules (they changed every day).
    Run CPAN installers, find out that module X doesn't install
    Fix and install module X
    Re-run the catalyst server find the next dependancy change
    etc ...
    Its 5:00, go home, and start all over the next morning.

  8. Writing readable code, adhering to coding standards/styles that are not your own.

    If other people cannot read/fix your code, then your code is unusable. If they have to re-write it with the first bug, then you shouldn't have bothered in the first place. The exception to this can be found in #2 above, however, that is the exception and not the rule. About a month later, I re-wrote the entire program using all the coding standards and rules that my group uses.

    Noone likes the allstar programmer, and while it gives you job security, you can never take a long vacation without a cellphone and laptop. You also will breed contempt with your fellow programmers who have to re-read/redo your code.

I am sure there are more to add to this list, but these are the few that come to mind at my office 2.5 hours before I usually get out of bed.

I hope that some newer programmers look at this and can sse that thier job doesn't suck as bad as they think it does. We are all in the same boat, and we all are dealing with the same problems as they are.

3 Comments


Great post. Very enjoyable read. :-)

Correct approach:

1) 'perl Makefile.PL && make installdeps'
2) fix failed installs
3) start mojomojo_server.pl -once-

UR DOIN IT COMPLETELY WRONG :)

About this Entry

This page contains a single entry by leonard published on August 3, 2009 6:00 AM.

PHP needs 'use strict;' was the previous entry in this blog.

Frozen Perl progress update is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.