Good Developer vs Bad Developer

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

[tbscope]

Just one more:

A brilliant developer knows how to make QObject subclasses available in scripts as both a return type and as an object.

var myObject = new MyObject;
myObject = someOtherObject.getMyObject();

var myObject = new MyObject;
myObject = someOtherObject.getMyObject();

To copy to clipboard, switch view to plain text mode 

Ohh dear, is this difficult :-(