Career advice for the newly minted programmer

Become the go-to guy for something useful

I’ve worked in some big software departments, some of up to 600 people.  The easiest way to stand out from the crowd is to become an expert in something.  It doesn’t have to be a big something, but it has to be something that comes up from time to time.  Bonus points if it tends to come up in emergencies.

Probably the best example is to become an expert in something related to the organization’s data.  The database schema, where the data comes from, quirks and issues with the data, or anything along those lines.

Is there a technology used in-house that isn’t common or popular (semi-obsolete and/or hated languages is a great example).

At one of my former employers, a huge financial services company, I was known for a couple of things.  I was really good at Perl, and I could debug and fix very complex SQL queries.  They didn’t even use Perl, but management knew that if the building was on fire and we needed to do something really weird, with gobs of data, really fast, I was one of the best bets to do it.  Those two skills got me alone in the room with senior management several times, and gave me a chance to save the day more than once. 

Be a leader

This should be a no-brainer.  A lot of the time you will find yourself on a small team.  Yes, the team reports up to a formal leader, but nothing prevents you from just taking on informal leadership within the team.  Be the one that keeps track of status and shares it with your leader, try to think a step or two ahead of where everyone is currently working. Programmers as a whole tend to be type B introverts and nerds, and proud of it.  Let them be.  You be type A.  Be a natural leader (even if it’s a bit unnatural for you at first)

Don’t be a brown-noser

I just said be a leader.  What I didn’t say is to be a yes man.  People see that a mile away.  Leaders lead, they don’t just stand in the shadows and repeat what the boss says.  That is the opposite of leadership.

Stand out by knowing when not to talk

You know the one.  Every single time management asks if there are any questions, they are the first with their hand up. Don’t do that.  It’s transparent, and a great way to annoy both management and your peers at the same time.

Before you ask a question, ask yourself; does anybody else here really want to know the answer to this?  Am I just seeking attention?  Is this better asked one-on-one?  Does this put my boss in an awkward position?

The bigger the meeting, the more you should think about keeping your mouth shut.

Be a professional

I could go on all day, and probably have on more than one occasion.  There is a world of difference between someone that writes code and a true professional.  When you are working in a professional capacity as a computer programmer, there is a lot more to the job than just hacking out lines of code.  These distinctions are often what separate an entry-level developer from a respected professional.

Design

Have you ever seen a professional paint a car?  There is so much up front work; disassembly, preparing the surface, masking, testing the sprayer, before they even think about spraying any paint.

The easiest way to tell a junior developer from a pro is that the pro does all the up-front work while the junior just jumps in and starts typing away.  In a program of any size, there are requirements to be gathered or at least clarified, technical research, interfaces (both API and human) and other design work before you start coding.  Of course there is common sense, and there are those that spend all their time designing in order to put off coding, but that’s a different story and generally a senior developer problem.

Document

Professionals document their work.  It’s that simple.  You need to document your design, the database, the U/I, how to identify and resolve issues.  You need end user documentation, developer documentation, and support documentation.  Your code needs enough comments that a person can read it and understand WHY things are happening, not what.

Test

Yes, a company of any size should have a dedicated QA team.  But many don’t, and even if they do, you as a programmer are the first line of defense against buggy code.  Slamming under (or un)tested code into production is noob 101.  Test thoroughly.  This means allocating time in project planning for testing. Whenever possible get users to test and signoff (informally if not formally) that it is good to go.  I can’t tell you how often I see people release code that is not fully tested and end up breaking prod.  

What goes right along with that is having a rollback plan ready.  Both for the deployment itself if something doesn’t work in production, but also if something serious comes up days down the road.  Rollbacks are critical documentation, whether management explicitly asks for it or not.

Wrapping it up

Stand out from the crowd by being the person they go to in emergencies.  That’s the quickest way to get management to remember and bond with you.  

Be the person that your peers look to as the de facto leader.  And remember, transparent stooges are not leaders.

Do your work like a real professional.  Your management, if they’re any good, is going to demand that of you anyway, so just do it rather than put them in the position of having to babysit you.