Printable View
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?
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
- ...
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 ;)
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 ....
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.
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
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" ;)
Bad developers can only use higher level libraries, while good developers can write those.
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.
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 :)
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.
I do need help with choosing but this is not what it's thread is about :)Quote:
Originally Posted by high_flyer
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.
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.Quote:
Originally Posted by squidge
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.
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).
I don't mind documenting code, but half the time I just forget to document.
Then you get your hands slapped ;)
Document what your code is supposed to do first, code after, then validate.
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.
Sounds like Zen! ;)Quote:
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.
If I had a cent for each such question on this forum...:rolleyes:Quote:
Nothing turns me off quicker than being asked a question about something that is detailed in documentation.
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.
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).Quote:
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.
Just one more:
A brilliant developer knows how to make QObject subclasses available in scripts as both a return type and as an object.
Code:
Ohh dear, is this difficult :-(
So true. Infact one could say that only a good developer can react to those changes. In all of non-trivial software you are going to experience feedback from multiple sources, so your design and/or implementation will indeed change. A good programmer understands that no implementation is ever complete. A good programmer is never surprised. (Ok, I lie, but a good programmer is infinitely less prone to being surprised). A good programmer does not hold any given implementation sacred.Quote:
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).
That's it for now.:D
Wanted to rant and figured this thread the most appropriate for it.
Does it seem to anyone else that Qt and how easy it appears to be (and indeed it is - you can have a trivial program with a UI up in moments with Creator) is drawing in the same crowd that suddenly appeared on the scene with the advent of Visual Basic? Anyone smell what I'm cooking? I understand that Qt and Creator have the goals of lowering the bar for entry into the design and implementation world, but good lord.
I'm not saying that all Visual Basic programmers are poor either. I've seen some rather impressive things done with it (it can call c and asm libs which totally unleashes the speed the applications are capable of). Hell, my first language was BASIC (which eventually lead me into assembly thanks to PEEK and POKE).
Hmm. Am I trying to say that RAD prior to education on programming is extremely detrimental? Maybe. What do you guys think?
I'd have to agree with you, people are downloading QtCreator and expecting to have an application up and running without first understanding how to program in C++. There seems a lot of "I don't want/don't have time to learn, just give me example code and I'll copy and paste". When it then doesn't work because they changed something major, they just post the outcome of the compiler and say something along the lines of "It doesn't work, fix it for me."
I don't know where the crowds come from. Obviously the general idea is that Qt is easy. Well, it is easy, but it is no walk in the park (it is compared to MFC development though). Anyone not willing to invest the time in learning C++ (or Python or any other language with Qt bindings) will come out disappointed. Shame really.Quote:
Originally Posted by Timoteo
I see that all too well especially on Qt on freenode. It's so common it ain't even funny.Quote:
Originally Posted by franz
I don't think that is any of creator goals.Quote:
I understand that Qt and Creator have the goals of lowering the bar for entry into the design and implementation world, but good lord.
Its goal (IMHO) is to make coding easy and sensible for coders.
Yes guys, but that is not the fault of QtCreator.Quote:
I'd have to agree with you, people are downloading QtCreator and expecting to have an application up and running without first understanding how to program in C++.
Its the fault of the people who are not willing to learn C++.
These people were always there, and will always be there, nothing anyone can do about it.
Just because there are such people doesn't mean creator/designer should not be easy and make development a joy.
To me the reason of this is simple and it can be described by four letters - LGPL. Back "in the old days" your Qt application had to be either Open Source or you had to pay for a commercial licence. Now you can write a closed source app without paying which causes all those would-be programmers that stopped their self development at the level of writing scripts in Visual Basic to leverage the opportunity to earn some money writing commercial software and hoping that a good development environment (tools + frameworks) will make up for their lack of skills. The sad truth is that it won't. Qt is easy provided that you know C++ well. Many people tend to forget that.
Maybe we should restrict the 'script kiddies' to using PyQt. Python is a very good scripting language and for a would-be programmer easier to learn and use than C++. And the binding with Qt is very good. (Used it 5 years ago on a Linux system, guess it only got better by now, and guess Windows works also fine.)
Then we just have to give them 1 installer that puts Python+Qt+PyQt on their system in 1 step so we get no questions about that.
And then we need a script-kiddy detector in the forum :)
Best regards,
Marc
First of all we have no way of enforcing such a restriction. Second of all people not willing to learn C++ will not be willing to learn Python. According to me the path is education, not restriction. We've been discussing some ideas during Developer Days, we'll see if we can make anything happen. But this requires time.Quote:
Originally Posted by marcvanriet
nice thread
my simple thought:
I think that good developer will tend to reuse the code, when a bad one will just try to rewrite things from scratch. Bad developers likes to write their own code, and good devs know that sometimes it's even more important to read someone else's code and try to improve and reuse it. Bad developers thinks that code written from scratch will always be better than old one.
Good dev: "This function/class/system is a mess. Let's try to do some refactoring."
Bad dev: "This function/class/system is a mess. I will write my own."
Of course there can be situations when only thing left to do is to rewrite, but I think you know what I'm talking about.