Desktop·25,135 discussions

Great developers vs Not so great developers

Locked

In the discussions under the blog – “Ripoff Educations” (http://blogs.techrepublic.com.com/programming-and-development/?p=368), 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

Topic

To me a great developer

In reply to Great developers vs Not so great developers

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

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

What if…

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?

Technical Architecture

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”.

Shouldn’t it be 2-way…

In reply to Technical Architecture

… the Indian programmers,[b]also[/b], 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.

It SHOULD be two way

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.

Convert What the User Wants into Something the User Uses

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’.

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

In reply to Convert What the User Wants into Something the User Uses

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’).

You forgot

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

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.

islands of expertise….

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 ]

Reality

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 🙂

I think that several large projects do benefit from…

In reply to islands of expertise….

decomposition into several large components that are distributed to different team with different skill.
The software I work on has several teams working on it because it is made-up of several fairly large components (Configuration tool, Runtime console, Server, Low-level drivers, Firmware). The teams are made-up of people with different skills and different background and this is working fairly well. The problem though is when people want to go and play in another teams playground. The results are often not very good (sometimes desastrous). Fortunatly this does not occur too often.
The problem that I see in practice come from a lack of a common background of fundamental skills: an understanding of good design practices and other such knowledge that have nothing to do with a specific languages.

JS

Existing knowledge of the current codebase

In reply to What if…

or of particular technologies doesn’t make a great developer by it self. They can be learnt as can the soft skills you need to apply your talent effectively.

A great developer can apply their skills in whatever environment required.

There’s a geek appreciation of a great developer and a production oriented one.

The latter requires far more soft skills, and it’s those coupled with software design and robust implementation that make a great developer as opposed to a great coder.

Agreed

In reply to Existing knowledge of the current codebase

If I were to generalize, would it be appropriate to say knowledge does not make one a great developer?

Including

In reply to Agreed

knowledge of how to be a good developer?

😀

Attitude first, then knowledge

In reply to Agreed

It was remarked already that skills or existing code can be learned. These are the result of the right attitude.

First, a great developer cares. Care shows forth in anything we undertake. Second, he has pride in his work.

I have one great developer. He takes time to understand the complete requirements. He thinks through the solution completely from the user viewpoint. He considers potential problems. He asks questions. He looks around before changing code. He codes neatly. He spends time on the user interface. He brings new ideas to the project and accepts change.

What more can I ask? No, you may not have his name.

Attitude, Knowledge, Confidence, and People Skills

In reply to Attitude first, then knowledge

I agree with the attitude about caring and seeing beyond their limited viewpoint. Have an open mind. They see what makes a good, usable and functional product for the end user.

Skills are also paramount, but I think a great developer learns new skills when and if necessary. Reading, learning, and taking classes are an important trait for staying current in this ever changing field.

I also think a good developer has developed confidence in his/her abilities and when a good developer is faced with (I’ve never done that before), because of past successes a good developer can say, well I can figure it out.

A great developer has people skills also. They can talk in coherent, non intimidating, language.

I’ve never done that before

In reply to Attitude, Knowledge, Confidence, and People Skills

is a driver for a developer. If your fear of the new makes you not want to find out, great good or even bad aren’t in the equation. You aren’t even a developer.

Totally Agree

In reply to Attitude first, then knowledge

I must argee with d.Sanders. NOTHING can kill a project (or sour the taste) quicker that someone with a bad attitude. We all know that there’s ‘one’ in every office….

Great developer

In reply to To me a great developer

Gees I had to read about 20 posts, and still i’m not safisfied with the definition of a great developer!!

Let’s start by what we are defining here: DEVELOPER.

Most people mentioned the softer skills of development. Whereas it is important nowadays, it does not make a person a great developer.

In my opinion a great developer is someone who’s work don’t come back with major outages, the fewer the better. Definitely not program crashes. His/her work should be easily maintainable. If the system never had a problem for a couple of years, and is used daily/at least in a cycle – then one can begin to speak of the developer as a great developer.

Not someone who knows how to address the business sponsor(s), directors or bosses. Those would be team leaders/ project managers / spokes people.

Of course knowledge of a system(s) is important. A developer must have foresight about future enhancements and build his/her masterpiece with that in mind.

