I've often thought, would it be useful to create a "Paul Graham Test" based mostly on the essays "Great Hackers" and "Maker's Schedule, Manager's Schedule" as an analogue to the Joel Test. It reinforces some parts of the Joel Test, particularly the unequivocal importance of private offices.

But it seems like so many Y Combinator companies don't embody these quality-first principles, and comments or posts espousing them even here on Hacker News seem to get consistently downvoted or quickly pushed out of the spotlight, or undercut by comments about how wanting an office is "whining" or hijacking the discussion into a debate about headphones vs. real estate costs vs. Agile teams, none of which are relevant.

I really wonder why Y Combinator, as a clear thought leader in the technology start-up space, doesn't vocally support private offices more, given Graham's own unequivocal endorsement of them in an essay about foundational ideas about software productivity and quality.

The same could be said about other topics beyond offices too.

> I really wonder why Y Combinator, as a clear thought leader in the technology start-up space, doesn't vocally support private offices more, given Graham's own unequivocal endorsement of them in an essay about foundational ideas about software productivity and quality. > The same could be said about other topics beyond offices too.

I have wondered this, as well.

Although it's admittedly not entirely charitable, my best guess is that it's because, even to YC, appearances and "social proof" matter more than promoting engineering productivity.

Still, if startup success isn't actually predicated on the benefits that private offices would bring, then there's not much point in YC supporting them.

Sadly, I can't imagine there's anywhere near enough data. The best we'd likely find is cubes-versus-open.

Overall the "Joel Test" is still relevant, but a few of his steps haven't aged well. 3 and 10 in particular.

10 (“do you have testers?”) still seems pretty appealing to me. I still see a lot of value in manual and black-box testing, especially for interactive tools.

#3? What's wrong with daily builds? Or do you mean it doesn't go far enough in that builds should be continuous, done with every code checkin?

The people I talk to, from Microsoft. Disagree. The politics are brutal and the infrastructure brittle and constantly changing (with all the overhead and oversight of a high-security industry like finance) until nothing really gets done.

"Microsoft" isn't really a valid answer to the question in my opinion. The company is huge and culture varies greatly from org to org and team to team.

Even concrete stuff like "offices going away" completely depends on your team.

There is an extremely thin line of commonality that you can pretty easily discern by reading blog posts and watching videos of the CEO and folks like Scott Guthrie; I find what I see in those communications to be genuine.

(disclosure: At Microsoft, and liking the culture)

That's true of the political battles at any large company. However, the question is asking about engineering culture.

Sure, company politics can interfere with this on occasion but it's rare. I read the question more as, "Which companies have the best philosophies regarding how engineering should be done?"

Could be a difference of course, but it's not clear.

link: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...