> For a computer scientist, a biologist’s methods can seem insane; the trouble comes from the fact that cells are too small, too numerous, too complex to analyze the way a programmer would, say in a step-by-step debugger.
I think this is probably the part about biology that people outside of biology appreciate the least. We know a lot about how cells and proteins work now. But despite this fact, it is still extremely difficult to understand exactly what is happening within a given cell in situ. Many measurement methods are likely to destroy or alter the thing you’re trying to measure… think Heisenberg’s uncertainty principle - the act of measuring the thing changes its state. Everything is sensitive to temperature, shear, ionic strength, pH, etc… and of course most methods rely on these levers to gain resolution and signal. So you have to have a clear idea of what you think is happening to even select a measurement technique that won’t ruin it. This is part of why, while we know a lot of the fundamentals, it is still hard to engineer functionality in specific environments .. engineering requires a lot of measurement and feedback.
I think that also offers insight into why software can be engineered so quickly. It’s a discipline where you can (relatively) easily place a probe wherever you want and understand exactly what’s happening in a (sometimes) deterministic manner. Everyone else is taking fuzzy shots in the dark compared to software. Imagine replicates being a thing you have to think about when debugging a program. Like in software, running your code again with no changes after it just failed is insanity. In every other engineering discipline, you sometimes have entire meetings to decide how many times to retry something that just failed.
The fundamental challenge of most engineering disciplines is attempting to create a model that represents a useful subset of reality but can be easily reasoned about and is, in some sense, reliable or reproducible. Perhaps what makes computer science unique is how unusually successful it has been in wrangling physics into a machine that appears to execute the laws of mathematics. Physics does rear its head from time to time (e.g. rowhammer and "single-event upsets"), but it is truly impressive how little we have to consider the physical nature of the machine nowadays.
However, other engineering disciplines do also try to build similar abstractions with varying levels of success. We've managed to build simple books of electrical standards that can be used by electricians around the world to build and reason about power systems without having to understand the weird quantum mind of an electron. I suspect we'll get there with biology too, we're just a century too early.
Computer engineering is literally designed to allow the most simple reliable substrate for the most complex possible abstractions to be built upon. It's bizarre (but common?) for computer science practitioners to be strangely unaware of how artificial the tools they use are. Then expecting the rest of the world to be as "simple" as their environment.
Semiconductor processing on the other hand is physics. Success is discovered rather than primarily designed. There are development tools, but things like the "pixie dust" used to avoid the superparamagnetic limit in spinning media were not understood for years after they were commercially shipped in hard drives. Biology/Pharma is much more complex/hit-miss and the biotech industry treats most employees quite badly.
This is exactly why I switched to computer science after finishing my biology BSc.
I don't get nightmares about analytic chemistry anymore, but the level of self-loathing you get from doing labs that never work out for reasons that defy understanding make the annoyance of debugging code seem quaint almost.
(I should really say "it used to", but now that I can run an LLM call locally and get a completely different response than the deployed version of a piece of software, with all other factors seemingly being equal...)
I too switched from biochem to CS: it was such a relief to work in a field where I felt that, as in math, you can get by remembering axioms and rules and derive the rest, without all the arcana of biology. (My mentor in biology bought me a copy of Barrow & Tipler as a parting gift, as if to say, CS and biology are not so different.) Today I’m not sure I still feel that way. Programming is more an empirical than logical discipline that ever before, as programs are too complex to be objects of pure reason; and the layers of stuff one needs to know keep growing in both directions, from SIMD to OAuth.
I’m so glad to come across this writer though. I was going to send them a note to tell them they have a real talent, until I noticed the long list of New Yorker and Atlantic publications, and thought: they already know. :)
Minor nit: the observer effect is distinct from the uncertainty principle, which says that two quantities like position and momentum (“conjugate variables”) cannot simultaneously be known to arbitrary certainty, which is to say, their wavefunctions cannot be simultaneously localized to arbitrarily small regions (of their respective spaces). This applies to any two functions that are Fourier transforms of each other, which position and momentum are (my terminology is sloppy here, but close enough to be useful), and has nothing to do with the change to a wavefunction that occurs by measuring it.
>the trouble comes from the fact that cells are too small, too numerous, too complex to analyze the way a programmer would, say in a step-by-step debugger.
It's like analyzing a Swiss watch if the back was welded on. You could send it though a shredder and analyze the fragments and work backwards to determine the size of the gears. But it's impossible to shred just one watch-- you have to shred a hundred thousand at a time, which are inevitably a complex mix of different watch models each with different minute lengths and hour durations.
Something I have felt is undertaught in introductory biology is how unknown human cells still are! No textbooks wants to list off a thousand proteins with "function unknown" next to them, after all. But to surprisingly large extent it's an undiscovered country. Just in the last few years we're discovering entire new species of RNA! https://www.science.org/content/blog-post/enter-glycornas
Good point. It reminds me of an observation made by Paul Sutter in his podcast [0]. Paraphrasing, there so many layers of emergent phenomena, most of whom we will probably never figure out:
- From quantum fields to atoms
- From atoms to chemistry
- From chemistry to biochemistry
- From biochemistry to cellular life
- From cellular life to multicellular life
- From multicellular life to consciousness
- From individual consciousness to social phenomena
> For a computer scientist, a biologist’s methods can seem insane;
I actually use biological methods all the time, now that I'm a dev. For instance in Biology, gene knock-out experiments are common, where you damage or delete a gene, and see what breaks. You then know that this gene is important for a given thing.
This is the equivalent to the debugging approach of "if I comment out this code, what happens?"
> Imagine replicates being a thing you have to think about when debugging a program. Like in software, running your code again with no changes after it just failed is insanity.
This is a common requirement in software QA. "Can we reproduce the issue? Does it happen every time? Is it sensitive to timing of user actions, or anything else? What part of the initial state of the system could affect this outcome? What other external or environmental changes will alter the result?"
Sometimes, the initial failure seems to have an obvious answer, and sometimes an immediate code change is the best first move. But replicating a behaviour does is insanity.
I think this is probably the part about biology that people outside of biology appreciate the least. We know a lot about how cells and proteins work now. But despite this fact, it is still extremely difficult to understand exactly what is happening within a given cell in situ. Many measurement methods are likely to destroy or alter the thing you’re trying to measure… think Heisenberg’s uncertainty principle - the act of measuring the thing changes its state. Everything is sensitive to temperature, shear, ionic strength, pH, etc… and of course most methods rely on these levers to gain resolution and signal. So you have to have a clear idea of what you think is happening to even select a measurement technique that won’t ruin it. This is part of why, while we know a lot of the fundamentals, it is still hard to engineer functionality in specific environments .. engineering requires a lot of measurement and feedback.
I think that also offers insight into why software can be engineered so quickly. It’s a discipline where you can (relatively) easily place a probe wherever you want and understand exactly what’s happening in a (sometimes) deterministic manner. Everyone else is taking fuzzy shots in the dark compared to software. Imagine replicates being a thing you have to think about when debugging a program. Like in software, running your code again with no changes after it just failed is insanity. In every other engineering discipline, you sometimes have entire meetings to decide how many times to retry something that just failed.