In most companies that do programming teams and divisions consist of programmers who design and write code and managers who... well, do the management stuff. Aside from just not writing code, managers usually do not even look at the code the team develops, and may even have no proper IDE installed on their work machines.

Still, the managers are to judge if a person works well, if he or she should be put in charge of something, or if particular developer should be assigned to a task of the most importance and responsibility. And last, but not least: the managers usually assign the quarterly bonuses!

To do the above effectively, a manager should know if a person is a good programmer—among other traits, of course. The question is, how do they do it? They don't even look at the code people write, they can't directly assess the quality of the components programmers develop... but their estimates of who is a good coder, and who is "not as good" are nevertheless correct in most cases!

What is the secret?

  • 24
    Great question. Most of the managers I've worked for, see the worst developers (really bad code and design) as being the best on the team because they always deliver on time. Then it's others in the teams that sweep up and maintain after them. Managers should read code now and then... – Martin Blore Mar 7 '11 at 20:37
  • 18
    Keep in mind, what makes a 'good programmer' to programmers may not be the same as what makes a 'good programmer' to a manager. – GrandmasterB Mar 7 '11 at 21:41
  • 11
    Most of the time they don't. – biziclop Mar 7 '11 at 22:36
  • 1
    It seems answer of How managers should know if a person is a good or a bad programmer? – Jigar Joshi Mar 8 '11 at 6:32
  • 2
    This is why I always assert that a software development manager should be a programmer, or rather have been a programmer. Their job now is to manage, but in order to manage effectively, they need to understand that which they're managing. They can only do this really well if they have been a programmer themselves in the not too distant past (and continue to keep themselves at least familiar with new technologies in software development). – CraigTP Mar 8 '11 at 8:47

17 Answers 17


Typically a manager will look at

  • Does the programmer get stuff done?
  • What do their colleagues think of them? The code that they write?
  • Does the programmer communicate clearly to the manager?
  • Does the programmer enjoy learning new things? Do they mentor others well?
  • Do they need a lot of management attention to get stuff done?
  • Does the programmer seem to get enjoyment from their work?

Its true that they usually don't see (or often understand) employees' code, but the above for them serves as a reasonable proxy for measuring how well an employee fits into the programming role imposed on them by their employer. If somebody isn't getting stuff done, gets low grades from their colleagues, can't communicate well, gets frustrated with different technology then they're used to, always needs supervision, and is always unhappy, its a good indication they aren't meshing well with this job.*

*It may be, however, that in a different context and environment they'd be very happy and enthusiastic. Maybe its just being that kind of programmer that they objected to, and they might do very well programming in a different context. "Programmer" can mean very different jobs at different places. But the manager cares mostly about their "programmer" role and how well an employee fits.

  • I think the most important of these topics is Does the programmer get stuff done? - I only complete it by adding Does the programmer get stuff done in schedule? – Herberth Amaral Mar 7 '11 at 20:42
  • 2
    Tiny caveat in regards to "communicates clearly to the manager": it depends more on whether the manager thinks he understood or not than on whether he really understood or not; that's why you have to check at the end what he understood because despite his possitive attitude, he may have understood something completely different. – wildpeaks Mar 7 '11 at 21:54
  • 4
    Herberth: "Get's stuff done" (on time or not) isn't necessarily sufficient, since the other team members could be picking up their slack. – Cercerilla Mar 7 '11 at 22:31
  • 2
    And "gets stuff done" without a lot of bugs is also important. In other words, are they always going back and fixing things, or is once something done, it's done? – thursdaysgeek Mar 8 '11 at 0:15

I disagree with the assertion that managers don't look at code. When I've managed teams, I've looked at some of the output of every engineer - and a big one is code. But not the only one - emails, design documents, whitepapers - it all factors in.

But that's definitely not the only factor. If one guy is sitting in a corner and writing brilliant code but he's a beast to talk to, won't answer questions, won't share status and won't compromise when develoment issues come up - I'm not so sure he's an asset to the team. Especially compared to a guy who writes moderately decent code but can do all of the above.

