Some people seem to get more hours in the day than everyone else. They’re omnipresent – jumping on problems before you know anything’s amiss, lending a hand to less experienced developers, killing it on their own code… Maybe they’re freakishly smart. Or work crazy hours. Or see things that seem obvious in retrospect, but no one saw before. It’s great working with someone like this, but it can also be a bit disheartening, since it’s hard to stand out when someone else is always in the spotlight.

Most people assume that being a star is just something you either are, or aren’t – that it’s some kind of innate quality, a genius that can’t be learned or understood by lesser mortals. According to this theory, A players are A’s, and the best a B player can hope for is to rule the roost on a C team. This is ridiculous, of course (and a bit offensive), but it’s an appealing excuse for avoiding responsibility for one’s own performance. The reality is a bit more mundane, and actionable – being a star is largely the result of a set of habits which lead to performance out of proportion to expectations.

First, do no harm

The most important requirement for exceeding expectations is… (drum roll)… meeting expectations. This may sound obvious to the point of banality, and yet it’s pretty common for someone who’s underperforming on their assigned tasks to be working on side projects, helping other developers, talking volubly about process improvements… And simultaneously complaining that no one listens to them, that their opinions aren’t respected, and that they don’t get credit for the great things they’re doing.

This is a bad place to be. You’re working hard. You’re creatively finding solutions to company problems. The developer next to you gets kudos just for doing their job, while your hard work and great ideas get ignored, and you get branded as being unreliable. The reason is simple – no matter how valuable you believe your side projects to be, your manager, business partners, and coworkers are depending on you for something else. If you aren’t delivering your assigned tasks on time and with a high level of quality, then anything else you’re working on is going to be ignored at best, seen as self-indulgent at worst.

Be reliable

Stars are extraordinarily reliable. When they say they’ll do something, you know it will get done. When they get a project, they don’t need much management, because they (mostly) manage themselves. There are several things that go into this, each of which is easily hacked:

• Keep a list of things you’ve agreed to do, and keep your calendar up to date

Everyone, and I mean everyone, is terrible at keeping to do lists and appointments in their heads. You will forget things if you don’t write them down. And in any event, you don’t get any brownie points for being able to keep everything in your head (in the same way that no one really cares whether you use an alarm clock or wake up on your own). Don’t be macho – keep your calendar and to do list up to date, and make sure you cross every single item off.

• Bad news can’t wait

This is one of the best pieces of business advice I ever got (thanks Clint!). When something goes wrong, the natural impulse is to be embarrassed, to try to make it up before anyone finds out, to cover it up. Every developer has had the experience of seeing a schedule slip, and trying to make it up by working nights and weekends. This almost never works, and it just digs you deeper into your hole – the longer you wait to tell people, the worse it’s going to be when you do. People will be upset to learn a project’s going over schedule if they find out a month before release, but they’ll be furious if they find out the day it’s supposed to ship. The instant you realize things are going off the rails, let the other stakeholders know. They won’t necessarily be happy, but they’ll know they can trust you, and the problem becomes a shared problem.

• Communicate status aggressively

Related to the previous point – keep your manager (and other stakeholders, as appropriate) informed of your status on a regular basis, even if you aren’t being asked to do so. This takes remarkably little time, and (assuming you’re meeting expectations) generates a high level of confidence in your ability to get things done. Imagine a several month project in which the developer delivers working code on time, but doesn’t communicate status along the way. Although the code works, this is going to create a lot of anxiety and mistrust of the final result on the part of the stakeholders, who won’t have any idea where things stand until the very end. Now imagine the same scenario, but with weekly progress reports. In this case, everyone is kept up-to-date and feels confidence that the project’s on track – which lets them focus their attention on other issues.

Improve your work product

The best process improvements aren’t going to make much of a difference if you aren’t producing high quality code on time. Assuming that you have the basic skills, there are a couple of quick hacks which will improve your chances of generating great code faster.

• Go with the Flow

Flow is the state of Zen-like focus in which you’re able to achieve optimal performance and productivity. There are books devoted to it (Flow, Your Brain at Work), but the key points are these: being able to achieve flow regularly is a core requirement for being a top coder; you need a quiet space free of distractions to achieve flow; once your flow is interrupted, it will take 15 minutes to get it back; most people spend their lives in a state of constant distraction, almost never achieving flow. Creating an environment in which you can shut out the world for extended periods of time is key to your ability to succeed.

Unless you’re building out your own office, you probably have limited say over where you sit, whether you get an office, how much space you have, and so on. However, you can set up your personal space to be as flow-friendly as possible. A space with a large number of distractions, that encourages socializing, or that makes it easy for you to get up and get a cup of coffee / soda / snack may be more fun, but it isn’t going to help you succeed. You need to be able to shut out the world (either by closing an office door or putting on headphones), focus, and work. A little up-front work (cleaning your desk off, putting your monitor on the side of your desk away from the hallway, buying noise-cancelling headphones, etc.) can have a major impact. Turn off the IM, Skype, on-screen notifications, email – anything that will distract you with a visual or audio cue. Make a habit of checking email only at specific times during the day – don’t be distracted by the constant drip-drip-drip of emails coming through. If something really can’t wait for a couple of hours, they’ll call or come over to bother you.

• Work until you’re done

Some developers work incredibly long hours. This can be in response to a sudden emergency, or as part of a deathmarch, or in the last push to meet a deadline, or just because they’re into their projects. DeMarco and Lister have some pretty damning things to say about the productivity of people doing long-term overtime, and in general, you should avoid environments in which this is common or required (the video game industry, for instance, is particularly abusive).

