Peter Lyons

Leveling Up: Career Advancement for Software Developers

Table of Contents

Introduction

TL;DR -> Click here to jump to the first real point if you hate introductions

This guide explains in detail the three key pillars to achieving success in a large software company. Success is defined here as a combination of desirable outcomes, including the following:

The purpose of the guide is to help developers quickly become highly valuable to their organization, and to therefore get promotions, raises, and quality of work benefits on an accelerated time line.

Audience

This guide is intended for professional software developers. The optimal target audience is the following group of people:

However, much of the more general information in this guide applies equally well to other IT roles including system administrators, devops, DBAs, network administrators, etc. A lot of this also applies to smaller software companies, although generally they wouldn't have so many different formal positions and titles available for a promotion track.

Scope of This Guide

This guide is based on my experiences at medium and large software development groups, including areas such as:

This guide may not apply as directly to other segments in the software/IT industry. The advice here is still valuable, but I don't have enough direct experience with the following areas to claim first-hand knowledge of how things work:

Thoughts on the Job Market

For what It's worth, here are my thoughts on the fluctuations in the job market for software developers. The market is consistently huge and favorable. Boom or bust and anywhere in between; if you behave according to the principles described in this guide, you can be assured that an interesting and rewarding job is always going to be available to you. Job security for competent and effective software developers is always sky-high.

Worried about your job going overseas? Again, make yourself valuable to the business using the advice in this guide and you'll be immune to this. The section on Pillar #2, Communication, shows how to communicate effectively. Someone twelve hours away may be able to contribute valuable code, but there's a strict limit on how deeply they can engage with the business given the realities of email from many time zones away.

Thoughts on Salary