Being a programmer/developer/coder myself, i know that it is not as easy as that. Many systems are being developed because it is needed yesterday. Also, often one inherits the system and has to patch things. These days many companies make use of contractors to help out – who don’t know anything about the systems and are too happy that they found a place where to “stick in the fix” – Making it very difficult to write good systems.

However, a great developer keeps in mind that somebody else may need to work/maintain that system once s/he’s moved on.

Ability to write maintanable code

In reply to Great developer

As a contractor I fully understand what you are saying about contractors involvement. In my opinion a contractor has two options patch the system without deviating from existing architecture/design framework or patch it by deviating from the design. If one takes the second approach then it becomes a maintenance nightmare. But if a developer takes (or attempts) the first approach then he already has one quality of being a great developer.

I’d argue that writing maintainable code is part of being

In reply to Great developer

a good developer. As far as I’m concerned if you don’t do that, you are a crap developer.

How maintainable it is depends on a number of circumstances. Including of course your definition of mainatainablity.

You could be one of those comment every line types!

As a contractor I’ve made some extremely horrible bodges to existing code. The existing code was crap, bodge was the only option allowed. I didn’t keep the fact that I had bodged it a secret, though.

So communication skills aren’t essential?

In reply to Great developer

[i]Not someone who knows how to address the business sponsor(s), directors or bosses. Those would be team leaders/ project managers / spokes people.[/i]

So how do you explain to your “team leaders/ project managers / spokes people” the impact on the development process by time limitations and project complexity? Are they supposed to know without your imput? And how do you explain that you can’t give the client Output A from database B without access to specifically excluded data x, y, and z?

That could be ….

In reply to So communication skills aren’t essential?

Problem #1 in many fields today. Too many of us, and / or our peers, lack or need to work on our communtions skills.
(Yup, me too.) Not an easy thing to do either. Aside from the obvious, German-English, there is also Techi-speek to Normal People. :0 -d

Communication skills are very essential…

In reply to So communication skills aren’t essential?

and i never said that it is not. I mentioned it in the beginning of my post.

What I tried to explain with this (maybe i also lack proper comm skills), was that pure development skills make one a great developer.

Ability to communicate properly definitely assist in good understanding by all parties, but it does not write programs/systems.

I understand your point, to an extent

In reply to Communication skills are very essential…

I think (hope?) what you meant to say was that great development skills make one a great programmer. But I think the lack of communication skills can prevent one from becoming a great developer.

I once watched a project (from the office next door) where a Pascal developer with minimal communications skills ran into a customer rep with the same problem. Since neither was able to make the other understand what was being said, the end result was high levels of frustration on both sides. Although the code was great and did everything the customer asked (and more), the UI rivaled a CLI in complexity, making it essentially unusable by the majority of the people it was intended for. The program was well-documented, but the documents were written for another developer. After several months of trying to build a UI that would make the customer happy, the developer quit in frustration. And I got to rewrite his docs to make them more easy to understand (“You know computers…”).

How to know What to write?

In reply to Communication skills are very essential…

Part of being a developer, however, is determining what code needs to be written or changed. This requires communication with an ever widening group of people as the developer advances.

For a brand new developer, I expect that the supervisor will have to provide a very detailed description of what needs to be done. As the developer advances, he should need less hand holding and at least be able to ask the supervisor for for more detail. The next level has the supervisor stepping out of the middle and has the developer going directly to the users or testers or whomever has an issue.

I don’t believe any sort of advanced developer can expect to work in isolation and not rely on strong communications skills.

Mental health is also important. Yes I know it sounds…

In reply to Communication skills are very essential…

strange however I really believe this. You would be surprised how a narcissistic team leader can damage the team spirit as well as poisoned communication with innapropriate interventions. I’m also refering to what is called “instrospective” intelligence. This is the ability for a person to recognized his own motivation and be consious of his bias (short definition).
An example of the impact of this is when a developper is not conscious of his fear of damaging his image as a great developper. The case were the estimation of a developper are challenged (“…is it really that difficult to implement this feature…”) is a good example of this.
The concept of “GroupThink” synthesizes an interesting phenomena that shows how sociological as well as psychological factors can damage the development process.
Good developers should be aware of those factors
JS

It’s The singer, not the song

In reply to To me a great developer

To me, in my role of project manager/tester, I look for a developer who thinks as as the end user and preempts their movements….. an intuitive end product that enhances the usability. When I check a stage of a project I can invariably ‘break it’ by acting as a dumb user!!
Neat, commented code with error handling complete the picture.

