Forgot your password?
typodupeerror
Programming IT

Ask Slashdot: Is Tech Talent More Important Than Skill? 277

Posted by samzenpus
from the two-sides-of-a-coin dept.
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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Is Tech Talent More Important Than Skill?

Comments Filter:
  • Neither (Score:5, Insightful)

    by Quinn_Inuit (760445) <Quinn_InuitNO@SPAMyahoo.com> on Wednesday July 31, 2013 @10:08PM (#44442629)
    Hard work usually wins the day.
  • Huh? (Score:5, Insightful)

    by Edward Scissorhands (665444) on Wednesday July 31, 2013 @10:09PM (#44442631)
    I don't understand the difference. Who cares? If someone can get the job done, that's what counts.
  • Talent, obviously (Score:3, Insightful)

    by Anonymous Coward on Wednesday July 31, 2013 @10:15PM (#44442663)

    Skill can be acquired.

  • by Anonymous Coward on Wednesday July 31, 2013 @10:16PM (#44442669)

    You would hate academia.

  • by sirwired (27582) on Wednesday July 31, 2013 @10:21PM (#44442695)

    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)

    by Anonymous Coward on Wednesday July 31, 2013 @10:25PM (#44442731)

    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)

    by sycodon (149926) on Wednesday July 31, 2013 @10:28PM (#44442745)

    What is described is two different jobs.

  • Re:Huh? (Score:5, Insightful)

    by Gorobei (127755) on Wednesday July 31, 2013 @10:33PM (#44442775)

    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)

    by hurwak-feg (2955853) on Wednesday July 31, 2013 @10:35PM (#44442791)
    I think Venezia is using the wrong words. I think Creativity vs Skill would be a better comparison. Talent in a sense is just a measure of how quickly one can learn a skill. Both talent and creativity are important. Creativity is needed to find innovative and unconventional (can be good or bad) solutions to problems. Skill is needed to be able to understand the problem and actually produce the work. Programming, systems administration, troubleshooting applications, and other IT tasks/roles all have skills and knowledge that one must acquire before being able to accomplish tasks the job requires. Without the skills and knowledge to fully understand the problem/task, the most creative (talented as Venezia puts it) person in the world won't be able to perform the task required of them. The reverse is also true. Someone could have the depth of knowledge to translate something as abstract as Python to machine code in their head, but if they lack the creativity to apply it or consider non technical approaches (which can be better in some cases) to the task or problem, they aren't very useful either. TLDR - Both are important.
  • Re:Neither (Score:5, Insightful)

    by hibiki_r (649814) on Wednesday July 31, 2013 @10:35PM (#44442793)

    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)

    by Alomex (148003) on Wednesday July 31, 2013 @10:38PM (#44442813) Homepage

    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.

  • by Chas (5144) on Wednesday July 31, 2013 @10:54PM (#44442903) Homepage Journal

    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)

    by bensyverson (732781) on Wednesday July 31, 2013 @11:07PM (#44442975) Homepage
    That's true, and it's sad. People overspecialize these days, and underestimate themselves as a result. If you can optimize integer math, you can think big picture, and vice versa. Creativity is creativity.
  • by satch89450 (186046) on Wednesday July 31, 2013 @11:18PM (#44443065) Homepage

    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)

    by Skapare (16644) on Wednesday July 31, 2013 @11:41PM (#44443189) Homepage

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

  • by Diomedes01 (173241) on Wednesday July 31, 2013 @11:43PM (#44443193)

    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.

  • by raymorris (2726007) on Thursday August 01, 2013 @12:20AM (#44443343)
    Working hard and smart at the same time is normally a winning combination.

    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)

    by Dahamma (304068) on Thursday August 01, 2013 @12:26AM (#44443357)

    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)

    by aralin (107264) on Thursday August 01, 2013 @01:06AM (#44443575)

    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)

    by Tough Love (215404) on Thursday August 01, 2013 @01:12AM (#44443607)

    Hard work usually wins the day.

    Hard work by a dullard is only effective for dull tasks.

  • Hard work? (Score:4, Insightful)

    by dutchwhizzman (817898) on Thursday August 01, 2013 @01:57AM (#44443817)
    Hard work may win you a pay check. Politics is what usually wins you a bigger pay check in IT. You can be skilled and talented all you want, but if you can't get your ideas across, you'll be sitting in a corner working your butt off without any recognition at all. You need people skills just as much as technical skills these days to survive.
  • Re:Neither (Score:5, Insightful)

    by Concerned Onlooker (473481) on Thursday August 01, 2013 @01:59AM (#44443821) Homepage Journal

    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

  • by Eskarel (565631) on Thursday August 01, 2013 @02:19AM (#44443907)

    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)

    by JaredOfEuropa (526365) on Thursday August 01, 2013 @02:50AM (#44443989) Journal
    Cute, but wrong. The world is full of persistent, determined failures. If you lack skills and talent, you will not succeed by persisting. If you lack the skills of a carpenter and the talent of an architect, you can "press" on all you want but it's unlikely that you'll build a house that stays up. You might come up with some sort of servicable shelter, but that's hardly contributing towards "solving the problems of the human race".

    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)

    by gbjbaanb (229885) on Thursday August 01, 2013 @07:39AM (#44444983)

    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.

Save energy: Drive a smaller shell.

Working...