Software developers are paid a very wide range of salaries. The high end of base salary is easily five times the entry-level salary. Steve McConnell, author of Code Complete and an advocate of the 10x productivity notion, has this interesting blog post on compensation (Link is to web archive, original URL was http://forums.construx.com/blogs/stevemcc/archive/2011/01/22/10x-productivity-myths-where-s-the-10x-difference-in-compensation.aspx)

Pillar #1: Technical Competence

Surely technical competence and the ability to do your job better than your peers is fundamental to career advancement, right? Well, this may come as a surprise to you, but technical competence is NOT the most important factor. Pillar #2, Communication, is by far the most important factor in how quickly you can advance your career. I'm discussing technical competence first only out of conceptual simplicity and to get these basic points covered so we can then focus on the second and third pillars, which are where all the magic lies.

So in this section we will review the core technical skills that are most crucial to our goal of rapid career advancement. If you want to advance, you need these technical skills and you need to be legitimately good at your job. This guide is about how to EARN promotions, and not some way to game or fake your way to the top.

Operating System Basics on Several Platforms

There are hordes of developers out there who know a single OS reasonably well. However, in just about any business, it takes more than a single OS to make things run. Thus when something needs to be done on a different OS, the single-OS developer is useless to the business and unable to help. If a basic problem is encountered on any OS, and you have to shrug and point to a colleague who can look into it, it sends a message to management that you are low-skill, entry-level, and should be compensated according to the technical problems you can solve. However, if you have basic familiarity with the different platform, you can at least do some basic troubleshooting or development work, and management views you as more of an asset to the business.

Unix/Linux Basics

There are almost no scenarios where basic (well, intermediate really) familiarity with a Unix style command shell (Bourne Shell) and essential command line utilities are not critical to doing anything useful. If you have basic capabilities with using a Unix command prompt, spend some time refining them. If you are a pure-Windows coder only comfortable inside your IDE, plan to invest some quality time on a Linux machine and get yourself comfortable with that too.

Linux-specific Competencies

Windows Basics

Like it or not, you must learn at least the bare minimum about Windows.

TCP/IP

Get and read a good book on networking with TCP/IP. The canonical work is TCP/IP Illustrated. I also found the training material for a Cisco Certified Network Associate (CCNA) to be fantastic. I used Todd Lammle's CCNA Study Guide, which comes with network simulation software so you can cable up switches and routers, edit their configurations, and see if things work properly. A solid understanding of TCP/IP information is incredibly important. This is pretty much the only single technical topic where every last bit of knowledge depth I have gained has paid dividends in the real world. It's very easy in technical topics to go overboard with knowledge and skill in most areas: for instance, how useful is my knowledge of the low-level details of how x86 PCs format and address hard drives? For practical applications, this information is essentially useless. However, TCP/IP is different. It's everywhere and you can get real benefits from gaining a deeper than average understanding.

Here are the key points you should understand

Troubleshooting and Problem Analysis in Many Environments

This is a chance to really shine outside of your primary role of writing software. When things break, the management chain starts to hear about it quickly and problems escalate up the chain. Management is going to reach out in desperation to anyone technical who can provide a fix. If you can step up and cleanly troubleshoot and resolve the issue, your name will be heard by at least two levels of bosses, and it only takes one or two of these incidents to get on the fast track for promotion.

Quickly Learning on the Job

The information you need is out there on the web. However, searching and finding highly specific technical information in a general-purpose web search engine actually requires a particular skill. It's not all that easy to track down obscure error messages from the inner depths of some obscure fiber channel driver, for example. Hone your skills at tracking things down. In particular, there will be lots of useless crud to wade through from bulletin boards of clueless people discussing their cluelessness with each other.

Becoming the "Go-to Person"

This is an easy way to build a reputation and get an assured spot on the next round of promotions. A "go-to person" is the single individual within an organization who can handle a particular issue or area. When you are the only person who can do something, you are more valuable to your organization. There's a formula you can follow to achieve this. Select an area that is difficult, annoying, or otherwise undesirable to most of your peers. Dig in deeply to this area, and get to where you are an expert. Everyone else will run from those issues and you can step up with confidence. Management will notice this. The comparison between most of the staff who can't handle this area, contrasted with your mastery, reflects really well on you.

Here's how I did this at my first IT job working the help desk at my college. It was the late 1990s and my college had predominantly Apple Macintoshes. It was a small liberal arts college which meant that for the most part each department operated more or less independently and there was no centralized support for many back office functions - including for sending out mass mailings. What this meant is that across campus there were a dozen or so administrators who were trying to take a spreadsheet and merge it into a form letter to print out a customized mass mailing - and here's the kicker - and print the envelopes too. We got a lot of calls about this in the help desk, and you can understand why. Printing a document is something these administrators did every day, so they generally had the hang of it. However, doing a mail merge and printing envelopes only happened a few times a year, and so the person doing it was often trying for the first time. Thus, a lot of help desk calls got generated. Additionally, just as the administrators didn't do these things every day, your average help desk consultant only got a call about mail merge or envelope printing every so often. At that time, it was pretty tricky and very frustrating to do this with the office software and printing software on Mac OS 8/9. There were three wrong ways to load envelopes into the printer envelope feeder, but only one right way. Getting the printer drivers to actually load the envelopes instead of letter paper was tricky, and varied according to the actual model of the printer. The mail merge only worked when you followed a specific voodoo path of configuration and data formatting.

So after I hacked my way through a few of these, I realized the other help desk support staff feared and hated these calls. Although it was tricky, I thought I could get the issues figured out and mastered. So that's what I did over the next few calls. I experimented and eventually learnt enough that for half a dozen different printer models and combinations of Mac OS versions, I could tell a caller exactly how to load the envelopes correctly and configure everything so they would print out correctly the first time. Within a few weeks of me leaving for a mail merge call and returning successful and unscathed after 30 minutes, word got around that I was the "go-to person" for envelope printing and mail merges. All the tickets for this started to come to me. If a call came in while I wasn't working, it would be queued up and an appointment made for me to go there when my next shift started.

Let's look at this from a management perspective. The managers track the help desk metrics and notice what issues are problematic. Suddenly, what used to be a royal pain resulting in lots of unhappy customers is now a solved problem requiring less time and resulting in customer delight. This is the kind of thing my supervisor would bring up in her weekly status meeting and note to management. This positive visibility to management is key. Managers lean one way or the other very quickly based on small amounts of data. So if you ask them for a raise or promotion a little ahead of the normal schedule, one or two of these incidents might be all that you need to get the nod.

Crossing the IT Silos

In many large organizations, expert specialists are hired into different groups such as networking, storage, database, operating systems, application servers, security, GUI, and patching. These people develop an expertise in a single area, and spend then all their time focused on that area. This creates an environment in which the situation often occurs where if a problem is fully contained in a particular silo, the experts in that silo are competent to resolve it. However, this also means that there is usually a dearth of systems integration knowledge and end-to-end understanding of how a complex system functions. For several reasons, the problems that cause these systems to fail or misbehave often lie across these silo boundaries. If you develop a small amount of expertise in each area and focus on how they interoperate and integrate, you can resolve these problems. By positioning yourself as a systems integration troubleshooter, you are opening up lots of opportunities to step up and resolve tricky problems and thereby gain a lot of positive management exposure.

Actively Adding Value and Taking Initiative

Periodically step back and take an analytical look at the state of the company. Are the processes and tools working effectively? What are the pain points and problems you might be able to improve? Find something that is not working and take on a small side project to get it fixed. When doing this, it is best to follow through on your own initiative as opposed to asking for permission beforehand. For example, in the early days of Opsware we had no good collaboration tool beyond email. Our consultants were discovering complex processes that we needed to share with each other effectively. Email is not a good tool for this. So one of our consultants took it upon themself to install and configure a MoinMoin wiki we could use to collaborate on technical documents and projects. They had it up and running before they even mentioned it to management. The wiki quickly became one of the company's most valuable IT assets and completely mission critical. This is still true seven years later. Many times this type of project doesn't require that much work. Perhaps a weekend of research and configuration and little or no coding. However, this can have a large long-term positive impact on the business, which will get noticed and appreciated by attentive management.

Pillar #2: Professional Communication

I made communication the second pillar so that we could quickly get the technical stuff out of the way before diving into the heart of the issue. Really, communication is what it is all about. This is what distinguishes the developers that go from entry-level to top-level posts in five years instead of twenty years (or never). So here's the magic of this guide. Communication is the single biggest factor in your success, and it's also the easiest to improve in leaps and bounds. Pay close attention to the information here: it has the potential to gain you tens of thousands of extra dollars in salary and benefits on an accelerated schedule. As we go over the various tactics for improving communication, you will see that they are straightforward and not at all difficult.

The "Duh" List of Things Not to Do

Don't annoy management.

If your manager finds your behavior irritating, they are likely to discriminate against you when it comes time for promotions, regardless of your professional output. There are many things software engineers do by nature that can easily clash with and annoy managers. It is straightforward to address these issues, and it can have a big financial payoff. This stuff is so easy and obvious that I slap my palm to my forehead every time I see someone violating these rules. They are in many ways common sense, manners, and courtesy, but even so, the unprofessional elements of hacker culture often reveal themselves inappropriately in a professional setting.

Again, all of these rules should be "no brainers"; things that you should just do, without needing reminders. They are easy and they maximize your chances of success. If you violate them, you take yourself out of the running for the biggest raises and promotions. You might like saying "asshole" a lot, but if I said you'd get $10K a year more if you stopped saying it, you'd probably clean up your act. Another way to think of it is, if I charged you $6.40 for every time you swore, you would probably stop swearing so much. That's how the math works out if you swear 6 times a day for 260 work days a year (2011) and it costs you a $10K raise.

Write good emails when interacting with customers.

Here's an example of my response to an annoyed user at my college. This was from 2001, when downloading multimedia files was all the rage, and our network was unable to keep up with the sudden large increase in bandwidth usage. The user sent the following email to the general help desk address. (The name has been changed)

Is there a reason why it seems to be impossible to sign on to AOL Instant
Messenger (AIM) during the day? I was told by one rcc that network usage
by various applications was ranked, and so those with a low priority almost
could not be used. This seems unreasonable. IM-ing is to many people as
vital a component of communication and information as email or the Internet
is. With all the bandwidth problems that the college seems to be having,
shouldn't you just buy more lines rather than attempt to dictate the
importance of one application over another (such as surfing the web over AIM
or RealPlayer)?

John Doe

Here is the reply I sent.

John,

CIT is aware of the many problems we are having with our network this
year and we are working hard to keep all network services usable while we
wait for more bandwidth to be installed. We are in the process of
acquiring additional bandwidth. Please keeps your eyes on
http://www.oberlin.edu/cit/ for network related news in the coming weeks.
Things should improve soon, and the bandwidth shaping policies that we are
implementing are not meant to claim that one use of the network is more
valid than another, but merely to make sure that a few users do not
consume all bandwidth and prevent classes that use the Internet from
functioning. As you may know, the widespread use of Napster and Gnutella
software virtually crippled the network in the fall.

Hang in there,

Peter Lyons
Help Desk Consultant

Now, this is a pretty straightforward response. There's no magic here and I didn't actually solve anyone's problem, technical or otherwise. However, this email got my name mentioned at the executive staff meeting because here we have some student (I was 22 years old at the time) who is representing the organization in a positive way in face of an upset user.

Around 2009-2010 it became much more common for companies (especially small companies) to be very honest and straightforward when communicating with customers about outages and other problems. There are now many good blog posts available to serve as examples of communicating clearly and helpfully to customers when problems arise. Read this example from github for reference.

Make sure management hears your name in a positive light.

Every time your name gets specifically mentioned amongst management in a positive context, you build your reputation by more than you would think. Managers and executives are decision makers, and in general, they usually only have access to summary-level information (hence the term "executive summary"). They don't always see details. So if a manager two or three levels up your management chain hears your name twice a year, and there are several dozen engineers working at your level, that might be all it takes for you to get the nod when promotion time comes around. So jump on whatever opportunities arise to get recognition and be sure to take credit for the work you do. Even a small amount of effort here can pay dividends.

Use the two-part summary/details email format.

When you have resolved a high-profile issue, you will want to send out a status email to let the interested parties know that the issue is resolved (and that it was resolved by you). It's very important that you deliver this information in two distinct sections. First, write a very brief non-technical executive summary of what the problem was and how it was solved. Do not use any technical jargon in this section. Next, in a clearly differentiated section, you may offer a further level of technical detail. Here's an example from my career.

John,

Last night we discovered an issue preventing transaction processing in the
Ohio facility. We were able to investigate and resolve the issue within 90
minutes. The transaction processor was caught up to schedule again by
4:30am. We have added a monitoring script to provide early warning should
the situation occur. Technical details are below.

Pete

Technical Details:

The /const file system on tp904.oh.example.com filled up. This caused the
transaction processor to exit. We freed up space by moving archived log
files to the SAN storage. We ran an integrity check on the transaction files
(chkinteg.09), and no problems were detected. We restarted the transaction
processor and verified that it was able to process all transactions and get
caught up. We added an OpenView alert script for all transaction hosts to
warn if /const becomes more than 85% full.

Sample #2 of two-part email format

OK, we have a full understanding of all of the myriad issues ----
was experiencing around OS Provisioning now. Thanks to ---- for
their assistance with the extended troubleshooting process and to
Opsware support and sustaining teams that spent lots of time and
energy pouring through logs and digging deep into the problem to
find and solve the issues.

Customer: ----

Problem: OS Provisioning fails inconsistently

**Executive Summary**

---- was experiencing failed OS Provision attempts nearly every
time, with builds getting to various stages before failing.
We have identified multiple underlying problems causing
failures at different points. These include environmental
problems, a set of circumstances than can cause the Opsware
build manager to get into a bad state, and recently-updated
HP NIC drivers causing the server to change IP addresses at a
critical point during the OS Provisioning process.

The environmental factors hae been addressed. The short term
workaround for the build manager is to 1) only redo the RAID
config when really necessary and 2) restart the build manager
nightly or as needed. The medium term fix is to fix a bug in the
buildscripts. Long term, the build manager should be made to
survive even when the buildscripts contains this type of problem.
The temporary workaround for the HP NIC drivers is to skip them
during OS Provisioning and install them later and trigger a
hardware registration.

