https://prog21.dadgum.com/154.html

programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to
implement your ideas.

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.

permalink October 3, 2012

previously

  * Digging Out from Years of Homogeneous Computing
  * What's Your Hidden Agenda?
  * Minimalism in an Age of Tremendous Hardware
  * The Goal is to be Like a Bad Hacker Movie
  * Hopefully More Controversial Programming Opinions

archives

twitter / mail

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?