Good Developer vs Bad Developer

[wysota]

Hi all,

I'd like to start a new discussion here. I was wondering what makes a developer "good" or "bad". I have my own opinion on the subject but I'd also like to know what others think. If you had to say what makes a difference between a good and a bad developer, what would it be?

[tbscope]

Characteristics of a good developer:
- Understands the basic concepts
- Knows where to find information
- Plans or studies most of the tasks beforehand (I consider writing simple sketches with pencil and paper the same)
- Takes the time to write a proof of concept or a test (to research a certain technique or api or ...)
- Knows that there is a user for his or her program and takes this notion into consideration when designing the program.
- Doesn't really care about IDE or language, he or she understands the basic concepts.
- Documents the code
- Takes care to handle bugs and suggestions correctly
- ...

Bad developer:
- Knows a thing or two, creates a nice user interface and then make your computer crash beyond repair.
- Is a script kiddy (copy and paste off the internet)
- Can not find information himself or herself
- Thinks an IDE with thousands of features makes him or her a better programmer.
- Can't understand basic concepts.
- Does not take the time to write concepts or test code.
- Does not plan
- Thinks that the way he or she works needs to be reflected onto the user of the program (usability)
- Does not write documentation
- Does not reread and improve
- Handles bugs and suggestions incorrectly
- ...

[Zlatomir]

I think i will learn some things in this topic so thanks... and i will try to contribute to what i learned so far.

Now, my opinion (NULL experience, so the opinion is for entry-level developer), a good developer (or just good, and developer sometime in the future) should know:
- the basic concepts of the programming paradigms (including generic programming)
In C++ if a developer will understand templates, he will better understand the generic containers and the generic algorithms and the requirements that the algorithms have about the containers or data in containers.

- to "express" the paradigms into a programming language (best for learning is C++ <just my opinion>)

- basic of STL (or another "standard" library, if he knows another language) the understanding of STL (in C++ case) helps on understanding any other library's containers and algorithm (like the Qt one);
Only "disadvantage" that i had is the confusion i kept doing about QList (that does have operator [] and its not a linked-list)

- and must be able to admit when he makes a mistake

And for a senior developer i think it is absolutely necessary to know to design multi-threaded and networking software.

Looking forward to see your opinions

[tsp]

My 2 euro cents

Both are able to implement the given task but the difference is that good developer implements given task in a much simpler way than bad developer!

Because the code developed by good one is simpler it also means that the maintainability and readability of the code is much easier i.e. those that count in a long run.

Keep it simple ....

[dpatel]

In my opinion,

A good developer will never jump into implementation until he has complete design of the application, where as a bad developer will open the IDE first.

[Ginsengelf]

Hi, a good developer should know which language is best for which task. Things one can do in a 3-line bash script can be a pain in C.

Ginsengelf

[squidge]

As an addition to tbscope's post, I think "Uses the correct tool for the job" is an important point.

Bad developers also tend to copy code of a webpage, paste it into Qt Creator, and then post on this forum when it doesn't compile and say "Why this error, what do I need to change"

[ivan.cukic]

Bad developers can only use higher level libraries, while good developers can write those.

[Lykurg]

An important point for a good developer is that you can think forward. He doesn't develop a solution just for the current requirements. He also spend some time (of course no 5 day of research for a simple case) to find the best way to ensure that the application will runs as long as possible without being optimized.

As a stupid example what I mean: You have 3 strings which are sorted and you have to find the index of a certain string. So you can simply loop through the list and this solution will - in this particular case - be as good as any other algorithm. But a good developer will use a proper search algorithm which is fast for a size of 3, but also fast for a size of 3000 items.

You never know, how the requirements will change, but wherever it is possible you have it in mind and choose a good solution for as much as possible situations.

[wysota]

Here are my thoughts...

When developing software we all use certain tools. Tools such as programming languages, compilers, text editors, frameworks, preprocessors, libraries, backends and possibly many different kinds of things that can be called "tools" that I'm not aware of. The computer itself is also a tool.

Now, in my opinion, the difference between a good and a bad developer is related to using the tools. But it is not, as you may have thought, that a good developer is able to use the tools and a bad one is not or that a good developer is able to find a proper tool for the job. For me the difference is that the tool is merely a commodity for a good developer and a necessity for a bad one.

If you are a good programmer/developer, you understand what a tool does and have at least some insight on how it does it, and if you had to, you could live without the tool - it would just take you longer to reach your goal. A bad developer needs the tool because (whatever the reason) he wouldn't be able to do the same task without it.

Consider a couple of examples:
- Qt Creator - a good developer likes Qt Creator because it makes it easy to traverse code, is handy when it comes to using documentation and is a time saver in a myriad of cases (i.e. commiting code to a remote repository); but at the same time he understands the compilation process, knows what qmake does (not how it does it) and is able to read and understand compiler output; a bad developer is merely able to push the compilation button and cross his fingers that it works.

- programming language - a good developer may not know a particular programming language but he knows the principles; if you switch from a language with garbage collector to a language without it you will be aware that memory is no longer managed for you and will search for how to manage memory in this particular language; a bad developer will simply not think about this at all because the language has always cared about it for him.