**Environmental Fixes**

During troubleshooting and environment verification, several other problems
in the environment were identified, although there is no evidence that any
of these contributed directly to the provisioning problems.

* Servers get the incorrect IP address during network boot.
  * Troubleshooting efforts identified the root cause of this problem to be a
    misconfigured managed server running VMWare serving DHCP on the provisioning
    VLAN. Only 1 device can serve DHCP on a given VLAN since it is based on
    broadcasts, and thus the managed servers being built would be assigned an IP in
    the 192.168.160.x range, which is not reachable from the Opsware core. The rogue
    DHCP server was tracked down with the support of ---- networking group and
    disabled. The problem was then resolved and servers could successfully enter the
    Opsware Server Pool.
* Build Scripts not the same
  * The OS Provisioning build scripts were not identical between --- and ---- data centers.
    The differesces appear to be insignificant. However, the files were brought into
    sync. The DOS boot images were also checksummed and confirmed to be identical
    between data centers.
 * Database inconsistency
   * There were some remaining differences between the databases in the two data centers after the
    automated resolution tools used by Opsware support had finished. These required
    manual intervention and were brought into sync manually. The multimaster mesh is
    now clean with no conflicts.
 * Incorrect time zone on ----
   * This server was configured for EDT while Opsware requires UTC on all core servers.
    The other 5 servers in the mesh are correctly configured for UTC. This was fixed
    Thursday morning by editing /etc/TIMEZONE and rebooting.
    ...

