Personally I think it's pretty easy to make the opposite argument. If you work on open source software in your spare time you have a chance to work with a wider pool of more talented engineers in a more collaborative environment and wider ecosystem of software than exists in any single company. Many programming jobs by comparison involve either menial CRUD-style work, or working for years on end on some specific component that does not convey much general-purpose knowledge.

Now, if you aren't the kind of guy that is motivated to work on your own then certainly a business environment will be invaluable, however I reject the idea that corporate programming somehow inherently teaches you more than you can learn on your own.

And I work at an investment bank. So I am not sure that this article has any basis in reality. When I interview people, the candidates that are self-taught seem to have the most experience and interest in the job. This almost always makes them an instant "yes".

But I don't really see people like this for very long; 90% of the people I interview are just "lifers" that move from job to job in the financial sector every 6 months. Their recruiters make them lie on their resume, and it comes out in the interviews and makes them look like horrible people. Instead of being self-taught, they simply don't know anything about programming. ("Your resume said you designed your own processor to process network traffic faster. What was your role on this project?" "Oh, uh, well, I uh, got some coffee for the dev team.")

To the contrary, banks are dealing with the established business models and are rarely tolerating even short-term decreases in the added value that every person brings to the company. They hire people to earn money for the bank, not to experiment, and they pay those people accordingly.

So untrue. I work at the biggest investment bank in the country, and this is just not true. Did I mention that this is not true? Not true. Oh so untrue.

Do banks want to decrease their added value? Nope. Do they have a desire to hire 300,000 employees? Yup. And guess what, there aren't that many good programmers in the world. Problem.

Prop shops might be more careful, but banks hire pretty much anyone and everyone and give them a lot of money. It's a big company thing. Do you have buzzwords on your resume? Congratulations, you're in. And you should see the code that this process produces! (My department doesn't do this, but it's clear that most of the other ones do.)

That is, unless they interview at an organization that is much more interested in finding compatible personality for their culture than they are in the person's ability. These organizations exist; I worked for one a year or two back. The candidate I was interviewing as part of a panel had not been asked a coding question to that point, and she was already quite far along in the interview process -- the next step after the panel interview was an offer. No one else really cared; they just wanted someone who would increase headcount while not disrupting the culture and structure of the organization.

So, the people who answer this way, they're just playing a numbers game. They keep going on interviews until they hit an organization like I describe above; at that point, all they need to be hired is to just be agreeable.

Also, most people have figured out how to trial-and-error tweaking existing code. Blank editor window? Nothing. Modifying a bunch of existing code that renders a web page? Surprisingly able.

Try being part of the interview process sometimes; you'll have lots of fun :)

For this particular job configuring routers was not a primary task, but because I had a passing knowledge of Cisco routers I asked a couple of questions since he had brought it up. After 2-3 questions which the candidate couldn't answer, he finally admitted that his experience in 'configuring' Cisco routers consisted of plugging the network cables into the port at the back.

We just live with the connotations of the term, "hack."

Here I was expecting to refute the OP, but instead I am left disappointed. He is not some academic elitist guffawing at the plebeians attempting to build their own ivory towers. Instead he is a corporate lifer making some inane red-herring argument. What he's really suggesting is that you cannot teach yourself anything. I find that notion particularly banal.

This is the real problem then, isn't it.

External pressure is not the only thing that can exert the necessary motivation to learn new things. But the crux of his argument seems to be that you have to have these external motivators, otherwise you'll never be any good at what you are learning.

I suppose the argument could be made that if you don't have external pressures, you won't learn whatever you are studying well enough. This argument seems specious to me. I've heard plenty of stories which validates against my own more limited experience with people who are motivated to learning by extrinsic motivations; on the level, they just aren't as good, because the extrinsic motivation ends the instant you can convince someone else you are good enough. From there, you only have to convince yourself you are good enough, and the thresholds for this vary a lot. Having the intrinsic motivation to go beyond what others expect I could only see having an additive effect on one's ability.

Or perhaps I am just making an attempt to validate my own intrinsic motivation to learn stuff in spite of a relative absence of external pressure. I can't help but think this author is attempting to validate the converse of that.

Or maybe I'm missing the point. Maybe if I want a position at a bank being held to this sort of standard, then I don't really have to worry about teaching myself new things and I can survive without a motivation above and beyond getting paid. I don't know that I'd be so sycophantic toward that culture, though, if that is all that is expected of me. I certainly wouldn't go so far as to write an article claiming it is a waste of my time.

