How I became a programmer

You know those kids who learn to program in assembly at age 12?

I wasn’t one of those.

I grew up around PCs, I was even the first kid on my block with a Local Area Network, but I didn’t program for a long time. I didn’t even know it was possible.  My journalist father was on the cusp of the Computer User revolution; but he didn’t know enough to know how computers were programmed.

Ergo, he didn’t tell me.

In 1993, my school’s computer lab received 386 and 486 PCs. I found the BASIC interpreter and did stupid things like:

20 GOTO 10

I was sure I could do more with it; but didn’t have the vision to know what the ‘more’ part was. It was a novelty, but not a terribly interesting one without context.  Later on that year I opened up the GORILLA.BAS file; but I just didn’t have the vision to play around with it. The game worked the way I wanted it to; why muck with it?

Gorilla.Bas - An oldie and a goodie


Then I was introduced to the TI-93+; a programmable calculator with its own assembly language. Cool, now this has potential, I thought. I had no idea what to do with it; but I at least knew it was there.

I gamed through High school; but never took Mathmatics past Algebra III — I had a high school teacher who was more interested in her Yearbook duties than she was in teaching math.  That was a bummer because up until that point, I thought I was pretty good at math.

I attempted to get into a public university for Computer Science, but was told quite pointedly that I didn’t have the math pre-requisites to do so. I ended up winning a four year full Leadership scholarship for a local Catholic college — and they had Computer Information Systems. Huzzah.

I took Java the first semester along with Introduction to Computer Architecture and Systems; but again the vision thing blocked my path. The Architeture class took me through the physical bit flipping and memory address allocation and whatnot that happens at the very core of the microprocessor, but the Java course was so far removed from that that it didn’t make sense to me how they connected. I needed to go lower level. So I took C++. At the time the public view of Java centered around rotating cubes, and while I dig rotating cubes, I didn’t see how a rotating cube mapped to a memory address instruction.

While taking C++, I had a healthy dose of Data Structures and Algorithms and Database Design. Now this had potential. Finally, something that made sense. The courses were a lot of fun, and although I momentarily bombed on Pointers, I figured those out and was well on my way to doing fun things… Except for the fact that these classes were for the lowest common denominator, in a school that was defined as a Liberal Arts school.

Once again: bummer.

To pass the time, and because someone told me that it was the basis for all web development at that time, I learned Perl (this was right around the time PHP 4 was released, back when it was called Personal Home Page (yikes!)). and proceeded to use it for every day scripting.

Junior year I rounded out the rest of the undergrad CS curriculum (save the senior project courses that closely mirror what software developers actually do on a day-to-day basis), and started drawing up ideas for websites. My first idea was a website that users could log on to to rate and share their experiences at private retailers, a la (which came 2 years later). I never got very far because I was called up, but I always wonder what would have happened if I had launched that site.

Right as I began my senior year, the government decided that it needed me to fulfill my reserve obligation. My Army National Guard Unit was called up and off I went to Iraq.

After I got back from Iraq, I wrote VBA code in for the Army unit I was assigned to. They used an Access Database to track everything that happened in their unit. My job was to make it generate pretty reports and create whizbang features that allowed them to track the disposition of members of the unit daily, and then generate pretty reports for multiple government agencies.  Before I got there, it took an entire day and coordinating with 5 people to do. After I finished, it took 10 minutes and no coordination.

Not bad, huh?

After that ended, and three years after I was called up, I took off the uniform for the last time and went to finish college.  My senior year consisted of a senior project that required us to pick from a stack of problems and fix one of them.  Typically, the local non-profits would ask the College’s CIS chair if he could spare a few students to write a program for them; we were those few students.

I led a group to design, implement, and deploy a Winforms based client-tracking system for a local non-profit charity. The code wasn’t tiered very well, it had an ugly 1-form-tabbed interface, and it crashed a lot. But it worked. This was my second real taste of success.

Due to domestic constraints at the time, I lived in an area that had very little programming prospects for me; and ended up taking a job as a Perl Web Application Developer about 60 miles away.  The work wasn’t much fun, but that was because I was the lone contractor on that particular project.  Thinking that this was how programming was, I opted to leave the job when the contract was up and go into Systems Administration.