Note these key points for communication.

Use corporate speak.

Listen to how managers and directors talk and use the same terminology as they do.

Use the right level of technical detail and jargon for your audience.

There is some art to getting this right. If you are communicating in detail about a bug to a fellow developer, feel free to be fully technical. Communicating to tech support, you can be technical about sysadmin stuff, but not include programmer-specific details. Customer emails should be in purely functional terms using the user-facing names for the model elements in your application.

For example, when writing instructions for a technical support engineer, you might be able to provide high level instructions like "restart the frobnicator" and assume the engineer knows the specific commands necessary to do that. If you had to give those same instructions to an end user, you would need to provide clearly explained step-by-step instructions including the exact commands or operations to be performed. If you are in the habit of restarting the frobnicator a dozen times a day, it might seem tedious to you to write out in gory detail how to do it, but keep in mind it is very likely the customer has never heard of the frobnicator and has never had to restart it.

Be relentlessly professional.

It takes determination to remain professional in times of stress. This is a skill that your management chain has most likely already mastered through experience. You will want to master this behavior through focused practice. What I mean by unprofessional behavior encompasses such things as shouting or becoming audibly agitated, using profanity, personal attacks or insults, blame shifting, or anything else that can be perceived as immature or inappropriate. I can attest from experience that there often times when there is a strong internal urge to blow off steam or "let them have it" when faced with the various annoying realities of big companies (bureaucracy, incompetence, cluelessness, etc). However, any incidence of this sends a message of immaturity and unprofessionalism to management. It also indicates that allowing you to work directly with customers is a risk. Stick to your guns and say what needs to be said, but always use strictly professional manner and demeanor.