One other point:

First of all, banks are always a good indicator of the position’s value in business terms.

How true is this? He seems to take the stance that banks are pretty much infallible when it comes to assigning proper value to individuals; the folklore I am exposed to here and elsewhere suggests this isn't anywhere near true.

It seems rather odd, also, that he asserts that banks will fire people who have even short-term decreases in added value. This seems really foolish; value generation varies over time. I don't understand how organizations with such a intricate grasp of value production could miss this. That is, unless they don't have that grasp he claims they do.

This seems like over-the-top smuggery. While I don't agree with a lot of the author's remarks, I certainly feel his pain and empathize with the idea that noodling or other aimless, low-motivation and low-direction play does not lead to the kind of expertise that will get you hired by the kind of people who use Haskell/F# to make money.

But this kind of remark seems wildly baseless. Is he postulating that if we find a bank using J2EE or Rails that you can get hired based on a few chapters of reading and a web site? This is not consistent with the rest of the article.

What I take away from the article is that he believes banks are very demanding, not that Haskell/F# is very demanding. In which case, if he finds himself at a J2EE bank, he's going to be discussing the kinds of things I recall working with in one of the world's biggest banks: the behaviour of transaction queueing systems, type erasure and its effects on reflection in the presence of certain generics, subtle considerations when using JDBC and Oracle, or whatever is now the kind of thing J2EE people lose sleep over (my knowledge is out of date, the things I mentioned may now be passé).

This seems like over-the-top smuggery."

That's probably because he didn't say it.

