I think a "talented" programmer is one that can adapt and learn quick (low ramp up time) and that can write clean, readable, and reusable code. Other aspects are important as well such as teamwork, communication, etc. but I don't really see that as being part of a programmer's talent.

Quote:Original post by Drizzt DoUrden
I'm wondering what exactly the difference is between a programmer and a "talented" programmer. From the perspective of, lets say, someone who is looking to hire a programmer as part of their development team (not a Lead programmer, who I am going to assume has talent plus experience in management of both people and code), when they look for a "talented individual", what are they looking for?

I don't know of any magic test that will let you look at a novice and examine their talent. I do know of several traits I look for.

Also, be sure to define what you are looking for. Do you want a programmer or coder: somebody who just transcribes into compilable stuff? Are you looking for a software engineer: somebody who can solve problems and architect solutions?

A junior level software engineer will show different skills than a junior level programmer. The latter is just current on the hardware and languages. The former is able to design broad solutions and well-versed on a lot of topics with programming seen as a means to an end. Many people fail to see the difference.

Are they driven, searching out their own fun little projects? Are they intelligent, able to solve problems quickly? Are they educated, well read in several subjects, and voracious readers? Do they have the correct domain specific-knowledge, understanding the questions and coming up with the correct answers? Do they volunteer additional domain-specific detail indicating a broader depth of knowledge?

Generally these people enjoy the field. They learn because they want to. They take on harder projects because they enjoy the challenge. They produce because they enjoy the craft, and less because of the paycheck. (caveat: paycheck still needed.)



On a side note, make sure you treat the talented people well. When you find a good software engineer (they aren't just "programmers"), pay them well. When a developer is able to routinely outperform two or three lesser skilled programmers, pay them accordingly.

> when they look for a "talented individual", what
> are they looking for?

I haven't seen that terminology in a long while. Some managers have been influenced by the thinking that was prevalent in the 80s when the US government was looking at productivity in order to assess the costs of software development. Some government branches were then looking at ADA and some of the novel software engineering methods (novel at the time) that were devised by guys like Tom DeMarco and others. It was determined then that the "average programmer" (the term used at the time) could generate an average of 10 lines of code per day, debugged and documented. That, along with the estimated KLOC (1K lines of code) of a project were used to estimate the costs of software engineering projects. That 10 number was an average, but you could find developers which could do 100 to 200 LOC per day, debugged and documented. That's 10x the productivity, with a fractional increase in salaries. It didn't take long for managers to readjust their HR practices to look out for those outliers, given the productivity/$ achieved.

That was then, although I still see that lingo appear from time to time in job offers. It doesn't mean much, except - maybe - signal to prospective job seekers this employer has the ability and the will to wait for the right people to come along; i.e. prepare for a 'no'. Nowadays, experience, teamwork, communication skills, leadership skills, ability to think outside the box, being customer-oriented, etc are factored into the selection process. So don't be too hung up on the productivity/$ thingy.

-cb

Quote:Original post by Drizzt DoUrden
frob definitely touched on something I was getting at, which was the differences between a "programmer" and a "software engineer." I wonder what the real difference is?

Programming is encoding known solutions in a manner computable by a machine. Software development - or software engineering - is the derivation of those solutions from the intersection of constraints placed by the human requirements/objectives the software is designed to fulfill/assist. Programming is a step in the software development/engineering process, and it generally includes code design, text entry (of source), build and output/artifact validation (debugging). Software development additionally encompasses requirements gathering, prototyping, usability testing, systems architecture and other facets.

Quote:I imagine it also comes down to playing your position. Someone who is hired as an engineer probably has had plenty of experience under somebody else's command before moving up. A programmer may have brilliant ideas but is it their job to express and share ideas, or is a programmer given a computer and given a task and told to get to the code?

Programmers can express and share ideas, but the scope at which they are able to share is bounded by their limited experience. Software developers/engineers (the terms are, to me, interchangeable, especially in light of the fact that the title "software engineer" can not be used in the state of Texas, among others, unless the individual has passed a professional engineer certificate exam) have a larger scope of experience, enabling them to offer insight on a broader range of issues.

Note that programmer and software developer are often used more or less interchangeably (usually to refer to the latter) by many people, particularly recruiters. SO read any descriptions thoroughly; don't assume a programmer role at one place is significantly different to a developer role at another, it may not be.