sfrench

That is the room where all of the eng team worked, but certainly not how it looked on a normal day. If you look, you can spot three clusters of 4 desks around the edges of the room in this picture. There were ~10 clusters of similar size that scattered around a large open space.

The worst part about that room was not the open feeling, but rather the silver walls and ceiling

Sometime around 8-10 years ago, requiring company approval for secondary sales started becoming a popular restriction to put into ISO grants (prior to that, it was just right of first refusal on sales). It's largely unfavorable to employees, but it does prevent some pretty bad situations. The benefits of this restriction were explained to me as two major things:

1) By preventing secondary sales, the company can control the going price for the stock. This means when the company has an independent third party do a 409a valuation, they don't have to take into account high third party sales, which would push the 409a up. Not inflating the 409a is beneficial to employees that want to leave the company and exercise stock. It means their AMT tax hits won't be as bad.

2) It also means the company/board get to control who are investors in the company, and thus who has the ability to request to relevant internal company information (like financials).

Given I had a job while interviewing, I was driving it as fast as I was comfortable. But the part that was important to me as a candidate is that I was getting feedback within 1 business day, and getting the next step scheduled for later that same week.

I previously worked at Stripe. Mark's post mirrors my experience internally as a hiring manager, and as a candidate. But as you said, at scale things get harder; I'm sure the experience does vary and some percentage of people come out with experiences that don't match the ideal.

My own experience was that Stripe was able to take me from a prospect to a hire in less than 30 days. My interviews and calls were all on Friday, and I would hear back on Monday with results and schedule the next round for that very same week.

My last 2 jobs have been working on developer productivity for 100+ developer organizations. One is a monorepo, one is not. Neither really seems to result in less work, or a better experience. But I've found that your choice just dictates what type of problems you have to solve.

Monorepos are going to be mostly challenges around scaling the org in a single repo.

Polyrepos are going to be mostly challenges with coordination.

But the absolute worst thing to do is not commit to a course of action and have to solve both sets of challenges (eg: having one pretty big repo with 80% of your code, and then the other 20% in a series of smaller repos)

I’m happy my stuff didn’t require multiple pages :)

I was chatting with one of the developers on this project this morning and seeing how we could integrate it into one of our projects. He mentioned that a simple js bundle version is coming soon so that you can just include it and start playing without having to worry about npm.

If you have a car, or don't mind jumping on Caltrain for the ride down, you can go to Mountain View to the Computer History Museum: http://www.computerhistory.org/

So interesting that this comes up today. We were discussing this yesterday in relation to an upcoming project where we want to maintain some amount of data for visitors to a website, but don't necessarily need to retain data for the visitors that we see very few times.

A couple years ago at a company hackathon, I took this approach, and then just baked these same tools into the app directly.

Django middleware to turn on/off and collect & store the profile data, and then a developer interface to read the stored profiles and render in SVG using pydot.

First off. You can learn on anything, so get whatever guitar you feel most comfortable playing (comfortable playing is the utmost requirement here). You absolutely have to go to guitar stores and have the guitar in your hands and in your lap. If you can't play, make sure to take a friend that can, as they'll be able to tell you if the guitar is "meh" or not.

Spend as much as you comfortably can, but don't kill your bank account. If you can, $500-$1000 is a good range and you have lots of good-quality options in both electric and acoustic.

I'm totally biased on the electric/acoustic debate. I've played almost exclusively acoustic for 20 years, and obviously prefer them. So from here, I'll dive into acoustic specific stuff if you decide to go that way.

Size/Nut Considerations: Two important things to pay attention to are the body shape/size (Dreadnaught/OM/000/00/ etc), and the width of the fingerboard at the nut. These are just some huge generalizations, but if you play a lot of fingerstyle, a OM/000 with a 1 3/4" nut may be what you're looking for. Whereas if you like playing bluegrass, you'd probably like a Dreadnaught with a 1 11/16" nut.

Woods: In addition, pay attention to woods the guitar is made of. Spruce and Cedar are going to probably be the two most common top woods, and Rosewood and Mahogany are going to be the most common back woods. Make sure to play combinations of these woods and figure out what you like. Most importantly, if you are paying more than $500 for a guitar, make sure that the top, back, and sides of the guitar are made of solid wood (no HPL, carbon fibre, laminates, plastic, etc.) If you are spending less than 500, make sure you at least get a solid top on the guitar.

