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.
Assuming Venezia is correct, which do you think is more important?
Whichever one I've got, with justification to follow.
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 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.
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!"
Except in modern practice, 'coder' is a monkey who took an 8 week Khan Academy course in Java, while an 'architect' is a guy who knows powerpoint. Most frequently observed alongside 'managers' whose skillset includes Outlook, and 'the rest of the employees' who watch as their companies fold/outsource anything important.
I want to delete my account but Slashdot doesn't allow it.
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.
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...