What makes a good developer?
-
Your point about intelligence is correct, but do you mean a 'programming language' when you refer to 'mastering language(s)'?
It's obvious that a programmer must master a language to be able to perform his job, just like a carpenter needs to be able to use a hammer.
But I don't believe that the difference between a good and an excellent carpenter is the way he holds his hammer.
It's the way in which he sees solutions to problems he comes across, the way in which he interacts with his customer's to translate their desires into a piece of furniture, ...
On the other hand, the difference between a good and a bad carpenter probably is the way in which he holds a hammer.
It's the same with a programmer. He doesn't have to excell in a language to write good programs. He has to know the language of course.
-
Hi NPeeters,
quote:
But I don't believe that the difference between a good and an excellent carpenter is the way he holds his hammer.sorry, I have to disagree on that. I think that is exactly what makes the differences between a smart and a not so smart carpenter. One other aspect is that he chooses the appropriate hammer for his work. And if this hammer is yellow, black or blue doesn't really matter at all.
Translated to programming is means you must first decide what language to use and then how to use this efficiently. Maybe not the best example is, when you are about to write an database app with a GUI. Although I like Visual C++, I would never choose this for my app. It's really cumbersome compared to say VB.
quote:
It's the same with a programmer. He doesn't have to excell in a language to write good programs. He has to know the language of course.but it would certainly help. One classical example for this are pointers in C. You can really easily use them,
... and you can spent hours or days trying to figure out, why your programm compiles but doesn't work like you want.
I think it is a dfference between working and good programs. If a program works in the way it is supposed to, the programmer has hit its target and his job is done effective. That doesn't imply that the programmer has chosen the efficient way to code his programm. Now this becomes sophisticated, and I would feel more comfortable to argue in german, but I hope things become clear enough!
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Frank,
Never thought about it that way...
One question though ...
What is the best program :
1. a perfectly written program, written with the best design methodology, with optimal performance, making use of the best technology for the job, taking into account all the pitfalls of the language, having a high degree of readibility and maintainability that does not do what the customer wants
2. a program where the design methodology is not enforced to the highest degree, that is written in a language that is not optimal for the purpose, and so one, but that does what the customer wants
In my opinion it is app 2.
There probably is a third kind of program, that also does what the customer wants, but keeps on crashing, has 'spaghetti code', cannot be maintained or extended ...
That's the bad programmer.
For me, it is not important what language a program is written in... A good developer will be able to use ANY language to get a job done, without compromising the 'structure' of the program.
Of course, if he chooses the right tool, he will be able to complete it in less time with less debugging and testing, ...
To get back to your reasoning with the carpenter :
the kind of hammer he uses is the algorithm, the decomposition, the architecture, the design
the colour of the hammer, that's the programming language
Edited by - NPeeters on 06/16/2003 01:20:53 AM
-
Hi Noel,
quote:
What is the best program :1. a perfectly written program, written with the best design methodology, with optimal performance, making use of the best technology for the job, taking into account all the pitfalls of the language, having a high degree of readibility and maintainability that does not do what the customer wants
2. a program where the design methodology is not enforced to the highest degree, that is written in a language that is not optimal for the purpose, and so one, but that does what the customer wants
In my opinion it is app 2.
obviously here's a gap. In university they teach us in data structure courses that app1 is the one and only. In the real world I'd prefer app 2, because the customer only pays for a working solution, not necessarily the perfect solution.
quote:
For me, it is not important what language a program is written in... A good developer will be able to use ANY language to get a job done, without compromising the 'structure' of the program.Of course, if he chooses the right tool, he will be able to complete it in less time with less debugging and testing, ...
It is not important what language you choose, if you can to the job with it.
I've said before, programming 'happens' inside the brain. So far, so good..but what if you can't express yourself? Or dilettantish? For you listener that will be tough, for the compiler will through errors on errors.
quote:
To get back to your reasoning with the carpenter :the kind of hammer he uses is the algorithm, the decomposition, the architecture, the design
the colour of the hammer, that's the programming language
Yup!
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Seems like we're thinking the same thing...
quote:
In university they teach us in data structure courses that app1 is the one and only.I never gotten any grades for something that didn't work
-
quote:
I never gotten any grades for something that didn't workEven if you get a grade, you'll definitely get no money
.I remember having endless discussions on the use of Pascal as a teaching language. While I believe Pascal is not one of the most commonly used languages these days, it is a nearly perfect language to study data structures and fundamental algorithms.
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
quote:
quote:
For me, it is not important what language a program is written in... A good developer will be able to use ANY language to get a job done, without compromising the 'structure' of the program.Of course, if he chooses the right tool, he will be able to complete it in less time with less debugging and testing, ...
It is not important what language you choose, if you can to the job with it.
I've said before, programming 'happens' inside the brain. So far, so good..but what if you can't express yourself? Or dilettantish? For you listener that will be tough, for the compiler will through errors on errors.
I would be very carefull with this statement.
quote:
It is not important what language you choose, if you can to the job with it.The reason is you can write instant message services with VB (not speaking .NET here) and they work but put several users on it and it will be tedious to the point of usless to use. You have to pick the right tool for the job.
Even going back to your statement about you would prefer to use C++ but VB is so much simplier. Again due to threading limitations and ability to customize redraw a costantly refreshing GUI in VB will strobe and make the GUI useless. Along with the fact you may have data transfers, calculations, and other process you need the user to see as seamless as oppossed to slugish and not readable.
Keep in mind you can use a tack hammer to break up a concreate slab but a jack hammer (or even a sledge hammer) is far more suited to the job and much more practical in getting the job done.
Oh and with the App1 and App2 difference you have to be extremly carefull. On eof the biggest things I hate as a customer is to find need for bug fixes. If there is something left undone then not only does the customer find it aggravating running across issues they find it very unprofessional. The customer is not you quality assurance layer. Sure it doesn't have to have every wizbang feature you can think of for the future but the base product should be the most effective it can to hold your customers attention. Plus if you write an app that is not as optimal as possible and does not enforce a particular design methodology you set your downfall up immediately.
For example the nuts at Netscape decided the code wasn't up to par but instead of touching the areas they needed to they threw out all the old code and started from scratch. Sure this means a potentially better product but they spent so much time before a new version that MS gained the extreme upperhand. Even thou they really didn't need to do all they did the result of their choice to rebuild from the ground up cost them the market more than anything else. But if you right subpar code with the intent of getting to the customer with concenr for the futur then you are setting yourself up for another developer to swoop in and steal your customer while you are starting over. Always keep in mind, designing right the first time is a cost savings to yourself in the long run unless you solution is just temporary to begin with (then you write to accomplish for a limited period). If you constantly have to start over and rework areas you spend more man-hours in cleanup and cost yourself in other areas.
-
Hi Antares686,
quote:
I would be very carefull with this statement.Why?
quote:
Even going back to your statement about you would prefer to use C++ but VB is so much simplier. Again due to threading limitations and ability to customize redraw a costantly refreshing GUI in VB will strobe and make the GUI useless. Along with the fact you may have data transfers, calculations, and other process you need the user to see as seamless as oppossed to slugish and not readable.Sorry, this was unprecise. I meant writing GUI stuff in VB is easier and faster than C++.
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Hi again Antares686,
should have reading further before posting the first time.
quote:
Oh and with the App1 and App2 difference you have to be extremly carefull. On eof the biggest things I hate as a customer is to find need for bug fixes. If there is something left undone then not only does the customer find it aggravating running across issues they find it very unprofessional. The customer is not you quality assurance layer. Sure it doesn't have to have every wizbang feature you can think of for the future but the base product should be the most effective it can to hold your customers attention. Plus if you write an app that is not as optimal as possible and does not enforce a particular design methodology you set your downfall up immediately.that's not always the case. I have seen several occasion where you need to buy a software, simply because noone else is selling auch a product.
Example 1: Institutional Asset management software (Only a few around here around in Germany.
Example 2: Reporting software to our regulating authority.
In the first case you have a choice (only among which is less evil, in the second you have no choice. And that's really bad software!
quote:
For example the nuts at Netscape decided the code wasn't up to par but instead of touching the areas they needed to they threw out all the old code and started from scratch. Sure this means a potentially better product but they spent so much time before a new version that MS gained the extreme upperhand. Even thou they really didn't need to do all they did the result of their choice to rebuild from the ground up cost them the market more than anything else. But if you right subpar code with the intent of getting to the customer with concenr for the futur then you are setting yourself up for another developer to swoop in and steal your customer while you are starting over. Always keep in mind, designing right the first time is a cost savings to yourself in the long run unless you solution is just temporary to begin with (then you write to accomplish for a limited period). If you constantly have to start over and rework areas you spend more man-hours in cleanup and cost yourself in other areas.I thought, their mistake was to cry out, Hey, we have a majority stake in Internet browsing application
? but I agree on the rest. Thinking first seriously on design and THEN implement is better than vice versa.
But I guess, you know too, that you sometimes have to deliver 'banana software', which mature at the customer.
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Seems to be turning into an endless discussion here...
Does everyone more or less see a developper as being someone who :
1. Is able to translate requirements into a design.
2. Is able to translate a design in a technical solution (select the appropriate technology and techniques to use)
3. Is able to create well-structured program code that does what it needs to do
Antares,
you are certainly correct when you say it is important to start off with a good design, so the code remains flexible, mantainable and extensible.
I only tried to make a point that it is not because you can apply the perfect programming model, that the result is good too. There's a lot of other things to care about.
Obviously, if you do apply a good programming model, you don't run as much risk to end up with a bad piece of code.
-
Oh yes I do agree I just wanted to make sure your message didn't lead anyone down a bad assumption of what you meant.
As for Frank
quote:
Example 1: Institutional Asset management software (Only a few around here around in Germany.Example 2: Reporting software to our regulating authority.
The good thing here is it is the other guy it messed up. If you find serious lack of quality in an application field that means it is open for others like yourself to step in with a better offer to get at the customers. Then it is a matter of keeping them which opens the market for other possilibities and the future of a good product taking over when only a choice of the lesser evil is available.
-
quote:
The good thing here is it is the other guy it messed up. If you find serious lack of quality in an application field that means it is open for others like yourself to step in with a better offer to get at the customers. Then it is a matter of keeping them which opens the market for other possilibities and the future of a good product taking over when only a choice of the lesser evil is available.You mean like MS has done with Internet Explorer. Only that they forgot to make it a 'good' product
...PS: And no, this is not an attempt nor an invitation to start a discussion about the merits of Microsoft
-
quote:
quote:
The good thing here is it is the other guy it messed up. If you find serious lack of quality in an application field that means it is open for others like yourself to step in with a better offer to get at the customers. Then it is a matter of keeping them which opens the market for other possilibities and the future of a good product taking over when only a choice of the lesser evil is available.You mean like MS has done with Internet Explorer. Only that they forgot to make it a 'good' product
...PS: And no, this is not an attempt nor an invitation to start a discussion about the merits of Microsoft
Exactly, but Mozilla may be catching up. Check the latest incarnate out.
-
You guys discussed many of the criteria for developing good software, but did we satisfy the initial question? "What makes a good developer?"
Curiosity gets you into programming, but a good and open attitude is important for later on success. Listening and communicating technical choices to non-technical people and your own team is a very important skill.
You need more than logic or the often misunderstood concept called "intelligence".
Programmers are always learning, so we need to be managers of our time. We all have our own knowledge acquisition methods where we hord information, code, articles and hopefully can recall. A DB is about recall, not just storage!
I was glad to see Antares mention getting the job done (among his many other good points. We are paid to stick to our schedule commitments, while doing a good job. That means not wasting too much time researching the best possible methods.
How good do you need to be any single technical area? Depends on who or what resources are around to help you! Yes, you need technical skills in logic, language, knowledge of program design, life-cycle, user interface and task flow. It helps if you know how to document (grin). You need to know the software plan and schedule inside and out.
On the big projects (not 1-person jobs) you don't have to be the smartest. Yet, you are expected to be good, quick, and a helpful team player. There are plenty of roles and areas in which to excel --- find your most helpful as well as your happiest niche.
Keep pushing your skills, but also do the things you have mastered where you can contribute the best. Share, teach and keep your head up for places you can help other team members.
Learn when to ask for help (code reviews will spot those areas if you don’t catch them first). How good is that clock in your head? Have you gotten over loosing track of time while working? Have you mastered that inner discipline of staying on target, and not indulging your curiosity when looking up something and running across a related topic?
Be knowledgeable, helpful, friendly, nice and hard-working and the areas you need help or make mistakes will be minimized and you will enjoy an awesome happy supportive team.
-
dalecorey,
I am still struggling with your interpretation for the need of intelligence.
Obviously, a programmer needs to be intelligent in the way that he can perform the analysis (and in heaps of other ways too).
But the analysis should not (and does not) rely on the programming language you will be using. As we stated before, a good developper must select the most appropriate language to suit the job. If you don't know the job (yet), you cannot choose a language.
(Recall the example from Antares on the IM soft in VB.)
If you do the analysis with the development tool in mind, you're bound to end up with a product that is more tailored to the possibilities / restrictions of the tool than with the user's requirements...
Compare to SQL ...
If you design a database, you start of drawing the DB scheme. After that it is not important if you implement the database in SQL Server, Oracle, DB2, Access, MySQL, ...
Obviously, each of these has it's own merits and pitfalls, so you'd better make a good choice based on your design.
.
? 
Viewing 15 posts - 76 through 90 (of 96 total)
You must be logged in to reply to this topic. Login to reply