I did (I don't know if you noticed he was linking to a separate page, and if so you followed the link), a long time ago, in a blog post. And of course the context was different.

Here is the original post from which that sentence was extracted. Hopefully it makes more sense in context.

-------------------------------------------------------

"To "learn AI" <---- title of the blog post.

first learn basic mathematics.

I keep getting asked this question and I keep saying the same thing - to three people in the last week, for e.g, two of whom were working through (or planning to work through) AIMA - so I thought I'd put this down here (and point anyone who asks the same question to this entry in the future).

Learning AI (or any deep comp.sci for that matter) is not like learning J2EE or ruby "dsl"s or whatever the fad du jour in the enterprise software world is - read a few chapters of the latest bestselling "pragmatic" book, write some crappy web site and hey presto you are the expert.

"Real" comp sci doesn't quite work like that.

To really understand a standard 3 layer feed forward neural network, for example, you need to have a solid grip on

    * vector spaces
    * basis vectors and change of bases
    * eigen vectors and eigen values
    * Basic matrix operations like inversion
    * multi dimensional performance surfaces
    * Quadratic functions and finding their global maxima within Newton's method and Conjugate gradients
    * performance measures and steepest descent
    * partial differentiation of vector values
    * numerical stability of algorithms

And, a feed forward neural network is only one type of pattern recognizer (or function approximator). There are many more, each with its own trade offs , and you have to know the math to make the trade offs.

That being said, the best book to start with is AIMA as long as you (1) learn the required math parallely (2) do all the exercises at the end of every chapter.(I can't emphasize this enough). Reading through != "working through".

If one is willing to work hard, there are very few fields as fascinating as the various branches of AI.

Once you start down the rabbit hole, however it may be very hard to continue writing all that heavy lifting enterprise software without hearing the giant sucking sound of your life going down the drain as you write yet another jsp page for the latest leasing system. ;-)

Be warned! :-D.

Anyway the really hard part of "learning AI" is not getting the books or working through them systematically (which is hard enough), but that is for another blog entry.

Post Script - Some book recommendations for beginners.

   1. Linear Algebra by Gilbert Strang
   2. Calculus by Gilbert Strang
   3. Artificial Intelligence A Modern Approach By Russell and Norvig
   4. Machine Learning By Tom Mitchell
   5. Neural Networks for Pattern Recognition by Chris Bishop
   6. Paradigms of Artificial Intelligence Programming by Peter Norvig (ok, this one is not quite an cutting edge AI book, but imo this is the best book on programming ever written and if you call yourself a programmer you should have it on your book shelf)

_______________________________________________________

Hopefully that wasn't too much "over the top smuggery" :-). (Not that I care if it is, I write stuff on my blog to clear my head, not be popular).

This was written as answer to my ex-colleagues from the world of enterprise software who asked for advice on "How to move into AI Dev and do interesting projects like you do" and the "leasing system " and "heavy lifting" "read some book and become the (local) expert" etc references make sense to the people (from ThoughtWorks) who asked me the question.

I am not sure how anything I said fits into this Java-bank-interview vs Haskell-bank-interview discussion.

Fwiw I am entirely self taught and was addressing other self learners in that blog post, so I am not sure how the author uses my opinion to buttress his thesis that "self learning is overrated". If anything I believe it is underrated.

jrockway said it best above,

" I've learned everything I know about programming on my own -- reading other people's code, and trying their techniques for myself. "

Amen.

All I can say is that when I quote other people to support my argument, people assume I support the words I am quoting unless I explicitly argue with them. He(?) quoted them, I'm ok with questioning them in the context of the rest of his post.

I disagree with the premise that reading a few chapters of a book and writing a crappy web site makes you an expert on anything, AI, DSLs, Ruby, whatever. Those are the words I took issue with. If you write for clarity rather than popularity (as I do), then I withdraw the suggestion of smuggery and suggest instead that those specific words are simply wrong. If you want to stand by them, that's your privilege, we can agree to disagree.

I agree with your statement I am not sure how anything I said fits into this Java-bank-interview vs Haskell-bank-interview discussion. I'm not sure either.

The author seems to confuse self-learning with learning only the theory.

The real title should be: "Theory without practice is overrated".

And when you word it this way, it's hardly anything surprising.

It's not even that. His assertion seems to be that practice outside of a sufficiently business-like environment doesn't count, because you won't be compelled to focus all of your time and energy on just those things that bring a positive change in rate of value production now. It's a dangerous game to play, but a desirable one moment-to-moment in an environment that severely dislikes disruptive ideas -- the thing that learning for something other than instant gratification is bound to cause.

The point is not that schooling sucks, but that it isn't guaranteed, either.

As others have noted, what made me successful wasn't that I avoided the classroom. It was that my way of teaching myself was to actually program things. It gives the experience you need to lock in the knowledge you're gaining.

Well, yeah.

When I see them claiming experience with any of the "cool" technologies, I usually throw them a couple questions related to Haskell[1], ocaml, Erlang, Lisp, 6502 assembly, etc. If they flub that area without acknowledging that it was a toy project, I'll know they are probably lying someone else. I'll be a lot more aggressive zoning in on the design and implementation of their most recent project. If they're soft, where I might normally give a little room for "nervous at interviews," they're pretty much done.

However, if they nail it, I know we're going to be able to work well together. Especially so if they get excited that someone is asking them about something...that...they'll...never...get...to...work...with...in...our...boring...IT...department.

sigh

[1] This one is almost too easy. "I hear these 'monad' things are really tough. What are they about?"

If you want to become strong enough to leverage yourself into a Haskell job, stop writing in anything but Haskell for non-production-work tasks. All your shell scripts--Haskell. All your recreational coding--Haskell. Picture yourself in a Shao Lin temple of Haskell.

Also, think about the flip side of your question. Haskell is a pain in the ass for the first few months. If you haven't climbed a substantial part of the learning curve by the time you interview, you might discover that you hate it[1]. Part of the interview process is not just seeing if you can do the job, but that you'll stick around for at least a year and not quit because you don't like the environment.

I normally wouldn't worry about someone trying to make a transition from Java to C#, but I would worry about someone trying Java -> Haskell without having broken through the "difficult" parts.

[1] There's a lot to hate. Imagine, on the flip side, if you had to program in RPG II. You'd want out as soon as you realized you made a mistake. Admittedly, RPG of any flavor doesn't sound sexy, but you get the idea.

So true!! It doesn't matter how much you read/experiment with distributed computing (or any advanced field). How many simulations you are running or papers you're reading on the subject.

The only reason I'd sacrifice personal freedom to work for a big company is not money but resources/environment. They have data, millions of users, hundreds of computers and the kind of challenge that will simply push you and make you better at what you do.

It kinda sucks in a way because unlike ECE or any "regular engineering", you don't need money/resources to do cool things in software. Unfortunately, I'm starting to realize that's not entirely true. As soon as you start playing with intense computing, you need $$$

That's really the only reason to work for a big company if you are _only_ passionate about software --> Data, resources, work environment.

Also, when people use the word "real" in a gratuitous way - such as "real" industry, "real" work, "real" programmer, etc - it always makes me suspicious that they don't know what they're talking about and are attempting to needlessly inject gravitas into their statements.