Slashdot Mirror
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.
There's only room for people who can actually get work done. Visualization of the problem is meaningless unless you can actually put in elbow grease to get the problem solved.
In silicon valley right now there is no room for ideas or the people who can't actually get their ideas into practice. Ideas are what kill profits, whereas hard work and skill will bring in money.
Assuming Venezia is correct, which do you think is more important?
Whichever one I've got, with justification to follow.
Skill can be acquired.
It depends on how much talent versus how much skill. You COULD just calculate the area under the curve to get total value...
Obligatory: http://en.wikipedia.org/wiki/Betteridges_law_of_headlines
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.
Talent is the most grossly overrated commodity in the world. I find for most people, there's a point in life that they can reach by coasting; they coast to X, maybe it's high school, maybe it's freshman year in college. Then they have to sweat their asses off to reach X+1. I'm interested in the people who have to sweat their assess off from the beginning, because then they learn to do it as a habit. Spend too much time of your life coasting and you'll find that you constantly seek out situations where you can coast -- it's safer and it feels better.
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.
doesn't mean they are. The dictionary definition of talent is so vague (4. a) : a special innate or developed aptitude for an expressed or implied activity usually of a creative or artistic nature) that it's not much more than something you can do with a degree of competence.
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.
In grand /. tradition, I am only commenting on the summary, as I have not read the article.
Talent is a great thing to have, but anyone sufficiently skilled to do the job is good enough. It doesn't matter how (easily) they got the skill. On the other hand, someone with talent, but no focus to apply it, is worthless. A super-star programmer who only writes good code is probably not going to be great when things go bad. Unless he only deals with his own code, he has to know how to read bad code, how to debug it and how to fix it without introducing even more bugs. That could also be a talent, but it's not the same talent.
TL/DR: Talent can get you skill, but a lack of skill makes one worthless for the job at hand.
If the zsh guy gets a problem with zsh you are golden. However if it's a problem needing some Erlang code to find the minimum feedback arcset you are in trouble.
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!!!
Is this about Architecture vs. Design vs. Implementation? Of course a really good engineer can do all three well and can document them well in addition. But there is no "more" important. Unless all are done well, the final result will suck. If you do not have somebody that can do all or the project is to large, you need to find somebody that does each aspect well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I've known no shortage of white board artists who could sketch diagrams in a blinding flash but who were otherwise completely useless to the team. Nor could they explain their white board diagrams in terminology that enabled those who were skilled at coding to be able to implement their grand visions.
Visionaries are a dime a dozen. But without the skill to put those visions in practice, they're just dead weight.
I do not fail; I succeed at finding out what does not work.
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.
This is a bit like asking which is more important: the left side of the brain, or the right side of the brain?
http://alternatives.rzero.com/
Is the talent to present and convince .. to get it sold. Without colleges support there will be no compensation.
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Have gnu, will travel.
...MBTI. And the answer is: you need both (technically, all 16). I'm an INTJ. I do INTJ work. Put me on a job where an ISTJ would excel and I probably won't last the rest of the month... and vice versa.
If there is a difference between skill and talent, neither the summary nor the article make the distinction clear.
You are welcome on my lawn.
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.
It probably depends on what their job is. Asking this as an open question is like asking "Which is a better tool, a hammer or a saw?"
If they're your UI designer, Software Architect, or User Experience Designer? It's probably better to err on the side of "talent" (creativity) rather than technical skill. These people don't need to output elegant and functional code, they just need to come up with clever ideas and solutions from a broader more holistic perspective.
If they're your Frontend Developer, UI Developer, or a high level programmer of some kind? They probably need a mix of the two, with an emphasis on technical skill. Their job is output code, but it won't usually need to be perfectly optimized and they will often need to solve new problems in unexpected ways.
If they're your backend dev, production software engineer, or other nitty-gritty code writer? Technical skill will be the more important trait. These guys will usually not be expected to solve the weird UI problems themselves (That's what the UX Designer is for!), but their product needs to be rock-solid from a technical perspective.
I didn't say anything of the sort. I simply said that the two words "Talent" and "Skill" have sufficiently close definitions that they might as well by synonyms. It's a lexical statement; nothing more.
I said nothing along the lines that anyone can become talented/skilled at anything they choose to. I don't see how on earth you leapt to that conclusion, AC.
...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.
if it were, I'd be working.
They're using their grammar skills there.
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.
I'd say the bigger issue than talent (or creativity, as one poster put it) vs. skill, since both can be learned with enough effort and training, is a reasonably-congenial personality. That is to say, you might have the hottest c0d1n6 5k1llz in the world, and the actual creative thinking ability to put those skills into practical use, but you're a complete asshole, no one's going to want to work with you - either your coworkers or your next prospective employer - and you'll basically just not get anything done that an employer will be willing to pay you for.
There are good reasons not to have the talent and/or skills to do the work - maybe you can't afford the necessarily schooling, tools, etc. or you have no opportunity - but there's never a reason to be an asshole, whether you are skilled/talented or not.
this is one of the main reasons i participate on mailing lists and forums, and write readmes, tech notes, and documentation - the act of writing (or speaking, to a lesser extent) to explain something to someone else, or to solve their problem forces me to put my own thoughts and knowledge in order and ends up increases my own understanding.
usually it's just a fairly minor incremental increase, but sometimes it's a major "aha!" moment of insight, completely overturning my old understanding and opening up new knowledge and techniques. Those occasional moments are priceless.
and, as you say, it's also a damn good way of debugging a problem - write it out, send it, and 5 seconds after you hit Send, you'll realise exactly how obvious the solution is.
I had a vanity Web page where I posted a workaround in a once popular programming language/system.
I received a "cold call" in effect interviewing me for a job. I guess there is not a big market for skill in the once popular programming language/system, but when a person needs that kind of developer, that need that kind of developer and cast a wide net.
I guess the solution I posted communicated that I had a lot of skill in that system. The person calling proceeded to ask me a lot of interview-type questions, "Did I know feature X? Did I know feature Y?"
I guess I didn't need to change jobs or I wasn't going to leap at freelancing when I had enough work to do or I may be lacking in some social skills. I guess I blurted out that I didn't know any of those things because I used this system but didn't have that level of skill in it. I explained that I really needed a solution to the problem I had encountered and I didn't let my lack of skills stop me from reading source code to that system to get to the bottom of what was happening and I posted what I came up with should anyone else benefit by that discovery as I am in an academic environment. The finding didn't rise to the level of a publication but it merited a vanity Web page.
A colleague describes that as "banging your head on the wall." Some hardware or software doesn't work according to spec, you can't scrap it, so you keep testing and debugging and searching and head scratching until you come up with a fix. It isn't skill, it isn't talent, it is simply a willingness to do whatever work it takes and not quit.
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.
The engine had trouble shifting out of 1st gear. I pull off the road, turn off the engine and restart to "reboot", drive off, and it shifts, but the engine labors.
I pull into the garage at home, and I am starting to trail smoke. Turn off the motor and the car smells real bad. Oh oh, the transmission just gave out and time to call the scrap dealer.
Curiousity takes over and I pull the transmission dipstick, and the fluid looks clean and smells fresh. Hmmm.
I start the car up thinking that an alternator or water pump is frozen, but the belt runs OK and no burning smell. I take the car up the road and pull over. It shifts OK but is running kinda sluggish. I had a problem with stuck brake calipers so a spit real good and touched each rotor.
The front rotors are cold. A back rotor is hot. Is that brake acting up again, just had the back brakes done. The other back rotor is hot. Is the parking brake dragging? Open the driver's door and, dang, I had left the parking brake on.
The brake light doesn't light anymore, and I parked in a public lot on a slight incline, so I set the brake. I put a sheet of paper over the steering column as a reminder. I had got in the car, pulled the sheet, and promptly forgotten what I had done so I drove away. No car problem -- I have a brain problem. Pop spent his last days in long-term care and I am age 56.
What's perceived as "talent" is a high level of skill. I simply don't believe in extreme differences in native ability between one normal person and another. Aside from physical defects, and impairments, every person starts life with very nearly the same brain. Differences in what we can do well develop over time by the accumulation of skills. The geniuses out there didn't get so good at what they do by being dealt a royal flush. They got there by being interested in certain kinds of activity and pursuing them relentlessly. Through constant repetition, the brain structures modify themselves to do the same tasks more and more efficiently and with less and less effort. The colleague who can instantly visualize and explicate a whole new infrastructure can do so because he has spent a lot of time studying infrastructures. The one who can design a new, elegant UI can do so because he has studied and designed a lot of UIs.
Wayne Gretzky became a great hockey player because he was fascinated with the game from an early age and spent many thousands of hours watching it and playing it and thinking about it when he wasn't not on the ice. Great programmers are like that, but with more code and less skates.
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.
The talent of Tiger Woods really just came from practising his skill as often as possible for many years. He's also done something similar with his golf.
Skill is more important because it gets the job done. Talent never gets the job done. Talent is the good looking secretary who can't type, while skill is the secretary who may not be a looker, but without her your company would go broke. Talent is the useless showoff who has a great set of tools who likes to brag about them, but skill is the often ignored man who knows how to use them. Talent is the new hire with a college degree and a 4.3+ GPA with an excellent resume, excellent talking skills, and answers all the questions right, while skill is the guy who solves problems, comes up with the correct solutions to do the task perfectly. I've seen a lot of talented geniuses but very few who had any useful skills in my 20+ years of sysadmin work, but I've seen quite a few skilled workers in my line of work who don't have any certifications or degree who can find solutions to problems and fix them quickly. So in my experience, skill over takes talent, just like wisdom over intelligence. You might have high intelligence, but wisdom is knowing how to use it.
I'm more talented than skilled, but consider skilled workers more important. Talented people will take their talents with them when they leave the job. Skilled workers will leave the benefits of their skill in the work they leave behind - better architected, easier to maintain, more bug-free code than someone without skill. Talented/unskilled people would get it done fast, and produce a trainwreck.
I have left slashdot and am now on Soylent News. FUCK YOU DICE.
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.
Just to explain for the 1st class citizens who work with real languages on real project with proper budgets and deadlines, the web world is mostly: we want it yesterday, for less, done by the company cat who ran away.
We who use PHP are the bastard children of a lesser god.
If you are extremely unlucky you will end up in a magento/drupal/etc sweatshop punching out nearly identical websites on budgets that real programmers call their hourly rate.
If you want to escape that you are going to need a couple of things. First of is the realization that until a project is finished, it has no value. An unfinished house at least has land that has value and bricks that can be sold. A broken down car can be sold as scrap but unfinished code? Worthless. So the first "skill" one requires is to be able to FINISH a project before the money runs out and that skill requires some real talent.
Pure coders tend to get stuck on details, optimizing the hell out of some sub routine while the program does not exist. Shall I illustrate this by doing something really bold and original and compare this to a car? Bet you never saw that coming.
A coder is someone who with a budget of 10k spend that on a sweet engine that he has lovingly tuned for 10 years and that will startup anyday now once he got some new parts and then it can go into his car, once he saved up another 10k to buy a car. A developer is a car mechanic who fixes your car for a decent fee.
Facebook is the prime example. Many a coder mocks them for using PHP and for having to spend a fortune on developing HipHop to make PHP run faster when they could have just used a real language from the start... except IF they had handed the project to a coder that coder would STILL be working on a super fast routine for the timeline, that would be in form the start and will blow the competition away in 2050.
In the real world, projects have deadlines and budgets and if you break them, the project breaks. Once the project is up and running, you can get in the coders and optimize the hell out of everything payed for by the profit being generated by the script kiddie developer who wrote lousy code but got it to work.
There are various websites were people can hosts their projects. Count the ones that NEVER release a single version... betcha they are done by coders who spend years working on a single function but couldn't manage to actually get a working product out the door?
That is one thing I look for in candidates myself, I don't care WHAT you build or how well you build it but did you EVER get ANYTHING out the door? Can you get it into your head that when you are asked to do something before a date, that it don't matter how nice it will be if that date can be postponed endlessly but that I want something that works by that date even if looking at it will drive people insane?
Mind you, I think the word talent and skill are totally useless to describe the difference. Perhaps the difference is that of a dreamer or a realist. And you need realists to get the money to pay for the dreamers who you need to keep increasing the money you are earning to pay for them both.
When the Sydney Opera house was build the Architect was needed to come up with this innovative design but it took a builder to come up with a way to realize it. BOTH together build it. Alone the builder would never have come up with the design and without the builder the architect would only have had drawings to hang on his wall.
You need the code monkey AND the guy who can see the big picture. And ideally they should be managed by a manager who understands the difference between deadlines that are real and made up ones.
Now find me a way to find good managers. THAT is the one everyone is looking for.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Getting @#@! done requires dreamers and do(ers), and even the critics.
It's simply not possible. If you don't get the tech, you can't work with it. Some may pick up new tech faster than others, or perceive to at least. But that is more related to how much other knowledge they have, and what's in the active portions of their brains when they are looking at it.
I work with a programmer who has a very sound programming way of looking at problems. Sometimes I learn things, but I'm never truly lost. He is a programmer working on programs, and I'm an Admin/Engineer working on systems related problems. I don't program all the time so what's in the fore part of my mind is not always best suited to thinking like a programmer. When he points out a way to do something while I'm writing a program, it's often different than how I had planned to do it but never illogical. Sometimes his requests are easier, sometimes not, but either way I understand it. I also implement it as he suggests because he's a damn fine programmer.
Now when it comes to systems analysis, I can give better methods to get results than he can. I can pinpoint errors quickly because that's what I do. What I do all the time is more methodical than pragmatic, but I do write programs to help the methods.
All of that out of the way, given time we could probably end up switching roles. We are both intelligent, and understand what each other comes up with (even if it was not our first thought).
My way of looking at it is this. As we gain knowledge we store knowledge for later access, but only so much can be in the foreground at any given time. The more we have in the background, the easier we can sort and make sense of new information. But our immediate access is only what's in the foreground. We have to shuffle things in and out to change that, and it does take a bit of time. The more we have, the better we are of course. The "Jack of all Trades is a Master of None" in my opinion is not necessarily true. The "Jack" in time can master anything that is true knowledge (understood learning, not rote learning), but not all at the same time.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
So skill? Talent?...
Neither. It's H1B visas.
Yes, it really is that bad.
Agreed.
Questions raise, answers kill. Raise questions to stay alive.
Skill is simply developed talent. The question is: which is worth more: mediocre talent, well developed, or great talent, indifferently developed? Tough choice that, I'd tend to take a pass on both.
Great talent better be coupled with great motivation or the result will be just be yet another great talent waiting on tables.
When all you have is a hammer, every problem starts to look like a thumb.
but most fall into one category or another
In my experience, most software developers fall into neither category. The vast majority are un-skilled, un-talented plodders. When you come across one who is either skilled or talented you should cherish them.
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?
Comment removed based on user account deletion
though i am gonna loose all my moderation done in this post... i wholeheartedly agrees with you.
talent can get you upto speed, skill means you are already upto speed. next just boils down to how much time(+resources) can be provided in a project. if project is in design phase or already in maintenance mode with few devs working for new requirements, (i personally) will search for talent. but if something needs be solved within 2 hours and my sysadmin is on vacation, i better get some skilled person!
again as in posts above, there are ideas guys/ gals, quick troubleshooters, people who understand business or users and they do also have their own use in their own time.
everyone downmodding this post will be prosecuted for reading my post without first buying a license!!!
It isn't art or science, it's engineering. It is different from both, and requires proficiency in both approcahes to problem solving.
Korma: Good
If ever asked "How many lines of code do you write a week?" The only possible correct answer is "As few as possible".
I Don't Work Here
I rather be lucky than good. Skill will carry you pretty far but in extreme situations talent will propel you much further as skill takes time to acquire.
Raw talent is a component of skill. Without talent, skill is limited. Period. The fact the he thinks he's seen skill without talent, just means he doesn't understand the subject matter well enough to be talking about this.
You need to build a team that has both types.
If you have a team of high level thinkers, but are incapable of delivering quality code on time, then that is not a win.
If you have a team of excellent developers, but can't design worth crap, then that is not a win.
You are NEVER going to build a team of people that are both types.
To suggest one type is better than the other is plain wrong, you need both.
So the answer is simple. You need a good manager who understands this and can blend a team together to make both types work at their highest level.
Unfortunately good managers are in very short supply.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Not sure why you're modded down. It's succinct and addresses the problem with the original question, that neither is better or prefered, both are required functions of a good IT team.
I haven't thought of anything clever to put here, but then again most of you haven't either.
The whole concept of x AM - y PM is wrong when it comes to IT. IT calls for flexible work schedules (unless one is doing pure development work) and IT professionals should be given the flexibility to choose deliverable deadlines and left to their own devises, accountable for their promised work. I have found that in organizations that focus on end results as opposed to strict work schedules, IT is far more successful, because such environments tend to nurture innovation and talent. Another thing is to encourage lateral thinking (out of the box) and problem solving skills. It is amazing how quickly even an "average" skill level can turn into high-level, when provided with the opportunities and the freedom to think.
Most enterprise-level organizations don't allow that of their employees (at least most of those that are IT user as opposed to IT creators). The employees then, with the lack of freedom then become drones who regurgitate mindless, automaton-like work year on end.
IT is an intellectual profession and IT professionals should be encouraged and nurtured to be thinkers, philosophers even. They should be given an environment where they can question every decision, know every reason why a decision was made and how their work affects the bottom-line for their organizations' business. That's when a narrow focused, unimaginative IT professional can start developing and exhibiting real talent and develop real skill.
There's no indication in TFS what the definitions of "skilled" and "talented" are. The examples presented look to me to be two different people who are each good at their jobs, with no indication why they are different. (And with it being from infoworld, I'm not going to RTFA.) But there are some other posters who have proposed distinctions, which I will comment about:
Innate thought processes.
Acquired knowledge.
And I will add a third - dedication or drive.
The first can be thought of as "intuition." I've encountered it when my thought process matched somebody else's. There have been times when I've had to work with a new bit of software I wasn't familiar with, and when trying to figure out something I'd think "Where would I put function X if I was writing this?" and I'd go look there and find what I was looking for. It's also worked against me - I've encountered software which worked completely different from how I would have done it, and it's very difficult for me to deal with it.
There's also an aspect of natural intelligence here, which I won't get in to much. Creativity, ability to learn, ability to make logical connections, etc.
And something often called "genius" which to me is the ability to make illogical connections that are nevertheless correct.
Then there's skillset. Intuition and intelligence can help, but won't get you very far if you don't know the syntax of something, or the capabilities of something... You can't say to yourself "If I was designing C++, how would I do it?" and then expect to produce bug free code that compiles under gcc based off your thoughts.
Finally, there's just how much effort you're willing to put into your work.
IMO, the first and third items are equally important - you can't get results without them, and I don't think they're easy to acquire through learning - but the second is of lesser importance because somebody well endowed in the first and third should be able to pick up the info needed for the second.
It can be a challenge, however, to judge somebody's innate thought processes and dedication to work during an interview. Much easier to ask fact based questions.
Talent *or* skill? I don't think so. I'll be modest and not mention myself... but I've certainly known a good number of folks, personally, who had both. First example that's known to all, my old friendly aquaintance (and political foe), ESR.
mark
Given his definitions of Skill and Talent, Skill can be farmed and scaled. Talent cannot. Talent wins. You cannot make up for a deficiency in Talent with a large outlay of cash alone. With Skill you can.
"Love heals scars love left." -- Henry Rollins
Yep, it's the reason I write docs and give brown-bag seminars at work. Plus my standard reply to folks who ask me how to do something is to check the wiki. If it's not in the wiki, let me know and I'll add it or make it easier to find. Then point them to the wiki. If it isn't helpful, tell me and I'll fix it and _then_ check the wiki. It ensures the wiki documentation is always up to date since I don't answer questions directly (well, if it's a short one) and the others on the team aren't afraid to make updates as necessary if they do find an error.
[John]
Shit better not happen!
those who divide people into two kinds, and those who don't
If you post it, they will read.
Skills don't show up by magic; they're something you learn. You need both talent and practice to get them, and if you've got less talent you generally need more practice (or better teaching materials to practice with.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I think you all make good points. If it ain't broke don't fix it is often a good idea. Sometimes not. I didn't specify why I deleted the code.
So true that someone else probably already did it and you can get the code on the Internet. I'm replacing a lot of over complicated and therefore unreliable code with GPL code it's been well tested (including unit testing).
Of course there's a lot of crap code posted on forums, places like stack exchange. Sadly , the comments section of the PHP documentation is full of really bad code. Perhaps because PHP is TOO easy to use - you can make it appear to work without having a clue what you're doing.
Lengthy functions that compile without a whimper? Talented, good programmers don't write lengthy functions. Instantly vsualize with extreme detail? I've seen that type. Someone usually ends up rewriting their spaghetti and sausage code. This article is shallow nonsense.
Ask "either - or" ?
What was the usual answer to a multiple choice question when you were in school?
"D: All of the above."
Excellent! I like this. I might go for Donald, though.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain