ikailan

I drank 2-3 Rockstars a day for a few months back in 2007. I knew they were probably not great for me. They made me shake. I just didn't think about it. I also couldn't stop drinking them, because I didn't get much sleep at night ... because I drank too many energy drinks.

Related: we don't often think about how much alcohol we drink or red meat we eat.

One thing that isn't mentioned is that the "friction" in selecting your friends is actually a positive. Instead of someone just shouting out to the world, my friend actually picked my name to receive some post. Not to mention: Snapchat has this built in status for how often users snap each other back. It's a built-in mechanism to get me to respond, similar to the way Facebook wanted it's "Sling" app to work, but without forcing the issue.

I used Snapchat with a very small number of good friends fairly heavily for about a month. Things we shared:

- what we ate - walking to work - on the bus/train - waiting in line - nothing at all - drawing on pictures of people - example: a friend is watching ESPN talk about the owner of the 49ers, Jed York, and drew a dunce cap on his head

I think we averaged 10 messages a day each.

Basically, for us, Snapchat was for sharing photos too stupid or personal for Facebook or Instagram.

The stickiness eventually faded. We got tired of seeing the same food, the same office, the same bus every day. Contrary to how we might represent ourselves on Facebook (SUPER AWESOME!!!!), Snapchat showed each other how utterly mundane our lives were. Of the original group of ~5 people, there's maybe one left.

We also used it a decent amount externally when we did certain kinds of live Q&A Hangouts like developer platform office hours.

I think you misread his paragraph. He was proud of the business the day in its state that day he walked into the accelerator (and presumably for some time before), not BECAUSE he walked into the accelerator.

Agree with your comment.