Get him Wayne

In reply to It’s The singer, not the song

he said comments.

Ah never mind been there done that. 😀

Software that preempts user actions

In reply to It’s The singer, not the song

Hey Kevin,

I’m sorry, I am sure that this was a typo, but the phrase really struck me as funny.

“I look for a developer who thinks as as the end user and preempts their movements…”

I think I’ve used that software. I remember trying to do something simple and being stopped at every turn.

From what viewpoint?

In reply to Great developers vs Not so great developers

From a business viewpoint, add being a team player to Tony’s description.

From the team’s viewpoint, you still need the team player requirement.
They also need to be able to write code to the standard set for the project.
they have to be able to comment their code effectively.
they have to be able to debug code.
They have to be willing to help the rest of the team when any member hits a blockage.

a Great Developer is more than just someone that can produce code. They have to be able to enable the rest of the team as well.

Greatness defined

In reply to From what viewpoint?

Wouldn’t the word “great” necessitate the inclusion of all viewpoints? For example: After a QA person identifies a bug, what is the attitude and approach of the developer could be considered in determining if the developer is “great” or “not so great”. Shouldn’t we include viewpoints from all?

That to me is why the emphasis of ‘great’

In reply to Greatness defined

is on the soft skills. To apply your technical skill (however strong or weak) you must communicate succesfully with the business, QA, users, peers and their dog.

Otherwise you greatness will never be apparent and therefore is non-existant.

and why

In reply to That to me is why the emphasis of ‘great’

I had team player as part of both mentioned viewpoints.

A major part of any team effort is communication. Without it all you have is a collection of individuals doing their own things.

in my view

In reply to Greatness defined

Q&A are a part of the development team.
without their input those doing the code part can’t find every problem, so they can’t fix them.
I wasn’t trying to limit the viewpoints to be concidered, just listed two and gave what these two can [ not do or will ] concider important in a great developer.

My two cents

In reply to Great developers vs Not so great developers

I like to think that a great developer is one who pushes boundries (yet recognises that you can’t always do this). Too many developers i see go in and get the job done, with no flair. Not saying you have to be creative to be great, but there’s a certain element in it.

They don’t research more effective ways, or new and emerging ways. They just do the work “how they always have”.

I’ll use my better half as an example. He is incredibly good at what he does, yet alwys tries to do better and does things with “coding” that most don’t. The rest of the developers around him go and do what they have to, still using what they learned 10 years ago, while he innovates and is continuously learning more.

Every week he brings home something new, 4 weeks ago he started using AJAX, now this weke he’s into JASON.. but, he’s using what he’s learning to enhance the product and make better ways to do things.

I think its all about the drive to improve:
oneself & the project

Attitude

In reply to My two cents

To summarize, you view attitude to be an important quality of a great developer. Being proactive stems from the attitude.

to summarize

In reply to Attitude

*sigh*
a lot of people say that to me, I’m starting to take it personally 🙂

But yes, thats it i guess!

:-(

In reply to to summarize

Oh my…. I was just trying to squeeze out the gist 🙂 . Some examples:

http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=210691&messageID=2167611
http://techrepublic.com.com/5208-6230-0.html?forumID=102&threadID=210691&messageID=2167428

tis ok :)

