Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Adam Thornton <athornton@gmail.com>
To: Warner Losh <imp@bsdimp.com>
Cc: COFF <coff@tuhs.org>
Subject: [COFF] Re: [TUHS] Interview question
Date: Wed, 4 Jan 2023 10:51:08 -0700	[thread overview]
Message-ID: <5F32EB3A-A50F-4996-84DB-6B3DC2BFA96A@gmail.com> (raw)
In-Reply-To: <CANCZdfrjXF7hQBax6my0x+vQUqujsZGYjZKyJ0vZ+NRMYNb4pw@mail.gmail.com>



> On Jan 4, 2023, at 9:00 AM, Warner Losh <imp@bsdimp.com> wrote:
> 
> The best programmers I've ever worked with understood teamwork and the team produced something way better than what any one of us could do (this was back in the days before egoless programming, CI, code reviews, etc), so we invented the bits that worked for us on the fly). The thing is, every single person on that team could (and often did) work on any aspect of the product, be it the documentation (though the tech writers usually did that), the code (the programmers usually did that, but the tech writers committed fixes to the example code that was in the book), to the printer being out of toner / paper, the soda supply in closet running out, the snacks that we got at costco running low, stuffing product into boxes to ship to customers, handling customer calls, dealing with talking to customers at a technical conference in a sales booth, presenting papers at conferences, etc. Nobody did anything entirely by themselves. We interviewed several 'lone wolves' that had done it all, but found the one we hired couldn't integrate into our pack because they couldn't be part of a team and put the team first and the group needs ahead of their own. That's the Genesis of my mistrust of this question, or at least the premise behind it. And Dan, these 'scut tasks' weren't about hazing, but just about doing what needed to be done...

One of the things that makes working in my team at the Rubin Observatory the best job I've ever had is that our manager is brilliant at hiring smart generalists who can play nice together.  It's not that we can all do everything: I'm pretty terrible at RDBM stuff, for instance (I have learned a fair bit about time-series databases in the last year), but in a pinch, we can step in and try and get each other unstuck, and between all of us we have a lot of experience and our hunches have gotten pretty good.

And honestly, it's just a lot more fun to have other people to bounce ideas off of and to make the stuff I'm writing better through thoughtful code reviews.  Sure, I have done solo projects that saw the light of day, some very very large (that text adventure is the second-biggest Inform 7 project I'm aware of, and it took a decade or so of free-time screwing around, on and off; it's got a good-sized novella, anyway, of text displayed to the player, and all the logic wrapped around that probably doubles the size[*]), but the stuff I am most proud of currently (which is the conversion of the JupyterHub Kubespawner to coroutines) was a maintenance project.

I didn't own the original codebase, my work went through several rounds of internal review before we submitted it upstream, and then it went through a couple more rounds of review with the project maintainers before they accepted it.  But accept it they did, and our spawn error rate is less than 10% of what it was with the thread-based version.  And to get that last 10% down significantly farther we're going to have to abandon their spawning model entirely, which is the right decision for the Rubin Observatory but almost certainly the wrong one for the vast majority of sites who want to run JupyterHub/Lab under K8s.

Adam

[*] Inform 7 is a weird language.  It's fundamentally declarative, and in some sense wants to make the experience of writing a text adventure a lot like the experience of playing a text adventure.

  parent reply	other threads:[~2023-01-04 17:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230102203646.GT25547@mcvoy.com>
2023-01-02 21:13 ` Adam Thornton
2023-01-03  2:58   ` Larry McVoy
2023-01-03  6:06     ` Dave Horsfall
2023-01-03  6:16     ` Adam Thornton
2023-01-03 15:57     ` Warner Losh
2023-01-03 19:53       ` segaloco via COFF
2023-01-04  2:44       ` Bakul Shah
2023-01-04  3:06         ` Larry McVoy
2023-01-04 15:42           ` Dan Cross
2023-01-04 16:00             ` Warner Losh
2023-01-04 16:52               ` Dan Cross
2023-01-04 17:51               ` Adam Thornton [this message]
2023-01-04 16:06             ` Larry McVoy
2023-01-04 16:58               ` segaloco via COFF

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5F32EB3A-A50F-4996-84DB-6B3DC2BFA96A@gmail.com \
    --to=athornton@gmail.com \
    --cc=coff@tuhs.org \
    --cc=imp@bsdimp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).