I bet you could point to the weakest software developer in your department with little hesitation. But if I asked you to identify your criteria, it's unlikely that "metrics" would play any part in that judgment...
writes Esther Schindler in a recent CIO.com article.
Schindler posted a similar question to online discussion groups, and summarizes the answers in the article. One of Schindler's hypotheses is that traditional software metrics may not help pinpoint the least desirable members of a development team:
The purported goal in collecting such measurements is to judge team members' production. With the best of intentions, a manager wants to use that data to strengthen and reward top performers, and also to identify weaker team members so they can be trained and improved...
Managers want to be fair and... well, not dispassionate, exactly, but at least even-handed. But judging a team member's contributions isn't easy. It's even harder if you're not looking at the developer's code day-to-day, or if your lack of technical expertise keeps you from understanding what you're looking at...
I think you could do a quiet survey in any programming shop, asking everyone who the weakest contributor is—and probably get the same answer from most team members...
Some of the responses Schindler received to her online query include developers who don't care about the quality of their work, those who produce more work rather than helping the team, and those whose arrogance causes grief to the team. Lack of experience, however, does not necessarily translate to the "worst" developer:
The "worst" developer on a team is not necessarily the least experienced. Someone who knows his strengths and is actively trying to address his weaknesses is often appreciated for the former and cheerfully mentored for the latter. Savvy managers enable the process because ... the team is good or bad together.
How do you pinpoint the worst developers on a team?
I don't spend time trying to pinpoint bad developers. I know 'em when I see 'em.
The common trait I see in the worst programmers is that they start coding without a plan. I don't mean necessarily a formal plan. I mean they don't have any idea how they are going to solve the problem at hand. They just code and code and meander around to a solution. We have a program written by a former coworker uses dozens of programs, complex persisted structures and external dependencies all in order to FTP files. That's it. The program FTPs files between machines. It takes about 100 times longer to figure out how to use it than it does to just do it the standard way. Trying to follow this programmer's code is like a going on a surrealistic fantasy adventure. You end up in strange places and aren't really sure why you are there or what's going on. Eventually it comes back around to the solution and works, usually, as long as nothing unexpected occurs in which case it destroys or corrupts data.
The one(s) who don't have *any* passion for what they're doing. From that follows everything - lack of pride & professionalism, the don't care attitude, sloppiness ..
And this question is kinda silly too - if my team is all top, dedicated performers, who/what is the 'worst' programmer?
> You end up in strange places and > aren't really sure why you are there or what's going on.
Ah yes, we had one of those a while back. All code was written as though it was a quick hack with no consideration to maintenance or readability. He once had a C macro containing a 'goto' called BOGO. He was told to change it. He did. To OBONGO! He's left now, but I'm still having to untangle the mess he left behind. I re-wrote a one of his analysis modules. It now has about half the lines it did before.
> And this question is kinda silly too - if my team is all > top, dedicated performers, who/what is the 'worst' > programmer?
Indeed, this sounds much like someone is calling for "Neutron Jack".
In my experience there is no linear scale anyway, even if not all programmers are top. Some people don't get programming and don't understand what they are doing as programmers. But they might have a good grasp for requirements and specs or doing otherwise useful things. In a sense a project manager has to create or better compose work and balance strengths and weaknesses. They shall get a better salary for a reason.
> The one(s) who don't have *any* passion for what they're > doing. From that follows everything - lack of pride & > professionalism, the don't care attitude, sloppiness ..
There should be a test of how passionate is one for programming. People under a certain threshold should be rejected ;-).
A programmer who doesn't own his work is the worst programmer.
He is the one who ignores flaws if he finds any, doesn't care to correct them before being told by anyone else, does not takes any responsibility for the code he creates, doesn't feel guilty if he finds bugs in the programs he writes etc
One cannot easily identify such programmers. One needs to invest time and energy by observing his work over a period of time.
> Ah yes, we had one of those a while back. All code was > written as though it was a quick hack with no > consideration to maintenance or readability.
In my experience, the worst programmer on the team is usually the manager, which is why some kind soul promoted him out of the way...
Among the current programmers, its clear that personality traits outweigh current technical knowledge. Some programmers simply don't like their profession, and no amount of skill will make up for their corresponding lack of motivation. Others are simply lazy, and will never go back and fix, let alone improve, their code. Both these traits would lead to poor work quality in any field. Sometimes it not just the presence of a bad trait, but the lack of requisite good ones.
When I first started, I thought it was all about skill, about things like a deep understanding of the language, the libraries, and the platform. Eventually, I realized that a "good programmer" could always pick up this type of knowledge as necessary. But what, then made them a good programmer? It was personality traits that were un-teachable, fundamental aspects of their being. Things like persistence in the face of frustration, inquisitiveness about how things work, a detail-oriented approach, and an appreciation of quality in all things.
>>It was personality traits that were un-teachable, fundamental aspects of their being. Things like persistence in the face of frustration, inquisitiveness about how things work, a detail-oriented approach, and an appreciation of quality in all things.
When a person doesn't have the aforementioned things, then how is it possible that he picks up technical stuff like the language, libraries and the platform?
> When I first started, I thought it was all about skill, > about things like a deep understanding of the language, > the libraries, and the platform. Eventually, I realized > that a "good programmer" could always pick up this type of > knowledge as necessary. But what, then made them a good > programmer? It was personality traits that were > un-teachable, fundamental aspects of their being. Things > like persistence in the face of frustration, > inquisitiveness about how things work, a detail-oriented > approach, and an appreciation of quality in all things.
My personal feeling is that it really comes down to problem solving, which can be learned but is not easily taught. I agree that fundamentally, the technical aspects of programming are just things you need to pick up along the way, although understanding the universal aspects of the trade do make a big difference and some of them are hard to pick up on your own. Problem solving is the most important skill, though.
> >>It was personality traits that were un-teachable, > fundamental aspects of their being. Things like > persistence in the face of frustration, inquisitiveness > about how things work, a detail-oriented approach, and an > appreciation of quality in all things. > > When a person doesn't have the aforementioned things, then > how is it possible that he picks up technical stuff like > the language, libraries and the platform?
There's a big difference in knowing a lot of information about a subject and having a deep understanding of it. I think that's what he's getting at. To give an analogy, great physicists are not people who know a lot of formulas by heart and how to apply them to a problem. They are the ones who can derive new formulas.
I have a piece of paper pinned to my partition above my desk. I think I may have got it from an article here. It lists four types of co-worker. I like to imagine I'm in the first category. I think my ex co-worker was in the second.
Intelligent Lazy people are everyone's favourite. They do things in a smart way in order to expend the least effort. They don't rush into things, taking that little bit of extra time to think and find the shortest, best path. They tend to make what they do repeatable so they don't have to go through it all again. These people usually make good leaders, and they are good to have on teams.
Intelligent Active people are useful, because they are smart, after all, but their intelligence can be slightly diluted or tempered by their activity. Where they don't have a perfect solution, they might act anyway, rather than sitting on their laurels, so useful people but not great leaders, and on a team, they can often put noses out of joint by acting too early and too fast.
Stupid Lazy people have their place too, they are easy to manage, they generally don't act on their own initiative too much and, given tasks that are not beyond them, they will perform in a predictable, consistent manner. Usually they won't cause any harm on teams.
Stupid Active people are the dangerous ones. Their default behaviour is to act, and in the absence of skill or thought they can cause all types of trouble.
readability, system efficiency, use of libraries, knowledge of the language, understanding the problem (from a user's perspective), comments, extensibility, modular design, knowledge of the common idioms of the language...
These criteria are the first to come to mind and are not in a particular order. A combination of these factors lets me know whether a developer is good or not. My own weighting of each criterion changes as I gain more experience. Early in my career I placed much greater emphasis on system efficiency; later it became extensibility and modular design; now I consider readability and understanding the problem to be critical for the applications I'm involved with.
Of course, some of the criteria are interrelated. For example, not understanding the problem to solve can lead to spaghetti code as can a lack of knowledge of the language and its idioms.
Flat View: This topic has 47 replies
on 4 pages
[
1234
|
»
]
Previous Topic