Be a straight shooter.

You might think the previous points about using corporate speak and being professional may be contradictory to being a straight shooter, but that's not the case. By "straight shooter", I mean that you can speak the truth and tell it like it is. You don't need to sugar-coat any technical realities or weasel your way around the current situation. Managers appreciate clarity and directness when it arrives in an acceptable fashion. So if you have bad news or concerns, feel free to voice them accurately and completely. The distinction here is that the language used to communicate has to be professional but the actual content of the message doesn't have to be softened in any way.

Be a corporate ambassador.

When a company is paying you a salary, you need to be aware that you always represent that company even in your after-work private life. It isn't OK to hit the bar with your buddies and loudly badmouth your employer. These things get overheard and repeated, especially given the omnipresence of numerous communication devices. Before you've finished your rant about how your employer's expense policies are ridiculous, it could have been tweeted by someone who has overheard you. If you really must vent to someone, do it privately in your own home to your spouse or significant other, and limit it to that. Ignoring this advice is an easy (and stupid) way to get immediately put at the bottom of the list for a promotion. Also, never assume that because someone is a stranger or works in an entirely different industry that you can badmouth your employer to them and no harm will come of it. It's a small world and now everyone is highly connected via Facebook and LinkedIn. Word travels fast.

Pillar #3: Getting Credit for What You Do

This is another piece of advice that is so easy to implement that you wouldn't think that it can make you tens of thousands of extra dollars, but it can and it has. So listen up: it's a sad state of affairs but the truth is you can appear as significantly more productive (and therefore more valuable) than your peers even if you are doing equivalent or even inferior work. How can that be? It's easy. No one except you is properly motivated to track your own work and productivity, and most people by default do a lousy job of it if they even make an attempt. It's a trivial job to keep track of what you do, get credit for it, and look like an absolute rock star. There are plenty of bright and productive developers out there who operate in a state of perpetual deadline panic and never keep track of what they are doing. Thus when performance reviews roll around, they struggle to put together three or four bullet points to describe the major deliverables they worked on over the past year. In addition, while many people do work that is not strictly part of their job description such as helping train new employees, they write it off as "one-off" work because it is not properly tracked; however, over time it tends to actually add up to a significant amount of time and effort.

Here's a simple technique to ensure everything you do for your company is tracked, which allows you to get credit for it and be properly rewarded. The basic points are:

  1. Take detailed notes constantly.
  2. Summarize your weekly activities in a weekly status report email to your manager.
  3. Generate a six-month summary of accomplishments based on the weekly status emails.

Let's look at each of these items in more detail.

Your Work Journal