Suggestions: In the 500-1000 range check out Loar, Recording King, Blueridge and Larrivee guitars. I've also heard good things about the Epiphone Masterbilt guitars. Some specific models to check out: Loar LH-250, Blueridge BR-140 (or BR-160), Recording King RD-310, Larrivee OM-03, Martin MMV (if you can find one), Martin 000-15 (or 00-15 or OM-15 or D-15),

In the 1000-2000 range Martin 18-series, Taylor 300 and 400 series, and Larrivee 5-series guitars are great choices. Some specific models to check out: Taylor 312/314, Martin OM-16GT. Martin OM-18 (or D-18)

I was a developer at digg from 2007-2010, and I can say his statement is just flat out wrong. Digg did hire great PHP programmers, but that was because they were great programmers, overall. Every single one of them moved, with ease, to other languages when required. In fact, a majority of the backend of v4 was written in Python.

It's also interesting to note that most ex-digg engineers primarily work in a language other than PHP currently.

Owen, I think your memory is a little fuzzy on this. If you recall, we overlapped for a few months in 2007 before you left, and the "lots of women" you describe just weren't there.

If I had to guess, it just flew under the radar enough to not be noticed. I'd bet they probably will have a C&D soon (if not already).

disclaimer: I used to work for Digg

This article feels very hastily thrown together.

No mention of APC and they didn't even bothering to discuss profilers beyond a link (which doesn't even return xhprof on the first page!)

The getter/setter thing is the perfect definition of a premature optimization. Making that optimization will result in an infinitesimally small gain compared to what could be had optimizing bad SQL and caching deficiencies.

Check out the JGI, their office is in Walnut Creek (you'd have to commute a bit, but it's exactly what you're looking for I'd assume)

http://www.jgi.doe.gov/whoweare/employment.php

I just saw the 120"x30" print rolled out in front of my office a couple days ago. I think the biggest challenge is figuring out a way to mount a rolled print that big without stabbing it with pushpins.

Netflix (who also survived the outage) wrote a blogpost last year in which they talked about a system they call "Chaos Monkey" which does this exact thing.

http://techblog.netflix.com/2010/12/5-lessons-weve-learned-u...

This is correct, BART stops in Millbrae.

The San Francisco Caltrain stops are at 22nd (in potrero hill) and 4th and King (SOMA). If you don't live in either of those neighborhoods, you'll need to take a bus or MUNI train to the station.

I just fired it up on a couple devices, and it's not very intuitive. It's a great idea, they just need some UX help now.

| What is a slow query log?

It's basically a log kept of queries that are running slower than a set threshold.

Read through this for the details to set it up and access it: http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

Looks like you probably can.

http://www.rackspace.com/cloud/blog/2009/07/30/setting-up-me...

I did a very similar hack for local gyms, but I keep it granular down to the individual checkin so I can do rollups on each hour over the week.

There really is an interesting post-mortem to be had, but I'm just not sure you're going to be able to interview employees to get it. The most candid talks happen between employees in IM conversations and over beers, and likely won't be hashed out online.

I loved my time at Digg. I worked on some great things, learned a ton, and yes, came out with some cautionary tales that will serve me well through my career.

I'm not sure he said that. I think if anything, he made the strongest case for Portland.

I think he does sell San Francisco a bit short in the beer department. While the city itself isn't known to produce a huge amount of widely known brews, there are a couple good breweries in the city limits. Additionally, some of the best beers in the world are all made within a half-day drive of San Francisco (Russian River, nuff said).

It "feels" wrong, but that's the way it's set up.

I used to work for UCOP (it's in the list), and about 5 years ago there was a big issue around "total compensation" for the high-level employees. That was the event that really sparked the level of transparency that you see in this database. Around that time, I recall my manager basically telling us that our salaries were all printed out in some book in Sacramento, and that people could look them up if they really wanted to. I guess the online database just makes it seem a bit too easy.

If you care more about the UCOP stuff google for "UCOP Compensation SFGate" you'll get plenty of info. Here are a couple links to get you started on what was going down:

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2005/11/13/...

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2005/11/13/...

Kevin mentioned it somewhere a few weeks ago. I forget where though.

I used to work at digg as a engineer. I won't say your distribution numbers are correct, but you've got the gist. There are multiple environments, reserved capacity, research and testing machines, etc.