The first kind learns and learns deep. They are spooky good at it. They'll latch on to something and then follow it all the way down to its roots, learning it in tremendous depth to the point that their skill in it seems almost supernatural. After all of this, they say to themselves "now what can I build with this?" (Or find a place where an employer tells them this).
The second kind decides what they want to build up front and then pursues wide and varied avenues of technology on the path to this destination. They often have fascinating slivers of depth in certain areas but lack that magical seeming deep domain knowledge. These are the people more likely to identify as "self taught" with all of the downsides that come with that. They make up for this with ridiculous determination and a kind of sixth sense for what is possible if you try hard enough. Everything they know, they learn on the path to the destination.
Both can accomplish amazing things. You'll never hire one of the second kind. The second just isn't going to be able to show you pointer arithmetic on your whiteboard in your pet language.
For instance, one of my good friends is one of the smartest programmers I have ever met. I've been bothering him to come down to our hackerspace (shameless plug: http://heatsynclabs.org) for YEARS, and he recently started obliging.
I came in one day and saw him sitting at a workbench hovering over a microscope.
Me: "Hey, Trav, what are you doing?"
Him: "Sharpening knives."
---
Ah, yes, of course. Because most people who want to sharpen a knife head down to the lab with a bottle of aluminum oxide because they want to use the microscope.
In the month since then, he has become an encyclopedia of knives. Every material, every manufacturer, every sharpening technique. I was at his house the other day picking him up for a road trip to Colorado, and his workshop is filled with sharpening stones (and rods) and different knives. On the ~9hr drive to CO, we went back and forth, me soaking up seemingly everything I could about knives.
Next month he's going to present at our little Tedx style event at the lab. (Members present on a topic they're knowledgable about).
But this obsessive learning technique isn't limited to knives. Back when we were roomates, he decided that he wanted to build a stepper motor controller, and I don't mean "assemble the kit from adafruit". He wanted to build a controller for the type of ultra-high-performance DC stepper motors found in hobby airplanes and helicopters because he wanted to build a quadcopter, but didn't want to use somebody else's electronics design. I spent that summer learning, by proxy, about control theory, what is back EMF, what do "closed loop" and "open loop" mean? How do motor controllers work, and why?
--
Examples of my friend aside, I think that your #2 is enabled by the traits that make up your #1, or that they can at least feedback into each other. You get the super broad domain knowledge because you've gone really, really deep into a few subjects, and can intuit most of the rest of the domain because of it.
I am multilingual, an autodidact and I love programming. I also have a gift (your 6th sense) for engineering in that I am able to visualize and analyze machines/systems by glancing over the designs or watching them work. Combined with soft skills and programming experience this has proven of great value in industrial settings where I am able to relate and connect the mechanical, software and other engineering departments.
A couple of years back I started working at a start-up doing robotics and machine vision. Due to lack of time and personal I had to teach myself everything from inverse kinematics, path planning to a solid knowledge of 2D and 3D machine vision. In less than a year I was developing and integrating 3D vision systems and steering industrial robots. Only after delivering that first project on my own did I allow myself to internalize my accomplishments.
I might not have a formal engineering degree, but being a jack of all trades has proven to be a high value asset. It's about finding an environment where your (broad) skills pay off.
Generalizations as the one above make it harder for people like me to start a career as I very much belong to the second group.
Also, I can show you pointer arithmetic in my pet language.
Maybe you won't hire the 2nd kind (as you say). Doesn't mean someone else will see the value in such background. Though there is an implicit message in your post. That all college trained programmers are the same. Which is downright wrong, due to there being a lot of different types of programmers. There are people who I wouldn't let near a database, but can really write some awesome C++. Or those who are awesome at writing web crawlers, but suck at making effective CRUD apps. Or maybe that guy who is a genius at VB.NET, and carries the weight of a whole company on his back (maybe he taught himself). You wouldn't hire those? Then you wouldn't hire yourself.
I am a college trained programmer, but I do identify strongly as the second type. When I really think about it, I'm forced to admit that if I was in charge of a large company's HR policy, that policy would probably prevent hiring someone like me for all but the most junior of positions.
A smaller company might have a lot more freedom in this regard. "You'll never hire one of the second kind" might better have been said as "big companies never hire the second kind".
I'm curious about why you say "You'll never hire one of the second kind"?
How does one of the second kind fit into the world as an employed developer? This is something I'm struggling with currently.
There are some positions where this obviously does work in your favour, but in general, you can be a junior in a bunch of jobs rather than a senior in one.
tl;dr: A Google-like company would not have hired (someone like) Woz.
(1) Its double-hard because there are no shortage of people with tenacity who have the knack for doing things in a terrible way over and over. They all think they're in the former category.
Yes, the punk band. Those misbehaving misfits that couldn't play their musical instruments and yet went on to change music forever.
The Sex Pistols succeeded with barely a shred of skill or talent because they were on a mission and executed it with ferocity.
No talent is required to make a difference. Just piss and vinegar and a grand vision. The Sex Pistols prove it.
This is assuming one accepts your definition of talent. Is it true that they had no talent? If they couldn't play their instruments, sing, or write lyrics, why did anyone listen to them? There had to be something there. If anything I might say it requires substantially more talent to overcome an utter lack of skill in order to excel.
Also, all else being equal, additional skill or talent won't hurt.
Bottom line: the stories you hear about people who go from nothing to incredible success are outliers. I think determination is absolutely underestimated relative to raw talent, but that determination should be leveraged in service of developing skill and/or harnessing talent, not in lieu of skill or talent.
The Sex Pistols were really the creation of their manager Malcolm McClaren. Which really is kind of apt, because if you don't cultivate your talents, your successes all depend on someone or something else.
Piss and vinegar definitely helps though.
I work at a newspaper and since I've been here (8 years now, I'm 28) I have learned some skills:
* Advertising Design(Print and Online Ads) * Layout Design * HTML * CSS * Some JS * PHP * mysql * Currently teaching myself Python * Online Advertising (Booking Campaigns)
I know how to do a lot, I just don't feel like I'm good at any of it. This is where I feel Jack of all trades (master of none) is an insult rather than a compliment.
Like the author I feel that if I apply somewhere else my skill level might not be up to par. It really is frustrating.
And yet, why would we need to be "Master" of anything?
One thing struck me in Hery's post: He did things. He accomplished. And many of these things he seemed to enjoy doing. How many of us here, with our fancy degrees and self-taught knowledge have lots of projects "on the side", always thinking "I'll do it when I got time" but never actually DOING anything? Like kids in front of a box full of LEGO, rummaging through the pieces, putting two of them together then going through it again,... In this age full of distractions (let's look at your reddit karma again, and are you sure your inbox is empty? maybe someone tweeted something interesting in the last five minutes), the value of your knowledge ain't "jack", your value as a developer lies in what you can accomplish.
Don't mind the bullshit job offers asking your for "ten years in java, 20 years in ruby and 50 years in BASIC (knowledge of COBOL a plus)", most companies would KILL to have someone as devoted (and versatile) as you.
Keep on!
Bundler, gem, pip, npm, blah blah blah. It's a lot of stuff to grok if you want to get anything done in the 'right' way.
Of course, even with such brief bursts of effort, you can "relearn" quickly by consulting various references and refreshing your memory, but it becomes difficult and scary to imagine what life would be like if we couldn't look up whatever we needed.
It'd be scary to work out math problems without pen and paper. It'd be scary to cross over the amazon without an airplane. Applies to every tool you use.
I'd like to think of Google as my secondary memory (HDD?). All I seem to have is RAM.
1. dabble in everything and master nothing
OR
2. Specialize in one thing and never touch anything else again.
There's a bit of a middle ground. Have one (or two, or three) things you specialize in and develop great depth, coupled with a tremendous breadth of general knowledge of related things.
You could strive to be a "generalizing specialist" as they say[1] or a person with "t-shaped skills"[2].
"T people" are very highly valued, in at least some contexts[3].
[1]: http://www.agilemodeling.com/essays/generalizingSpecialists....
[2]: http://en.wikipedia.org/wiki/T-shaped_skills
[3]: http://chiefexecutive.net/ideo-ceo-tim-brown-t-shaped-stars-...
Of course, this doesn't mean I think programmers shouldn't use Google or Stack Overflow, I use them all the time. However, the specifics of what you're Googling matter a lot. If asked to implement a Red-Black Tree and you have to Google that to get an idea of what it is (or to refresh your memory) that's one thing, but if you have to Google basic loops or "FizzBuzz level" basic discreet logic constructs to implement simple code, then that's a huge problem.
AI and Machine Learning are very interesting fields, but you need a deeper understanding of CS than you do for mobile/web development. Just out of curiosity, are you familiar with what a state-space search is, and the difference between breadth-first and depth-first?
edit: FYI, I'm also C.S. major graduating this semester. I consider my interests to lie in AI and ML as well. I've not had any trouble with technical interview questions.
Take some version of those classes (maybe OCW, edX, or Coursera) and you will be good to go — at least for technical interviews. If you like reading then Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein is the book that these courses cover.
Try this experiment: ask someone in school who just finished a hard-sounding class (that you haven't taken yet) to interview you based on knowing answers to things they learned in class. It should sound mostly greek to you. From your perspective, you don't stand a chance of knowing the answers. But, now you know that the delta between not knowing and knowing is one semester, or if you're brilliant, two nights of cramming.
My point is, there is very little delta in what is required to prepare for an interview and what is required to prepare for year-end exams in any given subject. You don't need a lifelong working knowledge of theory. You need enough immediate knowledge of algorithms to get you past the meat-grinder. Remember how you crammed in college? You can get by most of the time by cramming hard for the interview. Also, you get partial credit for thinking out loud about the answers you're considering giving, if you're anywhere within a mile of the correct answer, the interviewers will likely give you a passing grade on the question.
Once you're inside, most of those challenging questions, well, they'll likely never come up again. Just like the stuff you "learn" in college.
Source: In my previous life, I was part of a team of developers who interviewed people for technical positions. We were mean, ruthless interviewers. I've also been through the meat-grinder myself a few times.
I'll admit I'm a little confused, as my entry-level interviews never involved any questions about language or API trivia. If I had to write code, I could do it in any language I wanted and was comfortable with. And sometimes I wouldn't even have to write code, just discuss a problem and potential approaches. The solutions would never depend on library-specific knowledge.
Then you were lucky. A lot of interviewers can't get that far.
This will fix the problem of having a wide range of hacker skills and a portfolio of projects but not being able to make it through a Google inspired interview.
There's probably a Coursera or OCW course that might help but the key is you have to actually do the exercises.
I've had an interview or two over the years in which I surely lost out due to my inability to rattle off some bit of trivia about one thing or another, but it's probably for the best.
1) If the job was really so narrow that such a specific, rote depth of knowledge mattered I'd probably find it terribly boring.
2) If the interviewer is willing to write me off based on canned questions without actually conversing with me - the place where I feel I shine. I probably don't want to work for/with him/her.
Yes, there are surely exceptions to this, it's not a hard and fast rule, but as I said above it has worked out fine for well over a decade now.
Lest anyone think this is unethical, do remember that the large majority of job postings are made by people who ask the impossible (a level of experience in new languages that basically make it accesible only the language developers) or the irrelevant. Use your own criteria to determine when this makes sense.
In short, I think you're doing it right and will end up better off than someone who focused on one language because that's what companies appeared to want.
I have two suggestions:
Build an application in Clojure and in C/C++. IMO you should try a functional language (doesn't have to be clojure) and a lower level language. It could be a clojure webapp and a C++ opengl game... doesn't matter.
Here's something to get you started: http://nehe.gamedev.net/tutorial/lessons_01__05/22004/
I wouldn't worry about specializing just yet, just keep doing what you're doing, just up your difficulty level. Already you've done more than 50% of the programmers in the market (most know one language, like Java or C#).
Much of my education was from a "get cool shit done" perspective, and I did. I had solid projects in an array (no pun intended) of languages but lacked some of the true, lower-level knowledge as a foundation.
Your mileage may vary, of course, but if I could start my CS education over again, that would be my advice to... myself..
When a company is hiring, would they rather hire someone who can get by or a fluent speaker?
I think there is certainly a breath and depth balance to be had and I think you are correct in seeking more depth. A deep understanding of one language will allow you to more quickly gain depth in other languages.
And have fun!
It is really tough to strike a balance.
http://alexkrupp.typepad.com/sensemaking/2012/09/program-abo...
