General discussion


Great developers vs Not so great developers

By onbliss ·
In the discussions under the blog - "Ripoff Educations" (, one theme that appeared many times was - "great coder vs the not so great coders". I thought a separate discussion thread on this theme would be fun to have.

I am using the term "developer" instead of the term "coder" - just personal preference. Also invariably any person who codes does not "purely" code - they are involved in a project and work in the context of completing a project. Hence lots of soft and technical skills come into play. Also the work entails more than just coding.

So what traits distinguish great developers from the not so great developers?

edit: grammar

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

To me a great developer

by Tony Hopkinson In reply to Great developers vs Not s ...

is one who understands the system is more than the software.

A person who accepts, plans for and thrives on change.

Collapse -

What if...

by onbliss In reply to To me a great developer

...the system is so big that "islands of expertise" exists? Would you then break it down to the sub-system or component the developer supports or owns?

Collapse -

Technical Architecture

by Tig2 In reply to What if...

Theoretically, even while "islands of expertise" exist, your Tech Arch has SME level knowledge of the best approach to making disparate systems work together.

Within that overview, you have sub-system specialists capable of catching the nuances of a blended system. Generally, they have seen the sub-system work... and fail. They know the "softer" voice of the system as it "speaks" to their sub-specialty.

Onbliss, one of the key points in the development cycle that I see- I don't write code anymore, I just make sure that my team has what they need to do the work- is that I work with a lot of people from other countries. I bring this subject up only because I think that there are some great developers that are perceived as being "not so great" based on the cultural differences that exist.

I do a great deal of work with people from India. I have learned that we are very different in our communication styles and end up losing our ability to communicate well as a result.

A case in point- my fiance wrote an application that is mission critical. It is now with the Indian group that will test it. The US team wrote a test plan (bulleted) and sent it with the code. The partner has now made three different efforts to write a test plan that will pass architecture.

What I discovered is that we are not communicating the requirements in a manner that can be clearly understood by our partner. Nor are we checking to insure understanding.

It is necessary for Americans to learn how to communicate effectively with their partners of all nationalities and to recognise that cultural differences may block that effective communication. To me, only then, will we really know the great developers from the "not so great".

Collapse -

Shouldn't it be 2-way...

by onbliss In reply to Technical Architecture

... the Indian programmers,also, stepping up and improving to communicate effectively with the Americans?

Looks like you do not consider Effective Communication as being one quality of a Great Developer, but the lack of it as an impediment to determining the greatness of a developer.

Collapse -

It SHOULD be two way

by Tig2 In reply to Shouldn't it be 2-way...

But it isn't and will likely never be. Right or wrong.

Generally, the effective communication comes from project management. I know many great developers that have difficulty with that point- both American developers and Indian developers.

In an increasingly flat world, it is the responsibility of everyone in business to communicate effectively.

Collapse -

Convert What the User Wants into Something the User Uses

by frankstaheli In reply to Shouldn't it be 2-way...

Good 'coders' can create some really cool stuff, but what is important is to be able to understand what the user wants, and get their feedback to confirm that they feel you understand them. Then if you can put that understanding into clean, efficient code and the user actually uses it, you are a good 'developer'.

Collapse -

What the user wants? to get the job (well) done

by lclaudio.rodrigues In reply to Convert What the User Wan ...

A piece of software is like a tool, and as such should have a few attributes:
- be efficient in doing the job it was designed for
- be easy to learn how to use (an entire new thread on user friendly UI could go here...)
- be safe (just like an electric saw should never hurt the user, good software should not create havoc in the user environment because of bugs or distorted concepts in the code due to misunderstood user requiremenets)
- be easy to maintain (a good tool shouldn't take a full disassembly to clean and repair - here we talk about short well connected modules instead of one big chunk of code)
If you can cope with these attributes, to me you're a great developer (no necessarily a great 'coder').

Collapse -

You forgot

by Tony Hopkinson In reply to What the user wants? to g ...

cheap and ready yesterday.

Actually I wish more customers had maintainability as one of their design requirements. Might help me persuade the bean counters at the companies I've worked for that it was worth putting a bit of resource into.

Collapse -

islands of expertise....

by Jaqui In reply to What if...

Actually, this is very much the style of linux and the BSDs.
Where each major section of the operating system is developed by a separate team.
kernel, one team
base utilities, one team
cli shell, one team for each shell [ there are a dozen shell options ]
shell based apps, one team per app.
x server, one team
window managers, one team per manager.
[ Desktops like Gnome and Kde are further broken up due to the complexity. ]

There are benefits to this approach, mainly being in rapid dev cycles. if the system itself is using standards compliant protocols for communication between different parts then it makes integration of those parts a trivial exercise.

The dawback to it is that the overall vision for the larger project is hard to keep consistent. This is a part of why the open source operating systems have so many options for the same functionality. Each one being only a slightly different look at the desired end result.

Is this the way to go with a commercial project?
most likely not. very few commercial projects will be as complex as an operating system, so wouldn't benefit from breaking them into smaller projects.
[ an office suite is one of the few that will benefit from this ]

Collapse -


by onbliss In reply to islands of expertise....

There are pros and cons, and in my opinion such scenarios are not avoidable. It comes with our territory.

After a system is implemented it tends to grow and change. The design and coding standards deteriorate [Martin Fowler advocates refactoring]. Larger systems involving multiple tiers are complex; maybe not as complex as OS or Office suites. During maintenance one invariably encounters such island experts - those who are aware of the band-aids in place :-)

Related Discussions

Related Forums