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.
Assuming Venezia is correct, which do you think is more important?
Whichever one I've got, with justification to follow.
Skill can be acquired.
You would hate academia.
It depends on how much talent versus how much skill. You COULD just calculate the area under the curve to get total value...
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.
...but this isn't it. These are just two different kinds of skills.
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.
My car's engine or its wheels?
Do I need to have a fuel tank, too?
(sorry, I couldn't resist making a car analogy)
Karma: Terrifying (mostly affected by atrocities you've committed)
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!!!
I hire talent because I know I can teach skills.
Don't know source control? Let me teach you GIT.
Don't know shell scripting? Let me teach you Bash.
Build server? Jenkins
Build tool chain? Make/Ant/Maven/Grunt
Web server? Nginx/Apache
Reverse proxy and load balancing? Squid
Programming language? Java/C
Scripting language? Node/Python
Data modeling / schema? No/SQL
Design pattern? decorator, observer, module, factory
Don't know what to do with your new skills? Sorry, I can tell you what I want to do with your skills but what you want to do is up to you. If you can't think of anything then you're just a worker bee. You can work on contract but I won't hire you.
A fool throws a stone into a well and a thousand sages can not remove it.
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.
As a non-"ideas person" myself, I largely agree with the parent. I'm both talented and skilled at software development, but I'm not much good at coming up with the initial concept. I need someone to point me towards a goal in most cases (at least if it's not scratching my own itch).
Once I have that goal however it's a totally different situation.
...and so is the idea of being "gifted." Pardon this little rant, which is not directed at you, AC, but what we call "talent" is essentially skill plus passion. When a person is phenomenal programmer, or writer, or guitar player, they didn't get that way because it was gifted to them. They either put in thousands of hours practicing, or they had an all-consuming passion for it. So skill wins out in this reductive comparison, because in technology, you must be creative to be considered skillful.
Ok - I know plenty of guys that can do both ideals described, & I've seen it over a professional career as a developer from 1994-2009 fulltime. I've been fortunate to have been exposed to, worked with, and spoken to such folks thru academia right into the professional world... they ARE out there. They are BUILT, not born, most of the time. Field's TOO big for 'natural intellect' (skill via nature) to be the sole determinant.
I'm talking guys I saw go on WAY past where I was, & were better @ the game when I knew them professionally (going to MS, Symantec, & others + excelling)...
They didn't do it on natural skill alone.
They kept @ it, almost 24x7... why? Most loved it.
(Their motivator wasn't money alone)
On talent & intellect: A few BLEW MY DOORS OUT totally on both fronts, admittedly & probably still do.
(Yes, nobody "knows it all", & it takes time to say, learn not only to be a developer/coder, but also a DBA, webmaster, & even business process analyst/system analyst too - hence why specialization & teams exist + help - since no man is an "army of 1", especially on larger projects with gigantic business process logic behind them).
That's just my 2 cents though based on my personal experience & observation: Not "the biggest sampleset" statistically of course. However, the 'power' of great people, is that they provide examples & can 'inspire' YOU to be "that better man" (it's their greatest talent). I am thankful to have even KNOWN such folks in my life in athletics, academia, professionally, or even online.
Still - I think a human being is a marvellous machine, especially when properly motivated - & that yes, our minds (and bodies) are what I call "plastic": Meaning you can BE anything you like, or DO anything you like, minus say, natural constraints in physicality or "mental strength" for lack of a better expression... takes all kinds to make a world, & some folks yes, are NATURALLY thru gifts of nature/God/genetics etc., 'superior' (for a while @ least) to others for certain tasks too!)
We ARE "built to work" & when pushed? We improve, in just about anything.
APK
P.S.=> I'll still stick by the experience is the best teacher and hard workers rule I posted earlier... you can have all the natural talent in the world. but imo @ least & experience? It's NOT enough!
E.G. #1 of 2-> I've seen it as an NCAA athlete (1985 Letter K http://www.lemoynedolphins.com/sports/mlax/history/mlaxletterwinners ) in the physical world (e.g. guys that outright SUCKED their 1st year, e.g. http://en.wikipedia.org/wiki/Neil_Olshey (hey Neil, if you SEE this? Assist 'behind the back' vs. University of Buffalo to you per "yours truly"), lol he is an example of that, could barely play 1st year, but good athlete, in the end he rocked) but came back later like gangbusters via training hard & focusing - others 'coasted' on natural talent & those benchwarmers took their jobs from them in fact in SOME cases)
Alongside
E.G. #2 of 2 -> Where 'intellect rules' in computers (same basic deal, folks CAN improve if they're motivated & love what they're doing which imo is the MOST important factor)
I've seen it, & on many a level in this field and others in fact.
Still what I saw? Is if/when you don't work @ it + keep at it (not bad if you love what you do though), you atrophy or will NEVER make it on inborn talent alone - that can be the biggest shame waste though - wasted talent... apk
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.
Talk to the duck
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
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!"
There seems to be an stuff that seems an lot stuff that in theory will work but when it comes to the hands on part people with the hands on experience will say that will not work or it's an bad idea.
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.
A variation on this theme was a two tiered development group. Group 1 came up with every new improvement and product idea. Group 2 finished group 1's ideas. But group 2 didn't answer to group 1 so if group 1 had gone off the rails then group 2 sort of didn't work on it. The recognition was that group 1 was a bit ADD while group 2 was a bit autistic/OCD. The key was that group 1 would not communicate so much with group 2 as that would just end up with blood on the walls but that group 1 communicated with the fairly relaxed group leaders who just herded group 2 into not grumbling and moving forward.
The best interactions with the two groups were when group 2 would get stuck (their faces got closer to their screens) and group 1 would be handed the problem again. Often the solution would be available in 5 minutes.
This way group 2 could use TDD or coding standards, documenting, QA stuff, or whatever they wanted that would have driven group 1 insane. Once group 1 handed it over they could then forget the project existed. What they could often do was insist on certain parameters. 30 fps minimum or whatever they knew was critical to the actual success. Group 2 would then have to obsess over that instead of obsessing over some other religious matter such as excessive logging that dropped performance to 2 fps.
don't be a dick
It's what I tell all my students who ask for career advice, what tech to study, how to succeed in IT etc etc etc.
In an industry full of people with big 'ol chips on their shoulders about how special they are for knowing what a variable is, many of which have zero social skills or charisma, zero ability to see other people's/department's point of view, and where not an inconsequential amount are "on the spectrum"... just being a good guy (or gal) that makes your client's lives easier instead of harder and does it daily with a smile, a laugh and a warm handshake, is far more important than any technical skill/talent.
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?