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