Talking Yourself Out Of Your Job

Starting Your Career

If you've been programming for over a year - you've probably been assigned a monotonous, unrewarding, menial and/or junior task.  In fact, I'd argue that everyone should start out doing some of these tasks.  Not because everyone should be punished or put through the dreaded "trial by fire".  But, 

1. Every company has this kind of work,
2. It is useful for perspective (to get an appreciation for "good work"), 
3. It is important to understand the basics of where you work and 
4. Lastly - then you'll be able to understand the motivation for building the infrastructure necessary to reduce this sort of work.

A lot of what you learn during the beginning of your career has more to do with learning about how to work with others in a professional setting (i.e. on a real job).  You also learn the basics of the existing technologies at the company, the API's you'll program against, the most commonly used IDE, the source/revision control system (Git, perforce, etc) and so on.

Typically someone will be assigned to you to help get you up and running.  This person will be your "buddy" and you'll likely use them a lot in order to become productive and efficient.  They might even be the person that management uses to find out how well you are doing.  So, it goes without saying you want to make a good impression.

Becoming An Intermediate Programmer

What one company calls an intermediate programmer and what another company calls an intermediate programmer can be as different as comparing an Olympic athlete with a high-school athlete.  Typically larger "professional software" companies like Amazon, Google, Microsoft, etc have a very high standard for their programmers.  Smaller companies or companies whose primary line of business isn't software tend to have lower requirements for reaching the level of an intermediate programmer.

Moving to the level of an intermediate programmer typically requires the ownership and management of one or more technologies.  There might be opportunities for you to provide guidance to others and possibly at the high end of the spectrum to mentor others.

Reaching Senior Programmer

Just like intermediate programmer - there is a wide definition for what a senior programmer does.  Some of the titles given to senior programmers are "senior software engineer", "architect", "technical lead", and so on.  

Moving from intermediate to senior programmer - is much different from the move from beginner to intermediate.  Becoming a senior programmer requires you to be able to accept and manage ambiguity (both in underlying details of tech and in planning), being accountable/responsible for technology and its development, etc.  There is also typically an expectation that you will fulfill a mentor capacity.

Say These Things to Yourself...

The following quotes should be as automatic to you as a mantra or a motto.

"Sorry - I was wrong."

You might want to say it a couple of times to yourself (make it sincere) and accept the fact that on occasion you'll need to swallow your ego and accept you've been wrong.  Now if you can accept you're going to make mistakes, here comes the tough part - accepting it graciously when someone points it out.  

You're going to write some code and you're going to think it is awesome (or at least "good") and guess what - eventually someone on your team is going to point out your code is "wrong".  Now if your code has an obvious bug - taking this criticism is going to be easier to accept.  However, if the person in question just has a different approach (error code versus exception for example) to that problem they might tell you to change it - just to appease them.  And now prepare yourself - if that person is senior to you or if they own that tech - you need to learn that is the "right way".

"I'm Your Man (or Woman)!"

Remember at that bit at the start of this post about being assigned a "monotonous, unrewarding, menial and/or junior task"?  Well - here comes another tough pill to swallow - it doesn't stop the day you become an intermediate programmer.  This is a hard one to accept and one I'm still working on myself.  On that ill fated day when your manager gives you a less than glamorous task that no one else wants to touch with a ten foot pole - do it.  Don't complain, drag your feet or bemoan the fact it has landed on your doorstep.

The important bit here is not just doing the work, but doing it to the best of your ability and accepting that that work happened to be the highest priority task.  Now if you're anything like me - you'll probably ask yourself, but "why me?" - why can't the more junior member of the team do the work?  Well, the truth is they probably could have and you could have continued working on your "more important" work.

But, when management decides to assign someone work - that task is, by definition, not "unimportant work".  Whether you agree with management's prioritization of important work is not relevant.

Now, you might be saying to yourself - "what about my experience, skills and my career progression?".  And these are all valid questions - why was this task assigned to you, why isn't management giving you the more interesting or senior work.

My advice - do the work to the best of your ability and don't complain.  Don't gripe about the work to your peers and certainly don't send an emotionally heated email.  By the way - NEVER do that (send a emotionally charged email) - if an exchange becomes emotional - talk to the person face to face - don't elevate aggression with a pithy reply.  The topic of communication - specifically email is actually significant and important enough that it warrants another post.

Only once you continue to be assigned the least glamorous/interesting work (month after month) should you raise a concern and only with management (don't gossip with your peers).  The important thing here is that you don't react the first time this happens.  When you raise this with management - don't bring emotion or ego to the table - just ask if they're unhappy with your performance lately.  If they're not consciously "picking on you" (they're probably not) mention to them that you'd like the opportunity to work on more interesting features/functionality.

In other words - when presented with this kind of work - you tell them "I can take care of that".

Okay - So What's This "Talking Yourself Out Of Your Job" Business?

Well, the intent of this blog is to try to focus on the softer skills of being a programmer or just working with others in general.

I've been programming for almost 15 years as a salaried employee and most of it has been pretty interesting.  I've had the opportunity to work with a wide range of people (intellects, social skills, cultures, etc).

The summary of this post is the way to progress as a programmer, software developer, software engineer or whatever your profession might be is to meet the expectations of management.  It is okay to disagree with management and your superiors, but if you don't want to "talk yourself out of your job" - do what is asked of you.  You don't understand why people treat you the way they treat you.  Even if your lucky enough to always understand the reasoning behind everything management or a senior person does - your job is to meet their expectations - not yours.

This doesn't mean you shouldn't ever complain or expect to be able to do interesting work.  Quite the opposite - if you "do well by management" - you're increasing the likelihood that you'll be the first person on "who gets this choice bit of work".