In reply to :-(

I know what ye were up to 🙂

(and i know i can be a bit wordy!)

A Great Developer is not a Great Developer

In reply to Great developers vs Not so great developers

I have found a simple, non-technical evaluation that almost always works. Anyone who thinks he is a great developer is usually not, and anyone who does not think he is a great developer has a good chance of becoming one.

To become a great developer: always be willing to learn something new, always be willing to listen and learn from others, always be willing to admit someone else may know a better way. As soon as someone believes himself a great developer, he loses his ability to learn from others (the “lesser” developers).

To be a great developer, continue to learn every day.

A Great Developer is not a Great Developer

In reply to A Great Developer is not a Great Developer

well said…

Self-awareness

In reply to A Great Developer is not a Great Developer

Humility or arrogance apart, if a developer realizes the qualities that make a great developer and if possesses them, then why can not the person consider her/himself to be a great developer?

Because there’s always someone greater.

In reply to Self-awareness

When you make a stupid mistake, people will judge you on the basis of your self proclaimed greatness.

If your colleagues or your customers say you are a greate developer, then for them at least, you are.

Every one drop’s the ball every now and then, so painting a big target on your back just makes sure the knife goes in the right place.

It is one thing…

In reply to Because there’s always someone greater.

…to consider yourself a great / good developer and another thing to tout and strut around.

Excactly operate on the basis that you

In reply to It is one thing…

are. Maybe it will come true.

It’s the word great that’s a problem, implies that you can’t get any better.

Ultra developer, a new goal ?

So part of being a great developer is the desire to get better, the ability to do so and the confidence that you can.

A great developer always feels they can improve on what they just did, but makes sure there’s a finished product before they work on Mark II.

Great vs. ultra

In reply to Excactly operate on the basis that you

[i]It’s the word great that’s a problem, implies that you can’t get any better.[/i]

“Perfect” implies that you can’t get any better. “Great” only implies perfection for those unable to look beyond their small little worlds…

(I know that’s not you, Tony! 😉 )

Because Software Development is a Generalist Activity

In reply to Self-awareness

The problem with evaluating a developer is that software development as a whole contains a vast array of possible skills and knowledge and this array is constantly changing. It is simply impossible for one person to be great in every category.

The result is that one cannot create a top to bottom list of developers. Some will be stronger in some categories and weaker in others. To declare one’s self “great”, one must discount his areas of weakness. No one will be above average in everything about development.

To me, the great developer is one who considers himself average. One who knows he has good points and bad points and knows others have good points and bad points as well. The average programmer can give advice and take advice. The average programmer is willing to take on something new and not have to be the best at it.

My 2 Cents

In reply to Great developers vs Not so great developers

Here the the traits I look for, not in any particular order:

– Desire to continuously learn and improve their skills

– Understands the technology they are dealing with in a sufficient level of depth (normally, I’d say deep level of understanding, but there are times/situations where you have to learn “just enough” to do a job quickly and effectively).

– Understands the business domain that they are working in. You don’t have to be an expert, but you do have to understand the language of the business that you are developing the system for.

– Good “soft” skills. You need to be able to work good with other developers, customers, testers, vendors, etc.

– Do not consider their coding style to be “their own”, but rather a best of breed where they’ve taken techniques learned from others and integrated it into their style.

– Understand aspects of the development process that many seem to skimp on like: security, risk assessment, exception handling, documentation (as appropriate), etc. It’s not just about pumping out lines of code!

– Write code that is understandable, debuggable, supportable, etc. If you look at your own code a week/month/year later and don’t know what it was doing, you aren’t a great developer!

– Understand the trade-off between speed and quality of product. Know when to raise their hand and point out that a “required” delivery schedule is not attainable.

I’m probably already repeating what others said, so I will stop.

Good Summary

In reply to My 2 Cents

DPitz has a great summary of many of the items that contribute to earning the title “Great Developer” – one attribute that I didn’t see anywhere in this thread though was leadership. 1, you don’t need a title to be a leader. 2, even just being a great follower makes you a leader (example) to those below you.
Pride in your work, professionalism, soft skills, technical skills, all the things that have been previously mentioned are indicators that someone is or can be a great developer. To me though, its kind of like trying to rate a person on a scale of 1 through 10, without ever really being able to determine everything that a 10 includes. Sometimes a developer has to be a better project manager because the “project manager” with the title isn’t that good. Sometimes a developer has to be a better head-down codemonkey because he is the only developer. Sometimes a a developer has to be a leader, because no one else is stepping up and taking responsibility. Knowing when to be “a better something” when appropriate, and having the confidence to do so is what I think makes a great developer.

Another view.

In reply to Great developers vs Not so great developers

I think a great developer comes from the sum of the person and not just an analysis of skills. I also think a great developer only exists where there is an environment for he/she to exist and be supported as such.

Other things to look for in an individual:
* Passion. Some of the best developers I work with are musicians. Passion for something spills into their work.

* Eagerness. Eager to learn new technologies, new frameworks or just plain eagerness to prove ‘it can be done’.

* Attitude. No “I” in team kind of attitude.

* Gracious. Part of interpersonal skills and interpersonal communication.

* Effective communicator. I’ve seen a lot of comments here and one I appreciate most is someone who has the balls enough to tell a VP or President that they are wrong about some assumptions they are making about a project, technology, time lines, etc. without sounding argumentitive (basically best case scenario). This is quickly followed by being able to suggest alternatives and effectively sell them.

* Training. Taking training is one thing but if you’re forced to train others you gain better communication skills on how best to relay technical problems to non-technical people.

* Discipline. The best developers are the ones that also stop working when they are tired or finished an achievement in their work usually after hours. The best developers I’ve worked with ask to work outside the bounds of a normal schedule or just in the office because they can be too accessible and too distracted by daily life in the cubicle. Discipline also means not taking advantage of flexibility and still getting the job done.

* Getting the job done. A great developer will get the job done and make the superior look good while not being offended that he/she doesn’t always get credit.

Basically a great developer is truly the humble underdog.

I must be a 9 then

In reply to Another view.

Humble I am not.

I don’t have any superiors.

And I always back myself to get the job done, better than anyone else can.

😀

I do have enough humility not to describe myself as great though, that would be far too egotistical.

I must be a 3 then..

In reply to I must be a 9 then

cause I would add a random function to the project, to randomly change the splash screen to say that [ name of Department head that doesn’t give credit to team members ] just sits on his a$$ and brown-noses, he/she couldn’t do any real work if their life depended on it.

then when the clients get the product and the person they were told is responsible’s name appears on the splash, they know that the CTI / CIO is a useless t!t and not to do business with any company employing the twit.

after all, ALL GOOD MANAGERS will always make sure credit is shared.
If the Manager won’t share credit, fire their a$$ and get someone that is a team player in.

And there’s me thinking

In reply to I must be a 3 then..

you were humble.

ROTFLMAO

Humble is correct spelling for welcome when it’s on a mat.

yeah, right….

In reply to And there’s me thinking

me? humble?
I’m about as arrogant as you can get when I get stuck with pr!cks for supervisors. 😀
[ or even have to deal with a pr!ck at any time ]

I’m to confident in myself to be humble.

Discipline

In reply to Another view.

I was looking for that word from somebody :-), but in a different context. Discipline is paramount when it comes to sticking to conventions and good habits. For example: I get mad when I see developers checking in their code into VSS (or other source control system) with bad habits:
1) No comments
2) Checking in code without verifying that it builds without compiler errors
3) Being careless enough to overwrite another developer’s code.

