Ask Slashdot: Is Tech Talent More Important Than Skill?
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?
Hard work usually wins the day.
Stop learning! Only you can prevent esoterrorism.
I don't understand the difference. Who cares? If someone can get the job done, that's what counts.
Skill can be acquired.
You would hate academia.
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.
What is described is two different jobs.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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.
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.
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.
Chas - The one, the only.
THANK GOD!!!
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.
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.
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.
"To hope's end I rode and to heart's breaking: Now for wrath, now for ruin and a red nightfall!"
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.
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.
I was promised a flying car. Where is my flying car?
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.