One of the strengths of the Joel test is that it is very objective. There is no wiggle room on "Do you use source control?" or "Do you have a bug database?".<p>Many of these are completely subjective. Do you have "Healthy oncall" and "Technical managers who build trust"? Most companies you could argue either way.
The original Joel Test was 12 <i>binary</i> and mostly answerable questions, rather than an invitation to BS candidates. This test might be salvageable by cutting it down to the hard questions underneath. For example, "Do you have CI process setup that runs before committing the code?" is one of the best questions here, but rather than "before committing" it should probably read "before deploying to production". I don't think I've ever heard of a <i>local</i> CI process, which is what you would have to do to run it before even <i>committing</i> the code (or maybe the author meant a pre-commit hook?). I would suggest something with little wriggle-room like "Do you run every change through an automated QA process before being able to deploy it to production?" That is, nothing ever gets to production unless the automated (and ideally extensive) process succeeds.
I like this list. I’m at a Fortune 500 now after being unceremoniously dumped by a company that was trying to get themselves sold to private equity (If you watch daytime television in the USA you’ve probably seen the old company, and likely never heard of my current employer).<p>Being able to correct code on other teams if we’re blocked with a pull request, versus having no idea who owns the code and being actively stonewalled and ignored by people at the old place. Having documentation and business requirements written up vs being given source code and the old developer rage quit. Having a competent BA who is competent enough to read code vs having a BA whose job is literally only to ask me to update my tickets and badger me to write up the requirements to hide their own incompetence. Having good conversations about the tech we use vs feeling gaslit when mentioning a potential solution to a technical problem and having nobody respond or make eye contact.<p>Realizing that everyone who had been there a long time had the personality of a whipped dog. My coworker had letters from his wife encouraging him letting him know he could do it if he just worked hard! Which I suppose worked until the entire dev team got fired a year after I did.<p>I was really scared after leaving a great job and moving to that terrible one that I’d made a terrible mistake and most dev shops were just awful. Maybe they are but I’m glad I stayed where I am, I got an offer to make way more but I’m 100% sure I’d be laid off now due to covid-19 if I’d jumped ship. Based on my companies response to Coronavirus I think I might stick around for a long time.
What I like about the Joel Test is that it's not a test about whether your company has good working environments. Good is extremely subjective. Good depends on what you want. The Joel Test is a test about whether your company has adequate working conditions. Many of the points are no brainers. If you don't use source control and you don't have testers and new candidates don't write code, well shit, that's pretty damn bad.
I find that what keeps me at a workplace are the relationships that I form there. When I enjoy the company of the people that I work with, then I enjoy coming to work, even if the work itself leaves a bit to be desired.<p>I guess that this perhaps implies that communication is good and so all the desirables (code ownership, reviews, transparency, clarity of responsibilities etc) fall out as a result of a group of people relating well.<p>So, it's the relationships, more than anything else, I think.
Of all the updates to the Joel test I've read, this is by far the most... Nebulous. Maybe even asinine because even if you were to ask this in an interview, the interviewer could reply to half it these with a bland "yes" and there's really no way to confirm or deny during the interview since it's all based on opinion.<p>In the best scenario, the affirmative answers were straight up lies and then you know immediately that the organization is not for you (but only until after you join). In the worst scenario, the "yes" was actually honest and it turns out that you disagree with the company on what makes for good "celebration of initiative" or "trustworthy management" and suddenly you're the bad guy for disagreeing.<p>I like this one much better: <a href="https://myers.io/2017/04/04/the-joel-test-for-2017/" rel="nofollow">https://myers.io/2017/04/04/the-joel-test-for-2017/</a>
this reads like science fiction to me - all quite different to the work culture that i experienced; are there any examples of real companies that practice a significant subset of these principles?
"The Joel Test": 12 concrete questions that can easily be assessed.<p>"The Developer Culture Test": 12 vague statements.<p>How is this a <i>test</i>?
Every single one of these lists have an unwritten clause buried deep in them:<p>This has nothing to do with culture, because it's not like everyone who joins a company is somehow a magic promoter of all these things.<p>Rather, it's usually one or more people at top of the hierarchy who set the tone. An enforcer saint. Everyone else is just following orders.<p>Pray you work underneath one of these saints.
Isnt this a repost? <a href="https://news.ycombinator.com/item?id=23192306" rel="nofollow">https://news.ycombinator.com/item?id=23192306</a>
> <i>Is paying attention and acting on microaggressions and unconscious biases part of the culture?</i><p>So this is a <i>woke</i> culture test.<p>The conservative or libertarian half of developers are excluded.