Don't skip this one. This is a simple technique that can make a huge difference. Start a work journal - it can be nothing more than a simple text file. You should have one single journal for everything you do for your job. Organize it chronologically: do NOT try to make separate journal files for different roles or clients or projects. Put EVERYTHING in ONE BIG FILE. Don't try to organize it by category or client or anything like that. It is just a chronological journal with the first entry at the top of the file and the last entry at the end of the file. Make sure your text editor can be configured to instantly insert a timestamp, since you can use this to organize your journal. This is straightforward in most good editors, and there are even some OS-level utilities that can do this. Here's a sample from my journal to give you the flavor.

Tue Nov 08 14:20:00 EST 2005
-curriour IMAP has a short shell script that goes with it

Tue Nov 08 14:23:06 EST 2005
-when a shadowbot starts, it looks in /var/lc/crypto/shadowbotname/onefile.srv (public/private key pair for that comp
onent)
-it needs to find one and only one of these srv files
-it will also load one or more .crt files
-shadowbot also has client side validation
-the client's certificate must have been signed by one of the .crt file's CA

Tue Nov 08 14:30:01 EST 2005
-certmaster code that the client should be validating the server it is commented out
-look up the bug on this SAMPL00016632

Tue Nov 08 14:52:22 EST 2005
-jay thinks spin.cogbot.crypto.validity.period can be customized in the spin.args
(14:54:16) jay: spin.cogbot.crypto_validity_period

Tue Nov 08 14:55:17 EST 2005
-wow, this is settable in the OCC

Tue Nov 08 17:14:09 EST 2005
-great email from Jay
First of all, try looking on your system (in the openssl dirs) for  CA.pl. That's where I ripped most of this from:

You can make the root CA like this:

mkdir rootCA
cd root CA
mkdir demoCA
mkdir demoCA/certs
mkdir demoCA/crl
mkdir demoCA/newcerts
mkdir demoCA/private
touch demoCA/index.txt

You make a CSR for your agent CA like this:

...<SNIP>....
Tue Jan 03 13:51:45 EST 2006
-TASK: XXXX Delegated Administration
-WIKI SUMMARY: Call with John Doe on twist calls for Delegated Admin

Tue Jan 03 14:35:56 EST 2006
-converted the LDAP SSL certificate to pem format thusly:
openssl x509 -inform DER -outform PEM -in /cust/proserve/B1LDAP-DEV.DER.cer -out /cust/proserve/B1LDAP-DEV.pem

Tue Jan 03 14:38:27 EST 2006
-OK, great. Got UserFacade.createExternalUser() working.

Tue Jan 03 16:05:55 EST 2006
-WIKI SUMMARY: XXXX ISMTool call with Product Management
-TASK: XXXX CE
-WIKI SUMMARY: XXXX Date Status call

Tue Jan 03 17:27:39 EST 2006
U035792 is bala's EID

Tue Jan 03 17:49:09 EST 2006
-admin role in aaa is ID 1710777

SQL> select user_id, username from aaa.aaa_user where username='admin';

   USER_ID
----------
USERNAME
--------------------------------------------------------------------------------
     10777
admin

Things to note:

Daily Activity Log

Over time, your journal becomes an awesome treasure trove of knowledge. Do NOT worry about managing it. I kept a journal steadily for 6.5 years and my final text file was 207,470 lines long and 5 MB uncompressed. It compresses with bzip2 down to 1.2 MB. Just keep the journal going essentially for ever. Be sure to back it up by including it in a source code management system that has remote backups (git) and/or email a copy of it to yourself periodically.

Now, the key to getting great value out of the journal is to use a text editor with great search capabilities. I have never seen one as good as the "hypersearch" feature in jEdit, but I'm told TextMate has something similar. This becomes very important as the file starts to get very long.