what traits distinguishes great developers from the not so great developers

In reply to Great developers vs Not so great developers

A great developer understands the concepts of the work and the logic involved to complete the code.

A not so great developer understands the concepts of how to use Google to cut and paste all of their work from other peoples’ source code.

A great developer can relate complex concepts to non-technical individuals in a plethora of means.

A not so great developer can relate concepts to someone by giving them a URL.

A great developer can take an almost-impossible project and make it happen within reasonable bounds.

A not so great developer can take an almost-impossible project and make it impossible.

BTW…in the modern workforce, I’ve found that “developer” is now the professionally-correct term for “underpaid software engineer”.

When I want to big myself up with HR

In reply to what traits distinguishes great developers from the not so great developers

I call myself a software engineer, sounds better than a ‘mere’ developer.

It was my official job title at one place, I was still underpaid though. 😀

Silence ?

In reply to Great developers vs Not so great developers

What do you think about people, who can be the nicest people on the planet, but during meetings maintain lots of silence? They do not ask for more information nor give out more information. All good news or bad news get conveyed to the team almost at the 11th hour.

Hmm I know some good ones

In reply to Silence ?

who don’t speak up at meetings with business types, but don’t keep things from me.

It’s going to be hard to get on, if you go that path, though.

I know some who have got a lot to say all the time and none of it worth hearing.

You know the guys who are clever enough to invent their own scripting languages and too stupid to recognise they are re-inventing a wheel.

I’ve met very few who just hide in a corner though, they don’t last long enough to learn their names.

True.

In reply to Hmm I know some good ones

Yes…the opposite is true too.

[i]I know some who have got a lot to say all the time and none of it worth hearing. [/i]

Great developers

In reply to Great developers vs Not so great developers

Just as a matter of curiosity, whose criteria are we using to determine a “great” developer? As a [former] database designer who was privileged to see (and use!) my work in action, I learned quickly what might be the most important attribute (to the end user) of a great developer.

