Back when I worked at Boeing, I was once compared poorly against another engineer who was always down on the factory floor when called, any time, whenever there was a problem with his stuff. The thing was, I was not called down to the factory floor because my stuff worked.
I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
Other signs of a good developer are you don't have to micromanage him, and he's more of a partner helping you get things done rather than a subordinate you've got to spell things out for and check up on.
I.e. when he's on the job and you can relax and concentrate on other things, you've got a good 'un.
> I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.
I'm considered slow (ish), but I have very few bugs returned. Most (but not all) the faster devs have many bugs (often trivial, but sometimes show stopper) and spend time going back and forth with QA.
My thinking is, QA isn't there to find my bugs. They're there to make sure I don't have any. I seem to be in the minority on that thinking.
Ha! Resonates. Used to have a group of comm protocol engineers at our company, the most famous and popular with sales and customers. Reason: their code broke all the time, and they flew places to hack it until it worked. Looked like heroes most of the time. Meanwhile, our group got an award for least-bugs-in-a-release-ever. Well, recognized anyway, no money or promotion or even a plaque. So it goes.
Common problem is these people (who just do their job and make no trouble) are often seen as useless - you don't hear much about them anyway, what are they getting money for at all?? And the fact that their stuff just works makes many people think that they were just lucky to work on much simpler stuff than others - and you know, when code is done and works, especially a high quality code - it looks very simple, a buggy spaghetti code looks a lot more complicated and someone writing it usually has an easy time explaining a non-technical manager that he is working on very complex stuff...
Yup. The CMM of "firefighters" is immature and drama/chaos-oriented. Solid engineering is best when it often goes ubiquitously unnoticed because it just works like a reliable utility (uptime FTW).
I'm in the same position currently. I'm not available on weekends or extra hours during normal working days, some people are working extra hard and bringing up how much re-factoring needs to be done on their code. Except the extra hours are from fixing their broken mess, and the re-factoring is largely from self-inflicted injuries. Not that there aren't things that I wouldn't re-factor from my own code, but it's considerably less and I do it incrementally when I re-visit those sections instead of pounding my chest about how much work it all was. But the latter is praised.
My experience tells me that the best developers are:
- generous with their time to other devs
- not defensive about their code
- able to solve complex problems fast, and explain those solutions to other people
- able to focus really intensely
- enthusiastic about learning new things
- lazy about boring stuff (to the extent that they will spend 4 hours looking for a shortcut that saves them doing 1 hour of boring stuff)
but some of the most productive programmers I've worked with treated the entire thing as a job that they did from 9 to 5 to pay the bills, and their real interest lay elsewhere
and some of the best programmers I've seen were the hardest to manage, and ultimately were a net negative to the team
Coding is creative - there are an infinite number of ways to solve any given problem. This is why it's so hard to predict and manage, and resists quantification.
Ultimately, in a business setting, those are the only two metrics that matter.
Selection is a management problem, and like many management problems the median level of understanding is primitive and often dysfunctional.
Not many businesses understand how many flavours developers are available in, nor how to match those flavours to the team/project roles they need at that time. So they robo-hire with standard CS whiteboard hazing, or interview for "cultural fit", or some other nonsense.
The hard-headed hiring question is always "Will this person make the business more money, and if so, how?"
This may sound like a recipe for a sweat shop, but it really isn't. There's a lot of possible variation in "how", which includes making smart architectural choices, having good team lead skills, raising the company profile through social presence, and so on.
The strongest possible code is always a good thing, but sometimes it's fine if it's eclipsed by other qualities. You're hiring a person with many possible skills, not a cog in a machine that you're planning to spin as fast as possible until it breaks.
It's up to management to work out how to get value from that. And there's a lot of creative potential in management that traditional work cultures overlook.
I second this! From my experience the best or rather most productive programmers get stuff done focusing on customers over eligant code. Mostly, just because they want to get something done so they can either avoid further meetings or work on their personal stuff.
The "best" programmers you mentioned, from my experience, always end up souring the whole team. Most of the time, they can't seem to tell the forest from the trees.
With that in mind, one of the things I tell my team we always need to hire more of are just developers with social skills. Being effective at working with a team is 100x more important than being a good developer. As an example, I have spent weeks in meetings debating archetecture. Each meeting I would make my same suggestions and then the rest of our "best" developers would debate. By the 6th or so meeting regarding the architecture I just presented a prototype of the project. I won the debate by acting, not by trying to find an ideal solution.
When you can't find a clear answer... May be you asking the wrong question.
Create code is - in my opinion - a service, not a product...
If you keep paying a service like it is a product it will continue to be inefficient and open to opportunitistic behaviour.
What about changing the reward model then?
What you, programmer, get paid some fix price for expenses coverage and then a fee for each week (or month) you're software runs without a flaw? Or a fee that goes on as long as software keep working (with your eventual maintenance and fix help, of course).
This would make customer happy (he has a working programmer) and do reward more the best programmers.
The main issue of one-time assessment on programmer job is, in fact, that you not always discover software flaws immediately.. it takes time..
One quality of good developers not often brought up is empathy. It's absent from this article and all of the comments thus far.
Empathy is quite important in a vast array of creative endeavors. Development is not an exception in my opinion. It's the trait that allows developers to know what a person needs even if it isn't what they're asking for.
Being able to put yourself into the shoes of another busy person working in a domain you may have little familiarity with is difficult. Trying to solve technical problems for that person when they are not technical is harder. Efficiently using that person's time and getting to the root of what the actual problem is, not necessarily what they ask you to do, is harder still.
Getting to the point where you know how to ask the minimal amount of questions to understand the actual problem that needs solving takes practice and experience. It requires good listening and comprehension skills, and comes from caring enough in a person's problems to get to the root of the issue; an exercise in empathy.
By getting to the root of the problem you end up with better, more useful software and solutions, with less iterations. Even having the conversations to achieve these understandings requires knowing your tools well enough to gauge what's possible, an innate curiosity to care enough to dive into whatever it is that needs solving, and enough experience to know when to say "yes," "yes, but," "no," or "I don't know," to ideas. And to not only say it, but mean it, and know it to be true.
Additionally, developers who are good at actually solving problems for people must be creative enough to improve upon that situation without being told how.
All of these traits are excellent separately, but combined produce developers who solve problems and create value, not developers that just write code.
Empathy is a trait of some of the best developers I've ever met or worked with and a lack of empathy has been a strong indicator of mediocre, bad, or hard to work with developers.
Empathy is the just the newest word for certain people to feel that they're better than everyone else (who lacks empathy?).
After a while it gets tiring keeping up with it all, I sometimes think I should try and identify the newest word to add to the word bingo software developers seem to feel the need to employ to differentiate themselves from everyone else.
This is a great point, I think a good developer
-- has respect for other's code and perspective, he/she doesn't think that the previous developer did a bad job writing the code in first place. Many times the the code/solution that is better at times may not be good enough in long run
-- also a good developer is one who would write code/logic in such a way that the future developers would understand it easily. Sometimes having good comments in code could easily increase longevity of the program
Been a coder and engineer for 12+ years, now a manager of a team of 8.
I evaluate my team on their ability to ship regularly and with a consistently low bug count. I encourage communication regularly and pair programming and all that. And I am around and I listen and interact.
It is pretty easy to tell when someone isn't pulling their weight or is having problems contributing based on the interactions within the team. People naturally express frustration (as well as praise)... you just have to be an active, hands on (not micromanaging necessarily) manager.
In addition, I specifically look for growth mentality when hiring and cultivate it within the team. That way I can be confident that when a weakness or need for improvement is identified, the person will work on it. It's my job as manager to properly address it and motivate the person.
In my experience, KPIs and other measurables (including even basic timesheets) are always gamed by developers. And anyway there are so many intangible and abstract aspects to doing this job, especially as you advance in your career, that it's arguable that the most important parts of the work aren't even measurable in any real sense in the first place. That's the art.
There is quite simply no way to quantify in a scientific way how "good" a developer is.
Whether or not a developer is "good", and "how good", is purely subjective.
This is the core problem at the heart of all recruiting, and no matter how hard people try to quantify, test, assess and interview, it is still not possible to make an objective statement about how "good" a developer is.
Part of the issue is that "good" depends on a vast array of factors: the task at hand, the developers experience with the specific technologies, how they feel today, who the judge is, if the developer is feeling good or bad today, if the developer is interested in this specific task etc etc etc etc it goes on and on.
And one of the worst traps to fall into is to think that a developers "ability to code" in some way is a really good measure of how good that developer is. i.e. how quickly can you reverse an array, sort of dict of arrays etc. To my mind this is only a certain portion of what goes to make a great developer, and not even necessarily a very large or important portion. So many other things are important in making "a good developer" that assessing substantially on code seems misguided.
Most importantly, "good" to me, is definitely not the same as "good" to you, because the important things for you are likely completely different to the important things to me.
I wrote a post about some of the characteristics of a great software developer, but even this does little to nothing in terms of providing a "science" for the evaluation of how good a programmer is.
The best description for a good programmer that I have ever heard is from Joel Spolsky who suggested to employ people who are "smart and get stuff done". Interestingly, almost no employers take this approach to recruiting.
There is no reliable method yet. But who is to say there won't eventually be one?
You point out there numerous different dimensions of good coding. Consider an IQ test, it has many different categories, but since these strengths are correlated, you can compute an overall "score" for something very abstract like intelligence.
Why should we not, if we dedicate effort, be able to make something similar for coding? Aptitudes are already measured very effectively in many other disciplines (LSATs, MCATS, Putnams, SAT II)
The most important thing from my perspective is how well he or she develops in the context of the entire team. In no particular order a good developer will:
1. raise issues when other developers suggest solutions (even if just to play devil's advocate) to encourage discussion
2. be willing to have his or her opinion overruled by consensus, understand why, and proceed with contributing to implementation of it as well as if it hadn't been
3. accept constructive criticism in reviews of his code (and can make counter-arguments when appropriate without becoming defensive)
4. improve his or her craft by acknowledging and correcting errors in code and design when he or she makes them (nobody is perfect, and every experience level of engineer will make mistakes in judgement, and errors in logic, structure, and design occasionally), but generally make fewer such errors as time passes
5. seek out opportunities to share expertise, experience, and advice with co-workers
I'd say if most of these points are hit, a developer is doing a good job.
This article is right about one thing: managers should avoid mechanical metrics (lines of code cranked, bugs fixed, etc.) as a way of measuring developer competence.
Many developers are good at figuring out constraints and optimizing around them. It's a game for us. We're more productive when we're playing that game on behalf of our businesses and customers than on our own behalf. But if you award us points (dollars) based on optimizing metrics for ourselves, we'll probably do it. At the very least we'll have to spend mental energy resisting the temptation.
These kinds of metrics inevitably generate perverse incentives.
It's true that developers should remember that debugging code is harder than creating code. We should avoid creating code that is right at the limit of our cognitive capacity to understand. When we do create code like that, we've created code that's a stretch to debug.
There's a management corollary: don't use the most ingenious incentives you can imagine to motivate your krewe. You'll have a hard time debugging the incentives. And your krewe may exploit your buggy incentives in the meantime.
And, in both cases, imagine what will happen when your super-clever code or incentive scheme is handed off to your successor.
Oh? You want to keep doing exactly what you're doing now for the rest of your career? OK, go for it.
I think I often get rated poorer by management compared to others because I tend – by nature – to focus deeply on complex problems (Donald Knuth-style), whereas a lot of other developers communicate more, answer emails promptly, go to a lot of meetings and manage to cut 'n' paste together some code to show results the very next day. So you do get respect from fellow developers for your skills and experience, but managers don't really value you.
Nowadays there seems to be more and more focus on quick results ("profit") in development rather than an effort to have a more lasting solid base to build on; a lot of software is in eternal "prototype" phase, like the "under construction" state of web sites around 2000. I guess it echoes the general business mindset of quick short-term profit over lasting quality.
I think that pretty consistently the wrong people are chosen or promoted to lead or manage development projects; they are rarely the most knowledgeable of developers – if they know anything technical at all – and definitely even rarer do they possess the kind of personality that can actually stimulate and motivate others. I guess that's the curse of being more like an engineer as opposed to a business person; you tend to end up in a position where the people higher up don't necessary share the same motivations and goals, but have more control over your destiny than you'd like.
I would say the first step to competency in recruiting and managing developers is if you can tell when a developer is doing a terrible job. That's more important and easier, and more prone to objective measures. Someone who commits 100 lines a week may be better than someone who commits 200 lines, but the one who hasn't committed in a month may need some help getting things together.
With hiring as difficult as it is, developers who make any reasonable positive contribution are probably worth keeping.
From there, as a manager, the best thing to do is focus on getting the best out of each developer, and keeping the business profitable enough to be able to give raises that would make anyone happy.
> but the one who hasn't committed in a month may need some help getting things together.
They might, but on the other hand they might be the one who decided that the project needed documenting properly, or who is researching and designing the next feature.
I manage a data science team, and currently I measure on 4 axes:
–Technical (ability to effectively solve problems)
–Business (picking which problems to solve)
–Productivity (things done to improve workflows, automate processes, etc. of themselves & team)
–Team (teaching, hiring, training)
This works pretty well. I find that these skills are multiplicative, so someone's impact on the team is reasonably well-approximated by taking an average of these scores. I also find many things you might expect, e.g. variance in technical skill is pretty high, talented engineers usually develop high technical skills before high skills in the other domains, senior engineers tend to be force multipliers by being exceptional at the non-technical skills, etc.
Meh, this is almost exactly the formulaic industry-standard "solution."
The challenge here is that a human is evaluating all of these traits (you). Of course you think you're not biased, but research shows all humans are [e.f. more likely to promote people who remind them of themselves, without being threatening].
I think much like if an engineer made code and said "it's working great" without any kind of external monitoring to validate, asking a manager to promote without external validation is completely a crap-shoot.
I think what you label business is the most important and also hardest skill of these. It is also immediately relevant for productivity and team/training if you consider "learning as a whole"[0] a good approach (which I do).
>
The risk with this approach is that the criteria are vague from a developer’s point of view. They can’t really know what their manager is thinking. There is now an incentive to focus on learning to sell themselves to their manager instead of focusing on becoming a better developer.
This is true and very unfortunate.
Nobody realizes when a senior is working hard at preventing bugs complexity, or making code understandable or refusing to implement unnecessary features.
Managing a team as a tech lead (that is, I also develop a lot).
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.
I like this. So if the question was "how do you tell which sled dogs are really pulling", your answer would be: you can't, if you're standing on the sled. But if you're one of the dogs, it's a lot easier to tell.
Only a really good, really savvy manager can tell - The manager needs to be more knowledgeable (especially architectural knowledge) than any of the engineers working under them - That almost never happens. I've worked for maybe 10 different tech companies in my career so far and I've only had one manager who I considered to fit the description.
Most of the time, a manager might be really good in a very narrow area but they don't have the variety in experience or critical thinking ability to provide good leadership; they often just follow trends and patterns without actually thinking them through - They deal with everything as though it were inside neat little boxes and regurgitate blanket statements made by 'thought leaders' as the basis of all their decisions.
A software developer is doing a good job when his bottom-up programming skills are good. The most common mistake a beginner do is that he works top-down. The way you know someone works top-down is that he does not or don't want to rewrite existing code whereas he should be doing that a big amount of his time.
So, this sort of devolves to economics, at least where I work. What I mean is, the people that pay for the code don't care and don't care to know. And this is entirely rational from their point of view. If it appears to work, it's good.
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.
Is it really the most important? I'd question that. If you have a guy who writes brilliant code, but isn't on board with the company philosophy, or is acerbic and difficult to work with, or something like that, he won't be as effective as a journeyman better at the non-code aspects of the job.
Programmers are like art: you can't exactly pinpoint why a particular painting is good but you can usually still put different paintings in rough order of how good they are. It's never that one brush stroke that reveals the quality but the complete picture.
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.
Once upon a time, I was refused a salary raise because I've told that few of my commits had really critical bugs. On the same time another colleague was promoted to team lead because their app was flawless. A small difference here.
I've worked on multiple complicated legacy parts of the platform used by lots of people and the other team was building a single web api from scratch... I quit a month later...
Specific to this discussion, a big part of success as a developer is effectively communicating that one is doing a good job... if anyone has to ask this question, said developer has already lost!
The OP's question is definitely relevant to managers, and I appreciate the practicality of the discussion for both perspectives - what to do and/or what to look for.
Do we really need to know, in non-subjective way? In a 1000-person company, how many persons have their performance calculated in a non-subjective and vaguely accurate way?
It must surely only be in sales - where sales volume is a great measure, and I think sales people accept that they are allowed and expected to learn the cut-throat techniques to gameify the situation and win.
If we want to force the corresponding personality traits that make such measurement reasonable onto developers - then OK I think story points achieved (aka velocity) is an equivalent measure we can take.
An experienced twisted senior dev would know how to maximise their score there, and make a junior dev look atrocious in comparison, but if its OK for sales then its OK for devs?
(my actual opinion - being subjective and relying on the opinion of good managers is fine. The developer personality matches this.)
[+] [-] WalterBright|9 years ago|reply
I'd say a developer is doing a good job when you, as a manager, are not having him come in at all hours to fix problems with his stuff.
Other signs of a good developer are you don't have to micromanage him, and he's more of a partner helping you get things done rather than a subordinate you've got to spell things out for and check up on.
I.e. when he's on the job and you can relax and concentrate on other things, you've got a good 'un.
[+] [-] duncanawoods|9 years ago|reply
That's also what a developer who ships nothing, ever, looks like. There are quite a few of those. A developer who gets the most done and tackles the hardest work, on the most important and frequently used tools, integrating with the most problematic 3rd party systems and has specialist knowledge is likely to be called on a lot.
Ultimately you can't make any judgement of the developer without detailed understanding of the specifics of the work. This applies to every possible developer productivity metric which is why its so damned hard.
[+] [-] JustSomeNobody|9 years ago|reply
My thinking is, QA isn't there to find my bugs. They're there to make sure I don't have any. I seem to be in the minority on that thinking.
[+] [-] JoeAltmaier|9 years ago|reply
[+] [-] WalterBright|9 years ago|reply
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
[+] [-] anovikov|9 years ago|reply
[+] [-] BrailleHunting|9 years ago|reply
[+] [-] arenaninja|9 years ago|reply
[+] [-] blacksmythe|9 years ago|reply
Someone who did half as much work and made half as many mistakes was a much better employee as far as he was concerned.
[+] [-] ci5er|9 years ago|reply
[+] [-] cema|9 years ago|reply
[+] [-] collyw|9 years ago|reply
Is it stuff that he wrote or work he inherited?
[+] [-] marcus_holmes|9 years ago|reply
My experience tells me that the best developers are: - generous with their time to other devs
- not defensive about their code
- able to solve complex problems fast, and explain those solutions to other people
- able to focus really intensely
- enthusiastic about learning new things
- lazy about boring stuff (to the extent that they will spend 4 hours looking for a shortcut that saves them doing 1 hour of boring stuff)
but some of the most productive programmers I've worked with treated the entire thing as a job that they did from 9 to 5 to pay the bills, and their real interest lay elsewhere
and some of the best programmers I've seen were the hardest to manage, and ultimately were a net negative to the team
Coding is creative - there are an infinite number of ways to solve any given problem. This is why it's so hard to predict and manage, and resists quantification.
<edit for formatting>
[+] [-] TheOtherHobbes|9 years ago|reply
A bad developer subtracts business value.
Ultimately, in a business setting, those are the only two metrics that matter.
Selection is a management problem, and like many management problems the median level of understanding is primitive and often dysfunctional.
Not many businesses understand how many flavours developers are available in, nor how to match those flavours to the team/project roles they need at that time. So they robo-hire with standard CS whiteboard hazing, or interview for "cultural fit", or some other nonsense.
The hard-headed hiring question is always "Will this person make the business more money, and if so, how?"
This may sound like a recipe for a sweat shop, but it really isn't. There's a lot of possible variation in "how", which includes making smart architectural choices, having good team lead skills, raising the company profile through social presence, and so on.
The strongest possible code is always a good thing, but sometimes it's fine if it's eclipsed by other qualities. You're hiring a person with many possible skills, not a cog in a machine that you're planning to spin as fast as possible until it breaks.
It's up to management to work out how to get value from that. And there's a lot of creative potential in management that traditional work cultures overlook.
[+] [-] lettergram|9 years ago|reply
The "best" programmers you mentioned, from my experience, always end up souring the whole team. Most of the time, they can't seem to tell the forest from the trees.
With that in mind, one of the things I tell my team we always need to hire more of are just developers with social skills. Being effective at working with a team is 100x more important than being a good developer. As an example, I have spent weeks in meetings debating archetecture. Each meeting I would make my same suggestions and then the rest of our "best" developers would debate. By the 6th or so meeting regarding the architecture I just presented a prototype of the project. I won the debate by acting, not by trying to find an ideal solution.
[+] [-] velain|9 years ago|reply
[+] [-] randomdrake|9 years ago|reply
Empathy is quite important in a vast array of creative endeavors. Development is not an exception in my opinion. It's the trait that allows developers to know what a person needs even if it isn't what they're asking for.
Being able to put yourself into the shoes of another busy person working in a domain you may have little familiarity with is difficult. Trying to solve technical problems for that person when they are not technical is harder. Efficiently using that person's time and getting to the root of what the actual problem is, not necessarily what they ask you to do, is harder still.
Getting to the point where you know how to ask the minimal amount of questions to understand the actual problem that needs solving takes practice and experience. It requires good listening and comprehension skills, and comes from caring enough in a person's problems to get to the root of the issue; an exercise in empathy.
By getting to the root of the problem you end up with better, more useful software and solutions, with less iterations. Even having the conversations to achieve these understandings requires knowing your tools well enough to gauge what's possible, an innate curiosity to care enough to dive into whatever it is that needs solving, and enough experience to know when to say "yes," "yes, but," "no," or "I don't know," to ideas. And to not only say it, but mean it, and know it to be true.
Additionally, developers who are good at actually solving problems for people must be creative enough to improve upon that situation without being told how.
All of these traits are excellent separately, but combined produce developers who solve problems and create value, not developers that just write code.
Empathy is a trait of some of the best developers I've ever met or worked with and a lack of empathy has been a strong indicator of mediocre, bad, or hard to work with developers.
[+] [-] braveo|9 years ago|reply
After a while it gets tiring keeping up with it all, I sometimes think I should try and identify the newest word to add to the word bingo software developers seem to feel the need to employ to differentiate themselves from everyone else.
[+] [-] sandeep_a_k|9 years ago|reply
[+] [-] JackMorgan|9 years ago|reply
I've thought this for awhile, it's encouraging to see someone else draw the same conclusion.
[+] [-] RUG3Y|9 years ago|reply
[+] [-] ADanFromCanada|9 years ago|reply
I evaluate my team on their ability to ship regularly and with a consistently low bug count. I encourage communication regularly and pair programming and all that. And I am around and I listen and interact.
It is pretty easy to tell when someone isn't pulling their weight or is having problems contributing based on the interactions within the team. People naturally express frustration (as well as praise)... you just have to be an active, hands on (not micromanaging necessarily) manager.
In addition, I specifically look for growth mentality when hiring and cultivate it within the team. That way I can be confident that when a weakness or need for improvement is identified, the person will work on it. It's my job as manager to properly address it and motivate the person.
In my experience, KPIs and other measurables (including even basic timesheets) are always gamed by developers. And anyway there are so many intangible and abstract aspects to doing this job, especially as you advance in your career, that it's arguable that the most important parts of the work aren't even measurable in any real sense in the first place. That's the art.
[+] [-] andrewstuart|9 years ago|reply
Whether or not a developer is "good", and "how good", is purely subjective.
This is the core problem at the heart of all recruiting, and no matter how hard people try to quantify, test, assess and interview, it is still not possible to make an objective statement about how "good" a developer is.
Part of the issue is that "good" depends on a vast array of factors: the task at hand, the developers experience with the specific technologies, how they feel today, who the judge is, if the developer is feeling good or bad today, if the developer is interested in this specific task etc etc etc etc it goes on and on.
And one of the worst traps to fall into is to think that a developers "ability to code" in some way is a really good measure of how good that developer is. i.e. how quickly can you reverse an array, sort of dict of arrays etc. To my mind this is only a certain portion of what goes to make a great developer, and not even necessarily a very large or important portion. So many other things are important in making "a good developer" that assessing substantially on code seems misguided.
Most importantly, "good" to me, is definitely not the same as "good" to you, because the important things for you are likely completely different to the important things to me.
I wrote a post about some of the characteristics of a great software developer, but even this does little to nothing in terms of providing a "science" for the evaluation of how good a programmer is.
http://www.supercoders.com.au/blog/50characteristicsofagreat...
The best description for a good programmer that I have ever heard is from Joel Spolsky who suggested to employ people who are "smart and get stuff done". Interestingly, almost no employers take this approach to recruiting.
[+] [-] flukus|9 years ago|reply
[+] [-] alexandercrohde|9 years ago|reply
You point out there numerous different dimensions of good coding. Consider an IQ test, it has many different categories, but since these strengths are correlated, you can compute an overall "score" for something very abstract like intelligence.
Why should we not, if we dedicate effort, be able to make something similar for coding? Aptitudes are already measured very effectively in many other disciplines (LSATs, MCATS, Putnams, SAT II)
[+] [-] emodendroket|9 years ago|reply
[+] [-] sidlls|9 years ago|reply
1. raise issues when other developers suggest solutions (even if just to play devil's advocate) to encourage discussion
2. be willing to have his or her opinion overruled by consensus, understand why, and proceed with contributing to implementation of it as well as if it hadn't been
3. accept constructive criticism in reviews of his code (and can make counter-arguments when appropriate without becoming defensive)
4. improve his or her craft by acknowledging and correcting errors in code and design when he or she makes them (nobody is perfect, and every experience level of engineer will make mistakes in judgement, and errors in logic, structure, and design occasionally), but generally make fewer such errors as time passes
5. seek out opportunities to share expertise, experience, and advice with co-workers
I'd say if most of these points are hit, a developer is doing a good job.
[+] [-] OliverJones|9 years ago|reply
Many developers are good at figuring out constraints and optimizing around them. It's a game for us. We're more productive when we're playing that game on behalf of our businesses and customers than on our own behalf. But if you award us points (dollars) based on optimizing metrics for ourselves, we'll probably do it. At the very least we'll have to spend mental energy resisting the temptation.
These kinds of metrics inevitably generate perverse incentives.
It's true that developers should remember that debugging code is harder than creating code. We should avoid creating code that is right at the limit of our cognitive capacity to understand. When we do create code like that, we've created code that's a stretch to debug.
There's a management corollary: don't use the most ingenious incentives you can imagine to motivate your krewe. You'll have a hard time debugging the incentives. And your krewe may exploit your buggy incentives in the meantime.
And, in both cases, imagine what will happen when your super-clever code or incentive scheme is handed off to your successor.
Oh? You want to keep doing exactly what you're doing now for the rest of your career? OK, go for it.
[+] [-] wvh|9 years ago|reply
Nowadays there seems to be more and more focus on quick results ("profit") in development rather than an effort to have a more lasting solid base to build on; a lot of software is in eternal "prototype" phase, like the "under construction" state of web sites around 2000. I guess it echoes the general business mindset of quick short-term profit over lasting quality.
I think that pretty consistently the wrong people are chosen or promoted to lead or manage development projects; they are rarely the most knowledgeable of developers – if they know anything technical at all – and definitely even rarer do they possess the kind of personality that can actually stimulate and motivate others. I guess that's the curse of being more like an engineer as opposed to a business person; you tend to end up in a position where the people higher up don't necessary share the same motivations and goals, but have more control over your destiny than you'd like.
[+] [-] jrumbut|9 years ago|reply
With hiring as difficult as it is, developers who make any reasonable positive contribution are probably worth keeping.
From there, as a manager, the best thing to do is focus on getting the best out of each developer, and keeping the business profitable enough to be able to give raises that would make anyone happy.
[+] [-] danellis|9 years ago|reply
They might, but on the other hand they might be the one who decided that the project needed documenting properly, or who is researching and designing the next feature.
Not all useful work involves writing code.
[+] [-] SatvikBeri|9 years ago|reply
–Technical (ability to effectively solve problems)
–Business (picking which problems to solve)
–Productivity (things done to improve workflows, automate processes, etc. of themselves & team)
–Team (teaching, hiring, training)
This works pretty well. I find that these skills are multiplicative, so someone's impact on the team is reasonably well-approximated by taking an average of these scores. I also find many things you might expect, e.g. variance in technical skill is pretty high, talented engineers usually develop high technical skills before high skills in the other domains, senior engineers tend to be force multipliers by being exceptional at the non-technical skills, etc.
[+] [-] alexandercrohde|9 years ago|reply
The challenge here is that a human is evaluating all of these traits (you). Of course you think you're not biased, but research shows all humans are [e.f. more likely to promote people who remind them of themselves, without being threatening].
I think much like if an engineer made code and said "it's working great" without any kind of external monitoring to validate, asking a manager to promote without external validation is completely a crap-shoot.
[+] [-] kriro|9 years ago|reply
[0] See: "Making Learning Whole" by David Perkins
[+] [-] emodendroket|9 years ago|reply
Yeah, no kidding. Welcome to white collar work.
[+] [-] mikekchar|9 years ago|reply
Junior Developer: By how much more someone else was willing to pay them.
Intermediate Developer: By how screwed you are after they leave.
Senior Developer: By how screwed you're not after they leave.
[+] [-] eeZah7Ux|9 years ago|reply
[+] [-] RUG3Y|9 years ago|reply
Yes, I agree with all of these.
[+] [-] cygned|9 years ago|reply
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.
[+] [-] Nomentatus|9 years ago|reply
[+] [-] jondubois|9 years ago|reply
Most of the time, a manager might be really good in a very narrow area but they don't have the variety in experience or critical thinking ability to provide good leadership; they often just follow trends and patterns without actually thinking them through - They deal with everything as though it were inside neat little boxes and regurgitate blanket statements made by 'thought leaders' as the basis of all their decisions.
[+] [-] quadcore|9 years ago|reply
[+] [-] flukus|9 years ago|reply
This is the most important but also impossible for non-technical managers, or even technical ones that were never that good themselves.
Are there companies out there the do independent audits of developers/code quality? If always wondered if there is a business opportunity there.
[+] [-] handojin|9 years ago|reply
To audit the code accurately (as opposed to merely giving out aesthetic advice), in most cases would involve learning the domain, and this is what's expensive.
To the business folks, we're a black box. Stuff goes in, stuff comes out. And it costs. Paying someone else at least as much to prove that we did it according to 'best practice' (I think this is what you're suggesting?) would be anathema.
There might be a business there but it's not mass market.
It's probably also worth noting that all of the above applies to other domains too. Substitute 'code' for 'marketing' quality. In some real senses, die welt ist alles was der fall ist.
[+] [-] ADanFromCanada|9 years ago|reply
[+] [-] emodendroket|9 years ago|reply
[+] [-] yason|9 years ago|reply
With programmers, there are indirect, subtle signs which may or may not give clues. Sometimes they only validate some good or bad aspects of the programmer.
I think that to really know the only way is to work with the programmer and see what works and what doesn't. Generally the team does have a good notion of who are good and who are just great, although a manager might want to use the information from that source with some grain of salt.
However, it's easier to pinpoint programmers which aren't good, or not completely good. The guy who doesn't get things done. The guy who breaks more stuff than he fixes. The guy who rewrites everyone else's code as the first step in any project or the guy who's always asking help from others for simple things. Or the guy who is actually a good programmer but always ends up doing something a bit different than what the important things to do are. Or the good programmer who is relentless in insisting he's right because "that's what the facts are" while completely ignoring social issues such as understanding that a dictatorian attitude doesn't fly well with other programmers. These guys still do provide some value but you can see these shortcomings from far away. Then there are the guys who actually produce negative values, i.e. taking away others' time merely by being employed.
[+] [-] agounaris|9 years ago|reply
[+] [-] j_s|9 years ago|reply
https://twitter.com/practicingdev (on haitus)
"the thing that motivates me is inspiring developers to think holistically about software dev"
"The value you bring to your work is not measured in how much code you produce, but in helping other people solve real problems."
etc.
Semi-obligatory book plug: https://amzn.com/dp/B01LYRCGA8
--
Specific to this discussion, a big part of success as a developer is effectively communicating that one is doing a good job... if anyone has to ask this question, said developer has already lost!
The OP's question is definitely relevant to managers, and I appreciate the practicality of the discussion for both perspectives - what to do and/or what to look for.
[+] [-] razzimatazz|9 years ago|reply
It must surely only be in sales - where sales volume is a great measure, and I think sales people accept that they are allowed and expected to learn the cut-throat techniques to gameify the situation and win. If we want to force the corresponding personality traits that make such measurement reasonable onto developers - then OK I think story points achieved (aka velocity) is an equivalent measure we can take.
An experienced twisted senior dev would know how to maximise their score there, and make a junior dev look atrocious in comparison, but if its OK for sales then its OK for devs?
(my actual opinion - being subjective and relying on the opinion of good managers is fine. The developer personality matches this.)