St. Petersburg paradox - <AUTHOR> http://en.wikipedia.org/wiki/St._Petersburg_paradox

<comment><USER2> I would pay a large sum of money to enter this - specifically, up to $0.50/expected iteration, minus electricity costs - if I were allowed to write a computer program to play for me.

That suggests that the real resolution to this paradox has something to do with transaction costs. I wouldn't pay more than a few bucks to play manually because I don't expect to have time to play more than a few times, so the low- probability high-payoff events will probably never happen. I would pay a lot more if I could automate it, because then my cost per round becomes negligible, and I can rely on pure math.

This may be why most normal people don't found startups (they don't expect to have enough chances for their lottery number to come up), and why quantitative hedge funds can trade profitably (they can take advantage of arbitrage opportunities that most investors overlook because transaction costs make it not worth their while).

</comment><comment><USER3> This is hardly a paradox anymore. It only appears to be one if you accept "maximize accepted utility" as the decision metric.

Maximizing expected utility is a pretty good decision metric, but it has problems. Specifically, it has huge problems in handling very-low-probability- very-high-payoff outcomes. Here's a simple example:

Game 1: You get $1.00

Game 2: 99.999% chance of getting nothing. 0.001% chance of getting $100,000.00

The expected payoff in each is the same but they are _clearly_ very different.

Note: I realize I'm equating money with utility here. Just doing it for simplicity, you can replace with whatever you want to get a utility of 1 and 100,000 respectively.

Note 2: You can argue that utility is bounded (say between 0 and 1). But I don't think this solves the problem.</comment>


Android - what a fad - <AUTHOR> http://nadathur.posterous.com/android-dolphins-and-bonkers

<comment><USER2> tl;dr Author didn't like his Android phone, therefore nobody will like their Android phone.</comment>


Moneyball teams - <AUTHOR> http://bg-blog.com/2017/04/21/moneyball-teams/ <comment><USER2> I wish I could triple like this! Hire the best is lazy thinking.

* I have been on teams that were not considered the best until they had success, then everyone on the team was a "star".

* I have worked places where they only hire "superstars"\-- and were pretty serious about paying for good talent and being picky-- and still failed for all kinds of organizational reasons. Teams with more role players, or more cohesion of goals would have performed better.

*I have seen people recommended because they worked at "X" or worked on the "X" project, and then turn out to be completely underwhelming. Great teams don't always only have great people, and sometimes the great team has people on it who are one promotion away being at their level of incompetence.

<comment><USER3> At a former (large, organizationally deficient) company, there was this small team of 5 people with very different specialties (and personalities). They were a "strike team" of sorts, tasked with helping out at a technical level different projects that were in trouble. They were excellent. They saved my team's integration of a camera co-processor in an SoC.

But finally a re-org came around and some high-level manager didn't have a box under which to put them (or didn't have the right budget item to fit them in), and the team was dissolved.

The guys were good in the teams they each landed in, but the synergy[1] was dead.

Nowadays, my primary criteria for joining a team is the quality of the people and of the manager. I wish I could say I've seen other teams of the quality of that first one.

[1] yeah I said it

<comment><USER4> One of my most enjoyable periods while working for someone else was at CapGemini when I was between teams and lent out to do short term fixes for teams where they didn't have enough developer resources/the right resources. Typically just a week or two to go in figure out what was going wrong and patch their systems then get swapped. I don't know if it was the change of pace or the fact that you kind of got to feel like an office superhero that I liked more but I was really young so probably equal parts both.

<comment><USER5> I had a similar stint helping teams with system performance issues. I think I found it so enjoyable for two reasons:

1) Solving the problems involved the focused exercising of all of my software dev knowledge – often around database access, sometimes around garbage collection and memory allocation of the specific platform.

2) The impact was highly visible and appreciated (by the team, management, and system users), and the result was usually objectively measurable, e.g., the global search now completes in 1/50th of the previous time.

That said, when I reflect on the 10 or so projects I helped in this time, they were all problems the senior dev(s) on the team could have figured out. So, it wasn't really that I was some rockstar who had special knowledge. It was more that I was given time to focus on the issues, while the regular devs on the team had bugs to fix, features to work on, etc.

Like you, I now work for myself, but if I were offered a job doing small- medium performance optimization projects (without travel), that would be tempting.

<comment><USER6> If there were one key benefit of consulting / being an internal developer at large it would be the ability to _leave_ after finishing a project.

Sometimes that's sad. (When the client / team is awesome)

But usually it means not having to deal with any of the worst parts of office politics. (E.g. de facto stack ranking, non-merit-based favoritism jockying, office management politics, dysfunctional management priorities, waiting for someone to die / retire for a promotion, etc)

</comment></comment></comment></comment></comment><comment><USER7> Another way to look at it is: What causes projects to succeed or fail?

I've seen my share of failed projects throughout my career (as a participant and as a co-worker watching it happen). By a huge margin, most of the failed project did not fail because the engineering team was weak, or because they didn't hire "rockstar" programmers, or because the engineers didn't go to Stanford. They failed because of things like requirements growth, unrealistic schedules, emotion-based/gut-based (rather than measurement-based) product decisions, and external factors (market changing and company couldn't react). If companies spent more time worrying about these things and less time worrying whether their engineering interview candidates can balance a binary tree on a whiteboard, we might see hiring practices change.

<comment><USER8> I agree with everything you've said so I won't add to it.

There is an interesting anecdote that I love. Some number of years ago there used to be a show called EcoChallenge. It was made by Marc Burnett but before Survivor. It was simply an adventure race but no politics and no contrived voting. Each team of 4 must be co-ed. There is a starting point, there is a stopping point and there are way stations along the way. Simply go from start to end hitting the way stations. Everything else was left up to the teams. The one big twist is that you can't win unless _ALL_ of the team hits each way point. Teams are allowed to race 24x7.

One of the last years it was on tv, a team of navy seals bombed out and a team of 3 playboy playmates went further then they did. The team that won (from NZ) had a sick teammate and spent two days nursing their teammate into passable health. They loaded up all that person's gear split 1.3x, 1.3x, 1.3x, 0x and set off. They rocketed past all of the other teams and won by over a day.

This is what real success looks like. A determined team laser focused on the _exact_ same goal and doing whatever it takes to get there.

<comment><USER9> A bit more on topic, I was asked to read a book on leadership and teamwork that's a bit of a cliche these days but Coach Wooden's Leadership Game Plan for Success covers a lot of these ideas specifically in a sports context. A lot of leadership texts revolve around sports out of sheer ubiquity in subject matter among business leaders culturally but beyond some pop sociology type of research I really don't pay much attention to them in a business setting. Why? In much of the world of software, day-to-day work is not a race against a competing team towards the exact same goal as much as it is a race against oneself and against market inertia whether that may be the default mode of failure or convergence to an equilibrium point that needs to be readjusted as the team discovers the hidden rules of a game.

In fact, a lot of business is probably a lot closer to something more sadistic and cruel in gross mechanics like from Takashi Miike's 2014 As the Gods Will (and the manga of the same) - arbitrary filters where the rules are very clear only until after people have died. Some stages test raw individual skills while others test cooperation. And in some cases it didn't actually matter if you had either of those because "luck" is the bigger factor (the fact few in practice agree upon these slack variables to achieving business success shows how random things are for survivorship moreso than controllable factors like skill and effort)

</comment></comment></comment><comment><USER10> One of my favorite movies, _Miracle_ about the 1980 U.S. Olympic hockey team that upset the Soviets, had this dialogue that actually happened between Head Coach Herb Brooks and Assistant Head Coach Craig Patrick. I feel it applies here.

 _Patrick: This is the final roster? You 're kidding me, right? You're missing some of the best players.

Brooks: I'm not looking for the best players, Craig. I'm looking for the right ones._

<comment><USER11> Which implies something major that everyone is glossing over:

If the "right people" aren't the same as the "best people" are the criteria we're using for "best" correct?

<comment><USER12> I think the real lesson - and the premise behind Moneyball - is that when you have a complex objective, you can't evaluate people in a vacuum. You have to optimize at the team level. You can try your damnedest to come up with heuristics and metrics to evaluate individuals, but if you don't allow yourself to consider the context that they'll be working in, you'll miss a lot of potential.

<comment><USER13> I don't think this is the central thesis of Moneyball. I'm a huge baseball nerd, including on-field and statistical side. The idea behind the WAR (Wins Above Replacement) stat is that you should adjust for context, then evaluate players in that vacuum.

