"Playing" Programmer

A lot of us enjoy playing around with different languages, frameworks, etc.  This post isn't about you.  Others see any kind of coding as "play" because they enjoy it so much.  This post isn't about you either.  This post is about those who "play" programmer like small children "play" house.  They simply go through the motions, imitating what little they've seen of the real programming world.

There's no shame in playing at programming.  Essentially, it means you're a beginner.  The problem arises when you refuse to admit it.  If that's you, consider this article a wake-up call.  If you're worried it might be you, let me tell you a tale of two programmers:

It was the best of jobs, it was the worst of jobs.  There was a lot a freedom and flexibility at the cost of little-to-no structure in projects or planning.  "The boss" could drop a reverse eagle at any time.  Introduced into this ecosystem were two programmers.

The first one was me.  I, a starry-eyed CS student halfway through my college career, knew little about how the "real world" worked.  I started as an intern and did my darnedest to learn as much as I could during the span of my internship.  As I grew and learned, I discovered a lot.  The biggest discovery was that no one else at the company knew what they were doing[0].  Figuring the worst-case scenario would be that I would lose my internship position (hardly an issue), I wrote up a plan to integrate such basics as unit testing, source control, and code reviews into day-to-day life.

Now, I didn't know much more than "these things are needed."  I wrote a convincing argument and the administrative team agreed that they should be slowly integrated.  We started the long, slow process.  (I hadn't learned about Agile yet).

Then a new programmer arrived.  Let's call him Bonzo.  He was a likable person but had several flaws in his programming character.  I hope it's enough to say that he vehemently defended his exclusive use of Internet Explorer, saying "if it works in IE, it should work in other browsers."  Over time, he claimed that unit testing only wasted time and that it'd be much more efficient if we spent a dozen man-hours a month maintaining our own git server instead of GitHub.

What separated us?  We both were midway toward getting a programming-related degree.  We were hired to do about the same job.  However, I was constantly seeking to learn and improve, while he maintained the status quo.

If you're like Bonzo, it's time to make a change.  Doing things because they "make you a programmer" won't work.  Heck, even programming won't make you a good programmer unless you seek to improve.  If you're in a programming rut, good news: You can improve.  Start learning some of the tools of your trade.  The best place to begin is the Joel test.  Go through the list.  If you don't have experience with something (build systems,  bug tracking) get some (even if it's on a personal project).  Make sure to connect with other programmers (preferably outside your workplace) and learn from them.  Even Eric Schmidt has a mentor.  Find an open source project to contribute to.  Learn a new language (or a new use of an old one).  Finally, move into more advanced tricks of the trade, such as unit testing.

The only shame in being a beginner is stubbornly staying one.  There's no excuse.  Go be awesome.

[0] With regards to programming.  It was an IT company that had developed a small software division, and they still treated software projects like they were IT.