Programming History and Philosophy
Let me start of by saying I'm not concerned with becoming wealthy, famous, or notorious
because of programs I write. I (usually) have a job, and I make enough to keep me happy.
I'm not going to sit here and try to convince any of you that I am the be-all-end-all of
programming talent on this planet, and I will be the first to admit to being one of the
laziest rednecks you'll ever meet. Programming for me has always been about discovering
a job that needs to be done and whippin' out some code (hopefully damn cool code) in a
timely fashion, and then moving on.
In 1984, I started teaching myself (Turbo) Pascal on an Apple //e with a CP/M card in it.
My first program was a utility that patched the Turbo Pascal executable to have different
colors in the editor (after being told by other "programmers" it was impossible to do). The
rest, as they say, is history (and history is nothing more than rumor obscured by half-truths
Since then, I've written DOS TSR's, estate planning software, game utilities, image
capture code, programs for PDAs, medical record software, kiosk software, streaming video
and encryption code, and .Net applications.
From 1991 to 2007, I mostly wrote Windows code in C++ and pretty much got a kick out of
it. Programming has become quite a bit simpler than when I started out, and even I had it
easy as far as Windows programming because I didn't really start doing it until after the
advent of C++, class libraries, and application frameworks built by wizards. Before I got
here, seemingly endless switch statements and to a lesser extent, manhandling obscure
Windows API functions were nothing more than a bad memory for most seasoned Windows code
pilots. I had it very easy by some definitions.
Unfortunately, the world seems to be heading towards distibuted web applications, and
while I agree that there really is some need for this, it's inherantly insecure, and
besides, it didn't allow me to flex my C++ muscles. Instead, Microsoft is (or was) pushing
.Net along with it's 25mb runtime library - oh, wait - there are now SIX runtime libraries
to deal with (1.0, 2.0, 3.0, 3.5, 4.0, and 4.5). For someone that didn't even like to link
dynamically to the MFC DLLs, this really irritates the hell outa me.
Beginning in 2007, I started learning the .Net framework, and the subtle differences
between C++ and C#. I have to admit that the .Net framework makes it a lot easier to
implement more esoteric functionality, and learning all this stuff has kept me interested
in being a programmer. I also have to admit that, being unfamliar with the framework, I
reinvented a lot of the wheels that are already included in the framework. I don't consider
this to be completely wasted time though, because I learned a lot about the framework
along the way (including finding out that a lot of the code I was writing was already done
By their very nature, most Windows programmers are pretty damn lazy (yeah, me too), and
will whip out butt-ugly code with no regard for memory consumption or disk space
requirements because Windows quite frankly doesn't care. Excessive paging to disk is seen
as an acceptable trade-off when weighed against the cost implications of "doing it better".
I'm tired of this kind of programming (corporate bean counters be damned), but in a
commercial/corporate environment, I completely understand the need for just writing code
"that works" in the interest of maintaining the schedule. I try to write the most efficient
code I can, and strive to comment and document my code, especially for implementation of
Finally, I'm growing weary of Microsoft's propensity for completely changing directions
with regards to "how coding should be done". For instance, after spending four years
pushing us to learn and use WPOF and Silverlight, it seems that Microsoft is now turning
its back on both of those platforms. Now, it seems that Windows 8 demands "WinRT",
whatever the hell that is. I'm glad I'm nearing the age of retirement.