I’ve been thinking more about Andy Jones’ writeup on the need for engineering.

In particular, my inside view is that engineering isn’t that difficult to learn (compared to research).

In particular I think the gap between being good at math/coding is small to being good at engineering.  I agree that one of the problems here is the gap is a huge part tacit knowledge.

I’m curious about what short/cheap experiments could be run in/around lightcone to try to refute this — or at the very least support the “it’s possible to quickly/densely transfer engineering knowledge”

A quick sketch of how this might go is:

• write out a rough set of skills and meta-skills I think are relevant to doing engineering well
• write out some sort of simple mechanic process that should both exercise those skills and generate feedback on them
• test it out by working on some engineering project with someone else, and see if we both get better at engineering (at least by self reported metrics)

Thinking out loud on the skills I would probably want to include:

• prototyping / interactively writing-and-testing code
• error handling and crash handling
• secure access to code and remote machines
• spinning up/down remote machines and remotely run jobs
• diagnosing crashed runs and halting/interacting with crash-halted jobs
• checkpointing and continuing crashed jobs from partway through
• managing storage and datasets
• large scale dataset processing (spark, etc)
• multithread vs multiprocess vs multimachine communication strategies
• performance measurement and optimization
• versioning modules and interfaces; deprecation and migration
• medium-level git (bisecting, rewriting history, what changed when)
• web interfaces and other ways to get human data
• customizing coding tools and editor plugins
• unit tests vs integration tests and continuous/automated testing
• desk / office setup
• going on walks to think

I think this list is both incomplete and too object level -- the real skills are mostly aesthetics/taste and meta-level.  I do think that doing a bunch of these object-level things is a good way to learn the meta-level tastes.

Maybe a format for breaking down a small (2 hour) session of this, that could be done individually, as a pair, or hybrid (pair checkins inbetween individual work sessions):

• 5 minute checkin and save external context so we can focus
• 15 minute planning and going through a quick checklist
• 25 minute Pomodoro
• 5 minute break
• 25 minute Pomodoro
• 5 minute break
• 25 minute Pomodoro
• 15 minute analysis and retrospective with another checklist

The checklists could adapt over time, but I think would be fine to start with some basic questions I would want to ask myself before/after getting into focused technical work.  They are both a scaffold that best-practices can be attached to, as well as a way of getting written records of common issues.  (I'm imagining that I'll save all of the responses to the checklists and review them at a ~weekly cadence).