WhatMakesDevelopersGood

While reading the WhatMakesTestersGood thread, I thought, hmm, what makes a developer good? Here are some thoughts:

ability to focus on the task at hand and
ability to finish the task. For me, these two are linked. The ability to focus on the work is critical, but if the focus doesn't culminate in finishing the work product, then the focus is not entirely useful.
ability to recognize when there is and isn't a problem. Too many systems are answers to problems that aren't there.
knowledge that everyone makes mistakes, including yourself, and the courage to look for those mistakes in multiple forms

What additional attributes do you think of, when you think of great developers? JohannaRothman 2002.05.21

The skill to envision and articulate an end point.

The skill to develop a plan working backward from the end point.

The skill to discern the difference between a requirement and a preference.

SteveSmith 2002.05.21

Ability to recognize when straight ahead is not working.

Ability to see the abstraction and generalize rather than almost clone continually.

Ability to learn from mistakes, preferably from others as well as your own.

Recognize James Bach's good enough point avoiding the temptation to optimize or gold plate everything.

Ability & willingness to align priorities with the team.

Curiosity and drive to own his/her own learning and pursue it.

Knowing that quality drops somewhere after 40 hours per week.

BobLee 2002.05.21

To communicate efficiently and effectively.

ErwinVanDerBij 2002.05.21

Ability to interrupt a task when the need arises.

Willingness to talk to others about a design before coding it.

SherryHeinze 2002.05.26

Here's a little combination:

Able to communicate efficiently and effectively to others when interruptions of tasks become too frequent. Even more generally, able to regulate one's work environment to optimize results. - JerryWeinberg 2002.05.26

I'd like to explore Jerry's "optimize results" a little. One of my clients asked me "How much time should we expect to spend on software quality activities?" A great question. And, I had to give him the It Depends answer, because it really does depend on how good the developers are. So let me ask this question: Of the developers you've known, how have they made the software good?

Here are some of my experiences:

One developer had a philosophy of three: He knew he was going to do it three times before he got it right, so he figured he'd prototype, then design, then implement. Every time he tried to shortcut his process, he'd screw up, and have to do the previous activity again. And, it would take longer. This developer did Jerry's regulatory thing to optimize his results.

Before I hog this thread, any other stories out there? JohannaRothman 2002.06.10

I catagorize some people as "Junior Developers", because of some classic mistakes that they tend to make. When interviewing I try and see if people have make the realization that these should be avoided:

1) Jr developers want to rewrite all the code from scratch. They do not understand the system and wish to reimplement the whole thing so that they can understand it. This is true even if the part that needs work is small and easily isolated.

2) Jr developers do not design their code so that it can be debugged. That is the code should be modular so that errors can be quickly isolated to the likely part of code and the code should produce helpful error logs when faced with problems. These are the kind of people who ask "please help me debug my code" and after staring at the mess for a bit you ask "why did you put the bug in there in the first place? If you organized this better there would be no bugs."

KenEstes 2002.06.27

On joining a startup in 1986 as first full-time developer, we evaluated development languages and concluded that we had to settle for IBM Assembler as the run time libraries for PL/1 and COBOL had too many variants with our customers.

We had considerable experience with the down sides of Assembler, so I decided to emulate as high a language as I could within Assembler. We had portabliity and installability in mind as well as testability. Simple things like DISPLAY 'Oh, gee, I got here with ', result-code get pretty detailed, ugly and error prone in Assembler. The master ugliness of assembler is 8-character names. Ugh!!! We were able to purchase Assembler-H for a mere $2500 or so, which gave us long names and much better performance.

With another programmer of the same mind, we built a macro library and an operating system firewall. Our architecture target was to make dynamic linkage and true reentrancy automatic and fool-resistant.

The runtime linkage implemented automatic stack storage for function-unique inline data areas, and ensured all allocated storage was initialized (zeroes or explicit fill) to prevent non-repeatable random failures from uninitialized data. This proved to reduce per-routine initialization fairly significantly - you could trust NULL for first time tests.

Every DSECT (user defined data type) we defined had a displayable 4-character "eyeball" signature and a binary version signature. These made testability and "AHAH!" in testing much more frequent.

As far as I know, if you run ENDEVOR/MVS or ENDEVOR/DB from Computer Associates, if you get a dump you'll see a slew of "eyeball" signatures all over memory. Many of them start with a mysterious "$BS" or "$B" standing for "Business Software Technology, Inc".