Moneyball was about identifying and exploiting market inefficiencies. It actually rejects the team level optimization ("he's a team player" is explicitly rejected as a valuation of a player).

Instead, Billy Beane identified what components led to team success, then found which of those the market doesn't pay for. Then he got those guys.

Used to be thought that a good baseball team had a speedy leadoff hitter. Teams would play objectively worse players because they thought their style better "fit" their role.

Moneyball was the start of the revolution that you just want to get the best players. Then accept that playoffs don't really mean anything other than randomness with small sample sizes.

<comment><USER14> "Instead, Billy Beane identified what components led to team success, then found which of those the market doesn't pay for. Then he got those guys."

Let me ask you - as I am not a baseball nerd - if there is any counter- argument to the BillyBeane/Moneyball/WAR movement ?

I don't mean knee-jerk, irrational objections - but real, reasoned counter- hypotheses ?

<comment><USER15> Yeah, the counter argument is that you mess up the team chemistry. This is extremely hard to define and measure so can sort of always be used.

Billy Beane is constantly attacked for destroying the looker room chemistry in the local press.

<comment><USER16> >>you mess up the team chemistry.

True, only if you have a great team already and you don't desire messing it up. If that is the case, you wouldn't need that method at the first place.

On the other hand, teams are pretty dynamic these days given the interfaces and responsibilities are well defined. Or at least are largely defined well. So replacing team members is never really a problem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> _Presumably you have teams of Web-stack ( "Fullstack") developers._

This caveat should have been put up front.

Since "Best" is a vague loaded term it's more accurate to understand the problem that you're trying to solve.

If you are creating a new web-standard or industry shifting technology then you absolutely need the best. If you are creating a new web based CRM for firefighters, then you need someone who is good, but probably doesn't do vector algebra in their head or [insert favorite discriminator for something hard.]

<comment><USER18> > Since "Best" is a vague loaded term it's more accurate to understand the > problem that you're trying to solve. > > If you are creating a new web- > standard or industry shifting technology then you absolutely need the best.

There's a tension between these two sentences which is worth more consideration about what "best" really means and how it intersects with scalability.

If you're working on a web standard, "best" tends to mean things like "experienced", "works well with others", and "broad and deep understanding of what the users do".

If you're working on a major new technology, it might be more likely that you really need someone who is incredibly good at a particular hard skill but it's still likely that if you have a problem in that class it will exceed any individual's capacity and the limiting factors will continue to be coordination between people, ability to maintain clean separation of responsibilities, etc.

Think about something like LLVM – there's a ton of really hard work in compilers and optimization, it's had a significant impact in multiple parts of the industry, and while there are some people who rightly deserve a great deal of respect for work on those hard problems, a key part of the success which hasn't been virtuoso work at that level but rather keeping a design which is clean and extensible enough for so many different organizations to use and contribute to.

<comment><USER17> Yes, fair point. Ended up stepping on myself there a bit.

Maybe "Top of their discipline" would be a better way to say it.

<comment><USER18> Yeah, it's hard to talk about this since we're using a single term to convey multiple complex concepts.

<comment><AUTHOR> This reminds me of a post on Less Wrong about the meanings of words and the idea we're targeting. [http://lesswrong.com/lw/np/disputing_definitions/](http://lesswrong.com/lw/np/disputing_definitions/)

</comment></comment></comment></comment></comment><comment><USER19> Or, hire the best, and make a team out of them. Or hire people with high potential and push them to reach it. Or, hire people who can get the job done.

One thing for sure: if you have mind-numbing processes, "the best" will leave, and others will not reach their potential.

<comment><USER20> Yeah, these "don't do [hip thing], do [contrarian but normal/common sense] thing" articles (or the reverse of them) are becoming a bit tired.

You should have good team-building and organizational skills _and_ good technical hiring skills.

<comment><USER21> Everybody thinks they're doing the common-sense thing and not being contrarian, even if it's the hip thing.

<comment><USER20> Very true.

</comment></comment></comment></comment><comment><USER22> Moneyball and Six Thinking Hats are excellent approaches to for people and roles.

But they aren't enough. The key driver of top-tier teams is excellent ongoing safe communication.

To build communications, use team goals (e.g. OKRs & KPIs), team ways of working (e.g. TEAM FOCUS), and team positions (e.g. scorecards).