Another key is make sure you can quickly and seamlessly open your journal. I had my F5 key mapped to bring up a virtual desktop that had nothing but my journal file in a maximized window so at any point if I wanted to take a note I could just hit F5 and then start typing. I used F11 to insert the timestamps. You must also have a hot key to instantly put your cursor at the end of the document (I used to use CTRL-END, now it's CMD-DOWN).

Helpful Tools for Journaling

Keeping a Solid To-Do List

For years I used a simple section at the top of my journal file to manage my short and medium term to-dos, and a wiki page for long-term projects. It was a simple but effective system that grouped tasks into three lists as follows:

---------------------------------
|TODO TODAY|
---------------------------------
[+]This is a task I have already completed
[.]This is a task I have started but not completed
[]This is a task I intend to complete today

---------------------------------
|TODO SOON|
---------------------------------
[]These tasks should be done in the next few days

---------------------------------
|TODO LATER|
---------------------------------
[]If I probably won't get to it this week, it goes here

I had macros to mark an item as complete and then move it to another section of the file with a timestamp of when it was completed. Feel free to use a simple system like this. Of course, there are also lots of task management applications out there including TaDa List, Taskforce, and many others. The point is use SOME SYSTEM CONSISTENTLY. Don't just rely on memory, or spread projects across different tools. Consider reading one of the classic personal productivity books such as David Allen's extremely popular Getting Things Done. I haven't personally read GTD (yet), but I use a system. Lately I've been having great success with Workflowy, which I highly recommend.

Weekly Status Email

Every week, summarize your activities from the previous week and send a status email to your manager. I recommend doing this on Monday rather than on Friday, but I haven't done any research to prove if either is superior. You may also just ask your manager which he or she prefers.

The details of this email are important. It must be a HTML mail, not plain text. It should have a heading for each active project with a bulleted list of your accomplishments under each project. There should be one category for any miscellaneous work. You should also have a section for any outstanding work items you have asked your manager to handle for you or the team.

Here is a sample status email I sent:

Weekly status email sample

Key things to note:

All-Nighters

A quick note here on pulling an all-nighter. All-nighters are not good. Generally all-nighters are amateur hour. They are a sign that things are being mismanaged and out of control. If you have to do these regularly, think about having a serious discussion with your manager about permanently fixing the problem, or think about looking for another job. However, at least a few times in your career, circumstances may truly necessitate an all-nighter. Hopefully this is not more than once every 18 months or so. So, if and when the time does come, my advice is to make sure you get credit for it. This can be something as simple as sending out a status email at 4am. This is another thing that will reflect positively upon your dedication, but if the right people have no awareness that you pulled an all-nighter, you won't get any credit for it.

Performance Evaluations

Larger companies typically have formalized review processes every six or twelve months. These form the basis of salary and promotion decisions. Nailing your performance review is absolutely critical to getting those raises and promotions as soon as possible. Sadly, many people treat reviews as a nuisance of a bureaucratic red tape process, to be slogged through like so many TPS reports. And sadly for them, they miss a big opportunity. But gladly for you, with the advice in this guide, you will ace your reviews and go home with a bigger pay check. Don't make the mistake of writing this process off. It's important and the level of effort you put into your part of it can easily make the difference between getting a $4,000 raise and getting a $24,000 raise. With that in mind, plan to spend at least half a day, if not more, working exclusively on preparing material for your performance review. When that time comes around, this is priority number one. Any other urgent issues and emails can wait. This is how you get paid, so allocate the time and get it right.

You want to prepare a document (again HTML email is strongly encouraged here) that you will send to your managers. This document should summarize your accomplishments and business impact since the previous performance review, or since your hire date if this is your first review. This document should include the following:

During the review your manager will likely have a basic agenda already set. There will be a slot on this agenda for you to review your work from the previous period and talk about your goals for your career. This is your chance to shine. Review your document verbally, adding additional details and color as needed.

There will be one or more standard forms that need to be filled in. Don't let the format of your company's standard document constrain you. Create your own document using the format above or some variation that expresses exactly what you want and exactly how you want to achieve it. You can then take the raw content from your custom document and copy/paste it into your company's standard document as needed. For reference, here is a sample form of a typical annual performance review template.

Tracking Your Performance Reviews Over Time

You should personally archive your performance review materials and have your own notes for reference. It seems that big companies like to switch performance management software about every three cycles, and whenever they switch, they usually are not able to migrate the data from the old system to the new system. Keeping your own copies and records will allow you to better track long term progress. You can also send a full record to a new manager if you are assigned to a new manager, which also happens fairly regularly. Thus you can get your new manager up to speed on where you started and where you want to be.

Communication Reader Write-In Anecdotes

A reader of this article emailed me these stories from their experiences I wanted to share.

lesson 1: keeping my head down and just working hard on my assigned job will get me nowhere without communication

Situation:

In a previous job, I was part of a scrum team working on a product with 5 or 6 other developers. In the 2 week sprint cycles, I concentrated on working on the backlog 100% of my time. I was thinking: if i just do my job with hard work, I will eventually get noticed and promoted.

At the same time, some of the developers work on side projects that they selected while working less or even completely not working on the team backlog for certain sprints. They the side projects were voluntary stuff like writing newsletters or fixing other stuff of other teams. The team backlog was celebrated as the success of the whole team, and any credit to the side projects went to the other individuals. They received one time bonuses and promotions. I did not receive anything extra for "doing my job".

How I handled:

I decided to do something about this. I also decided to approach it in a way that does not involve saying anything negative to management about anyone such as : Developer X was not doing his job on the planned sprint while writing newsletters.

I picked out things that I did anyway in my daily work that benefitted the organisation as a whole and communicated this to my manager and about how this contributed to the overall unit operational strategy. One example was how I was working very closely with colleagues in Bangalore on certain issues and how I bridge the divide between german and Indian teams. I kept communicating similar points to my manager in our 1 to 1 talks.

Result:

It took many months before any results showed, but gradually my efforts were recognised and I even had a cash bonus for it. I've learn that communicating what I do even if its "part of the job" is very important.

lesson 2: expressing genuine interest can open new chances

Situation:

At an internal tech developer conference, I was listening to a innovative talk by a colleague from another department at that time. I thought the talk was really cool and was impressed that there are teams working on such topics at the company.

How I handled:

A few days later, I ran into him at a supermarket (talk about luck). I was super nervous but I mustered courage to speak to him and told him I really enjoyed the talk, and asked if he could tell me about other projects his team was working on.

Result:

He took the time to show me ongoing and previous projects done at his team in informal coffee corner meets. At $COMPANY, there is this "fellowship" arrangement where you can work at another department for a few months as a guest. I asked if I could work as a fellow because the projects are really cool to me. One thing led to another and I ended up applying and getting a permanent position at the team a few months later. This is my current job position.

Notes on Writing Well

How to write without writing

Key Points: Performance Reviews

Notes on Changing Companies

Most successful careers involve working for at least several different companies. Just a few quick tips here. Plan on changing companies as appropriate when the opportunity feels very compelling and the improved benefits are significant. Be aware that frequent moving from company to company used to be a major red flag (I think), although in 2018 I think average tenures at a company are less than 2 years so maybe no one cares about longevity anymore. So just be aware of that as you are considering your options and think about the big picture. Expectations vary by industry and company size here as well. When the time is right, changing companies can get you a big salary increase ahead of schedule. Of course, this is all part of "the game". At the end of the day, you want to be enjoying your work and feeling fulfilled and inspired, and that matters more than the money. These decisions are tough. Consult your friends and family. Don't get trapped in a rut in a bad job for a long time, and don't get in the habit of quitting every ten months. Find that good middle ground that feels right for you.

About the Author

Peter Lyons has worked as a software developer and technology consultant since 2001. His career is detailed his career page. He has worked at small (30 or fewer employees), medium (500 employees), and large (10s or 100s of thousands of employees) companies and consulted at many Fortune 500 businesses. As he learnt the skills described in this article, he was able to advance his career rapidly. Of course, if he had known at the beginning what he knows now, things might have advanced even more quickly.

Exhibit A: Salary Chart

If you are uncertain about the veracity or value of the tips in this article, I offer up this graph of my salary as evidence in their favor. Assuming my starting salary straight out of college as "1" and computing the rest as multiples of that, here's what the growth looked like. Thus the chart doesn't show my specific earnings, just how they grew over time. This includes both base salary and cash bonuses. This does not include any form of stock, although I earned a bunch of that as well. By 2011 when I decided to take my career in a very different direction, I was earning over 4.6 times what I earned straight out of college.

Bar chart of salary over time

2020 Update and Where to Go from Here

This article is approaching 10 years old. I still think many of the core ideas are still solid and applicable, but as one would expect most of the technical stuff is now thoroughly outdated. I spent a while thinking about what an updated version of this piece might look like, but before I started to write things down, I found some newer existing resources that were so on-target in terms of topic and high-quality in terms of content I'm just going to link you to them.

First is Chelsea Troy's Leveling Up Series which is great and applicable to early-career people as well as more experienced folks.

Regarding advancing beyond individual contributor roles into engineering leadership, I whole-heartedly recommend reading staffeng.com, which I have been studying intently recently. As of September 2020, I was promoted to Staff Engineer at Mailchimp, and staffeng.com has been a great resource as I endeavor to do well in my new role.

Also excellent and worthy of study is Dropbox Engineering's career framework.

Comments

Please share your responses to this article on my blog post for this article.