And so it begins.

reciently I've decided that OLA is going to be more of a
service and informational company. By this I mean that
OLA will not just be in the business of creating
applications. We are also going to start creating
content. I specifically will start moving my focus away
from the code and into the educational arena. Have no
fear others will still be rampant coders.

To get the ball rolling I figured I'd start out with what
I know. Code.

Over the past few years I've struggled with the challenge
of being better at programming. I've spent many
hours/week/years talking to the "old timers" to get a
better idea of what makes a better coder. How does one
need to think to be not just good, but great. Here's what
I think I've learned.

1. Oh my God comment your code. I don't care how much
you think your code is self documenting it needs comments.
There is nothing like getting someone elses code and
having to read it line by line to understand it. Even
languages as simple and straight forward as python need
them. Some of the newer coders out there may say. "I
understand it". To them I wish with all my heart that they
have to read code from an ex-co-worker.

2. Every beat of your heart matters to you. It is
litterally life and death. Every cycle matters to your
processor. Ok now this is a bit over the top, but I think
that a great coder strives at all times to be efficient.
Now I'll be the first to admit that there are always
trade offs where code is concerned; however I think a
good coder writes efficient code, a great coder writes
efficeint code consistently. "So what if the order of
the if/else make a difference.... " said another coder I
know. it's not something you should spend time thinking
about. To that I say. Okay it's a small thing and don't
sacrifice too much time thinking about it. But know that
it does matter and strive to understand it.

3. Use meaningful variable names. A few years ago I was
working on a project and found a function named TKR I
asked the coder who wrote the function the day before what
the function "RFD" did. (just made that up then) he of
course didn't know. then i asked what about "POH" again
he did't know. I did this with about 5 more three letter
function names. Finally I asked about TKR, to which he
said again "I don't know, what's the point?". "The point"
I said "is that if a day after writing a function you
don't know what it does how the hell do you expect me to
know." Oh and because he hadn't commented it took use
both about 15 minutes to figure it out. (it retuned The
Known Records)

4. Use white space like it's free. (when it is)
Clummped up code is nightmarish to read. It makes even
the simplest code seem scary. That's a perfect way to
keep your job but kill your productivity. Noone will ever
want to edit what you wrote, not even you. There is also
no reason for it. (unless your using a lang that doesn't
ignore blank lines) Think of code as written english.
You'd never read a book with no paragraph breaks, the
same holds true to code.

5.

Ok. I thought I'd have 5 things but I just couldn't think
of a5th thing. Those are really all I learned, Now I'm
not new to coding and by some standards I'm not old to it
either. I do however think each one of use could be
better if we created smoe rules to live by (as coders).
Code is IMHO a very beautiful thing. Coders have a
responsibility to keep it that way.