[dustingetz]

i totally understand and respect your position and that's definitely a strategy that can work.

The other end of the spectrum is, you could contract someone like Tony Morris[1] at $250 an hour for 20 hours a week, and he will build your product faster than a team of untrained engineers, or more likely, build a product that untrained engineers aren't capable of building, with a defect rate close to zero.

Not every strategy is right for every business, but generally, the harder the technical challenges, the more cost effective it is to pay for a superstar.

[1] http://tmorris.net/posts.html

[oblique63]

Yeah, but I think the over-arching idea that the OP was getting at, was "what if we can breed these 'superstars'?"

That would certainly seem feasible if you interview for personality traits, interests and learning skills, more than actual/concrete knowledge and working skills. And of course, this would be a lot more cost-effective as well. In that case, I would say that the key would lie in paying more attention to human psychology/intelligence research than to tech blogs/circles to find out more about 'superstars'.

[btilly]

To a point that is possible. However there are key lessons that don't really sink in until after you have made certain mistakes and have seen the consequences. For instance I understood the value of forcing variable declarations, and of having multiple layers of safeguards after a typo in a variable name caused me to take down Bloomberg's ftp server about 15 years ago.

Judging from ability and personality, it was clear at that point that I had potential. And I received some excellent mentoring. But potential and mentoring do not ensure a smooth path to success.

[oblique63]

While that's true, it still seems a bit orthogonal to the point, because the argument being made is essentially about efficiency, not necessarily effectiveness. If we think about all the people that have had such experience changing epiphanies, then take the subset of those who might actually be able to communicate these valuable experiences across in a programming interview, suddenly your selection pool becomes rather small. Which is oddly reminiscent of the current 'talent shortage' issue. Thus, approaching the problem from a different angle which considers this concept of 'experience' to be more of a byproduct of a certain set of traits than a trait itself, you suddenly open up your list of possible candidates to something a lot more workable.

Because after all, there is nothing preventing people selected for personality traits to reach these same epiphanies that 'experienced' people have (regardless of mentorship), it's just a matter of whether or not you as an employer would be willing to accept this 'risk'. Given the current state of affairs with regards to 'talent', I could see many finding the risk permissible. Not to mention the fact that the set of 'smart people with potential' is not mutually exclusive with the set of 'smart people with experience'; of course, selecting purely from the set of people that meet both criteria would still fall under the realm of chasing unicorns, but the point is that the two are not exclusive.

[btilly]

The point that was made was that smart people with potential are cheaper to hire and easy to train. My point is that smart people with potential and training are great, but aren't actually as good as smart people with potential and experience.

The trick is, of course, that smart people with both potential and experience tend to be easy to identify..and very expensive.

[oblique63]

Well yes, but the fact that they are expensive is a byproduct of their rarity (which results in us talking about cheaper engineers), and that can be symptomatic of a system with an efficiency problem. The argument then is about confirming that it is.

[btilly]

Expensive, yes. But expensive compared to value produced?

Every decent programmer has stories of a time they put in 10 hours of work to save a highly paid person 20 hours/month for the rest of time. I say stories because there are many such. On my resume I list a number of cases where I added X millions/year to the bottom line of small-medium companies. It is not a complete list. What value should an efficient market put on a programmer who does that repeatedly?

For those willing to work as an employee in the Los Angeles area, the value the market places is significantly under $200k/year. Now you tell me, is that expensive relative to value?

[mbillie1]

> That would certainly seem feasible if you interview for personality traits, interests and learning skills, more than actual/concrete knowledge and working skills.

That's a good chunk of the way we (ThoughtWorks) interview, along with general smarts and good company fit. It's easier to teach a very smart person [language x, skillset y] than it is to teach a random person who knows [language x, skillset y] how to be very smart.

[porker]

> And of course, this would be a lot more cost-effective as well

Only if you can retain them, once they get smart and realise how good they are. Gratitude (and staying with the company who invested in you) aren't popular these days.

[virtualwhys]

You mean the guy that one could argue is solely responsible for the Code of Conduct header on every TypeSafe affiliated Google Group?

Yah, that guy. Sure, for $250/hour he's probably fairly amicable.

He's categorically brilliant (in FP implemented Scala, certainly), but good luck grokking his mile long type signatures when he's gone from the project.

Saying that, if part of his consultancy is to train the team in FP and explain his code, then there is "real" value in the hiring; otherwise, where would you know to begin when updating the system down the road?

[jcampbell1]

> with a defect rate close to zero.

Most of our defects are not software defects, they are product/marketing/strategy/SEO/SEM defects.

If American Express wants to launch some app with defined features, then Tony sounds like a great guy. We kinda understand our customers, but not really. We throw pasta at the wall and see if it sticks. Once it sticks, I can hire Tony to make it great. Tony will never accept us as a client for good reason.

[kamaal]

I don't have decades of programming experience. But with whatever limited experience I have I can tell you. Especially with software knowing what to do is the most difficult part, doing it isn't even a problem.

A product is ultimately a discovery which you have to do in iterations. It won't be until the last iterations you will know what to do. Once things are clear you don't a rock start to get things done, any one can do it now. Rock stars are needed speedup those iterations, do the discovery super fast and get the clarity.

[terenceong]

i might be missing something but is tony morris someone who is famous for being really good at programming or something? i googled him and couldn't find anything concrete, and yet you and the guy you replied to seems to already know who this guy is and have some kind of assumption about his abilities. i'm sincerely asking.

[virtualwhys]

Tony Morris is more infamous than famous.

In Haskell he's nobody special; however, in Scala he's known as one of originators of Scalaz, and has made contributions to the development of the Scala language itself. TM is very strong in category theory and has no problem speaking categorically about the correctness of his views.

He's a polarizing figure in the Scala community and seems to enjoy pissing people off (again, the code of conduct banners seen on Scala Google groups can be by and large attributed to TM, which is an accomplishment, thus the infamous claim).

In TM's defense, as a teacher he does force the reader to stretch beyond their current (limited) understanding. If he came across as less of an a$$hole then he'd probably have a larger role in Scala and the programming world as a whole.