It's not about technology for its own sake. It's about being able to implement your ideas.
The most memorable computer science course I took in college was a two part sequence: Software Development I and II. In the first semester you built a complete application based on a fictional customer's specification. To date myself, it was written in Turbo Pascal for MS-DOS. In the second semester, you were given someone's completed project from a previous year of Software Development--a different project than the one you just worked through--and were asked to make a variety of modifications to it.
The checkbook tracking application I inherited was written by a madman. A madman who was clearly trying to write as many lines of Pascal as possible. Anything that should have been encapsulated in a handy helper function, wasn't. Code to append an extension to a filename was written in-line every time it was needed. Error checking was duplicated when a file was opened. There weren't any abstract data types, just repetitive manipulation of global data structures. For example, if there was a special case that needed fixing up, then it was handled with separate code in twenty places. The average function was over two hundred lines long. There were functions with fifteen levels of indentation.
And yet, it worked. The author of this mess didn't realize you aren't supposed to write code like this, that all alarms were loudly reporting that the initial plan and set of abstractions were failing, and it was time to stop and re-evaluate. But he or she didn't know what all the sirens and buzzers meant and hit the afterburners and kept going and going past all point of reason. And the end result worked. Not in a "you'd rely on it in a life and death situation" way, but good enough for how most non-critical apps get used.
That is why big companies hire young, enthusiastic coders. Not because they're as clueless as my madman, but because they can self-motivate beyond the barrier of full understanding and into imperfect and brute force solutions. I'd want to stop and rework the abstractions I'm using and break things into lots of smaller, reliable, understandable pieces. My code might be more bullet-proof in the end, but I still have a level of admiration for people who can bang out complex apps before they become jaded enough to realize it's not that easy.
(If you liked this, you might enjoy Do You Really Want to be Doing This When You're 50?)
permalink January 5, 2014
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?