My notes about these are open source: [https://joelparkerhenderson.github.io/](https://joelparkerhenderson.github.io/)

Edit to explain abbreviations:

* OKRs = Objectives & Key Results

* KPIs = Key Performance Indicators

* TEAM = Talk, Evaluate, Assist, Motivate

* FOCUS = Frame, Organize, Collect, Understand, Synthesize

<comment><USER23> CARGO CULT BUZZWORD OVERLOAD

<comment><USER24> For those wondering: Collect, Aggregate, Reduce and Generate Objectives to Cultivate Understanding Learning and Teamwork

</comment></comment></comment><comment><USER25> Hiring the best doesn't scale. Building teams does. The problem as with hiring the best is that almost no one knows how to build good teams. You will probably spend way more time resolving conflicts and dealing with politics than you'd like and in the end the software product will still be a steaming pile of technical debt.

<comment><USER26> upvote x 1M

</comment></comment><comment><USER27> Cached: [https://webcache.googleusercontent.com/search?q=cache:zDlwVT...](https://webcache.googleusercontent.com/search?q=cache:zDlwVTWJLLwJ:https://bg- blog.com/2017/04/21/moneyball-teams/+&cd=1&hl=en&ct=clnk&gl=us)

</comment><comment><USER28> This is a pretty important lesson that gets lost at times. Teams with people of diversified passions work well; if everybody is super into data structures, UX, security, etc., then debates can rage and feelings can get hurt. When people on a team specialize differently, everybody can be a mentor to everybody else. To me, that is a great team to be on.

<comment><AUTHOR> Yes, and I also suspect this has lead to "we don't hire jerks" policies, which are great when you find someone who enters a conversation and talks down to everyone. That person fails a culture fit.

However, there's another kind of person who just talks over you, doesn't put in the effort to communicate their ideas, or refuses to accept other ideas. These can remain hidden until tested in the depths of some technical discussion. They might pass a culture fit.

</comment></comment><comment><USER29> I agree, same sentiment from W. Edwards Deming: "A company could put a top man at every position and be swallowed by a competitor with people only half as good, but who are working together."

[http://quotes.deming.org/authors/W._Edwards_Deming/quote/101...](http://quotes.deming.org/authors/W._Edwards_Deming/quote/10159)

</comment><comment><USER30> It happens now and again that the best team has very few of the best players:

\- Denmark at Euro 92. The only world class player, Michael Laudrup, decided he was boycotting the coach. His brother was a fairly decent striker, and future Man Utd legend Peter Schmeichel was in goal, but everyone else was a journeyman.

\- Greece at Euro 2004. Nobody from a top team in a top league, but Otto Rehagel managed to coach them to victory. Not amateurs, of course, but certainly not superstars.

\- Leicester City last year in the Premiership. Nobody on the team was a real target for a top club, except maybe Schmeichel junior, also in goal. But they played a great season and one of them got voted player of the year. And Vardy beat the scoring streak record. What's interesting is how they fell apart this season under the same coach, who then got sacked and replaced by someone who has partially brought back the magic.

The rest of the time, the winners are built around a small number of world class players, and competent squaddies. This is typical of US teams, where you have a salary cap, meaning the superstars will be spread out, and you need to be efficient in paying for the squaddies that are appropriate for that star's game.

<comment><USER31> So once in Premier League since it's inception (1991 IIRC) and twice in Euros since I don't ever remember when should be that surprising?

</comment></comment><comment><USER32> My model for ideal hiring are the Spurs. They consistently hire for talent and potential, provide the proper mentoring and conditions for the potential to fully materialise.

"As you sow, so shall you reap". But few have the patience to sow nowadays. We rather buy ready-made in the grocery store.

<comment><USER33> Most companies cannot have their employees sign multi-year contracts. Outside of sports, there is a much bigger risk of your competitors poaching people after they've developed.

<comment><USER7> Presumably that's always a risk regardless of whether you hired someone junior and trained them or whether you hired someone already skilled. As long as you're doing the standard things that help you retain talent (like paying market rate, providing good opportunities, etc.), there should be no reason to worry, right?

The only companies that should be worried about "poaching"[1] are the ones, for example, who are not paying market rate, have crappy projects, provide no career advancement opportunities. I've never heard of a talented employee leaving a company for literally no reason.

1: Which by the way, is a pretty offensive term--we're not deer or wild game owned by some feudal lord.

<comment><USER34> > The only companies that should be worried about "poaching" are the ones, for > example, who are not paying market rate....

Well, "only" is implying it's not almost universal. Companies routinely pay market rate for new hires and then base raises and bonuses on KPIs for individuals, teams, or the whole organization.

Are there companies that say, "Well, we had a mediocre year, but market rate for devs went up 8%, so I guess that will be the baseline raise for everyone."? If a company does anything less, eventually employees are paid below market rate and they're forced to negotiate a bigger raise (convincing management to ignore KPIs and pay attention to market rates) or find a new job.

<comment><USER7> Or they leave for a company paying new hires market rate.

The job market doesn't care if your company had a mediocre year, any more than your suppliers care. If the price of screws or cables goes up 8% you either pay it, look around for something cheaper, or negotiate. Somehow, when it comes to labor, companies think paying "what we paid last year plus N%" makes sense.

I guess the take-away here is: Companies by and large do not worry about poaching. Rather, they are willing to live with it because they see the alternative as too expensive.

</comment></comment></comment></comment></comment><comment><USER35> I'm four paragraphs in, and I don't want to get too hung up on grammatical errors, but it's making it hard to follow along on what point they are trying to make.

> and was won against with teams spending over $100 million

What does that mean? They spent less on their teams, and they lost? So they should spend more!

> Once upon a time the ambitions of your company were exceeding the throughput > capacity of your development teams. This is the ultimate goal of hiring...

This sentence ends with the ultimate goal, but "this" seems to be referring to the previous sentence, when it really isn't.

> If ambition growth constant

I'm guessing they mean "is" constant?

<comment><USER36> I am a native English speaker and I had a hard time following the point as well. I surmised from the title that the thesis was going to be "x number of decent developers who work together well can produce a product better/faster/cheaper than x great developers who don't get along"

I think a bit of proof reading might make it easier to follow the argument in this article.

<comment><AUTHOR> I had hoped to convince people that since hiring is about improving team throughput there may be better ways to do that besides simply saying "hire the best".

</comment></comment></comment><comment><USER37> I am a bit surprised if this is new information to anyone who has managed teams and/or thought seriously about the challenges that job has to face. When ever I hear an executive making the assumption that "software engineers" are a fungible resource and they will just move 6 over from the project that is on track and humming along to the group that is behind and in trouble I know they are clueless about managing high performance teams. Every team needs a mix of people and when done well the talents and skills of the individual members complement each other and create an effective whole. Too many people trying to drive, or too many people unwilling to drive as an example can both leave the team floundering and unproductive.

When someone asks me what I think their priority should be as a manager, their day to day job if you will, it is looking for ways to improve this spread of talents to minimize overlap and cover gaps.

</comment><comment><USER38> Only hiring the best is inherently unsustainable, because it implies a need for "other companies" to train people into being the best, and only then are you willing to hire them.

The greatest companies are those who offer an atmosphere in which good developers can grow into the best developers. The worst companies are those who believe they can hire people from great companies, and consequently transform into great companies themselves. Great companies produce value; poor companies consume it.

<comment><USER39> This is an interesting point. Companies that try to "hire to greatness" have a steep fee to pay for their hiring approach, and it might not work for reasons that cannot possibly be squashed into, and recognized from, the sloppy "greatness" scalar used to score the possible team members.

As you said, cultivation of expertise is a better approach, and I'm happy that where I currently work fosters this carefully and deliberately.

</comment></comment><comment><USER40> One thing that struck me from Ed Catmull's book on Pixar, Creativity Inc[1] was how much effort they put into trying to get people to work together effectively and how important that was in the final results, versus the talents of the "super stars".

After the Disney acquisition, they kept the companies separate, but basically got rid of a bunch of red tape at Disney Animation and injected a bunch of Pixar cultural practices. The DA team went from mediocre results (many people thought Pixar would just shut them down) to producing hit movies.

[1] [https://www.amazon.com/dp/B00FUZQYBO/](https://www.amazon.com/dp/B00FUZQYBO/)

</comment><comment><USER41> I used to play basketball almost every week at the university gym. There were these guys in their 60's who still played with 19-25 year olds and routinely won. I asked one of them if he saw one particular thing young people tended to ignore. He said, without hesitation, "the team game."

There is probably some bias, the young guys probably didn't play quite as hard as they would have otherwise, but I'm really not convinced that accounts for the entire story.

Maybe it's just as simple as: interaction effects on teams are often stronger than main effects.

</comment><comment><USER42> The 'best' is so subjective as to be meaningless. I have worked with probably 500 software engineers, and I have been the best of all of them. (Well, one guy was probably as good as me.) But, maybe this is only because I value things that a lot of other people don't? My criteria are just different.

I have led teams that developed software resulting in 4 successful (another subjective word, but in this case, acquired) startups. I designed and implemented 14 products. All together these products were used by hundreds of millions of people. Some of them are still used 10+ years later.

But, I still can't always convince hiring managers to hire me. I don't have a blog (don't care). I don't have a github (don't have time). After being turned down some say that I'm 'too mellow' or that I'm too abstract or too specific or that I didn't answer their questions (usually one specific) the way that they wanted me to. Again, it's all subjective.

At the end of the day, it's just a fashion show. And, when it comes to work, I'm not into fashion (I have a laser focus on the product, its market suitability, its functionality, and and its market success).

Basically, people hire the ones that they like. And, I believe the evidence shows that most managers prefer to hire people who are worse than them, or at least only better in certain ways. Corporations are just glorified hierarchies, remember.

So, if you get turned down a lot, take it as a compliment.

<comment><USER43>
        > I have been the best of all of them

What's your metric for that? How would you have known if you weren't?

<comment><USER44> Well, that's the problem isn't it? All you have are confirmation and survivor biases to work with. You're going to get a lousy outcome.

Someone with far more practical experience than you might sound paranoid about some things you don't even think about, and blasé about others (because they have ways to mitigate the problem if it actually happens). You won't know enough to realize why they aren't on board with your priorities, and you will make conclusions that have no basis in reality.

You've only known this person for 45 minutes. You've known yourself for decades. Which one are you going to assume is the idiot in this situation? How often are you going to be wrong? And how would you ever know if you were wrong? You just kicked this person out of your life because you didn't like their answer. If they become lead developer at your biggest competitor, are you even going to remember their name?

</comment></comment></comment><comment><USER45> This reminds me of Reed Hasting's culture deck (he even uses a baseball team as a metaphor when describing Netflix's hiring practices). To further the analogy, Netflix would best be described by the Yankees--pay top-of-market for those who have proven they are the best at their role. This has been effective, for both the Yankees and Netflix. But, the interesting caveat, as alluded to by the OP and the moneyball A's (and other teams), is that this might not be an optimal strategy.

<comment><USER46> I think the Yankees model is a (possibly reaching) metaphor for capitalism. All the capital concentrates in a few hands. But where are all the "best" people supposed to prove themselves?

That's why you see so many posts in this thread like "I worked on the perfect team for a short period, but alas, it was short lived." Building the gestalt is always going to flame out. Right at the moment when you realize you've assembled something special is when your team members start getting traded to the Yankees.

That's why the only sustainable model is culture, culture, culture. Always be striving for the perfect combination of team members. Keep the talent pipeline active, and if you have someone who doesn't fit, get them out of there.

<comment><USER45> Interesting, to belabor the sports team metaphor, culture does indeed seem to be an alternative to max salaries. C.f., Spurs being one of the most winningest teams in the past couple decades, Tom Brady taking pay cuts in order to maintain and foster a dynasty, and Steph Curry doing similar. In all these cases, a great coach (read, CEO) has fostered a strict but burgeoning cultures which rewards its members through a shared success in what they love and not an individual's compensation.

Of course this analogy can be dangerous. Athlete's get paid extraordinary sums, even while sitting on a bench 99% of the season. Whereas many employees __have __to worry about their own compensation simply to survive, and such selling of culture as a supplement to compensation won 't always put food in your mouth (and thus can be exploitative).

Nonetheless, I appreciate your comment, you brought up an interesting view on workplace culture that I never thought about.

</comment></comment></comment><comment><USER47> One metaphor I've been kicking around lately is that a long-term sustainable software team needs a mix of "gas" (folks whose instincts are to churn ahead -- "move fast and break things", if you will) and "brakes" (folks whose instincts are to keep things under control, slow down and do things "right"), and an organization that knows how to balance the two.

</comment><comment><USER48> I remember when michaelochurch was on HN. I think even nostrademons admitted that closed allocation sucked.

</comment><comment><USER14> I think we need to be critical of the Moneyball narrative - and not just because Oakland hasn't actually performed that well under the MB regime ...

The understood narrative is that dummies were choosing players based on broken heuristics and that proper, sober heuristics would uncover hidden value.

Put another way: If you remove human decision-making and replace it with algorithms you will achieve better results.

I am skeptical of that conclusion in every other realm and I don't think baseball (or hiring, as is the case in this article) should be exempt from that skepticism.

Having read MB the book (and seen the movie, for what that's worth) I wonder if Billy Beane is missing the potential for deeper insights that only human brains can put together. It is the thing that we are good at, after all ...

<comment><USER49> > Having read MB the book (and seen the movie, for what that's worth) I wonder > if Billy Beane is missing the potential for deeper insights that only human > brains can put together. It is the thing that we are good at, after all ...

The human brain is _also_ very good at misleading itself. Statistics is how you avoid that.

Do remember that Moneyball happened in an era where statistics was _just_ becoming more ubiquitous. Bill James was collecting and collating statistics from a bunch of volunteers who used to snail mail him the scoring sheets from the games. He only quit doing that in 1988 because suddenly there was a flood of statistics.

So, from weak data to Moneyball in less than 10 years is actually fairly impressive.

<comment><USER50> > _So, from weak data to Moneyball in less than 10 years is actually fairly > impressive._

And it's taken over every sport thereafter: soccer, hockey, football and basketball.

</comment></comment></comment><comment><USER51> This reminds me a lot of Dan Luu's article, in which he makes the same "Moneyball" comparison:

[https://danluu.com/programmer-moneyball/](https://danluu.com/programmer- moneyball/)

</comment><comment><USER52> > Software Development is often about human factors as much as it is the code.

Totally true that. But the title almost suggests you can build a winning team out of a random bunch of average developers.

Although the best developer is an illusion as it doesn't exist as such, just 'building teams' doesn't really say much to me too. I've seen very terrible teams that should have been replaced with just 1 good developer..

Personally I prefer to hire the best fit for the job, whether he or she will be part of a team or not.

</comment><comment><USER53> Thinking aloud...I wonder if the ancient Greek methods of sortition and ostracism have any place in building teams at companies.

Obviously election (selecting people from a group) is hit-or-miss anyway...so maybe reverse-election (eliminating people from a group) could help.

<comment><USER3> As a kid, one of the comic books I loved was the sci-fi Scrameustache [1]. One of the recurring characters was a society of aliens called "Galaxians", who's society was based on extreme sortition. Every week (or day?), they traded posts. One would be a squad leader one day and the janitor the next.

Even as a kid, I realized this was a flawed concept, because it assumed experience and knowledge were fungible. Still, it was fun to think about...

[1] [https://en.wikipedia.org/wiki/Scrameustache](https://en.wikipedia.org/wiki/Scrameustache) [2] [http://www.bedetheque.com/serie-682-BD- Scrameustache.html](http://www.bedetheque.com/serie-682-BD-Scrameustache.html)

</comment></comment><comment><USER54> Seth Godin actually talks about this in his book the dip where he mentions that the best means the best in their world (he goes on to explain the concept of their world). Highly recommend the read.

<comment><AUTHOR> Thanks for the recommendation, I'll add it to my reading list!

</comment></comment><comment><USER55> Excellent start to a post but really needs a follow up. I'd love to hear OP's ideas on practical steps to take in order to effectively execute his team based hiring model.

</comment><comment><USER56> The Moneyball metaphor is useful. The "best" player in baseball (Ty Cobb) batted .366 over 24 seasons.

For every 10 attempts ( _at bats_ ), he "failed" 6.5 times.

Moneyball teams are really about hiring professionals who consistently bat .300.

If each player is batting .300, then the results will compound (more RBIs and runs for the team).

</comment><comment><USER57> Sooo I totally agree with this concept: that teamwork is more important than individual contribution; that we should focus on teams rather than metrics; and that teams are simply more resilient than other types of organizational structures.

Buuut, then the author starts talking about some corporate-bs mumbo-jumbo "skills matrix". Moneyball is about "black swans" as Nassim Taleb would put it: unexpected outcomes that defy the current knowledge base. In other words, a conclusion that we could not have reached via deduction (but only perhaps abduction).

But that goes completely against the "skills matrix" concept. The whole _point_ of Moneyball is that the Oakland players were flawed given standard metrics -- in fact, most were (very calculated) gambles.

>The final touch is to match these against levels of mastery. A lower level of skill may be someone who is largely uninformed of the subject, a middle level may be someone who can constantly use that skill well, and a high level is someone who is a mentor and thought-leader.

Oh god, he really did miss the point.

>With your new chart you are well prepared to decide where to make an investment. Should you hire for a specific weakness? Which team members get what training? Can we run peer mentorship? Do I have unchallenged experts who have no room to grow? Your answers are straight-forward now.

Yep. Whoosh. The whole idea of a strategy like Moneyball is that answers are not straightforward. Moneyball is all about intuition vs. evidence. In the case of the A's, intuition seemed to trump evidence, but the author keeps telling us to collect more evidence (in the form of matrices, skill trees, or whatever else). Not only is that the categorically wrong approach, it's also not how you build good teams.

<comment><USER58> I wouldn't have said that Moneyball is all about intuition vs. evidence, with intuition trumping evidence. Rather the other way around: the A's acquired talent that the _evidence_ suggested was underpriced, disrupting the traditional intuition-based scouting approach. It seems like you've got that backwards.

<comment><USER57> I really disagree, and I Podesta would also:

[1] [https://www.psychologytoday.com/blog/plato- pop/201109/moneyb...](https://www.psychologytoday.com/blog/plato- pop/201109/moneyball-it-s-intuition-vs-evidence)

[2] [http://www.datacenterknowledge.com/archives/2011/09/23/the-l...](http://www.datacenterknowledge.com/archives/2011/09/23/the- lessons-of-moneyball-for-big-data-analysis/)

According to Podesta: "Subjectivity ruled the day in evaluating players ... We had a completely new set of metrics that bore no resemblance to anything you'd seen. We didn't solve baseball. But we reduced the inefficiency of our decision making."

<comment><USER58> That supports exactly what I was saying: "In the competition between intuition vs. evidence, evidence wins."

So it's not clear why you are saying "In the case of the A's, _intuition seemed to trump evidence_ , but the author keeps telling us to collect more evidence (in the form of matrices, skill trees, or whatever else). Not only is that the categorically wrong approach, it's also not how you build good teams." (Emphasis mine.)

<comment><USER57> Evidence may or may not win (that wasn't my point), my point was that Moneyball favored intuition over evidence. Even Podesta concedes that. So using it as the example in the original article makes no sense.

<comment><USER58> > Moneyball favored intuition over evidence. Even Podesta concedes that.

Both the articles you've linked contradict you. _Traditional scouting_ favored intuition over evidence. DePodesta and the _Moneyball_ approach turned that on its head, favoring evidence.

> DePodesta: "We said 'unless we can prove it, we're not going to believe > it.'"

</comment></comment></comment></comment></comment></comment><comment><USER59> These topics are orthogonal. You can hire the best and build teams at the same time.

<comment><AUTHOR> I agree with that. I attempted to describe a way for a company to improve throughput that isn't simply "hire the best".

</comment></comment><comment><USER60> Boss: I only want to hire the guy who worked on XXXX Project. me: That project was 2 years late and 1.2 million over budget. Boss: Still, he did something right.

</comment><comment><USER61> Going to paste this here: [https://www.nytimes.com/2016/02/28/magazine/what- google-lear...](https://www.nytimes.com/2016/02/28/magazine/what-google- learned-from-its-quest-to-build-the-perfect-team.html)

</comment><comment><USER62> If you say "the best" that also includes being good at teamwork. Great programmers write great interfaces anyway and are highly flexible.</comment>


Python Tips and Tricks, You Haven't Already Seen, Part 2 - <AUTHOR> https://towardsdatascience.com/python-tips-and-tricks-you-havent-already-seen-part-2-952828cfd0bf <comment><AUTHOR> This is second part to the post I shared here yesterday: [https://towardsdatascience.com/python-tips-and-trick-you- hav...](https://towardsdatascience.com/python-tips-and-trick-you-havent- already-seen-37825547544f)</comment>


Show HN: Design small, rle-encoded fonts for use in low-resource systems - <AUTHOR> http://smallfont.develop.vodka/ <comment><USER2> I like this - spent a good 5 mins designing some chars.

Suggestion: Add a grid of the chars created so far rendered at 100% (i.e. 8 pixels by 8 pixels, or maybe 200% 16 pixels), on the right hand side of the large box - so that the designer can see all the generated characters at once - to get a feel if any of the chars look odd across the whole font set.

</comment><comment><AUTHOR> I am working on an embedded system project with a low-powered microcontroller and low-resolution graphic display.

I wrote this tool to design a very small, compressed font.</comment>


Ask HN: How to commit comments to different repo? - <AUTHOR> Does anyone know of a way, via software or some other means, to be able to leave yourself comments that can be saved without getting overwritten by pulling a git repo?
I want to be able to go through an open source codebase and leave myself comments so I can understand it. But obviously, I don't own that repo and can't commit my comments to be saved. And in addition, any time I updated the code by pulling, I'd overwrite my comments or have a bunch of conflicts (assuming git doesn't throw a fit with unsaved changes in the first place).
So if there was a way to commit all my comments to one repo, then I could update the code and comment separately and have it all work out. Does anyone know of a way to do this? Even if it's a PHPStorm plugin or something IDE based, that would be fine. <comment><USER2> Clone the repository, create your branch "with_comment". Every time you want to sync with the upstream repo, you pull in the master branch where you have done no modification, and merge to you comment branch whenever your need/want.

I don't think there is any way to have the conflict automatically resolved if you cannot commit (and have other people actually resolving the conflicts)</comment>


Ask HN: I am underpaid. Am I? - <AUTHOR>

Hi All,
When I started working as a QA Engineer(Telecom products, in The India) way back in 2006 July I used to get $60 a month. Yes Its just $2 a day. And I know why.
When I passed out from college holding a degree in Information Technology. I was not fitting into the entry criteria for most of the companies and the reason was my percentage in 12th exam. It was just 51% with 4 number grace in physics. I had no idea about almost all the subjects that I studied in college, EXCEPT networking and JAVA. By the way I was good at JAVA.
Though I got my job as a QA Engineer, I used to do networking and Unix stuff to feel better at work place.
Till Dec 2008 my salary was incremented to $300 a month. Because I joined a finance project team and was doing Selenium automation. Due to this I was now part of some techies. I started working of some JAVA projects back home and learnt Web Development. and this pulled me to write some code that helps in testing, like DB comparison, data loading etc.
When I changed my job after 3 and half years in 2009 I was at $400/month. And my new salary was $500/month.
Since I already started automation and started writing innovative solutions for testing I got good hikes in my second company and I left it in 2011. I was getting $700/month.
Now in 2013 after my first hike in my current company I am getting $1200/month.
I strongly believe that I am still underpaid, because the kind of skill set I have and the work that I do is helping hundreds of people to make their life easy. I am 6+ years experienced now.
I am a Test Automation engineer, and I know JAVA, Perl, Python, Grails, Django, JS, VBScript, CSS.
What you say? <comment><USER2> say about what?

you have 6 years of experience, most of them in qa. I don't know if your a decent developer. So, maybe try management position. Give us the Github link with some projects in grails/Django. And please, don't use java and css :) Is like kitchen sink</comment>


Sundar Pichai Calls for AI Regulation - <AUTHOR> https://www.bbc.co.uk/news/technology-51178198 <comment><USER2> Alternate headline: "Sundar Pichai wants to cement his AI marketshare and squash innovative startups"

<comment><USER3> My cynical take is that he wants to avoid taking any moral responsibity for his ai. As long as there's regulations, they can fall back to a "we followed the rules" defense and morality falls on the regulators.

Without regulation, they have to defend their actions by arguing that they do is morally justified.

<comment><USER4> Someone smart, once said, "Watch what they do, and not what they say".

Unless google is actually spending serious money lobbying for laws that impose any restriction, this is just bland obligatory public speech, that the culture demands.

<comment><USER5> A similar sentiment is "don't tell me what you care about, show me your financials and I'll tell you what you care about".

Also, I think you meant to say "spending serious money lobbying against laws..."

</comment></comment></comment></comment><comment><USER6> Sundar Pichai's call for regulating artificial intelligence is a slap in the face to anyone working in the field of AI. There are obvious existential risks that he seems happy to skip over. His choice of AI is pure marketing driven FUD, mixed with a healthy dose of self promotion.

Don't wait for him to put up any cash to reign in Nuclear weapons, Global pandemic, Carbon emissions, Bioterrorism etc. Pichai will dismount this soapbox as soon as a new buzzword hits Twitter. [https://killedbygoogle.com/](https://killedbygoogle.com/)

</comment><comment><USER7> And then a different take: [https://thenextweb.com/artificial- intelligence/2020/01/20/su...](https://thenextweb.com/artificial- intelligence/2020/01/20/sundar-pichai-offers-a-cryptic-warning-against-over- regulating-ai/)

<comment><USER8> In fairness, at least there is some consistency, whether you interpret it to be genuine or not:

> Now there is no question in my mind that artificial intelligence needs to be > regulated. It is too important not to.

</comment></comment><comment><USER9> How can we seriously begin to regulate anything tech related until we actually have people who have worked in tech or understand tech in government roles in some capacity, either consulting or full time ?

<comment><USER10> This is why the people that regulate things often come from industry. You'll see a lot of (not entirely misguided) complaining about the fact that the people that regulate finance, for example, often come from a major bank like Goldman Sachs. While this can lead to questionable rules in some cases that "favor the banks" at least someone that understands the industry is regulating the industry.

I'd rather that than have some idiot who knows nothing write the rules and screw everything up.

<comment><USER11> Mario Draghi also had a career at Goldman before he ran the ECB. Goldman is not called a vampire octopus squid for nothing. We have especially seen in banking what regulation from the industry boils down to.

There is no need to be an industry expert to become a regulator, it is on the regulated to explain the context as simple as possible.

</comment></comment></comment><comment><USER12> Seems perhaps like a shiny distraction from calls for economic regulation or privacy regulation.

</comment><comment><USER13> OpenAI? Maybe Google should join/sponsor them?

<comment><USER11> With Microsoft? Would that signal AWS superiority in the cloud war?

</comment></comment><comment><USER14> The thread is already filled with the usual "CEOs only call for regulation when they're ahead" posts.

I find this to be such a shallow generic libertarian take on tech. Not only does this always seem to come from people who eat up everything tech executives say _on every other topic except regulation_ , it also totally treats Pichai's arguments in bad faith.

Here's another take. Pichai is just a smart guy who is genuinely worried about the abuse of the technology because there is indeed a lot of state actors or other potential to abuse the technology in privacy damaging ways. If you want to scare Google with regulation try anti-trust, not AI and privacy security.

Nobody is competing with Google or the large players on AI anyway, regulation or not. Their advantage is in data, scale and talent. If anything higher privacy standards might create ecosystems of privacy focussed companies in the space.

<comment><USER15> I'm someone who generally thinks we need much more tolerance for regulation in the States, and even I'm not buying Pichai's stance.

CEOs of publicly-traded corporations do _not_ act in good faith towards anyone but shareholders. We can debate whether or not they're morally obligated to (I would say yes), but realistically, they do not.

The _only_ reason a hired CEO would push for regulation of his own industry besides wanting to stifle competition, would be if current (or upcoming) regulation was unpredictable and he wanted to reduce risk by getting a clear- cut answer. You _maybe_ could make that argument around something like privacy where there's a mounting wave of public pressure. But at least right now, AI is in no such situation.

<comment><USER14> Google probably loses out a good amount of bucks due to their stances on defence work. I don't see how this can be attributed to some sort of cynical corporate play, it's simply company culture.

Likewise, I don't see how a lot of these companies calling for facial recognition bans can be considered to be in their interest. When the government looks for large infrastructure those companies are the only real players. Remove all regulation, and the government still not hand their data to some sort of garage startup.

CEOs of large companies are totally able to act in good faith towards people other than their shareholders. Of course, often they do not, but they certainly can.

The arguments around caution and privacy of citizens are sound and reasonable. Everyone can make them. There is no reason to not listen to Pichai just because he runs a business.

</comment></comment></comment><comment><USER16> AI intrinsic socialist nature is showing in comments like these. It's so weird to hear companies ask for regulation while the government is saying don't worry about it. Either Google knows something mainstream AI research doesn't or it's some kind of weird deferential posturing about competencies.

<comment><USER17> Companies tend to only want regulation when they need to block out competitors by raising the bar to compete. Maybe they're worried about stealth startups that may already be ahead of them?

<comment><USER18> They also tend to ask for regulation when they see stirrings that regulation is on the horizon. Better to shape it then have it forced upon you.

</comment></comment></comment><comment><USER19> Sure he does. They actually want global regulation so they don't have to worry about pesky little things like national entities regulating their stuff and perhaps fining them some billions down the road.

If only there was a global government to lobby to it would make things so much easier legally speaking. /s

Regulation is also great to kill would-be competitors. Classic pull the ladder move.

The government should start _taxing_ data. Just like any asset data should be listed in their financial statement per type and quantity and taxed. Derived models taxed based on the input data.

<comment><USER20> Case in point - recent onslaught of regulation in the EU, including GDPR, was meant to push Google out of the market but their market share only increased, with valuation hitting record yet again just now.

</comment></comment><comment><USER21> Is it a case of either us regulating AI or AI ultimately regulating us? It would be tricky to implement such regulation, it would need to be a global effort like nuclear non-proliferation. Otherwise certain nations might pursue unregulated AI in hopes of some advantage to the detriment of all.

What times we live in.

EDIT: updated text to clarify position of curiosity.

<comment><USER22> There already is an autonomous closed loop from human behavior, digital surveillance of that behavior, and AI models that train on that data and use their models to influence human behavior.

<comment><USER21> I have limited knowledge in this area, but would AI not at some point behave in a way like virus or bacteria and propagate and adapt in some ways until it's free (even if unintentionally) of those limitations.</comment></comment></comment>


Bioinformatics with Perl 6 - <AUTHOR> https://perl6advent.wordpress.com/2016/12/02/day-2-bioinformatics-with-perl-6/ <comment><AUTHOR> And, the book it talks about is here: [https://www.gitbook.com/download/pdf/book/kyclark/metagenomi...](https://www.gitbook.com/download/pdf/book/kyclark/metagenomics)</comment>


Learning to Swim By Reading a Book - Teaching CS in Rwanda - <AUTHOR> http://blog.nyaruka.com/learning-to-swim-by-reading-a-book <comment><USER2> That's a good FizzBuzz problem. Broadening the scope from Rwandan CS students, many well-compensated professional programmers in rich nations could not complete it successfully. I know, this is crazy, but we live in a crazy world.

And to those HNers who think that inability to FizzBuzz is a funny story made up by overly cynical neck beards: spend a year hiring.

<comment><AUTHOR> Ya, it is a similar thing for sure. The problem is just accentuated here. Two of the four we interviewed had some clue as to get started. The others were pretty stuck right off the bat. And that's (approximately) the best out of 50.

That they don't code at all in school is just inexcusable.

<comment><USER3> I suspect that the sample size is too small to really draw any reliable conclusion.

Having said that, you are on the ground. You see and talk to them. You definitely have a good idea of what you are talking about. Me, i'm just a guy half way around the world feeling pretty bad about it - and hoping that this is not true.

You touched on so many points that i endorse and recommend heartily. Programming is coding. It's hands-on. People have to sit in front of a machine from day one, hour one of their learning. People learn from writing crappy code, and debugging crappy code till the code starts to work. People learn from making their own mistakes. People should learn that programming cannot be memorized and repeated ad nauseum on exams.

I remember the kind of folks i interviewed when i was starting a company in india in 1995. I was horrified at the nature of rote memorization in many schools and collages. I made a decision not to hire any one with a CS degree as i felt that i would have to spend too much time making them unlearn bad habits. I then decided to go out, hire students with no programming background, teach them coding from the ground up. Teach them to solve problems one step at a time. Teach them the joy of debugging. And they turned out to be great.

I suspect that every country, region, city, place might have to go through an evolution of programming culture, but the internet and it's legions of programmers gives a great way for beginners to short-circuit their learning process.

Let us know of ways we can help, as well.

<comment><AUTHOR> Thanks for the comment, it sounds like you've seen very much the same thing.

The encouraging thing of course is that there is huge talent here, it isn't the people, it is the institutions that are failing them. But we've hired two who are super bright and which we've helped along and are doing awesome. So ya, of course that is fun and is why we are here.

One thing that has come out of this discussion is one of the asides I put in about the MIT courses. And I think we might actually try to facilitate getting a group together to work through it, at a reasonable pace. (say one class a week) We'll see.

Would love to hear more about your experience in India if you ever have the time. My gmail is the same as my user account.

</comment></comment></comment></comment><comment><USER4> Going on a tangent here.

While programming is certainly the most marketable skill of a computer scientist, computer science is _not about programming_. Computer science is the mathematical study of computation; it's the study of processes and of information. It is possible to be a great computer scientist without knowing how to program.

This doesn't excuse the university of Rwanda: programming is possibly the best tool we have to teach CS these days, and it is a skill that most computer scientists should grok. But I do think a CS degree's value is not only measured by how good a programmer it means you are: CS is a scientific field, not engineering.

<comment><USER5> Lacking tangible skills, it's hard to evaluate whether someone is a "great computer scientist".

Can you be a "great artist" if you can't even draw? How about a "great architect" if you don't know how to build a house?

Possessing the basic skills in your field of study, I think is a prerequisite for acquiring the advanced skills and the ability to contribute to the state if the art.

<comment><USER4> There are other tangible skills a computer scientist should have, other than programming. The ability to demostrate graph properties, solve computability and complexity problems, explain and develop algorithms are all things that don't require programming at all. Some of my best teachers at college are not great because of their programming skills, but because they are great at other areas of CS.

</comment></comment></comment><comment><USER6> You sure can't learn CS by _only_ reading a book - the keyword here is _only_.

Following through good books is an excellent way to learn programming. I don't believe anyone who has followed through K&R would have any difficulty getting through these fizzbuzz questions.

The analogy with swimming is flawed. You don't need to read books to learn swimming(or maybe there is some theory involved - I don't know), but books are a vital part of a CS education. Good books teach you a lot more than what you learn by randomly typing.

An hour in the library saves a week in the lab.

<comment><AUTHOR> Hrmm.. Maybe, maybe not. I'm certainly not making the argument that you shouldn't read, if anything, my argument there is don't attend university if your professors have no idea what they are teaching, which is the case here.

Obviously, those who write books usually have a pretty good idea of what they are talking about, so gaining knowledge from them is a great strategy.

And yes, there is a belief here in Rwanda that you can learn CS by ONLY reading books.

But to your point, I'm not sure why you rank books so highly, when in isolation they clearly aren't enough. The average student probably won't grock worse case runtimes by only reading about them. Having a lecturer explain it and give examples will help, but actually implementing some sorts and seeing how fast they run on different size data sets is really what is going to drive it home.

But for a great many programming jobs, I would actually make the argument that you COULD do them without reading a single book. Granted you probably won't be building the next map-reduce, but you can still be effective.

Learning how to find solutions online, read documentation (does that count as a book?), and debug, as well as fundamental algorithms are the big skills.

<comment><USER3> I beg to differ.

When one first starts out, it's ok to just sit in front of an interpreter or a compiler and start trying out small programs, make mistakes, learn from them and go on.

But one vital quality of good developers is being able to read code, understand good code, borrow good coding habits and using them in your work. Many excellent books are available where what shines through the pages is the author's experience in writing good code, explaining the logic of how he or she arrived at it, and then solving small problems which might come as exercies at the end.

University degrees, learning on the job, etc will only get you so far ahead, but to leap ahead in your productivity, it's best to learn from the real giants in the field.

Programming is a field that constantly changes. Reading, Applying, and learning new skills, and new techniques is part of the skill-set needed to survive. Great books are a complement to hands-on experimentation in this regard and cannot be over estimated as more and more learning is often self- learning since it's difficult to always find good mentors.

<comment><AUTHOR> I don't think we disagree. I didn't say you were likely to become a GREAT programmer without reading, or even that it is far easier with formal training from competent teachers.

My point, rather, was to say that for a great many jobs, jobs that most of us here on HN might turn our nose up at, but programming jobs nonetheless, you can survive without that reading.

I would even go on to say that the vast majority of programmers out there doing the job day to day, perfectly adequately no less, have never read any of the tomes we hold so dear.

Could they be more effective if they had? Sure. Could their processes be improved? Absolutely. And I'd be the first to say they should. I do want to live in a utopian world where everybody reads HN, cares about worst case runtime and stresses over the density and color of their code.

But realistically, as in any other field, only a small fraction of people are interested in learning their field to that degree, and the rest are perfectly fine being (merely?) adequate. That's ok because there are a great many jobs perfectly suited for them.

But again, the point of the article is not how to create the next K&R. My goals are much simpler, much more modest. I just want functional programmers, at the basest level. And as you said, at the beginning, there is just not substitute for time in front of a keyboard.

</comment></comment></comment></comment><comment><USER7> I think its quite interesting that the example chosen to display how bad theory without practice can be is swimming (which is an excellent example). Im currently working in the Philippines with setting up an development team and here some of my local co-workers have had theoretic swimming in school. They got a grade, but cannot actually swim! Got a bit surprised when I heard it for the first time.

<comment><USER8> I was there a few months ago. While tourists were swimming, Filipinos were all floating with life jackets.

It surprised me that, in a country that is basically a cluster of small islands and where you can only get around by boat, nobody can swim.

</comment></comment><comment><USER9> I think the major problem here is that CS and programming are too intermixed in education (and thus in the industry too). Uni degrees ( _imho_ ) should educate _scientists_ who study their field and do research.

If we continue on the swimming analogy: You don't actually need to know how to swim to research swimming. You just need to know how to gather data (by studying swimmers), and how to analyze that data to draw some conclusions.

I think the mixup is reflected in the comments here on HN too, people going to study CS in hopes to learn to program, with no intention in becoming a scientist. And then they are disappointed when the CS curriculum is trying to train them to be scientists.

imho the whole computer related education needs a complete re-engineering, from primary schools to universities. We need to assess what kind of people we need (scientists, engineers, mechanics, professionals, common people, etc?), and what skills they need to be efficient at their future jobs. I think it's quite clear that the concept of having CS and throwing everything computer- related there is not working very well atm.

</comment><comment><USER10> Well, I can never resist implementing these interview questions! Here's my answer:

      def strip_dupes string
        res = ''
        string.each_char do |char|
          next if char == res[-1]
          res << char
        end
        res
      end

Any improvements?

update: and can never resist reducing them to one-liners either.

      def strip_dupes str
        str.each_char.inject('') {|r,c| r << c unless c == r[-1]; r}
      end

<comment><AUTHOR> You're hired. Though we are mostly a Python shop, I'm sure you'll adapt. Sorry, no relocation package though. :)

</comment></comment><comment><USER11> "My advice to anybody in Rwanda who wants to learn Computer Science is this: Don't attend University"

Honestly, this advice applies to anyone anywhere.

<comment><USER12> Have you attended a university? Did you study computer science there?

If not, how can you make a comment like that.

<comment><USER11> i earned a bs in computer science from a liberals arts college (Xavier) in 2007, and an MS in computer science from the University of North Carolina in 2009. I am thoroughly convinced i'd be much farther along in my career now if i'd never gone to college.

thinkign about this has brought back a lot of memories, so i apologize for the long post.. maybe i'll turn this into a blog post.

at the end of high school (i graduated in 2003), i spent a lot of time hanging out with defunkt (github co-founder and ceo). we dreamed of making our own games; "you be john carmack and i'll be john romero," he told me once. summer 2003, between halo (and later planetside) LAN parties with our circle of friends, i started learning directx. our plans were probably too ambitious (3d multiplayer action game) for a group of recent high school graduates with no work experience, limited knowledge of c++, and no art skills. i got to the point where i had a .x mesh of a tiger moving around a hightfield (with shading!), a simple network chat protocol and console, but when our artist left for college, i had no real hope of finishing the game.

towards the end of that summer, we started a 'consulting firm' which never really went anywhere. when school started i spent most of my time working on bullshit homework assignemnts and working as a bus boy for spending money. i was also majoring in physics and math, so i didn't have much free time. what little time i did have, though, i spent programming. defunkt showed me php and apache, and i learned far more trying in the 10 hours a week i spent programming a 'schedule the bus boys' web app than i did in the 30 hours a week i spent going to class and doing homework.

defunkt spent most of high school fucking around and having fun, whereas i spent it studying my ass off and taking AP classes to get more college credits - i started undergrad with something like 50 credit hours. defunkt didnt' get into the college he was hoping to (miami univeristy of ohio), so he started at a community college instead. he dropped out in spring 2004 when he realized how worthless it was for him. i knew he'd be wildly succesful and cursed myself for not having the courage to do what he did.

he then spent all his time trying to find programming work, while i spent all my time busing tables and doing all the stuff i had to do for the english and theology classes i was taking becuase i chose to go to liberal arts college in cincinnati, ohio instead of an engineering program at a top-rated school. i had a girlfriend at the time, whom i'd been dating since i was a freshman in high school, and i thought i was chosing love over money. :-/

defunkt found some work doing web development for a trucking company in new jersey (i'll always admire his hustle) and in spring 2005 he parlayed that experience into an offer to work for cnet in san francisco. he tried to convince me to move with him when he got the offer from cnet. at the time, i told him something like 'i know you're going to be incredibly succesfull but i dont have the guts to quiet college.' to be honest i really watned to go, but i was still in that (now very unhealthy) relationship at the time, and didn't have the courage or insight necessary to break it off.

fall 2005 was the worst period of my life. my friend was apparently doing quite well for himself in california, and i was bored and miserable in college, stuck in a relatinship i thought i had no way out of. i had had tried unsuccessfully to get programming internships, but hat no luck becuase xavier wasn't known for its cs program, and the best i could do was an IT job at a medical device manufacturer. i spent my days fixing corrupted outlook installations and installing replacement hard drives. all the while i was coding like mad on the weekends, on toy projects (a risk map generator was one of my favorites) and simple games. again, i learned more about good design and code layout working on those projects than i did in class, where i was now ostensibly learning about "software engineering".

the only thing i remember from the software engineering class i took was when we were pretending to come up with 'user stories' for an electronic voting machine. my friend jacob and i were supposed to be the customers, and sharon and kyle were supposed to be the developers. jacob and i said that the machine should be a regular dodecahedron that spins on its axis 'like those sunglass racks at the malls', and it should have eye recongition, a finger print scanner, and stool sample acceptor to identify voters. it's still funny in retrospect, and i guess it did teach us that customers are fucking morons, but i could have told you that without the class.

fall 2005, i was diagnosed with depression and then bipolar disorder, and put on a number of different medications. i tried to kill myself a few times and went to a mental hopistal. my life seemed to be going nowhere. i figured i'd be stuck in that relatniship the rest of my life, doomed to spend eterntiy fixing broken hard drives in cincinnati.

finally, in early 2006, i worked up the courage to break up with my girlfriend. live got a hell of a lot better.

damn this is long.. to the point!

i learned a lot of aweosme stuff in school, don't get me wrong. i can show you how to convert a deterministic finite state machine to a regular expression, and construct a NFA for ww' like nobody's buisness. i spent summer 2006 working for the NSF on approximation algorithms, so i learned a lot about that kind of thing. and there were some things i learned in school that have been really useful - we wrote an operating system my senior year, and it was a hell of a lot of work. i learned a ton about debugging and machine code.

at the end of the day though, i look at where defunkt is now, ceo of a wildly succsessful start that's basically a household name among hackers, and i'm still a nobody.

i woke up one morning when i was 14 and decided i'd better start kicking ass in school if i wanted to succesed in life. if i could go back to 14 year old me, i'd say forget abotu school. you can learn a hell of a lot faster than any teacher can teach you. learn to code by coding nonstop, and get experiecne working for other people as soon as you can. the stuff you learn in school is valuable, true, but it's not worth the opportunity cost. i had a full ride to undergrad and still feel like it was a net negative financial decision.

<comment><USER13> Dropping out of college to run a startup is a bit like dropping out of college to play in a band.

For a lucky few (and I do mean _lucky_ ), it works out magnificently - but for the majority who try it, you don't get anywhere meaningful.

During the boom time a few years back, it was a more viable option, but in todays economy it's a far more risky venture and you're highly likely to spend a few years going nowhere, rather than ending up with a degree and the reasonable shot at a steady job that that gives you.

I probably wouldn't recommend a CS degree at a liberal arts college not known for its CS program, but I would certainly recommend studying at a well-known institution over striking out on your own.

<comment> barry-cotter _Dropping out of college to run a startup is a bit like dropping out of college to play in a band._

The chances of hitting the big time may be roughly similar but the median guy who's spent four years working on becoming a rockstar 30 hours a week, seriously, no bullshitting can play music well and has a very nice social circle, the median programmer-equivalent can get a well paying job even if he never makes it as a startup founder.</comment></comment></comment></comment></comment>


On Art - <AUTHOR> http://www.tbray.org/ongoing/When/201x/2010/05/27/On-Art <comment><USER2> An example of gaming art: Shadow of the Colossus.

The gameplay elements are integrated into the storytelling in a way I can only describe as art. Desolation, terror, desperation, and triumph experienced in the gaming elements are as well integrated into the story as the best soundtracks are integrated with the best made movies.

The experience of holding on by your fingertips, as the grip bar shrinks, the horror experienced when scoping out the 8th colossus from a distance and letting it close with you, the hopelessness of operating the last character to appear... these are all integrated with the emotional intent of the part of the story they are in, to the point where the gameplay is integral and not a bolted-on gimmick.

Interactivity is just another element, like color, sound, music, CG, 3D, or any number of technical innovations. It's just another tool to be used, artfully or clumsily. It may start out as a gimmick, but creative and talented people will figure out how to properly integrate it over time.

(Yes, soundtracks, color, CG, and 3D were once all pronounced to be gimmicks that added nothing to the art of movies.)

<comment><USER3> Seconded. Shadow of the Colossus is the best refutation to Ebert that I can think of.

One factor that you're leaving out is the moral horror of painfully slaughtering these giant and beautiful creatures. Often the colossi are completely benign, and you have to figure out a way to injure them to get their attention or bring them down to your level. My wife watched me play the first level, and left the room horrified.

Thus, the emotional reaction of the player is a key component of the art. I began the game tackling the first colossus with feelings of guilt and shame for being such a butcher, but that was tempered by the knowledge that the kill was a _necessary_ act. You have a love to save, after all.

However, as you progress through the game your revulsion subsides. You become numb to the screams of pain, the frenzied attempts to shrug you off. It becomes simple sport, instead of a vile but necessary act. The kills devolve to "just a game". Your character physically reflects this, as you become gradually darker and deformed, but at such a slow pace that you don't notice until the corruption is quite far along.

And then, at the end, after you thrill to the final hard-won kill, the morality comes rushing back. What you've done was wrong. Evil. Even though you set out with the best of intentions, your soul is now irredeemable. The guilt is intense. Then, finally, redemption of a sort.

SotC is emotionally richer than most films, and the responses that it evokes would not be possible in any other medium. SotC is art of the highest caliber.

</comment></comment><comment><USER4> I don't get it. In every post or essay about video games not being art, I've yet to see a standard on which the statement is judged.

If smearing human fecal matter on different things, or squatting in a bus stop and then cutting 1 ton of raw onions constitute art, then the beautiful stories and and visual effects (and sounds and music and etc...) of video games that arouses genuine emotion in the players who experience them should indisputably be called art.

Simply because fun is one of those emotions that is often felt while experiencing the games doesn't mean it isn't art. That's not written anyone.

What's even the point of not calling it art?

Absurd. All of these arguments.

<comment><USER5> What you don't get is that art is a social hack.

A long long time ago art, craft, science and even what then passed for engineering and manufacturing, were all pretty much the same thing.

Over time we started to separate things, first science split off, but eventually we even split craft from art.

And what's left in art is not some sensible definition like what can educate the illiterate, enlighten the literate, and entertain the enlightened.

It's not even some fuzzy definition like what ever is a comment on the human condition. The stand for an art piece could totally be that, until the artist tells you it's just the stand the art is still coming. Even some artists who make amusing and animated art have been accused of not making art at all but some kind of crafty floss for the eyes bullshit that so totally not art.

(Please be aware that when I wrote the above I had sculptures in mind, not video games.)

Art, and I don't just mean the products of art, but the all encompassing culture, critics, buyers, sellers, "artists", groupies, the whole thing: it is all a social hack.

If you totally buy into and can't use your own taste to tell something good from something else, we'll then you've been totally 0wn3d.

If you just like music and some other artsy type things, but don't get "it". Well then you're doing much better then people who overpay for crap they don't understand, but you still don't get it.

If you get recognition and/or fame, money, what ever, but you get for something which requires a lot of work/effort/time/talent, what ever, then you're really good at that thing! But you're not necessary also really good at art. Even if the thing is something everyone agrees is super artsy, like painting.

If you're getting paid, especially if it's a lot, for anything that doesn't require much of anything, this includes work/time/loss of dignity/etc, if you can get paid a lot from "art" for not doing much, well then you get it and are winning at this particular game.

<comment><USER6> The term Art has different meanings for different people, but ironically one of the core characteristics of a work of art is that it itself has different meanings for different people.

Art is the social objects that people like to own, produce, view, reproduce, etc., in order to advertise certain aspects of themselves: their taste, their wealth, their vow of poverty, their snobbery, their connection with "the real", their flights of fantasy, etc.

Art is like rational argument, but with metaphor in the place of logic.

Art is that which is perceived while in a self-consciously art-consuming mode of thought.

Art is symbols in a web of epistemology, postmodern constructs the mastering of which generates academic status.

None of these is truly correct, and there may be many more. It's up to you which judgements to use. But don't expect other people to agree with you if you put all your eggs in just one of these baskets.

Myself, I hew most closely to the metaphor as logic approach. Art, for me, has to be visceral, it has to engage the senses; as well as being interesting, engaging the intellect; as well as being emotive. It should engage at all these levels, and resonate with me, things in my experience of life, and make it richer.

</comment></comment></comment><comment><USER7> Only one character in Portal? Don't forget about the Weighted Companion Cube. That character is pure genius.

<comment><USER8> Ultimately, the weighted companion cube is simply an extension of GlaDOS. As a character, it exists entirely in her monologue; certainly the literal box is not a character, inasmuch as it is simply a box.

<comment><USER9> You must have killed your companion quicker than anyone else.

</comment></comment></comment><comment><USER10> I've thought about this quite a lot, and I've come to the conclusion that calling games art is like calling reality art.

The specific thing that distinguishes video games are game mechanics. And, self contained, game mechanics are basically the physics of the game's universe.

Are well implemented game mechanics art? No. Game mechanics need to be transparent, unless the game is trying to make a statement on game mechanics or something (Braid?).

Video games are a nexus of things that are art, but it just doesn't seem technically okay to call the game itself art.

The best thing video games have going for them is that they can be good for the imagination. The very best video games are exploratory (Myst, Shadow of the Colossus), where interaction is not inconsequential, and they use the medium to its fullest potential. However, this inspires a sort of vacant awe that really doesn't teach you more than "there are a lot of possibilities out there."

Video games are basically just low-density information relays. They're like those "Baby Einstein" videos for older people. Soothing to the brain, but strengthen the wrong facilities.

Like anything else, moderation is key. You need a healthy diet of books, music, movies, food, with a pinch of video games to top it off, to relax the mind from all that high density information.

(Note: I am an old school gamer. These new games really do confound me, and the only game I've purchased in years was the recent Rocket Knight.)

</comment><comment><USER11> Don't fall into the trap, as this Santiago has, of arguing that games are art because they have become _really good_.

First, your opponent can counter with "I don't find them very good", and the productive part of the discussion is over, especially if you are arguing with Ebert.

Better yet, they can argue that subjective quality is irrelevant to the definition (the point you should be making). If bad art is nonetheless art then good non-art is nonetheless non-art.

As another commenter pointed out, the whole discussion is a tactic of misdirection. It doesn't matter what's art, it matters what's _good_ , and this quibbling over semantics is a diversion from that asymptotically complex matter, which old farts like Ebert would rather not face.

Ebert argues that games are not art because they have failed to motivate him to _ever experience one for himself_. If you need more than that fact to win the argument, you are probably over thinking it.</comment>