When it comes right down to it, programming is simply simplifying a process into a step-by-step procedure.

The trick is to make the code so simple that humans can understand it easily and quickly too.

I believe than anyone should be able to write code!  It is fun to get into the flow of coding and even more fun to see the end result: a working program.  I have seen instances where the code was much more complicated than it needs to be.  This makes me wonder whether the original author was in a rush, was working late at night, or just plain wanted better job security for being the only person capable of understanding and changing the code.

Code should be written to be as simple and as easy to maintain as possible.  If performance issues appear after the code is delivered, and adding complexity can increase efficiency, then that is fine!  

But it is crucial to realize that if no one else can understand the code, then all I can say is, good luck trying to make it run faster!

I feel that in the rush to get things done, in some cases quality code takes a back seat to timely deliveries.  

To an extent this is fine and quite understandable.  Missing a deadline is just as likely, if not more so, to cause a project to fail, and moreover the term "quality code" can easily mean different things to different people.

  • Unless explicitly directed otherwise, I will deliver code that is as simple and as maintainable as I can make it.  Early in my career I learned that maintainability is key and many experiences have reinforced this lesson.
  • If I see something is broken in the project, I will tell you about it.  If it is in an area of the code that I am tasked with changing, unless explicitly directed to leave it alone, I will feel obligated to fix the problem.

If these opinions seem obvious to you, good: that means we think alike!

I have wanted to take on more short-term, side projects for many years, but a couple of concerns have held me back.  This article addresses those concerns head-on.

  1. No "under the table" work.
    If there is one thing I want to avoid in life, it is drama with The Government.  I fear that when some people think of "short term projects," they think of "under the table" work.  I actually had a close friend do some "under the table" work one summer, and the IRS eventually found out about it.  That is not something I am willing to go through.
  2. Side projects must not interfere with full time work.
    Another reason I have been a bit reluctant in the past to take on side projects, is I am concerned that they will interfere with my full time work.  Jobs today take a lot of energy, and it can be difficult to switch from one development environment to another.

Number 1 should go without saying, but I want to put it out there anyway.  If you pay me for work, I will report it on my taxes, regardless of whether you send me a 1099.  Because that is how I roll.

Regarding number 2, this is why I am most interested in small side projects.  Different jobs require a different level of commitment, often at different times.  Sure we can always pull an all-nighter to crank something out, but often that results in a low-quality project or next-day-grumpiness at best.  I want to avoid that as well so it is best to be upfront about how I feel I need to set priorities.