Coming up with an extensible architecture that stands the test of time is one mark of a great developer, in my ever-so-humble opinion ;-)

Happy Independence Day, folks!

--BobLee 2002.07.04

XP mentions four values: Communication, Simplicity, Feedback, and Courage.

Agile Modeling adds another: Humility.

I think Humility is pretty important. --KeithRay 2002.07.06

I humbly agree. - JerryWeinberg 2002.07.06

I am so interested in "humility" as a characteristic of good developers. I've seen several groups held hostage by very un-humble developers who had cowed some persons into believing that if he/she left the entire system would crumble. EstherDerby 070702

Jerry pointed out in Psychology of Computer Programming long ago that mastery requires separating your ego from your product. Once you have institutionalized code reviews or pair-programming, you know at the gut level that you can learn something important from anybody [including new trainees]. That helps keep you humble. I think there's a Maslow heirarchy of qualities in development, and humble is somewhere around the first or second plateau. You need to get past that plateau to be good. -- BobLee 2002.07.07

Unfortunately, humility is not sufficient to become good :-) Maybe the problem is we're mixing personal characteristics with skills and experiences. Here's an attempt to reorganize what others have said earlier:

Personal characteristics:

humility
ability to communicate with the other people on the project
able to create simple implementations (does this reflect the XP Simplicity value?)
ability to receive feedback (and give it?)
Courage to (Keith, courage to what? I was all set to say "courage to forge ahead, even if you don't have a clue how this will turn out. But, I don't know what the XP people were thinking with this one.)

Experiences:

Ability to recognize when straight ahead is not working.
ability to know how many hours per week (or per day) they can effectively work
ability to choose design discussion partners

Skills:

coding skills in the language(s) in use for this product
ability to plan backwards from the end point
focus on the task
finish the task
knowledge of requirements and preferences

What do you think? --JohannaRothman 2002.09.22

That's close, Johanna, but one more experience/skill I learned on my first 30-person project:

Willingness and ability to share design/coding knowledge with junior team members to reduce the creation of inexperience bugs.

Our Commercial Accounts Billing System had 5 junior programmers that were making new bugs faster than the senior developers could isolate and repair them. We had to explicitly walk thru some code at training speed with them to halt the bad practices done in ignorance. Their academic training hadn't equipped them for team effectiveness.

A team is as weak as its weakest link, so bringing newbies up to speed is a team priority. The ratio of effort between bug creation and bug repair doesn't favor "mind your own business" developer teams.

--BobLee 2002.09.22

Courage to do the right thing.

The right thing might be writing a new unit test (supported by a pair partner), or refactoring code (supported by a test suite), or asking the Customer (supported by having an on-site Customer).

Too often programmers don't have the courage to ask, test, or refactor... under time-pressure or low self-esteem.

KeithRay 2002.09.22

Even if the "right thing" is something un-XP ish? I'd rephrase as "especially when the right thing goes against the current culture". -DaveLiebreich 2002.09.22

"ExtremeProgramming is a "starting line", not a "finish line". It doesn't forbid doing whatever a project needs to do, though it recommends doing it in a simple way that values people over process, etc...

KeithRay 2002.09.22

The ability to say "No" congruently (or at least tactfully).

DaveSmith 22 Sep 2002

That's the same thing for managers. See NoBirdsofaFeather.

Bob, you're talking about more than mentoring here aren't you? Or am I putting words into your mouth? I used to ask new college grads to think of themselves as high-paid apprentices. Every time I paired a newbie with an experienced person, both people benefited. The experienced person learned by articulating. The new person learned what they don't teach you in school. This only worked for me when we (all of us) decriminalized defects. We can learn to not make this kind of defect again, but if we do, it's still not the end of the world. That's what reviewers are for.

Keith, thanks for explaining the courage comment. Too many people, whether they are developers, testers, or managers, don't have the courage to do what's best. Sometimes, what's best is NO :-) (Thanks Dave.) --JohannaRothman 2002.09.23

JR, I do mean more than mentoring - the tech leaders could have continued to heroically find and fix bugs, but recognizing that there was more leverage in bringing the newbies into best practice/worst practice awareness took greatness. Our manager and the tech leads met and discussed the problem - rising bugs from juniors, but the solution was in the technical realm so we purposely set policy of inviting 1-2 juniors into each walkthru to learn by example reading good & bad and the consequences. Had we let the walkthrus stay elite reviewers only we wouldn't have escaped the plague.

BobLee 2002.09.23

Updated: Tuesday, September 24, 2002