Good Developer vs Bad Developer

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