Here's some stuff I look at when I'm in a position to give out rewards, but with the huge caveat that it is absolutely a gut reaction, cause none of this can be quantified:

  • Status - is it clear, accurate, & timely? When discussed, is the person on top of the status or a little blurry on the current issues? Does the person have the right judgement to raise a red flag when something has caught on fire?
  • Problem-solving - both asking and answering is important. Does the person know when to ask for help, or where they spinning their wheels indefinitely? Better yet, when others have problems, does the person help find the solution or become part of the problem? Even having the good sense to back off when the problem isn't in your area of expertise is worth a few points. Also there's points for going outside the group or the company, and going to sites like this, or other internet answers.
  • Attention to process - usually this is pretty obvious - even in a non-anal-retentive company, if someone is bucking the system, it's seen in the chaos they leave behind them. If other people are cleaning up another person's features because they didn't adhere to guidance or architecture, then we have a problem. Bonus points go to those who figure out ways to make consistency and quality easier.
  • Completion rates vs. bugs vs. complexity - get stuff done, but get it done right. Everyone's got a few bugs, but if the guy gets stuff done fast and buggy we have a problem. I generally find this isn't something that you can assess in the daily sense - it has to be looking back at a release or a phase or a fiscal quarter.

And other people's input. Frequently I've been in a position where various engineers were in charge of various parts of the project. Sometimes team leads, and sometimes just the owners of a particular peice of output (like "the build guy"). People LOVE to talk about the extremes - the acts of heroism or the frustration of the problem children. Usually in the act of following up hands on with those issues, I find out a lot about BOTH parties.