I wonder if this is what non-programmers think the advantages of understanding programming are? Looks like the author has never actually held a real programming job (http://www.linkedin.com/pub/kirk-mcdonald/0/4/824).

Learning programming skills does have some benefits in learning problem solving. I'll never tell someone NOT to dabble in code, but I don't think the benefits are as pronounced as this article is making it sound to self-teach a tiny bit of programming. There's an earlier comment that states that it might hurt more to know a little; I can see where that viewpoint is coming from.

Anecdote alert. I have a wannabe tiger mom. Unfortunately, she had to work full time+++, so full on tiger-ness could not manifest.

Just as children of many non-tiger moms DON'T learn decision making and time management skills: some do, and some do not. There are other factors at play. At a certain age, it's near impossible for a tiger mom to control 100% of someone's life.

I went to GDC in 2011. I remember that there was a country trying to talk game companies into opening a branch in their country. It was Germany, I believe. They had a beauty pageant contestant dressed in full garb at their booth. It made absolutely no sense at all.

No, not at all. Serving meals makes it much easier to convince your team to go to lunch together (though many folks will eat at their desks, PLEASE DISCOURAGE THIS). Lunching together with your team frequently is the single best benefit of a company that offers cafes for employees. It's one of the ways non-urgent but important information propagates around an organization.

Anyone that has worked in the Valley that knows ex-Yahoos have heard crazy, crazy stories of what it was like. I remember hearing a story about an employee who worked there who wanted to quit to do a startup. Her manager panicked, saying, "you can't leave. If you leave, we will lose the headcount because we won't be able to backfill it fast enough." So what happened? The manager made an off-the-books agreement with the person for her to "work from home" for a few more months while the manager scrambled to backfill, still collecting a salary, while doing absolutely nothing at all. I never followed up to see what came out of this. I probably should.

Contrary to the flame-baiting you might see, Marissa is making some progress in turning Yahoo back into a desirable place to work again. I'm hearing from good engineers I know at respectable companies that have either considered it after talking to recruiters or have actually accepted offers. I suspect there is some method to the madness around the remote working policy - we'll just have to see over the long run what shakes out of it.

Learn what you want to learn, because your tools will change. Many Ruby programmers came to Ruby because of Rails. I'm part of the camp that stuck around because of JRuby for a while, but nowadays I find that I write very little Ruby and a lot more Python.

Don't worry too much about what you hear about performance. If you are building a Twitter, then yes, it might matter what language you're learning. Ruby, Python, and PHP tend to be in the same ballpark in terms of performance, with each having their own warts.

As of late, I've been most interested in golang.org. You can learn the basics in an afternoon at tour.golang.org.

It's been a while, but there was a lot of use of Groovy on Grails a few years ago for exactly this reason. I was a strong advocate of JRuby when we did run Ruby code, but it didn't get very far.

It was only the mobile API server. Shameless self promotion: http://news.ycombinator.com/item?id=4615429

LinkedIn isn't constrained to the JVM, as they had some apps running on CRuby 1.8 and node.js, but they do heavily favor the JVM. JVM interop DOES help with much of their existing codebase which is Java heavy.

They remodel the offices pretty frequently. Sometimes ... too often, I think.

The answer is yes. There are lots of non code related things that are done from work pods: reading a design doc, joining a video conference, planning work travel, performance reviews, and so forth (uh ... reading HN on a break). The common spaces are a nice change of scenery. I've worked at places before where I have had 4-5x the amount of office space. Our desk areas are comparatively small, and we are packed close in most instances. As much as I love my standing desk with dual monitors, it's sometimes a good idea to move around to not get cabin fever.

I am, however, skeptical of the people who bring their laptops to work out of massage chairs. I like massage chairs, but they are way too distracting.

Second example: The Golden State Warriors. Go Dubs!

Worked with John briefly when he was with analytics. Great energy and I wish him the best (bummed he is leaving, though)! He's dead on about how much Google invests in their employees. The value of the things I have learned and am still continuing to learn here have been nearly unmatched. The best reason to join Google is that there's always something to learn, and some of the best mentors in the world to help you learn those things.

I think this is only for new customers, not existing ones.

There's space for both. Coding skills are a single dimension, and should never be the sole attribute for hiring good developers. It's about time management, project management, people management. I want to see your code, but I also want to see what you were able to do on the teams you were on. And if you were on a failing product - I want to know that, and ask you why.

There's something to be said about being able to manage successful open source projects with lots of contributors. That's a huge plus in my book. The majority of programmers, though, are not going to be working on projects like this. A smaller plus is when you contribute to a large, quality project, because it shows you can learn to understand a new codebase and determination to get your patch in.

s/recruiters/spammer recruiters

I'm no fan of recruiters myself, but using ONLY GitHub can be short sighted. Not everyone contributes to open source. GitHub has yet to launch products for recruiters. Honestly ... that is a really tough space, and the top guys at GitHub need to figure out if they want to make that a real business or not, because a half hearted investment is not going to benefit anyone.

I think there is some value in LinkedIn integrating with GitHub, but why not just more robust links? What's the value in showing recent checkins, when I can just click through to GitHub and see EVERYTHING?

It's easy to blame LinkedIn here, but this was likely a mutually beneficial outcome agreed on by both GitHub and LinkedIn. LinkedIn didn't want to maintain the APIs GitHub uses; GitHub doesn't want to have to update its app.

There's no such thing as no maintenance cost. Everything has a maintenance cost. Make sure unused code doesn't break takes time and resources. Breaking code makes your product look unprofessional.

I don't think this is what's happening. If I had to guess, they are slowly deprecating the OpenSocial based InApps platform piece (launched in 2008 - http://socialtimes.com/linkedin-inapps-year-end-review-2008_...) by piece. This happened with LinkedIn events. I'm a bit surprised they didn't replace events with a non-InApps based version, migrating the data, but it was probably not deemed a priority.

This reminds me of an older article from the WSJ:

http://online.wsj.com/article/SB113236377590902105.html

Note that Monta Vista doesn't have an entrance exam - parents of students that work hard want to be around students that work at the same level.

"The two schools, put another way that parents rarely articulate so bluntly, are too Asian."

"'This may not sound good,' she confides, 'but their child may be the only Caucasian kid in the class.'"

The difference is that the NYT article emphasizes the students' working class background. In Cupertino, the families tend to be upper middle class.

This article is wrong. Here's why: http://ikaisays.com/2012/10/09/why-the-real-reason-silicon-v...

Hey Michael!

Was there a recent discussion? I'm fairly certain everyone has moved on from Rails, and I'm not sure if they're still using it anywhere at LinkedIn. There are a few folks using JRuby, but I believe they're using Sinatra:

https://www.google.com/search?q=jruby+sinatra+linkedin

Hah, I bet all the new engineers were like, SWEET! I get a system with 36 gigs of RAM!

Then their hearts sank when they realized why.

I don't think it's about the language - it's about knowledge. A backend specialist can learn Javascript but may not know the nuances of working with the DOM, or optimizing for pagespeed, or the important front end libraries. Similarly, a front-end specialist may not have all the experience necessary to diagnose problems in a deployment. That's one reason I don't buy the "front end developers can now do backend development because of node.js" argument. Any sufficient competent backend developer can start writing Python code in a day. What that developer doesn't get in a day is understanding deployments, popular Python libraries, the ecosystem, etc.

(I'm hosted on Wordpress; that's their problem now)

It was a huge gain because the original Rails servers were running on single threaded Mongrel and blocking on cross data center IO.