Saturday, June 24, 2006

Long Programming Short

I have often wanted to equip myself to do programming in short bursts. I often think I can accomplish this in the check out line at the grocery store, or while commuting (voice recorder for driving, or handheld device for bus/train/carpool). I often think, "if only I could use all this dead time to get something done." Here's the problem: that dead time is dead because you don't have something to program that is small enough to fit a unit of it into that time, and still interesting enough to be worth doing.

Sure, I can write "Hello, World" applications all day at the 7-11, but I can't really implement an object relational mapper, or a compiler while waiting for my meal at Del Taco. Interesting problems are by definition hard. Anything that could be done in the "off time" of some other activity has already been done in every programming language, most of which you can just download from the internet for free, because the authors know it only took them 20 minutes to do.

How can we combat this problem and still end up using those lost minutes productively? One thought is parallelism. If you can break your huge task into millions of little tiny (different) tasks then you could conceivably just do a single miniscule task while you wait for your quadruple espresso. You have to maintain a list of the tasks, unify the code somewhere, and make the entry reasonable enough that you can do it anywhere.

Another idea is to use an iterative approach. Just do one small change. Refactor a single line of code, change an error message, rename a function in your program, put a copyright header on yet another file, adjust your make file, write a single test within a larger unit test framework, just do something. Squeeze in commenting the "why" of a function or portion of a function while the $3.50 gas flows from the pump to your eternally thirsty gas tank.

Can it be done? I'm not sure, but it's worth a college try at least.

Wednesday, June 21, 2006

Web Programming and Interpreted Languages are the same thing.

Client side web programming and interpreted languages are the same thing. Each runs on top of a platform that provides a layer between the operating system and the application you write. Each requires the user to download (or have already installed on their machine) some sort of "virtual machine" that intreprets text directly or some form of middle language (CL in .NET, bytecode in Java, etc.). The only real difference (and it is a biggie) is that Internet Explorer or Firefox is effectively installed on every machine connected to the internet. Both of them sufficiently support a content language (HTML), a positioning language (CSS), and a scripting language (Javascript). Why aren't we writting application servers that deliver code (in a text form, like HTML is delivered) to the browser that can then be interpreted by a plugin for the specific scripting language it's intended for (Perl, Python,Lisp,Ruby,etc.)? This would give you the centralization available with web applications, and the GUI reaction speed of an interpreted program running on your local machine. Am I the only one who thinks this would make the delivery of programs really easy while also making them user friendly?

Thursday, June 15, 2006

Wussing Out

So, I just put a two liner at the top of my "most recent" articles on my website directing people to come and read my blog. I am assuming that they have tired of reading the two articles that I had posted last year on my website. It feels something like a cop out to just let someone else do all the HTML, Javascript and backend database stuff.

Oh well, at least now I have time to do something other than write blog software, which is in such abundance I am surprised that it hasn't grown a consciousness of its own and overthrown Paraguay or attacked the Balkans. I mean seriously, how many RoR apps are required before the code become self aware. What if God was just trying to make his galatic website and he accidentally invented consciousness while he was trying to get a nice AJAX spreadsheet going? Makes you think, huh?

Thursday, June 01, 2006

Software Engineer Dissatisfaction

I read a lot of my fellow software engineer's blogs. I read technical posts. I read books. I read message boards. I read. Today, while I was reading a rant about the poor practices of most of the recruitement / technical staffing agencies when it dawned on me. Maybe this is obvious to everyone else, but hear me out. Software engineers are always dissatisfied with something (everything?), and I think I know why.

We spend our entire lives trying to quantify, qualify and design systems to be efficient, functional and easy to work on. We can't help ourselves - we even do it to non-computer systems. Whenever we look at a system we instantly see how it could be better, or at least how we think it could be better. Why hasn't someone seen this before? We don't even work in that industry and we can see how it would be better, just based on common sense. This frustrates us.
We rebel against the "that's the way it is concept" because in our code we have ultimate control, things can be better if we are willing to put in the effort. Changes in code are much faster than changes in government, society or the recruitement process. Changes in our systems are effected at the speed of light while everyone else is waiting for the bus by the side of the road.

The uglier version of this sentiment is the root of why we talk down to other groups (salesmen anyone?). We see that their system is lacking, inefficient and driven by dogma. That's not even so much what is bothering us, it is more that people caught up in that kind of a system are unwilling to do anything about it. Why won't they fix it and make it easier for themselves, more efficient and more productive? I think we collectively look down at other groups because we think they are foolish for just grinding it out day after day and not trying to improve things.

We are a progress driven bunch. So, we reject anything that does not help us get somewhere new. Why do you think it is that this industry can produce an entirely new platform to work on every five years? We want something better. We keep trying. We keep working towards it, even if it's in small steps. Hence, anything that is not changing as rapidly is clearly not being worked on enough, perfected enough, improved enough. We are blessed to be dissatisfied with the status quo, but at the same time, we are constantly dissatisfied and grumbling about the lack of progress.