[COFF] [SPAM] Re: [TUHS] Re: [SPAM] Re: Re: Hypothetical: Could MULTICS have been written in C, if available?
Adam Thornton via COFF
coff at tuhs.org
Thu May 28 10:44:20 AEST 2026
"Sweep the floors" is an interesting one (I think you've mentioned it here
before).
I mean, yeah, sure, if it needs doing, it needs doing, even if it's not in
my job description. Hand me the broom.
But really that opens a whole host of other contingent questions.
I've worked at startups where, yeah, we were all expected to clean up the
place, and answer the phone, and take the outgoing mail down to the post
office, and shovel snow, because it was like four people in a rented shop
in a strip mall (or sometimes a townhouse that was definitely not zoned for
business, but hey, whatever) and there was no provided-with-the-rent
facilities maintenance. A little skunkworks place like that, yeah, that's
not even a strange request (although I would find it weird and off-putting
if I were the *only* person asked to do various jobs that larger offices
tend to have staff for).
But if it's a Fortune 500 company operating out of a standard professional
office park somewhere, it *would* be bizarre if it were a habitual request
(stuff can always go wrong: the janitor called in sick one day, or
whatever, sure, gimme the broom; I'm talking about, I'm often being asked
to sweep up). Why does someplace like that not have someone assigned to
the site whose job it is to make sure there's toilet paper in the bathrooms
and to keep the floor clean? I'd probably take that as an alarming sign if
I was interviewing. (In retrospect, I should have been more wary about an
IT job I took--in the healthcare industry!--where the toilets were just
about the filthiest I've ever seen in a developed nation. That should have
been a red flag the day I interviewed.)
Likewise, if it's somehow become my job to be the facilities maintenance
guy, it feels like there's a management problem, in that if I'm cleaning up
the place, I'm probably not developing software at the same time[*] and in
general you don't have to pay janitors as much as you do software
engineers, so every minute I'm scrubbing a toilet is a minute you're paying
me way too much to do that and paying me, at least as importantly, *not* to
solve your software engineering problems.
Adam
[*] Actually I'm not certain about that. It often is the case that if I'm
stuck, it helps if I get up and walk around and do something that isn't
programming (sometimes, in fact, just pacing the building halls) in order
to let my back-brain chew on a problem, and then when I get back to my
desk, I have some ideas I didn't when I got up, so it's plausible that
taking a sweeping break would do something similar for me.
On Wed, May 27, 2026 at 2:28 PM Larry McVoy via COFF <coff at tuhs.org> wrote:
> On Wed, May 27, 2026 at 12:56:52PM -0700, Adam Thornton wrote:
> > On Wed, May 27, 2026 at 11:01???AM Larry McVoy via TUHS <tuhs at tuhs.org>
> wrote:
> >
> > > I took a different approach, we hired excellent programmers
> > > and our stuff worked.
> > >
> > >
> > This is probably a COFF question, but I'm interested in your process for
> > hiring excellent programmers. CCing to COFF and I suggest we continue it
> > there.
>
> Strangely enough, a lot of the same stuff your current boss wrote up.
> The technical part is pretty easy, the core of my team were all top 1%
> programmers. Those people tend to recognize that talent up front.
>
> We had two compatibility tests and one question (that well over 90% of
> programmers fail).
>
> If we needed you to sweep the floors, would you?
>
> We asked ourselves if the recruit passed the super market test. If you
> saw them at Safeway do you want to go talk to them or do you want to
> hide in another isle?
>
> The technical (sort of) question was from me and it had a lot to do with
> the fact that we were a small team and I wasn't interested in managing a
> large team: Tell me about something that you built, at least 10 other
> people have used it without contacting you other than to thank you. By
> "built" I mean you identified the problem, came up with a solution,
> packaged it up, announced it on comp.sources.whatever (or hackernews
> for you youngsters). You did the README, the man pages, any web support
> needed. You wrote test cases. You did *everything*. No support staff.
>
> I had an example that I did as a student, I wanted to have regexp version
> of mv/cp. I called them move.c and copy.c and did a shell function like
> so:
>
> function mv {
> case "$1" in
> *=*) move $*;;
> *) /bin/mv $*
> esac
> }
>
> and then you could do
>
> $ mv =.c =.c++ # bad example, in poor taste :-)
>
> I wrote the code and docs and packaged them up into a shar file and
> announced on comp.sources decades ago.
>
> My example was delibrately choosen to be something simple. Complexity was
> not the point, completeness was.
>
> Very, very few people passed this test. I hired people who didn't but
> I liked working with the people who did, better. There is something
> satisfying about working with someone who understands what "it's done"
> actually means.
>
> All the engineers interviewed every engineering candidate so other
> folks may have had other questions. I remember there being widespread
> agreement on the sweep the floors thing and the supermarket thing.
> I believe both of those came from Bill Moore (ZFS guy), he had gotten
> them from other startups.
>
> --lm
>
More information about the COFF
mailing list