Ask Slashdot: Is Tech Talent More Important Than Skill? 277
snydeq writes "Taming technology is sometimes more art than science, but the difference can sometimes be hard to discern, writes Deep End's Paul Venezia. 'You've probably come across colleagues who were extremely skilled at their jobs — system administrators who can bend a zsh shell to their every whim, or developers who can write lengthy functions that compile without a whimper the first time. You've probably also come across colleagues who were extremely talented — who could instantly visualize a new infrastructure addition and sketch it out to extreme detail on a whiteboard while they assembled it in their head, for example, or who could devise a new, elegant UI without breaking a sweat. The truly gifted among us exhibit both of those traits, but most fall into one category or another. There is a difference between skill and talent. Such is true in many vocations, of course, but IT can present a stark contrast between the two.'"Assuming Venezia is correct, which do you think is more important?
Neither (Score:5, Insightful)
Huh? (Score:5, Insightful)
Talent, obviously (Score:3, Insightful)
Skill can be acquired.
Re:"Ideas people" are worthless (Score:3, Insightful)
You would hate academia.
He's using silly terms to confuse himself. (Score:5, Insightful)
The terms to use aren't "Talent" and "Skill" (those are pretty darn close to synonyms)... If you use those two terms, of COURSE you confuse yourself.
I believe in IT we would refer to the two people as a Coder vs. an Architect. And yes, one person is often better at one of those things than the other. And this sort split is virtually universal across professions; it's not special to IT in any way.
Re:Neither (Score:5, Insightful)
No way.
Someone who's willing to spend 12 hours a day trying their best, but not actually getting anything done is far less useful than someone who slacks of 7 hours of the day and gets a monumental amount done in the 60 minutes they are actually working. Usually the people doing that are pretty skilled and pretty talented - and have the bonus that when the shit hits the fan, you can usually get weeks worth of work done in surprisingly short time spans.
Different Jobs (Score:5, Insightful)
What is described is two different jobs.
Re:Huh? (Score:5, Insightful)
I don't understand the difference. Who cares? If someone can get the job done, that's what counts.
Ah, grasshopper, as you gain respect and seniority, you will find the success of your project becomes more and more dependent on other people.
If you want to continue to succeed, you need to understand these peoples' strengths.
1. No skill, no talent: avoid these people, have them write doc or something.
2. Skill, no talent: give them designs or procedures. They will execute well if they understand what you want.
3. No skill, talent. Mentor them and watch them closely. You will get a Scala engine running 20 lines of code in the middle of your Java app if you don't pay attention.
4. Skill & Talent. Just chat will them about what you need. You'll get what you need in no time.
Wrong word choice (Score:3, Insightful)
Re:Neither (Score:5, Insightful)
A programmer with no talent that is a hard worker will still have tons of trouble doing anything new. And if the work is not new, do I really want someone to write more boring code?
Now, there's such thing as a developer that spends the entire day goofing off, and those won't do any good. But after you pass a very basic level of dedication, it's the smart developers that have a clear advantage.
If there's anything that the question is missing, is social skills. A very good developer that sits by himself is valuable, but if he can help others be better, and can communicate with users and people in other disciplines properly, he'll be far more useful.
Grow up (Score:4, Insightful)
We used to ask these questions back when we were seven:
Who do you love more, your mom or your dad?
Oh grow up. Both are important and there is absolutely no reason or need to create a linear ordering among them.
Different? Sure! But a meaningless difference. (Score:5, Insightful)
Skill or talent!
Stupid. Stupid. Stupid.
This is essentially a false dichotomy. Creativity vs technical excellence.
Sure, you can have creativity without technical excellence. There's hordes of crappy garage bands out there that can attest to this.
You can also have technical excellence without creativity. Think about some of the ugliest, most painful-to-read code you have ever seen, but that happens to just work.
You do NOT prioritize one over the other (well, you can, but you're a dumbass of Jobsian proportions if you do).
Ideally, you want them to co-exist, harmoniously, in your people. Or, if that isn't happening, you make sure that they can interact amiably.
Sadly true (Score:3, Insightful)
Re:Huh? You think docs are unimportant? (Score:5, Insightful)
OK, I have QA training in my background as well as programming skills, so apply appropriate amounts of salt: some of the most interesting blunders in design, and blunders in implementation, are exposed when a good technical writer tries to makes sense of what s/he sees, and fails. In the process of trying to teach others how it all works, all the warts, cracks, crocks, and kludges are exposed in all its glory. What doesn't make sense in a manual will most likely not make sense in the real world. Think of it as scaffolding for the mind. "According to the specification, when I do THIS then X is supposed to happen; instead Y happens." And so forth.
When I was in a large programming group in the 70s, I was the guy sitting at a Wang word processor, banging out design specs and cursing some of the square-heads that couldn't seem to design their way out of a paper bag. When my company decided they wanted to build their own replacement computer for one they had been buying for years, they turned to me to "reverse engineer" the computer -- including all the proprietary extensions and additions -- so the hardware group would have something to design to, and the SQA people to test the implementation against.
Actually, it's an old story in Engineering. When you try to explain something, you see holes that you were blind to for days, months, even years. It's an "Aha!" generator.
Re:Neither (Score:5, Insightful)
This so often depends on what the task is. If management chooses to let you decide how to go from problem to solution, this kind of thing can happen for a lot of people. If management is already dictating specifics of the solution, then it is most likely to end up as a disaster (except people with the special unique skill of knowing how to deal with idiot managers).
Is this whole story a troll? (Score:5, Insightful)
Is this whole story a troll? The false dichotomy proposed between the (poorly-labelled) attributes of "talent" and "skill" is disingenuous. The comparison between acquired knowledge (what the author refers to as "skill") and inductive reasoning about a proposed new piece of functionality/infrastructure/etc (referred to by as "talent" in this bizarre example) is contrived, and somewhat arbitrary. I almost never read or discuss Slashdot stories anymore, and this s a great example of the underlying problem. Now, all you kids get off my lawn, and leave me in peace.
true for jobs other than programmer, though ... (Score:5, Insightful)
It's been aid that laziness is a popular characteristic of a good programmers. a programmer's JOB is to make the computer work for you. Hard work in programming sometimes means writing 18 different classes in one day, to handle 18 different columns. a better approach is to write one abstract class and a couple of subclasses that handle the different columns is polymorphically.
Many times I've deleted a hundred lines of code and replaced it with four lines that do the same task more reliably and more elegantly. My predecessor worked hard. I worked smart.
That said, reading a 1300 page book to learn HOW to do it in four lines was "hard work". I suspect programmers should listen to the old advice about sharpening the axe and spend a lot of their mental energy learning how to accomplish more faster, rather than producing more lines of code per day. The number of bugs is proportional to the number of lines of code, so the person who writes more lines per day really just creates more problems per day.
Re:Sadly true (Score:5, Insightful)
If you can optimize integer math, you can think big picture, and vice versa.
Actually, after interviewing literally thousands of software developers over my career, I can tell you that is absolutely NOT true...
Re:Neither (Score:5, Insightful)
Oracle was trying in 2-3 projects over the span of 10 years to create a certain NDA covered technology. One of those tries involved a team of 700 people over 5 years. All those attempts failed and have been scraped, in some cases whole teams of people layed off. The attempt that eventually succeeded was one talented architect with 2 developers working for 6 months.
Hard work my ass.
Re:Neither (Score:5, Insightful)
Hard work usually wins the day.
Hard work by a dullard is only effective for dull tasks.
Hard work? (Score:4, Insightful)
Re:Neither (Score:5, Insightful)
I'm going with Coolidge on this one.
"Nothing in the world can take the place of Persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent. The slogan 'Press On' has solved and always will solve the problems of the human race."
-- Calvin Coolidge
Re:Talent is a myth... (Score:4, Insightful)
Talent isn't a myth, but it isn't what people think it is.
Being talented doesn't make you a phenomenal programmer because you still have to learn to program. Being talented however allows you to understand what it is you are doing in a way that makes becoming a phenomenal programmer vastly easier. This makes talented people look like better programmers when in fact what they are actually better at is understanding and learning programming, or music, or whatever else it might be. That's really only a semantic difference though because at equal levels of skill(and particularly at close to zero skill) talent shows up in the results.
Does that mean skill and hard work don't matter? Of course not. It does however mean that if you want to perform as well as someone who is much more talented than you, you will have to work significantly harder than them.
Re:Neither (Score:5, Insightful)
Persistence is important of course; without persistence you are unlikely to develop your skills and talents. Solving hard problems takes persistence. But there is a difference between persisting in attacking a hard problem and not giving up after a failure or three, and persisting in trying and trying again when you simply lack the skills for the job. As GP points out, persistence can make up for some lack of skill, but it will not bring you on the same level as a highly skilled person.
Re:Neither (Score:4, Insightful)
And if the work is not new, do I really want someone to write more boring code?
yes.
Part of the problem with the IT industry is the continual churn of 'new' stuff as everyone seeks to find ways to enhance their CVs. If we focussed on solving problems with existing tooling, we'd have a mature industry with standards and established practices, and have mature, stable products that worked!
Its the so-called smart developers that aren't happy with yesterday's solutions and want to rewrite it because they're often not smart enough to maintain existing code.Maybe the smart ones are the ones who do the work on boring code after all.