However… Whenever you’re working on something, you have to juggle a lot of different variables. Being able to hold large amounts of code in your head at once is a requirement for being able to create or work with complex systems, and setting yourself up to succeed with this is a key part of being effective. Going home while in the middle of something complicated is going to cause you to lose a fair amount of time, as you’ll have to restart the next day with a cold mental cache. So, if you’re in the middle of something complicated, work until you’re done. Finish it off before clearing your mind for the night. You may end up working slightly longer hours, but you’ll be saving your future self a lot of time.

Don’t wait for someone else to solve your problems

“Man, this build process takes a long time.” “I wish someone would automate this.” “Someone should really document this code.” “Someone should clean up these errors.” “It would be interesting if someone set up a static analysis tool to see what kinds of errors it would show in our code.” “This tool is getting really painful to use – we should migrate to a new version or a different, better tool.” “I wish there were a document to help with onboarding.” “Our code review tool sucks – I wish someone would install something new.” “It would be nice if someone organized lunchtime tech talks.” “We should have a weekly book group to discuss technical topics.”

Every time, and I mean every time you hear yourself (or someone else) wishing that someone would take care of a common problem, you’ve just discovered a way to stand out by helping a lot of people. You need to grab this thing, hold it close, and jump on it quickly before someone else does. I’m serious about this – scratching an itch a lot of people are feeling – even if they don’t realize it until after it’s gone – is one of the surest ways to get positive recognition. This is what stars do – they make life easier for the people around them, often by generalizing the solution to one of their own problems until it’s useful for other people too. Don’t let these opportunities slip away.

Sometimes you can roll the solution to one of these problems into an existing project, sometimes you have to do it on your own time. Frequently, though, the solutions are fairly simple, and only want someone to realize that there’s a problem in the first place. Note that all of the examples listed above are things that I’ve seen done – are any of them itches that need to be scratched in your organization? No one’s stopping you.

Focus on the important things

In his ridiculously popular best seller, Steven Covey talks about the 2×2 matrix of important/not-important and urgent/not-urgent. This one chapter is worth the price of the book, but can basically be boiled down to the following two points: focus on the most important thing you can be doing right now; and, ignore things that are unimportant, even if they’re urgent. Try to ask yourself throughout the day – what’s the most important thing I could be doing right now? What am I actually doing? If they aren’t the same thing, why not? It’s nice to be able to cross things off your to-do list, but if none of them are actually important, you’re wasting your time. Be on the lookout for tidying up activities (e.g., obsessively cleaning up your email’s inbox), and see if you can batch or automate them (e.g., only check email at certain set times during the day).

Find a niche

Sometimes, all it takes is to find an important niche and exploit the hell out of it. For instance, having a deep understanding of garbage collection, functional programming, concurrency, etc. can be a fantastic asset – if you actively work to disseminate that knowledge and use it to improve your company’s product(s). It’s good to be the genius who swoops in and saves the day – but it’s better to work to educate other engineers, so that knowledge about your niche becomes more widespread in the organization. Being the top scorer on the team is good – helping the entire team to do better is great. The first is being a great individual contributor, the second is taking a leadership role. Education might take the form of tech talks, reading groups, guided code walkthroughs, documentation, and/or explanatory emails.

Caveats

One problem with the previous two points is that it can be very easy to slip into religious zealotry, or to be perceived as such, unless you do the work up front and can present data-based evidence as to why the approach is correct. Trying to convince people that they need to convert their shrink-wrap product into a PaaS offering written in OCaml because that’s your area of expertise is going to be a losing argument. Advocating for the integration of a static analysis tool into your automated build system might not be compelling – unless you’ve already run it against the code and can show that it’s uncovering serious bugs. In general, it’s easier for people to accept change if a) there’s concrete data demonstrating it’s an improvement, b) it simplifies something they’re already doing, instead of fundamentally altering it or adding something new, and c) they don’t have to expend any of their own energy.

How the other half lives

There’s a lot of stuff here, but nothing (with the exception, perhaps, of finding a niche) requires particular gifts in coding or people skills. You don’t have to be a genius to work until you’re done, or set up a work area that encourages flow, or recognize when you’re idly wishing someone else would solve your problems for you. Of course, none of these will help you if you don’t have the core skills, but assuming you do, these habits should markedly improve how you’re perceived, and for good reason. Consider the world from your manager’s point of view:

Your manager’s performance is judged primarily (or entirely) on her team’s performance, over which she has very little real control. Her knowledge of the team’s status is based entirely on what they tell her, and the frequency with which she can ask for status reports is limited by fear of micromanaging. Every person on the team is going to make up their own narrative about how things are going unless she’s constantly providing reassurance. She has to balance administrative tasks (reporting, budgeting, etc.) with management tasks (one-on-ones, performance reviews, recruiting, project/risk management) with technical tasks (unless she’s completely hands off). Some of her direct reports take up a lot of her time, some can work independently, and some save her time. She has to pester some of the team members for status reports, others provide them without having to be asked. Some team members hide problems until it’s too late to do anything about them, others proactively communicate when there’s a problem. She has to remind some of her coders to do things multiple times, she can depend implicitly on others to do what they say they will. Whom do you think she’ll enjoy working with most?

A final word

There are many paths up the mountain, and there are many ways to be a star. The above is by no means an exhaustive list, and you’ll discover your own tricks to improve performance – remember, whenever you find something, share your discovery. That’s one of the most important parts of being a star.