There's also a factor in there regarding Managing Humans. No engineer is exactly like any other. So they don't all shine in the same light. One writes brilliant bug free code, but another helps solve cross cutting problems that breaks everyone's code. One is great in person, one is better in writing. One is incoherent at 9:00 AM, one is out of here by 3:00PM. There's a certain need to step back, figure out what is most beneficial to the team and what might be a factor of personal bias (like the desire to kill that chipper 4:00 AM guy, just because I can't function until 11:00 AM).

  • 2
    It seems answer of How managers should know if a person is a good or a bad programmer? – Jigar Joshi Mar 8 '11 at 7:21
  • In my experience at the organizations I've worked managers sadly don't have the bandwidth to look at every developers code. – Doug T. Mar 8 '11 at 15:21
  • @Jigar Joshi - don't know how every manager does it - this is what I've done when asked to do performance reviews or make recommendations. – bethlakshmi Mar 8 '11 at 20:27
  • @pythagras - my counter question would be "which manager?" A manager of 40 people - no, of course not. A manager of 10 people - probably wouldn't kill you to sneak in 1 hour per person scanning code in known to be critical areas. 1 hour per 10 employees over 6 months seems easily doable. – bethlakshmi Mar 8 '11 at 20:29

This varies a vast amount depending on the manager's technical expertise.

  • For the most part, they're probably judging you on how you communicate. How you communicate with the manager and how you're seen communicating with your colleagues.
  • If you're lucky to have a lead developer who is closer to the manager, the manager may seek input from the lead developer.
  • Keep in mind that the manager's primary responsibility is to get things done. He needs to see producing various outcomes and goals to meet the business' plan. So, if you're somehow able to look like you've having a direct influence on the outcome, this will bode well for you.
  • 2
    You know, the "lead developer" hypothesis reminds me exogenesis theory, which states that the life on Earth was created by aliens. Yes, a manager indeed may rely on the lead developer's observations, but it was this manager who made that developer "lead"! Which brings us back to the problem: how does management know who's to lead? – P Shved Mar 7 '11 at 20:49
  • @Pavel: You've pointed out an interesting (yet, separate issue). Assuming a lead developer has been appointed: the majority of management trusts and believes in their decision (i.e. whoever they picked). – Jonathan Khoo Mar 7 '11 at 20:54
  • if you're somehow able to look like you've having a direct influence on the outcome. That is the thing which is most exploited by good bonus earning but bad coding developers. – IsmailS Mar 8 '11 at 12:28

Generally, they don't.

That is why programming is a "Market for Lemons." http://en.wikipedia.org/wiki/The_Market_for_Lemons

Code gets screwed up, and it's generally not for 2-3 years before you know. Programmers typically stay 18 months, so you never see the culprits at the failure.

Managers have to take your word that, for example a release takes four months and a hundred iterations. Maybe you're editing lots of deployment files by hand and hand-reading log files for errors mixed in with status ? They don't know that it could be done better.

So be honest, and professional and try to improve. With experience a manager will start to see patterns of good and bad behaviour.

  • Regarding my comment on the question itself about asserting that managers be (or have been) programmers themselves. What you describe in your answer is exactly what I have experienced when I've had a manager who isn't or never has been a developer themselves. Unfortunately, there are many managers just like this out there. – CraigTP Mar 8 '11 at 9:22

How do managers know if a person is a good or a bad programmer?

I will start with a gross sweeping generalization: most managers cannot tell a "good" programmer from a "bad" programmer.

With that out of the way, what most managers (I've met or worked for) consider "good" in a programmer is not the same set of skills that another programmer would consider "good."

how do they do it?

A results-oriented manager is going to look for things like "smart" and "gets things done." They aren't going to care if you show up to work in sweatpants as long as you get the stuff done on time and on budget.

A process-oriented manager is more concerned with "how things get done." This means getting to work on time, wearing the right clothing and do you have the right cover sheet on the TPS report.

person works well, if he or she should be put in charge of something

Being "in charge" takes different skills than writing code. If a person has the people-skills needed to lead a team, then that person should get tapped to do so. If you promote people based on the key job elements of the job they are currently performing, eventually they get to a level where they're now incompetent. This is called The Peter Principle.

  • I've never heard the separation between result-oriented and process-oriented managers. +1 for that. – mwilcox Mar 8 '11 at 14:19

Obviously it always helps to have a programming literate manager who can actually read code and even more importantly delve into the bug tracking system and understand what's going on, know that not all bugs are created equal and just delivering bad code on time doesn't count for much.

But that's an ideal case. For a manager to get the measure of a programmer from a non technical perspective I have a couple of suggestions.

  • Do they promptly/regularly/consistently highlight where there are problems with getting things done to meet the currently specified requirements... and are thoroughly annoying because of it (this is software development after all, if it's not complex enough to have these issues, it's not a real development project).
  • If they're not sure about something, do they immediately say so - only a programmer confident in their own ability would actually do this (and they know if you don't like it, they can easily get another job). Conversely someone who knows they are seriously out of their depth tends to hide and look for cover.
  • What do other programmers in the team say/imply about the other programmers? If you're a half decent manager, you are in the trenches with your programming team - especially during integration testing/bug fixing time. So if you're not getting this kind of feedback, someone else should be doing your job.
  • And my favorite: what I call the 'tomcat' programmer. If after a little while you are constantly noticing various programmers always milling around the same programmer's desk (assuming they are doing work and discussing some troublesome issue, and not the resident finder of cool & funny webstuff)... then there's a reason other programmers are gravitating to that person's desk. If they aren't already a team leader, then they probably should be made one asap.

If any or all of these apply, you are likely to have a good programmer on your hands. Note that by good programmer I don't just rate their coding ability but other useful stuff like being able to communicate with other human beings ;-)

  • gee thanks... if so that'd be my very first meme. In case it's not obvious to anyone, it derives from the 'herding cats' analogy. – nomaderWhat Mar 8 '11 at 21:14

The manager may not know when the code you write is brilliant or if it could be improved by a huge factor, but what he does know is: Did you meet the deadline with code that worked? Are you a person he can trust to fix the problems other peopel create? Did the client or user notice a problem that got escalated to his manager? Was there a major disaster on your watch (Deleted the user table, forgot to set up backups, sent an email to customers with proprietarty data from another customer that they should not have seen, etc Did anyone compliment your work to him (especially in writing)? Do people say good or bad things behind your back?

  • 1
    It sounds to me like politics and reminds me about one of my previous company. – IsmailS Mar 8 '11 at 12:30
  1. In most cases where your code is not evaluated by your manager, it's evaluated by your peers (whether formally, or informally when they try to work with your code). Your boss will use the opinions of your peers (again, whether formal or informal) to some extent.
  2. Your general reliability and how quickly you progress on and finish tasks is often a very important factor, separate from your coding ability.
  3. Communication. If you're getting a lot done and doing it well, your manager needs to know about it! (Avoid bragging, of course). Learn to "manage your manager" and not simply be passive. Help your boss to know how you work.

The managers are coders themselves and therefore can, by simple observation, figure out whether the coder is good or not.

If your managers are not coders (and you're in the software business), you're screwed.


As a manager, here are some of the things I looked at when evaluating my programmers:

  • Peer feedback. I asked the programmers on my team, and programmers from other teams to send me feedback about my people.

  • Peer respect. When my programmers hit a problem they can't solve, they say "let's go ask so-and-so for advice."

  • Gets things done. I say "I want X" and the next day, X is done.

  • Gets things smart. I say "I want X" and the next day, not only is X done, but all X-like things are resolved and don't need further attention.

  • Fixes me. I say "I want X" and the programmer says "X isn't right, we should do Y, and here's why."

There aren't a lot of good managers out there (see related question: how do progammers know if a person is a good or a bad manager?). Managing people well is hard, and takes a lot of time and hard work. As soon as I was managing 5 people, I had almost no time for programming. When I was managing 8+ people, I could no longer manage them as well as they deserved.


I think that the premise of your question is somewhat flawed in that it asserts that managers don't actually look at code. I have worked in many situations where my managers was a fellow engineer and actively participated in code reviews.

However, there definitely are a plurality of situations in which a non-technical person is in charge of software engineers, and they are not able to rely on their own knowledge and experience.

In these cases, the responsible managers will call on the engineer's peers for advice. They will ask non-technical people in the organization with whom the engineer interacts to see if he has good people skills that are compatible with increased responsibility.

The irresponsible ones will just go with their "gut" reactions are use some kind of generally-unsupportable "metrics".

It's a crap shoot, but you can always quit and hope for something better elsewhere.


Where I work, when employee evaluations come around, the managers send an informal, anonymous questioner to those who regularly interact with the employee; both fellow developers as well as customers. This gives fellow developers an opportunity to give input on performance as a coder that managers may otherwise overlook.


The manager has to look at measurable's. What aspects of the job, are measurable in terms of work getting done, quality of work. They may not know if your doing a quality job, unless you generate lots of errors, or doesn't allow the end user to do what it's supposed to do.

Your work costs the manager money in expenses, so therefore you have to be financially profitable to continue employment.


I'm not saying this is the best way to do it, but they could base it on customer satisfaction. If they like the application, accept the amount of bugs, and feel you add new features in a timely manner, could your developers really be that bad?

Of course they could. They're able to brute force through coding because you have 10 people doing the work of two. Or the customers are satisfied because you sell your app so cheaply.

Another problem with this approach, is you have to wait until an application is almost completed before the non-technical manager can get any customer feedback. Build an app for a year only to release it and no one likes it.

Life would be simpler if you could rely on telling people to 'Just make it work.' When you understand and make people adhere to the right process, you eliminate many problems. You can have demanding deadlines that are realistic. Any fool can come up with unrealistic demands and run the risk of losing talented people.


I think most of us on a technical team know who rocks and who sucks. Unless you have tremendous turnover the cream rises to the top and the dead weight sinks. The crummy devs are always in some sort of trouble--they forget to test their code before they check it in so builds break, they always have an excuse when they don't get something done, and on and on.


I think they do not know if someone is a good programer, beucase they don't have the skills to do so. They check if someone is a good developer. Programming is an activity of development, but development has many others. So they check if you are on time, if your estimations are good, if there are many defects on things you have done in your bug tracking system, your soft skills, commitment, communication, etc.

What some It gurus sometimes forget and get upset about is that our work is not only programming, we have many other things to do that are also very important. While your manager will not take a look on how your code looks like (because it is completely unimportant to him), he will check if you are a team player, responsible, respectful and do a high quality job in overall.

Sometimes I think code is overrated.


I think there are very few people (let alone managers) who don't have a good general understanding of the pecking order for developers. Everyone thinks they are a top notch developer, the only people who don't know who the bad developers are, are those bad developers themselves. Anyways, if you were to go around and ask someone to rank the developers they work with I'm sure it would be an easy task for most people. So there is no magic in determining who is performing very well and who is performing average or bad etc... The only gotcha where developers and managers will disagree are with those salespeople types, the loud ones who sound like they know what they are talking about but really don't. Most managers are bamboozled by them but the developers aren't. It usually takes an epic failure by the salesperson before the manager catches on.

After that, it is your manager's biases that determine your ranking. To some, coding is an entry level task, so while you may be excellent at coding it will not get you that promotion you are looking for. While others look at the design or architectural aspects as being most important. And others believe the requirements definition and gathering (ie. business analysis) is most important. If you want to know what is important to your manager and you didn't get a top performer ranking, ask them what do I need to do to get a top performer ranking? You'll learn what is important too them in that answer and then it's up to you to make sure you excel in those areas of importance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.