I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
Do You Really Want to be Doing This When You're 50?When I was still a professional programmer, my office-mate once asked out of the blue, "Do you really want to be doing this kind of work when you're fifty?"
I have to say that made me stop and think.
To me, there's an innate frustration in programming. It doesn't stem from having to work out the solutions to difficult problems. That takes careful thought, but it's the same kind of thought a novelist uses to organize a story or to write dialog that rings true. That kind of problem-solving is satisfying, even fun.
But that, unfortunately, is not what most programming is about. It's about trying to come up with a working solution in a problem domain that you don't fully understand and don't have time to understand.
It's about skimming great oceans of APIs that you could spend years studying and learning, but the market will have moved on by then and that's no fun anyway, so you cut and paste from examples and manage to get by without a full picture of the architecture supporting your app.
It's about reading between the lines of documentation and guessing at how edge cases are handled and whether or not your assumptions will still hold true two months or two years from now.
It's about the constant evolutionary changes that occur in the language definition, the compiler, the libraries, the application framework, and the underlying operating system, that all snowball together and keep you in maintenance mode instead of making real improvements.
It's about getting derailed by hairline fractures in otherwise reliable tools, and apparently being the first person to discover that a PNG image with four bits-per-pixel and an alpha channel crashes the decoder, then having to work around that.
One approach is to dig in and power through all the obstacles. If you're fresh out of school, there are free Starbucks lattes down the hall, and all your friends are still at the office at 2 AM, too...well, that works. But then you have to do it again. And again. It's always a last second skid at 120 miles per hour with brakes smoking and tires shredding that makes all the difference between success and failure, but you pulled off another miracle and survived to do it again.
I still like to build things, and if there's no one else to do it, then I'll do it myself. I keep improving the the tiny Perl script that puts together this site, because that tiny Perl script is unobtrusive and reliable and lets me focus on writing. I have a handy little image compositing tool that's less than 28 kilobytes of C and Erlang source. I know how it works inside and out, and I can make changes to it in less time than than it takes to coax what I want out of ImageMagick.
But large scale, high stress coding? I may have to admit that's a young man's game.