

The Rands Test - filament
http://www.randsinrepose.com/archives/2011/10/11/the_rands_test.html

======
jasonkester
I normally find this author quite enjoyable to read, and this seems like "the
piece" he's been wanting to write for a long time. So it's surprising to find
it thrown together so seemingly hastily and written so poorly.

It starts off with a couple paragraphs filled with non-parsable sentences like
" _I was employee #20 at the first start-up and the first engineering lead_ "
(which start up again?) and " _A growing groups needs to continually
invest..._ ", and then it spends four full paragraphs talking about "1:1",
without ever bothering to define what a 1:1 is. It sounds like it must be a
meeting of some type, but not one I've ever heard of, and as far as terms go,
it seems to be almost designed to be non-googlable.

I gave up at that point.

So hey, Rands, if you're reading this. I (and probably others) would really
appreciate it if you gave this article another edit or two. Put it back up
here when it's ready!

~~~
rcfox
For what it's worth, 1:1 is also known as a one-on-one. Basically, just a
meeting between you and your boss.

He describes it fairly well here:
[http://www.randsinrepose.com/archives/2010/09/22/the_update_...](http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html)

------
JBiserkov
What I really like about The Joel Test-the-article
(<http://www.joelonsoftware.com/articles/fog0000000043.html>) is that it
contains links to other articles presenting the individual points in more
detail and providing context some readers are complaining is missing in the
Rands Test.

It kinda serves as an "index.html" to all of Joel's writings, the page that
you can point a novice to and let them explore from there.

------
georgieporgie
I completely disagree on status reports. I've only worked at one company where
we sent them weekly. I found them invaluable for looking back over what I'd
accomplished. I viewed it more as a weekly journal than a tool of oppression.

That said, the rest of the management system was in shambles, and they'd have
failed nearly every other question. I don't believe that inherently makes
status reports a bad thing, though.

~~~
ajryan
If you wrote something in your journal/status report that was useful it
probably would have been more useful in your bug/task tracker or wiki or
somewhere else that your colleagues could find it in context.

~~~
Periodic
This is the real point the author is trying to make. Any information you would
put in a status report should already be in another system already. You have
your task and project management system, your bug tracker, your version-
control system, and your code-review system. All of these should list
essentially all the things you've done and it would be easy to look back over
a historic list for your user.

Status reports are generally duplication, and if they aren't, then the tasks
are not being tracked properly.

~~~
snprbob86
Not everything can easily be itemized into a bug tracker or project management
system. Sometimes you just need to tell a story. This is particularly true in
disciplines outside of engineering.

~~~
dpritchett
That's where the well-run meetings come in.

~~~
snprbob86
Not all teams are co-located. Real-time communication mediums are sometimes
the wrong choice, like when you need to curate your message. Meeting minutes
are just another kind of team-wide status report. Collaboration is complex and
nuanced. Status reports have their problems, but they have a place.

