What kind of a software engineer do you want to be known as?

Around this time every year, companies start doing their annual reviews. Coincidentally, software engineers start wondering what their peers and managers will be saying about them. Throughout my career I’ve always watched as colleagues worried about the results of their annual review. Will they get that promotion? Will they get that raise? Or will they be told that they are not performing up to expectations? All of this happens, like clockwork, once a year.

Annual reviews are a reminder that your reputation matters. For most of the year, software engineers don’t care at all what anybody else thinks as long as they’re getting the job done. Then annual reviews come along and we realize we might have rubbed some people the wrong way. I know software engineers who year over year always feel like their review is incorrect and unfair (though I’m sure other occupations have similar issues). What makes it more difficult for software engineers is that we deal so much with code that we sometimes forget how important it is to deal with people. The code isn’t going to give us a negative review so long as it works. Then again, you’re expected to write code that works, so your review only ever reflects when you don’t write code that works.

The rest of the review is based on what people say about you. They are your colleagues and your managers. And you probably didn’t even stop to think about that until around review time. If you’ve ever received a review that has been a complete shock to you, that means you didn’t spend enough time during the year to figure out what kind of the software engineer you want to be known as.

Never be surprised again

It’s been a long time since I had an annual review that surprised me. My last manager even came to expect it from me, as he would usually begin our conversations by saying, “I’m pretty sure you know what this is going to say.” He was right. It was very easy for me to predict what would show up on my annual review for one simple reason: I had already decided what I wanted to show up on the annual review the year before.

This is probably different than the way you’ve ever thought about annual reviews. Most of the time, you meet with your manager and set goals for the next year, and then your annual review is a checkpoint to see if you achieve those goals. Unfortunately, the goals are typically task oriented such as, “learn about Node.js”. It’s relatively easy to see if you’ve achieve those goals. What most people never stop and think about is what you would like to see on your annual review next year.

Stop and think about that. Decide right now what it is that you want your annual review to say next year and then take the steps necessary to make that happen. Keep in mind that your annual review typically reflects your reputation in addition to your technical work. The technical work takes care of itself but the reputation piece is one that you must actively work on.

Your reputation

Do you have any idea what your reputation at work is right now? If not, ask some colleagues that you trust to tell you how they view you as a coworker. Listen closely for adjectives because that’s what makes up your reputation. Then decide, is that a reputation that you want? Or is there one that would serve you better? What kind of a software engineer do you want to be known as?

Do you want to be known as the one who always shows up late and in a bad mood? Do you want to be known as the one who happily takes on complex problems? Do you want to be known as the one who smells badly? All of these things are within your control. You can create the reputation that you want for yourself, it just takes a little bit of planning. Everyone has a professional reputation but not everyone takes the steps to actively evolve that reputation. And believe it or not, as you get more experienced, your reputation starts to matter even more than your actual work.

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren’t improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

An example

The last time I stopped and thought about the kind of software engineer I wanted to be known as, I came up with a list of things that I wanted people to say about me on my annual review. These things reflected not necessarily what I was already doing, but what I would aspire to do in the next year. The things I wanted people to say about me on my annual review were:

  • Nicholas is fun to work with.
  • Nicholas cares about the career development of his peers.
  • I trust Nicholas to work on important projects.
  • If Nicholas is working on something, I know that it will get done correctly.
  • Nicholas is capable of learning new things quickly.

This is just a sampling of some of the things I wanted to see on my annual review at different points in time. Note that they all have to do with how others perceive me rather than the quality of the code that I wrote.

Next steps

Once you decide what you’d like to see on your annual review, the next step is to figure out how to make that happen. This is a little bit more difficult than other task-oriented goals because it relies on the opinions of other people. That being said, it’s certainly not impossible. You just need to stop and think about how your actions affect how other people see you.

Take the example of being fun to work with. Why would people say that about you? Well first and foremost, you have to be reliable. That means showing up on time, completing tasks that are assigned to you, and being a good team member. It’s not fun to work with someone who is unreliable. Assuming that you are reliable, then “fun” is achieved by having good relationships with those on your team. That means talking about things other than work, getting to know people outside of the code they write in the job that they do. It could also mean that you’re the one who starts Nerf gun wars or helps to plan team activities. The bottom line is that people enjoy working directly with you and would welcome the chance to do it again in the future.

