A Quiet Path

Programming computers is one of the most exciting fields out there.  Of course, this is according to me, a computer programmer.  But what does a programmer do, exactly?

At the most basic level, a programmer is telling the processor of your machine what to do.  Immediately, this is limited by what the programmer can consider.  If a programmer doesn’t think of, say, a color palette when selecting how to display text, the color palette will not be there.   So we have limited what your program can do simply by being the person to create it.

Next, the programmer is translating what the user wants into what the computer can do.  This, I think, is where many software packages fail to one extent or another.  Does your programmer really understand what the user needs?  Has the user articulated what they need?  Has the user made known to the programmer, in a way the programmer understands, what the user wants?  I’m not saying that users (or programmers) aren’t people.  But some programmers, and some users, don’t look at things in quite the same way.  So building an understanding between programmers and users is difficult.  Especially for large scale systems, like Word, Linux, or Windows.  So many users, with so many different ways they want to work, and so few programmers – and even fewer official releases, which are the final arbitrators of the programmer’s work.  So here we have two more limits –  how well the user can use your program, and what features you create that show up in the releases of your program.

Then there are bugs – the issues that the programmer didn’t intend, but end up happening.  These sometimes happen because of the way the programmer thinks about a problem, which may be different from the way the user thinks about it.  They may arise from multiple features interacting with each other, or the program running on a platform the programmer didn’t expect (less memory, or no keyboard available, or whatever).  They may arise from simple issues, like mis-named or re-used variables.  Or perhaps from art that looks right, but ends up being the wrong size, or doesn’t correctly use alpha channels, or any number of other issues.  But they exist, and not all bugs will be fixed before release.

This is all very philosophical, but builds to an important point – no matter what the programmer does, they will never create the perfect program.  There are too many users, too many features, too many bugs, and too many assumptions by the programmer to ever create something that everyone can use.  Any program beyond a simple “Hello, World” will experience some kind of problem, and even “Hello, World” will have issues such as “But what about the universe?  You didn’t greet that”.

That doesn’t mean the programmer’s role is hopeless.  Far from it, in reality.  The programmer is in a unique position to listen to their users, define interfaces, and eventually create code that tells the computer how to do most of what most users need from their program.

One facet of a great programmer is the ability to work with others.  This can be shown by the ability to work within a team of programmers.  Or to talk with artists and figure out how to make a better color wheel that will save them 5 minutes a day.  Or to accept feedback about bugs, and fix the issues, even if it was someone else who really caused the problem.  Bonus points if you work with that person, so that both of you learn something new about fixing the issue.

In the end, I see the role of the programmer as an assistant.  We take what others want/need, and make it happen.   The designers create the world.  The artists make things look nice.  The programmer takes the design and art, then pushes the machine to bring that vision to the user.

This means the programmer must constantly learn new things – be it the most popular terms in paint packages, how to manipulate 3D models in a modelling tool to format them for display, discover how to convert a boss character into code (efficiently, hopefully using some previous standard for boss characters), cinematic camera techniques to show off AI decisions, or whatever else may come their way.

And one of the biggest lessons is that while perfection may be unattainable, great software can still be made.  It takes time.  It means listening to others.  It means fixing bugs that you would never encounter the way you operate, but others will.  It means project planning, and knowing when to say that a given feature or bug fix is too risky.  And it means learning new things whenever you can, so that you can get that much better for the next project.