It’s the ability to design a consistent user interface, with all of the following provided for the user:
1. concise, helpful feedback on errors: “The part number field cannot be blank.”
2. clear instructions where required: “Passwords must be at least 8 characters long and must contain at least one each of the following…”
3. non-standard data formats specified in titles: “Date of Birth in YYYY/MM/DD format”

Nothing fries the end user more than receiving the lazy programmer’s error message of “Invalid entry” when no instructions or clues to what format the data should actually take were provided.

Edit: clarify

Not just users

In reply to Great developers

You get a bug report with that in it, especially when they can’t remember what sequence of actions generated it and you can look like a right wally trying to find it, never mind fix it.

Firing squad offence in my book, that one.

My other favourite is

Try
{

….
}
Catch
{}

Where’s my gun?

no gun Tony

In reply to Not just users

use a rusty spoon, it will hurt them more ]:)

The worst I actually saw for bad error messages:
[b]
Installation failed
Error code 10
[/b]

Took three weeks to get borland to tell me error code 10 is a generic error code that means absolutely nothing.

Found out the cause of the error though, REGIONAL settings.
You can’t install Kylix 3 download edition
[ the free version ] in any region but the USA. the language for your system MUST be US English, with US measurements for it to install.

since most linux distros moved from the 2.4 kernel, you can’t install Kylix at all. it requires the specific toolchain for the 2.4 kernel.
[ another bloody stupid decision they made ]

They are always the best ones

In reply to no gun Tony

They tell you nothing, you google them, and you find a load of conflicting whys and some solutions that make no sense at all.

What if I use dum-dums, sort of appropriate in the circumstances.

As soon as Borland let people like Anders Helsberg go without replacing them they started writing their own epitaphs.

The only thing you get from sitting on your laurels in our industry is a green ring on your arse.

It is sad though. I really miss the old Borland/Microsoft…

In reply to They are always the best ones

competition. Of course if you use C# you have Anders Helsberg on your team which is a consolation I suppose. I miss the Borland C++ 3.1 giant boxset of manuals that you could read on the bus (without carrying a portable). The diversity of good commercial tools was getting really good and then M$ killed all of that.
The good side to this I think is that the open source community is filling up the void and this is good.
JS
P.S.: I agree about the rusted spoon. 😉

aww

In reply to It is sad though. I really miss the old Borland/Microsoft…

I had the giant box set for C++ Builder 1. I think I still might have some of them kicking around.

I know somone who has a copy of BDase IV, still in it’s shrinkwrap. same size box as the old Borland Builder products.

no dum-dums

In reply to They are always the best ones

the rusty spoon inflicts more pain on them, and give you greater stress releif.

you know, the screams of agony as you slowly carve their bodies to bits with the spoon will wash away so much stress its worth the extra effort.

Off the topic??

In reply to Great developers

A great developer will incorporate all of a company’s business rules in code. For the developer to do this, he must understand the business or should have a go-between (such as a system owner, someone with the relevant business experience) to help convert the written business rule to code.

With this in mind, the situation often arises where the developer is NOT the single-point-of-responsibility for the development. Here, the developer is a team. A team of more than one person, where the process of coding business rules is well-thought-out from the user and system owner, to the coding.

This environment works well for us where the developer is constantly receiving feedback from iterations, with a system owner ensuring that the coder gets the right message and codes the business rules with an agreed-to outcome.

Yeah that’s off topic

In reply to Off the topic??

that’s a great coder, a person who is next to useless with out a great analyst, and on anything non trivial a great designer.

One of the things that was said several times is a developer must be able to communicate, communicating with their team will have some obvious advantages.

Who said single point of contact anyway?

Putting on the Ritz or roping cattle

In reply to Great developers vs Not so great developers

It seems like there is a lack of strong agreement on what a developer is. I like to look at it from the one hat, one job perspective; and that some people wear many hats. In a small shop, one person could wear all the hats; in large corporations there could be numerous people wearing the same hat. So to me the definition of a great developer comes down to do they wear the hats they have well, and do they communicate well with the people who wear the other hats. As an example, if your a one person operation and you find yourself with project that requires a hat that you lack the ability to wear, you could choose to put the hat on and get through or you may choose to put on your collaboration hat and work with someone that wears that other hat well. A good developer may get by with wearing the hat and may even become better because of wearing the hat more; but I think that the great developer collaborates and may also become better by working with someone who wears the hat well.

[Author]

Replies