You can take all of your reputation goals and break them down in that way. Almost all of them are reflections on how you interact with other people. As you go through the year, keep an eye out for interactions that run counter to your goals or strengthen them. For example, if you got into an argument with a colleague, how did that argument resolve? Did you both end up feeling resentful and not wanting to work with the other person? Or were you able to reach an understanding that was mutually beneficial? Any time and interaction doesn’t quite go smoothly, that’s a good time to review your reputation goals and see how that interaction affects them.

Conclusion

Your reputation as a software engineer matters. It’s something that you should actively seek to develop throughout your career because that’s what sets you apart from everyone else who can write the same code that you do. As you get more experienced, your reputation matters more and more, and can be the reason that you either get or miss out on new opportunities. As software engineers, we spend so much time thinking about code that we often neglect personal relationships with our colleagues. Yet our colleagues are the ones who contribute to our annual reviews and ultimately to our success. Watch your interactions with others, try to establish personal relationships with people, and frequently review your reputation goals to see if you’re on track. Hopefully at this time next year, your annual review won’t be such a big surprise.

Comments

  1. Stephen B

    Great points Nick, as a more junior level developer i tend to focus more on quality and quantity of the code I write, but the idea of outlining what I want to hear in a review is something i'm going to do from now on.

  2. Chatman R.

    I work on my own right now, but I want a reputation as someone who can be trusted to not only get the job done, but get it done in ways that leave a solid base to build upon. On my review, I'd want to be known as the guy to call when you want to facilitate growth. I want to be a developer who makes things easier on developers who come after me and the people who use what I build. Knowing how to program is great, but understanding why you write programs is even better. The work I do should fulfill a real need; whether it's to inform, educate, build a brand, or just entertain. More than anything, I intend to communicate my passion for web design & development in both my work and the way I interact with others. Hopefully that's going well.

    This was an awesome post. I feel as if too many developers neglect the human side of the equation. I've noticed that no matter how great your technical ability, actually connecting with your team and the people who use what we build--whether it's an internal business application or a website, is what will keep you in demand throughout your career. Reputation does matter.

  3. Amit Behere

    Unfortunately, what sometimes happens (more often than one would expect) is that despite of doing everything you think is necessary to get the review you want, you don't. The reasons usually have to do with your own manager or your company's management chain.
    When something like this happens, consider changing your workplace since it is not an environment you fit in.

  4. Colin

    Great article.

    Quite often developers forget that to be a developer does not mean that you should be able to only write lines of code. Listening, understanding, communicating, supporting, collaborating, talking and many more skills are just as important. And its based on all of these skills will your reputation emerge.

    Here is a blog post which supports what you are saying - The role of a software developer.
    http://www.softwaresprint.c...

  5. Games Josling

    There's always the mixture of tech-competence and overall social-competence. So you have a job that is f.e. 70% tech and 30% social competence, or some other combination.

    Quite frankly, once the tech competence levels are dumbed down to 10-20% (Java, Javascript, C#), you are living in the pupil of 1000 eyes. Not exactly nice.

    Being correct and being polite isn't enough now. What's the solution if your tech-oriented? Get a new job.

    Software development IS team work, anyway you see it. That's fine... That never was a problem. People that are dysfunctional, are diysfunctional ever where.

    If a company is unable to take college graduates that are competent with programming and create productive teams and developers, then the COMPANY has failed. That's not a programmers mistake.

    Again ,with AGILE, crtitical decisions can be team decisions only (lazy managers!) , therefore now everything can be a social issue. product design! requirements! communication with the customer! technology! People start hacking together the crap of the universe and it still doesn't crash (Java). Yeah, now its time to be nicer to each other and simply accept that fact. But every component they use for their app WASN'T developed using agile, but using engineering principles. Cleary, a lot of real software devs that are engineers can "do agile", but not vice versa.

    So the question is rather: Do you - as a software engineer - want to be dependent upon social issues and some other-non-technical facts or be dependant upon technical issues and social competence?

    Get the job you want, and be socially competent - ALWAYS. And don't let your boss fool you. Its a power game. If they save money by keeping you in check, they WILL do it.

  6. AlexK2009

    As a contractor I found this useful. While clients tend to worry about the quality of work, at higher levels, such as architect, interactions with people become important: either in order to swing the decision when a possible extension is in the air or to get a great reference.

    I knew a regular employee who was fired because no one wanted to work with him. He was technically the best person on the project (it was a big project).

  7. Joe Dempsey, Sr.

    Thanks for your thoughtful comments and ideas. I wish I had known you 40 years ago. During my consulting career, I quite accidentally became known as the go-to guy who could solve the problems where others had failed. I never intended my career to take such a twist but I always seemed to be the guy who came in after the other guys who screwed things up. Being in such a situation subjects you to a lot of close scrutiny by those clients who had decided that they "won't be fooled again". I now had to repair the reputation of the consulting community. Clients generally paint with a broad brush. Being placed in a situation where our technical skills will save the day is a happy place to be for a consultant. Now, years later, I realize that I could have been so much more. This blog post of yours, Nicholas, sums up exactly how to become more.

    I took the liberty of tweeting the following (I am @Pioneering):

    NCZOnline: What kind of a software engineer do you want to be known as? http://goo.gl/j5uxo

    I look forward to your next post.
    -- Joe

  8. Catherine Bullard

    I work in an area with attitudes and problems but I've found that by using online tools, I am tapping into those same programmers and collaboration has become easy without the workplace politics of being in the office. We still have offices, but are able to conduct business completely online. We have online chats, can share desktops, and are able to work on the real issues instead of worrying about being nice and pleasant in the work place. When we are all in the code, it is like a group of mad scientists that are working to solve the greatest puzzle of all time! We have great fun and after sessions that are intense, the office comraderie grows naturally.

  9. guy

    There is a corollary to this. If like me you have been doing this since you started working, you will also realize the review has symmetry. If you find it is not possible to orchestrate the reveiw you decided on, you are working at the wrong company and it is time to leave.

  10. Diane W

    Interesting read... It's unfortunate that the trend in interviewing for technical positions seems to completely ignore a lot of these "soft" skills. It seems like it's much easier to focus on interviewing people for specific technical skills with coding tests or clever puzzles, but in my experience those types of tests fail to demonstrate how the person is to work with on a daily basis (or whether or not they have some of the other soft skills needed to actually get things done as part of a team).

  11. Miles Thornton

    Nicholas,
    I completely agree with your post. We developers tend to focus on the task at hand, the current fire. We often forget the soft skills that are so critical to a successful career. I especially appreciated your take-charge-of-it approach. Well done.

    I too am reposting: http://www.nczonline.net/bl... on FB.

    -Cheers!

  12. john

    Great post, excellent points. It shows a real pro-active approach to ones career, which is so important and frequently forgotten (guilty on that one I'm afraid to say).

  13. Ron

    @Amit Behere
    I totally agree with Amit's comment. In most organizations it is the 80/20 rule. 20% will do the 80% work. These 20% have their heads buried under pile of work and will finish their's and others (in the name of help) work on time and at time of review will be looked down upon saying you guys are not being nice enough to others. The other 80% will brown-nose, back stab, play politics and what-not and will take credit and get credit for others work. Managers also want that since they do not feel threatened by these sloppy workers. Its the 20% that they are are scared and worried about. So what happens when reviews come; the good honest works are at the mercy of the Idiotic Managers.
    There is new term for this "Welcome to Modern Age of Slavery, dear Software Engineers."
    If one gets a chance read the book : "How to work for an idiot" by John Hoover.
    Mind you; read it but do not become an idiot yourself.

    Ron.

  14. Nicholas C. Zakas

    @Ron - If you really have that level of problem with a manager, then you need to find a new job. If you are within an organization that doesn't appreciate you or your efforts to improve then it's time to leave. But don't make the mistake of believing all managers act like this - there is sure to be one or two you'll encounter in your career, but you can't generalize that to everyone's experience.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.