- computer - a good developer will be able to "create" an application even without a computer, simply by conceiving the algorithm on a piece of paper.

and something popular these days.....
- network programming - a bad developer will always do network programming in multiple threads not because it is the proper way to do it but rather because he doesn't know it can be done differently; for me this is a classical example of "commodity vs necessity".

So the bottom line is - you may know how to use tools, you may be an expert in a particular programming language or environment, you may be creating proper creative and multithreaded applications, you may know whole Qt documentation by heart but this may not be enough to consider yourself a good developer. Would you be able to implement your application if someone took the C preprocessor out of your toolchain? "A C preprocessor? I don't need a C preprocessor, I'm programming in C++!", you say... well... keep dreaming

[high_flyer]

Hey witek, are you hiring new guys and need some help with choosing?

Well, agree only to some extent with some of the things your mentioned.
All of you went very in detail, and I don't think that either the good or the bad programmer can be sum up in a list of "features".
Most (not all) of the features you listed for one type, can be available at the other, with out changing him from good to bad or vice versa.

There is also a difference between a good developer for open source, or commercial software.
You can also be good at developed GUI applications, but not so good with scientific signal analysis.

But if you push me, then I'd go for much more general '"features" that will produce the specific features you listed, and more:
- Analytic thinking is in my opinion the most important ability any developer should have.
- Almost as important is to know which questions to ask (or what to look for)
- For developers who are paid for time, the ability to evaluate a time for a task (and meet it without compromising the quality of work) is very important.
- Good code hygienics - this means many things, and if you know what I am talking about you are probably not the worst developer
- Using encapsulation and reusable code (true for any language)
- Generating code that is as specific as needed and general as possible
- Good resource management.
... and so on.

Cheers.

[wysota]

Hey witek, are you hiring new guys and need some help with choosing?

I do need help with choosing but this is not what it's thread is about

[squidge]

If any of you do commercial software engineering, I would be interested to know the ratio of documentation to source code, time wise.

For example, for a project earlier this year for a part of a simple consumer audio entertainment device, we did 3 weeks of code and 20 weeks of documentation. An additional 8 weeks was testing, as we had to prove it under various conditions (99% of which it would never experience) and of course document each test along with the proof that it did pass. I'm not talking about hardware here, just a pure software solution.

[wysota]

If any of you do commercial software engineering, I would be interested to know the ratio of documentation to source code, time wise.

At the company I cooperate with I'm practically the only one that does some kind of "good-enough" development documentation but nobody ever reads it anyway. I'm afraid this is similar for most small/medium sized software development companies. There is constant pressure on new features and no pressure for improving the skills of developers.

We do generate a lot of business-related documentation though. But it's really worthless for a developer. This sucks as after a while nobody knows how things work and why they were done that way. Of course comments in code are also very sparse.

[Timoteo]

The things that most influence my opinion of someone else in a programming environment are a) ability to research and b) willingness to research.

Nothing turns me off quicker than being asked a question about something that is detailed in documentation. The converse is also true - I love a great question. Even greater is the question that I cannot answer (because I love to research).

Also, being able to abstract a specific solution into something that can be applied to a broader range of problems is a huge plus.

So I suppose what I am touching on here is a fundamental cognitive trait that is part of the distinction between "bad programmer" and "good programmer". Myself, I want to be an "awesome programmer" but I am not there yet (and even "good" is debatable).

[ComaWhite]

I don't mind documenting code, but half the time I just forget to document.

[squidge]

Then you get your hands slapped

Document what your code is supposed to do first, code after, then validate.

[genjix]

A good developer has intimacy with the computer ecosystem. They implicitly feel which tools are needed to fill the void. They have a harmony with their code and fit well into their community, cooperating with others. A good developer is a hacker and cautious planner at the same time, with well rounded senses and experience.

[high_flyer]

A good developer has intimacy with the computer ecosystem. They implicitly feel which tools are needed to fill the void. They have a harmony with their code and fit well into their community, cooperating with others.

Sounds like Zen!

Nothing turns me off quicker than being asked a question about something that is detailed in documentation.

If I had a cent for each such question on this forum...

[franz]

There's a lot you can use for qualifying the quality of a developer and everything has to be seen in perspective. As for the tools and stripping the C preprocessor from a c language: Could you do still be reasonably good at your work without the compiler, the assembler? Some tools are essentials.

A good developer knows what tools make him work more efficiently and will probably work very hard in order to have to work less (the good kind of lazy). Cares about his work and the thriving of his work (and keeps it thriving by whatever means possible. Auto-tests, code reviews, refactoring etc.).

A bad developer doesn't really care. He just codes and hopes it works.

A good developer will never jump into implementation until he has complete design of the application, where as a bad developer will open the IDE first.

I don't think anyone has ever had a complete design of the application. Software is an organic thing. Not something you design, build and never touch again. Sometimes you have to start coding to get a feel for the right solution (prototyping, tracer-bullet programming and other buzz-words).