So You Want to Be a Coder

by ATrigueiro

If you want to be a coder and you want to be able to do it for a long time, then use the"two out of three ain't bad" rule.

This advice is directed to those who have finally broken into their first coding job and know they want to do this as their career.

I have been coding for over 30 years and been paid to code in upwards of 60 to 70 coding or scripting languages.  During that time, there have been a couple of moments where I felt completely unemployable.  I first started on mainframes, and when the Graphical User Interface (GUI) became all the rage, I was asking myself, "Why do people need mice?"  I was a very good typist and the mouse seemed to slow me down.  I did not want to learn about using a mouse.

However, I realized if I still wanted to be a coder, I needed to adapt.

As a very good typist, I did not want to use my right hand to operate the mouse, so I learned with my left hand.  I use a right-handed mouse with my left hand.  I am a bit of an oddity when people look at my seemingly crazy ergonomic setup, but it works for me.  However, being a "real old" coder is even more of an oddity.  I feel like a unicorn sometimes.

I stayed being a coder and learned that I needed to constantly look forward to what was being popularized in the mainstream and in the IT world to keep this career.  At one point in the mid-1990s, relational databases were taking over and if you could not operate in Structured Query Language (SQL), then you would not get a job.

In the late-1990s, the World Wide Web took off and being able to code anything on the Internet made one very employable.  I lucked into that, because "fancying myself a writer" meant that when the ability to publish to the "public sector" with HTML became a thing, well, I jumped in.  That meant as the dotcom boom took off, I was very employable.

Now in the 21^st century, relational databases have begun to fade in favor of less "structured" data stores, like MongoDB.

A web technology invented by Netscape (remember that browser?) called JavaScript is rapidly growing into all development areas, not just the so-called "web world."  Whether JavaScript will continue to be on the march is hard to know, but when Microsoft creates a language (TypeScript) that "compiles down" to JavaScript, it is hard to argue.  In the old days, compiling meant creating a machine language executable.  Is JavaScript going to be the "machine language" of the 21^st century?  Dunno.

In any case, it must be clear to you now that being a coder is a pretty steep hill, and once you get to the top, it is only climbing other steep hills that keeps you being a coder.

I write this to give you fair warning of what you are getting into.  Right now, the salaries are very good if you know the "technology du jour."  You may land that killer paying job right now, but make sure to save some money for the lean times.  Every five to seven years, you will likely have to step down to a lower salary to get immersed in the new tech of the day.  Relearning your job every five to seven years is really hard and that is why so many coders morph into project managers and executives.

One of the most frustrating parts of being a coding professional is that most of your work - and definitely the hard work - is behind the scenes.

The work of coding is so much in the "virtual" world.  Unlike a bricklayer, who can point to the walls and buildings he has built or a teacher, who has many students that they have touched in the real world, much of the coding professional's work is in the virtual realm.  It is hidden and ephemeral.  Even those things that are great accomplishments to your colleagues can only be shared for a very finite amount of time.  It is hard to share that super-efficient COBOL algorithm you wrote 20 years ago with any current colleague without being seen as "behind the times."  Still, there are workflows, ideas, and configurations that can remain for decades after.

Nonetheless, if you are planning on coding for more than 30 years like myself, be prepared for the cyclic nature of the job.  Sure, it is tied to the economic cycle, but it is also tied to a tech cycle.  The tech cycle is the tough one to ride.  You can move to that project manager job or move into the C-suite track to preserve your salary, but you will never return to coding, most likely.  The reason most make the switch away from coding is to avoid the hit to the salary and the ego that riding the tech cycle can mean.

Why do it?

Here is why I have done it for so long.  I am a "hired brain," kind of like a hired gun in the Old West.  I am hired to bring my intellect, experience, and coding to the specific problems of a given business.  This is one of the great benefits of being a coder.  You learn a lot about different businesses as you move through the tech cycles and economic cycles.  Also, when you "have skills," you can cut your own deal.  You want four 10-hour days, just negotiate it up front.  Negotiate everything you want up front when you are at the top of the tech cycle.  The independence this brings is liberating.  The ability to tell an abusive manager "buh-bye" in front of other long suffering staff is pretty cathartic.

However, riding the tech cycle isn't the hardest thing to do while managing your career.  The hardest thing is knowing when to leave.  It can be very difficult to leave a good salary and a comfortable job with people you know.  The economic cycle rarely matches the tech cycle and this can make the decision difficult.

Here is the secret to deciding when to leave.

Use the system that I call the "two out of three ain't bad" system.  There are three main factors to consider when deciding if it is time to move on.  You need this system badly, because looking for the next job is hard.

You have to be convinced that you need to and this is how you determine that:

1. Do you get compensated well?
2. Are you working on current technology so your skills are still in demand?
3. Do you like your boss?

Note how two of these three factors are not tied to tech.

One is about economics and one is about quality of life.  As long as two of these three things are true, then it is O.K. to stay, but if it gets down to one, you need to move on.  If you like your boss, but you have to answer "no" to the other two questions, then it is really time to start looking.  When you hate your boss, it can be a lot easier.  It is when you like your boss or you are getting paid a lot of money that this formula is most useful.

Use the "two out of three ain't bad" rule and you will be able to make that difficult decision to move on to the next job.

That is usually every two to four years, to be honest.  And yes, I have had over ten W-2 jobs in the last 30 years and numerous contracts.  In that career timeline, I am still counting the first corporate coding W-2 job as well - and that went seven years - because it is the one that taught me this valuable lesson.

I'll let you crunch the numbers from here.  You are a coder, after all.