How different these two worlds are!  As a programmer I rarely spoke with others, but as a System Administrator, I was in a new environment almost daily, doing something new and different. The job was as varied as the day is long; and there were always improvements to be made.  I promptly used Perl to automate system administration tasks (like waking up the PCs for disk defrags, keeping an active display of which computers were up, etc). Once I finished there, I used C# and the SendKeys API to automate the startup of the Point of Sale computers.

I was good at System administration, but I was in a place where there wasn’t much of a future.  How many SysAdmins do you know that start their own company?

So I went back to programming, and have been for the past few years.

Did I mention that I love every minute of it?

The 5 types of Programmer companies

I recently had a chat with a recruiter about why I wasn’t interested in a prospect. This is the answer I gave him:

In answering your question, it’s necessary to list the categories we (Software developers) put companies into.  Depending on where a developer is at in his career, different types of companies may occupy a different order.  The ordering of the list changes depending on the developer. This is by no means canonical.

Software development jobs generally fall into one of a few categories:

1. Startup – ‘Fun’ atmosphere, chaotic, making new things, generally at the cutting edge; fails easily, pay isn’t as good, but the other benefits (working from home, relaxed dress code, casual work atmosphere) make up for it. Long hours at times. Developers care about the company and their work. Selling environment may dictate ‘ship now, fix later’ mentality (that normally leads to project failure down the road)

2. Private Company that sells software as its primary business function – Developers treated well, first class citizens; pay is very competitive and benefits are outstanding. Normally right around 40 hour work weeks (there’ve been numerous studies that show as knowledge workers work longer hours, they perform more poorly mentally); dress code varies, but normally Jeans and button down or something along those lines. Well defined process; Developers care about product and company, vested interest to see it do well.

3. Private firm that sells something else and makes software as a ‘supporting’ function – Developers more often than not are second class citizens; restrictions on what developers can do; working with new technology or making changes ‘for the better’ is hard. Pay is great, but it’s a mixed bag as to whether the other developers really care or if they’re just collecting a paycheck. Dress code is conservative.

4. Private Firm support government entity – Somewhere between 2 and 3, depending on the company.

5. Public (government) entity – Not cutting edge at all (in most cases); heavy restrictions on what a developer can do; watched like a hawk; change is unheard of.

Explain the Path Not Taken

In my travels around the blogosphere, there is a common refrain in technical advice. For any given problem, there are n number of ways of doing it, but there is one most right way.  When writers write, they have a limited amount of time, so they tell you the ‘right’ way.  They may tell you not to solve your problem a certain way; but often times they don’t tell you *why*.

Why the hell not?

The answer you didn’t choose is as important as the answer you chose.  The reasons behind it are just as important, if not more so.

Recently, I was tasked with improving the performance of an advanced search query.  The query was taking about 5 minutes to execute.  No, that’s not a typo.  After diagnosing and benchmarking the query with the resident Oracle DBA, we started brainstorming fixes; and the idea was to get the low hanging fruit out of the way.  Here are the list of possible ways to fix this issue:

1. Force the user to use more than scant criteria for an advanced search (in this case, by requiring the user to enter more information into other indexed fields)
2. Improve the query performance through adding the appropriate indexes
3. Parallelizing the query since parts of it used a full-table scan.

Pros and Cons:
Approach 1:
Pro: Allows us to defer the actual query performance issue
Con: Makes user unhappy; alters existing functionality

Approach 2:
Pro: Low hanging fruit. Easy fixes; easy to benchmark
Con: May not get us ‘all the way there’; may have un-intended side effects.

Approach 3:
Pro: Divvies up the Query into multiple threads
Con: Possible to slow the query down since those threads have to share information

We tried the latter two approaches.  I documented the first one; but did not implement it. The second approach netted a 78% performance increase when we added two indexes.
 The third approach ended up actually reducing the original query by a miniscule amount but it was three times slower than approach #2. Ultimately we added the indexes and reduced the query time by 78%; a non-trivial amount; and sufficient since the feature is used very rarely.   To put more man-hours into a fix for a feature that is so rarely used would be folly.

My point is, it’s important for the developer that comes after me to know all of this.  If the client says, “78% isn’t good enough” then the next developer will need to know what I already tried; otherwise he’ll simply waste time re-duplicating effort.

The next time you see a blog post on the internet detailing a fix, ask them what didn’t work — you may be surprised at the answer.