
A Developer Culture Test - gregdoesit
https://blog.pragmaticengineer.com/the-developer-culture-test/
======
TheCoelacanth
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?".

Many of these are completely subjective. Do you have "Healthy oncall" and
"Technical managers who build trust"? Most companies you could argue either
way.

~~~
netfl0
Came here to say this. I was sorta shocked at the hubris in the title, then I
read the article and was disappointed by the rife subjectivity.

The Joel test is not “feels outdated” and there was no evidence presented to
support the claim.

~~~
ryanbrunner
I agree with the points re: subjectivity, but I do feel the Joel test is
somewhat outdated, if only because everything on there has become table stakes
rather than genuine differentiators.

A 12/12 on the Joel test doesn't mean you're a great company, it means you're
not a total garbage fire.

I'm not going to presume I can come up with a whole new test on the spot, but
I'd expect a "modern" Joel test to have questions like:

\- Do you use CI? \- Do you deploy changes individually? \- Is your code
coverage > (some amount)

~~~
poulsbohemian
>I agree with the points re: subjectivity, but I do feel the Joel test is
somewhat outdated, if only because everything on there has become table stakes
rather than genuine differentiators.

This might be, but there are a whole lot of companies in the world that can't
even make table stakes.

------
l0b0
The original Joel Test was 12 _binary_ 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 _local_ CI
process, which is what you would have to do to run it before even _committing_
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.

~~~
onion2k
The main point of running a CI process is to stop you breaking the build, so
you need it to run before the point where your first build happens. For most
teams that will be on a merge to develop, because develop is deployed to a
test or QA server. It'd be odd to run CI locally but you definitely want it to
happen a long time before anything is ready to go to production.

~~~
clarry
> It'd be odd to run CI locally

Oh, I would if I could. Conceptually, not very different from running make and
fixing any compiler warnings or failed tests before making a commit.

I think that's how a lot of CI gets started: locally runnable tests are
automated to make sure they're always run before the commit lands.

Unfortunately automating CI often pulls a lot of server side infrastructure
and platform specific mechanisms that break the ability to run it locally. I
find it very frustrating to commit, push, wait for server to nag me, fix,
commit again, push again, hope it works this time. It just creates a lot of
noise and IMO doesn't flow very well. I'd prefer to be able to test everything
locally as far as is possible.

~~~
onion2k
One of the nice things about the project I work on is that things like eslint,
stylelint, and the unit tests all work locally inside of Docker, so I can be
sure I'm pushing code to the repo that won't be rejected by CI for code
hygiene reasons. CI runs all that stuff as a check, but it's really there for
the integration and end-to-end tests, and the build and deployment processes.
If you can get your project to work that way it's really nice to have.

------
wincy
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).

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.

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.

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.

------
_hardwaregeek
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.

------
henry_bone
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.

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.

So, it's the relationships, more than anything else, I think.

------
luord
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.

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.

I like this one much better: [https://myers.io/2017/04/04/the-joel-test-
for-2017/](https://myers.io/2017/04/04/the-joel-test-for-2017/)

------
enriquto
This is not a test, it is a list of paragraphs with opinions.

~~~
throwaway_pdp09
That in itself does not make it wrong or useless. What would you suggest in
place?

~~~
enriquto
Either write a test (like joel's test) with clear questions that afford clear
answers, or don't name it a test. The current title is quite misleading. I
have nothing against these opinions, they are quite reasonable, if a bit
vague. But a test they are not.

------
MichaelMoser123
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?

~~~
amzn-throw
I'm not going to be popular by saying this, but Amazon and AWS thrive at every
single one of these.

The only one that I know is not universal is "Healthy oncall".

------
kleiba
"The Joel Test": 12 concrete questions that can easily be assessed.

"The Developer Culture Test": 12 vague statements.

How is this a _test_?

------
troughway
Every single one of these lists have an unwritten clause buried deep in them:

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.

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.

Pray you work underneath one of these saints.

------
vivekv
Isnt this a repost?
[https://news.ycombinator.com/item?id=23192306](https://news.ycombinator.com/item?id=23192306)

------
BurningFrog
> _Is paying attention and acting on microaggressions and unconscious biases
> part of the culture?_

So this is a _woke_ culture test.

The conservative or libertarian half of developers are excluded.

~~~
yakshaving_jgt
I think you need to be more charitable with your interpretation. Sure,
"microaggression" is an incredibly loaded term which I don't think is used
outside _woke_ intersectionality politics (which, I will declare up front, I
think is a terrible thing). However the ability to identify unconscious biases
is an important skill — especially in a hard science — regardless of a
person's political outlook.

~~~
BurningFrog
> _However the ability to identify unconscious biases is an important skill_

I very much agree with that.

But the woke have no interest in exploring that. They already "know" the bias
everyone has. It's part of their belief system, and not open for debate or
reflection.

~~~
vore
Please don't construct a strawman like this. Also, please don't accuse others
of doing the same thing you're doing yourself.

