34 Years in the Panopticon: Specifications, Formal Methods, and the AI Inflection Point

Monday 2/24/2026 marks 34 years since I started working full-time post-undergrad (2/24/1992). Another lap around the sun in what I've come to think of as the long game of systems software.

Last year's post https://vzimmer.blogspot.com/2025/03/33-years-in-panopticon-books-et-al.html touched on the "prisoner missing his cell" metaphor—retirement that didn't quite stick. A year later, I'm increasingly convinced we're at an inflection point where the nature of the cell itself is changing. Not just in work practices, but in what "work" fundamentally means in software engineering.

The Specification Bottleneck I've been reading through research on https://latentintent.substack.com/p/model-intelligence-is-no-longer-the, and it crystallized something I've been observing: **AI models can now match IMO gold medalists at formal mathematics but struggle with basic enterprise CRUD apps**. The paradox isn't about intelligence—it's about specification completeness. When we write code, we're performing lossy compression of intent. The "why" gets lost in the "what." In a human-to-human handoff, we reconstruct intent through context, documentation, and institutional knowledge. But when AI enters the loop, that lossy compression becomes the bottleneck. Consider the analogy: **Prompting an AI and keeping only the generated code is like compiling source code and keeping only the binary.** Sure, it works—until you need to modify it, debug it, or extend it. Formal Methods Go Mainstream (Maybe?) The fascinating development is that formal specification is becoming tractable at scale. DeepSeek-Prover-V2 https://github.com/deepseek-ai/DeepSeek-Prover-V2 demonstrates AI decomposing complex theorems into subgoals and synthesizing complete formal proofs in Lean 4. This bridges informal reasoning (the "why") with formal verification (the "what"). I've spent a lot of time recently writing lean files to help prove properties of well-beloved specs and code. I keep thinking about Gödel's Loophole https://en.wikipedia.org/wiki/G%C3%B6del%27s_Loophole—when Kurt Gödel prepared for his U.S. citizenship exam in 1947, he discovered what he believed was a logical inconsistency in the Constitution that could legally transform it into a dictatorship. The exact loophole was never published (Einstein and Oskar Morgenstern deflected the conversation during his citizenship interview), but the incident illustrates something profound: **Even the most carefully crafted specifications contain contradictions that aren't apparent until subjected to formal analysis.** This is precisely what we need for specifications: - Intent conflict detection (like Gödel found in the Constitution) - Ambiguity highlighting (what happens in this edge case?) - Property-based examples (concrete test cases from abstract properties) - Traceability (why was this constraint added?) "Specs as Code" and Model Specifications There's a convergence happening. https://model-spec.openai.com/2025-04-11.html represents an attempt to precisely define intended AI model behavior through structured specification rather than ad-hoc training. The spec includes a "chain of command" for resolving conflicting objectives (helpfulness vs. safety vs. legal compliance) and aims to be machine-checkable. This mirrors the broader shift: from implicit behavior to explicit intent. The https://arxiv.org/abs/2310.16218 research explores how to update LLMs with new knowledge without catastrophic forgetting. The parallel to specifications is clear—we need specifications that evolve without losing historical context. Version control for *intent*, not just code. The New IDE If specs become primary artifacts, we need different tools. Current IDEs help with: - Syntax highlighting and completion - Type checking - Refactoring and navigation - Debugging execution The **Specification IDE** needs to help with: - Intent documentation (capturing the "why") - Ambiguity detection (underspecified requirements) - Consistency checking (finding contradictions, à la Gödel) - Example generation (property-based tests) - Traceability (linking intent to generated code) - Intent diff (showing how specifications evolved, not just code changes) Imagine a git diff that shows: ``` - System should handle "reasonable" load + System should handle 10,000 req/sec with p99 latency < 100ms ``` That's far more meaningful than 500 lines of changed code. The Constitution Problem in Software The Constitution analogy runs deeper. Constitutional amendments show intent evolution—the 14th Amendment doesn't delete the 3/5 Compromise clause from the original document; it adds context that overrides it. Historical decisions are preserved with their rationale. Software specifications need this same property: new requirements added with rationale, contradictions flagged, historical decisions preserved. We don't just want the latest version; we want the *evolution* of intent with full context. This is particularly relevant for firmware and platform security—domains where specifications have historically been underspecified, leading to vulnerabilities when implementations made different assumptions.

Democratizing Software Development

Here's where it gets interesting: **when the spec is the code, domain experts become first-class contributors**. Today, contributing requires understanding programming languages, frameworks, design patterns, and deployment pipelines. But specifying intent? Domain experts already do that. A medical professional can specify record requirements. An accountant can formalize tax calculations. A compliance officer can define regulatory constraints. With AI handling spec-to-code translation, the programmer's role shifts from writing code to: - Architecting systems - Designing specification languages - Building verification pipelines - Reviewing generated implementations The Year Ahead At 34 years in, I find myself more interested in the meta-problems than the object-level problems. Not "how do we implement secure boot?" but "how do we specify secure boot such that implementations can be verified and evolved?" The companies and teams that figure out how to capture, maintain, and evolve specifications will have a massive advantage as AI code generation commoditizes implementation. The bottleneck isn't "can we build it?" anymore. It's "can we specify what we want clearly enough?" That's a fundamentally different problem—and it requires fundamentally different tools, skills, and mindsets. --- Random Observations **On AI and "Specs as Code"**: Found an interesting talk reference on https://www.youtube.com/watch?v=8rABwKRsec4 that I need to dig into more. The idea that specifications should be executable, testable, and versioned isn't new—but AI makes it practical.

**On OpenAI's Model Spec**: https://model-spec.openai.com/2025-04-11.html dedicates itself to the public domain with CC0 1.0. That's a statement—they want the specification approach to proliferate, not the implementation details.

**On Formal Methods**: DeepSeek-Prover-V2 using Lean 4 is significant. Lean has always been the "we'll use this in 20 years" formal system. Maybe that timeline just compressed.

**On Work Longevity**: Someone mentioned that if you're still working in tech in your 50s, you're "doing it wrong." I prefer to think I'm doing it *differently*—focusing on problems that compound over time rather than chasing the next framework.

**On Retirement**: "RETIREMENT FAIL!" still makes me laugh. But I'm not sure I failed at retirement as much as retirement failed to provide the intellectual leverage I was looking for. There's something about working on problems that outlive you that's deeply satisfying.

** On applying formal tools to firmware: I dabbled a bit with an innocuous aspect of firmware and formal tooling https://github.com/vincentjzimmer/Documents/blob/master/differential-formal-verification-uefi-dxe.pdf as a UW grad student on leave from AI program..... I need to polish up some of the lean4 work that might be of interest, too, along with rocq, hol, etc. This study was sort of an homage to hard time in PI cores at job.last and job.last.last I suppose.

---

The specification is the new code. The question is: are we ready to think differently about what "writing software" means?

On to year 35.

Full circle

It looks like the bricks-and-mortar Microsoft library in Redmond is closing https://www.geekwire.com/2026/microsoft-campus-library-closes-in-broader-shift-to-ai-powered-digital-learning-experiences/.  I fondly mentioned this building in posts like https://vzimmer.blogspot.com/2025/03/33-years-in-panopticon-books-et-al.html. 

Meanwhile in downtown Seattle I discovered https://www.spl.org/

So why am I in downtown Seattle these days? Well, it's proximate to the Anduril https://www.anduril.com/ local office https://www.cnbc.com/2025/06/10/anduril-cnbc-disruptor-50.html

on the Seattle waterfront where I work.

To me Anduril Industries (AI) is sort of the convergence of many themes of cybernetics, a topic I mentioned earlier in https://vzimmer.blogspot.com/2012/10/did-book-inspire-your-choice-of.html. This includes Wiener's innovations in control theory and math that led to things like automated anti-aircraft https://www.columbia.edu/~jrh29/licklider/lick-wiener.html. 

Working with modern AI systems reminds me of a quote I heard from a Nvidia scientist in podcast where she mentioned that today's AI is really 'applied signal processing.' This appeals to both the EE in me with signal processing, real analysis, hardware, etc, and the CS part of me with system software, logic, and security. 

Also Norbert W. did logic at beginning and then the plumbing around control theory and signal processing later. So perhaps that's an arc, too?

I say 'full circle' in the blog title, though, to reflect my professional journey. My first post undergraduate job was at Daniel Industries where I worked on embedded firmware for flow computers that had various themes of safety, embedded, values, signal processing, sensor fusion - building robots to control and monitor gas flow. And now to Anduril to go fully into autonomous robots for sea, land, air and space.

Interesting times.

big money, open source, papers

It was interesting reading the recent article https://techcrunch.com/2025/06/17/sam-altman-says-meta-tried-and-failed-to-poach-openais-talent-with-100m-offers/. What caught my eye was the mention of Noam Brown https://noambrown.github.io/

The name sounded familiar and then I recalled the talk at UW https://www.cs.washington.edu/news-events/event-details/?id=3334. It was one of the rare talks that wasn't recorded to YouTube, but I did catch a few interesting screen shots.

I like the fact that games like Poker are a fertile area of research with AI.  It reminds me how probability and games of chance informed so many other engineering domains, like information theory and signal processing.

On the topic of research and closer to home, I recently saw a paper about using CheckedC C dialect  https://www.checkedc.org/ in EDKII https://dl.acm.org/doi/10.1145/3728929. Apparently there is LLM support now https://github.com/3clsp/checkedc-llvm-project and a repo of the work https://zenodo.org/records/15192126.  It appears CheckedC came out of Microsoft Research (MSR) https://www.microsoft.com/en-us/research/project/checked-c/ a decade ago.

I still believe the future is Rust, but the above effort provides an interesting insight into some evolutionary alternatives. Speaking of MSR and Rust I was happy to see the work on porting SymCrypt to Rust and using formal methods pioneered in MSR for assurance, too https://www.microsoft.com/en-us/research/blog/rewriting-symcrypt-in-rust-to-modernize-microsofts-cryptographic-library/.

I am a believer in open source and publications. I find some of these papers since they cite earlier work I've done, whether it was early attempts as Rust firmware in Redleaf https://dl.acm.org/doi/pdf/10.1145/3317550.3321449 that quote the symbolic execution paper https://www.usenix.org/system/files/conference/woot15/woot15-paper-bazhaniuk.pdf or the above spatial memory safety CheckedC work above that cites some of the beyond BIOS papers

If you can wade through the patent citations of curation sites like https://scholar.google.com/citations?user=9fW87_IAAAAJ&hl=en&oi=sra 

you can see how books like Beyond BIOS https://scholar.google.com/scholar?oi=bibs&hl=en&cites=15000311566023066784,2826375497166231441&as_sdt=5 and the symbolic paper https://scholar.google.com/scholar?oi=bibs&hl=en&cites=11728545597760724102&as_sdt=5 are leveraged by others.

I will continue to opine on this topic of open source and publications being a positive flywheel for industry on another day.  Here's looking to close June of 2025 with a short blog.

Turbulent weather, books, and new jobs

Weather issues https://mynorthwest.com/4010489/cliff-mass-warns-of-powerful-storm-approaching-western-washington/ have impacted the region recently. The power at my home was out for a few days but I was able to reach the office. While there I recall one conversation from a colleague "Power outages in India, not just this long." A similar sentiment was express by a Brazilian co-worker. I suppose the outage reflects the pleasure and peril of the Pacific Northwest with its significant old growth and above-ground power lines. One challenge this offered was having to take a 4am PST call from  the office to deliver a talk https://docs.google.com/presentation/d/1gbKhl3ncwRm0QB1ZD3xZhjhRFWxUp_dKtdnQemtpoX0/edit?usp=sharing to an open source firmware event in Germany at https://www.ruhr-uni-bochum.de/en.

Part of my Franken-prezo can be seen below. It was pieced together from old public slides spanning CanSecWest '15 in Vancouver BC through Hacker-to-Hacker circa late '23 in São Paulo, Brazil, viz., 

Recently a local university asked me to give their students a talk on BIOS. I agreed on the conditions that it wasn't at 4am PST and that it was in-person. If they had asked last week I would have added the additional proviso of not occurring during a post wind-pocalypse power outage :)

Given this is a blog that purports to cover musings on firmware and UEFI, I figured that I'd note that recent event.

Speaking of firmware, before this talk and continuing in the spirit of this blog's theme there was an Intel blog posting related to the Open Computing Project Summit recently about open source server host firmware https://community.intel.com/t5/Blogs/Tech-Innovation/Data-Center/Advancing-Open-Source-Firmware-on-Intel-Xeon-6-Based-Platforms/post/1636720 

Postings like this and recent work by 9e mentioned in https://www.phoronix.com/news/9elements-SkylakeX-Coreboot are always nice to see as they describe work with provides community choice and offers additional insight into how this class of platform is built. In addition, this work potentially heightens awareness of the circular economy.

This above-cited blog post-dated my time at Intel and pre-dated my time at.....at.....

As I mentioned in https://vzimmer.blogspot.com/2024/09/reflecting-on-my-time-at-tech-company.html, I felt a bit nervous about retiring when everyone was telling me that I was 'too young.' As such, I cut my retirement a bit short and recently joined a new tech company

(ID# blinded in picture).

The Microsoft experience has been pretty interesting so far. The old and new commute only differ by a small distance shown below. In fact I had taken that trek a few times in the past, both walking during the summer months and driving during the rainy days when collaborating with Microsoft as an Intel employee.

And the Microsoft campus here in Redmond, WA is sprawling. I initially found myself using a maps application on my phone to navigate both walking through and driving across the campus. To my delight, one location I found was a physical library in Microsoft building 92. Real books, not epubs and mobis and pdfs and html renderings.....! And to my surprise there were a couple of familiar titles on the shelves, including a couple of host firmware texts - https://www.degruyter.com/document/doi/10.1515/9781501505751/html?lang=en and https://www.degruyter.com/document/doi/10.1515/9781501505690/html?lang=en. 

And now the latter has been YouTube-ized https://www.youtube.com/watch?v=ZrkX4tdg49s.

When I related this library finding to former Intel colleague (now an eng at AMD?) he shared a snapshot of the books on his home office desktop, including https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/.

Speaking of firmware books, Jiming Sun's presentation https://talks.osfc.io/osfc-2024/talk/G8RDEX/  on firmware requirements from a CSP provided a unique perspective.

He also mentioned at the 11:10 minute mark some background on FSP and the embedded firmware book https://link.springer.com/book/10.1007/978-1-4842-0070-4, too. Therein he noted the popularity of the book by way of the site https://bookauthority.org/books/best-firmware-books. 

#1 firmware book? Fascinating metric. I'm not sure about the dataset used to generate that ranking. Although now at Amazon AWS, Jiming was a good collaborator during our joint tenure at Intel. 

On the topic of books, on the Weds workday ahead of the T-day holiday I found another surprise when a coworker dropped by my touchdown/temporary office with one of the firmware books in hand https://link.springer.com/book/10.1007/978-1-4842-7939-7

I like books. And doors on offices are another fascinating phenomena after several decades of largely living in a cubicle. 

Moving beyond the topic of books and continuing with co-workers theme, I see that another former Intel co-worker has left the blue building (Inside Blue to Outside Blue, departed the Blue Planet, gone from being an In-tel to an Out-tel?) is the other half of the 300-issued-patents duo of 2014 https://vzimmer.blogspot.com/2022/09/new-milestones.html who has a new opportunity https://natcast.org/natcast-announces-dr-robert-chau-svp-research

I guess the lure of the 'enhanced retirement package' of September drew him out, too? Maybe it was the new job title and mission which both sound pretty cool.

Speaking of retirement, or now post-retirement, since landing at MS I've tried to look up some former collaborators like https://www.linkedin.com/in/vkurien/ mentioned in https://vzimmer.blogspot.com/2023/02/blue-hat-2023-and-uefi-secure-boot.html but noticed that he's been gone for some time. During this inquiry I observed an interesting aspect of his profile that includes a mention of our joint work, viz., "Co-invented UEFI secure boot with Vincent Zimmer of Intel. UEFI boot vulnerabilities were identified by a novel information flow modeling technique. "

I don't recall ever showing up in someone's LI experience listing. Interesting.

Although I started the blog grousing about weather maladies I really cannot complain so much. Another "Vincent Zimmer" has had it much worse recently https://www.youtube.com/watch?v=db9lTZiUgt8 it appears.

On the flip side, when I was leaving Intel, there was a session where the team was queried about what folks thought the imminent retirees would do post-Intel. One suggestion for me was a future as a patent attorney, and another suggestion was that I'd give a Ted Talk. On the latter suggestion it looks like another "Vincent Zimmer" beat me to the punch https://www.youtube.com/watch?v=eKdCsk3Yw-U. I think that disqualifies me for a future Ted Talk - speaker name hash collision rule :) 

On the topic of the former suggestion of going back to school in the above-listed bon voyage meeting, I attended a Saturday conference https://con.racket-lang.org/ on the Racket programming language during my retirement windows between Intel and MS. During the lunch break-out at UW Kane Hall I expressed my interest in pursuing more formal graduate education when the PhD candidate to my left mentioned "yes, I'm in year 10 of my PHD program. I had to switch advisors and topics." Hmm. Given those types of statistics it would be a foot race between a PHD and Medicare eligibility for me. There were some interesting talks at the conference, though, including a keynote from the SICP https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs authors

I really enjoyed their first-person view of technology and personal journies therein.

And the conference shared other other bon mots on programming.  Some may think Racket (and functional programming languages like Lisp in general) is so far from mainstream languages that there is little value in delving into these alt-langs, but I'm always surprised at the cross over of ideas from one language community to another or how a clean, pedagogic language can clarify your thinking on a subject.

Maybe I'll just continue the auto-didactic path and see if I can audit some uni courses of interest? I still remember Richard Ladner's https://www.cs.washington.edu/people/faculty/ladner late 1990's wisdom during my UW CS algorithms course - "What I teach you this quarter will become irrelevant soon, but what I can impart to you all is to teach you how to teach yourself and learn on your own." One of these AI sessions reminded me of this spirit in the slide below.

Speaking of gifts that keep on giving.....

Of course even Racket conference touched on AI, mostly via a spoof of LLMs by one UBC prof. 

On a more serious approach to AI, though, I did attend a few IEEE-sponsored IEEE AI events on the UW campus and in Seattle, too. 

I have to confess that the half-dozen LLM and AI texts & papers on my desk didn't receive as much, er, 'attention' (pun intended https://arxiv.org/abs/1706.03762), as I'd like to have applied during the 4 week retirement.

So this is nice symmetry. The blog opened with describing a talk to university students and ended with some wistful higher education sentiments. Not quite Finnegans' Wake of the first and last sentence running together, but good enough for JIT blog-writing I suppose.

I am still holding out using copilot or gemini or chatgpt or locally phi/llama/qwen/.... by way of ollama to create and/or polish these postings. I guess I like to maintain the raw, natural intelligence (or natural obtuseness) feel versus the polished AI-driven edits/creation.  I am curious about other's thoughts on the topic. Maybe I'm just another John Henry versus the machine on this one....But in other activities these tools are amazing....Maybe just for this blog I've leave them out and keep it's artisanal feel :)

And so much for a November posting. Churn in the weather and the tech employment scene seem to be the themes of this posting.  

i/o, globalization, pqc, ai, oh yes

I talked a bit about the RAID work at Compaq, or the SMART2-SL 'Dazzler' board in my last post http://vzimmer.blogspot.com/2023/10/october-firmware-events.html. Another interesting thing that landed while at CPQ was I2O https://en.wikipedia.org/wiki/I2O, or 'Intelligent Input / Output.' The idea was to bring intelligent offload engines to open platforms. The Wikipedia post has some views of its history. My view was that version 1.0 was challenging in that it asked the host to do the data movement, not the I/O card. If you are offloading the last thing you want to do is encumber the host with 'more work.' We built an adapter card on top of our CPQ RAID controller to provide the I2O hardware interface and then we mapped the commands into our internal command set. Version 2.0 described having the data mover in the I/O device, which made more sense. 

This reminds me of the cycle of technology. Patterns like offloading I/O from the host CPU, from IBM channel processors of old, I2O gestures, Myrinet smart NICs (woohoo - safe code, Modula3, too) https://dl.acm.org/doi/pdf/10.1145/319195.319197, Nitro, DPUs, IPUs,....traversing the 1950's to today.

The post also mentions UDI.  Interesting stuff. Reminds me of the complaint about UEFI that it didn't solve the 2 problems of the BIOS ecosystem - suppliers and having to write a driver 2x - once for pre-OS and again for the OS. UEFI attempted to solve a class of this issue w/ UNDI, both the 'hardware UNDI' and the software UNDI. The former would be architectural hardware like VGA to allow for runtime access. In practice the latter was solved with GOP and the framebuffer at runtime. For I/O this was a mile too far.

Speaking of blogs, I haven't quite figured out the substack phenomena. Is this the new 'blogger'? I created account https://panopticon404.substack.com/ but haven't posted.  Google 'the panopticon' and guess my motivation for that name. 

I really like blogger.  going on 14 years using the service.  I had fear initially that when google bought it they'd kill it, but I suspect it's a low-impact enough service like other freebies, including my homepage https://sites.google.com/site/vincentzimmer/ that it's not worth closing and generating the associated ill will?

Unlike blogging at Intel where 1st party sites like 'uefidk.com' (mentioned 9 times in https://link.springer.com/book/10.1007/978-1-4842-0070-4, sigh) that went away w/o redirecting the content to somewhere like firmware.intel.com, I realize how ephemeral these sites can be.

Speaking of substack, https://www.noahpinion.blog/p/the-next-phase-of-globalization-is had an interesting post around globalization. I still recall how Richard Wirt set up PRC firmware team in '01.  Similar teams in Russia.  He was 'globalization before globalization was cool' IMHO.

I enjoy collaborating w/ colleagues across the globe. The 2020 book w Jiewen Yao in Shanghai, PRC. The SPDM paper https://www.mdpi.com/2410-387X/6/4/48 w/ Jiewen and Krystian in Gdansk, Poland. Two 2022 books w/ Subrata in Bangalore, India. I think I touched on this point of book author geo's in http://vzimmer.blogspot.com/2022/10/a-tale-of-two-books.html. 

The SDPM talked about post-quantum cryptography (PQC). This is a space getting attention, and pages 23+ of https://uefi.org/sites/default/files/resources/USF_Security_Webinar_Final.pdf talk about work for host firmware, including a proposal for accommodating PQC in UEFI https://bugzilla.tianocore.org/show_bug.cgi?id=4087.  

Describes the proposed mapping.

Provides the deadlines. With some of the challenges in evolving the UEFI CA and Secure boot ecosystem https://uefi.org/sites/default/files/resources/Evolving%20the%20Secure%20Boot%20Ecosystem_Flick%20and%20Sutherland.pdf this will be an interesting journey.

The wave keeps flowing

I argue that the workday is like barbells.  There are a spate of meetings from 6am to 10am PST for Europe, Israel and India.  Then the PRC workday starts at 5pm PST and pick up India workday at 8pm, netting out to a typical day of 6am to 11pm.  

Luckily Saturday no one has a workday afaik.  I recall this theme as a broken record with me given my anecdote on http://vzimmer.blogspot.com/2021/01/books-and-computers.html about the currency trader.

Occasionally I sneak out to Seattle in the PM to catch events. Recently https://tech.cornell.edu/people/greg-morrisett/  was in town to meet with alumni. It was nice to meet the creator of Cyclone & typed assembly. I had to share my tales of woe trying to use Cyclone https://cyclone.thelanguage.org/ in the early days and was happy to see a mainstream memory-safe systems language like Rust appearing on the scene. This tech inspired some interesting designs on my side, including the below that will expire in 2 weeks, viz.,

Greg mentioned the challenges of industry to hire folks for high assurance software work. 

Maybe that problem of moving folks to Rust will be ameliorated by the 'assistant gap' mentioned by IOActive? I dropped in the IOActive event tonight in Bell Town and their CTO talked about "the SDLC process and AI." He mentioned how chess assistants after the Deep Blue event with Karsparov in 1995 had a 10 year run until event an assisted human couldn't beat a machine. He then showed the exponential growth in code writing assistants commencing in 2020 and pondered how much shorter the 'era of assistants' will run for code writers until the day the machine does all of the work and the prevailing 'programming language' becomes English.

As a quite side-bar on AI, I worked my way through https://www.amazon.com/gp/product/0137470355/ over the thanksgiving holiday. I liked the mixture of math and programming, along with the historical arc it described. I was amused by the point that the early deep learning efforts felt compelled to have a mathematical foundation for their work to 'justify it' whereas with the latest efforts like generative AI people haven't expected such pedagogy if things 'work well.' The book reinforced my assertion that learning the basics of math will serve you well as the trends of tech churn. For example, having mastered the basics of linear algebra, eigenvalues, etc as an undergrad decades ago are still relevant in this deep learning work today. The same holds for statistical signal processing, information theory, and signal detection from the electrical engineering corpus. But the deep learning domain is so expansive and fuses art like big data, software systems, computer architecture (e.g., array processing redux). I can now better appreciate the point Mark R. made in 38:4 https://www.youtube.com/watch?v=Wx1WBLdUwtg about using his summer sabbatical to get more experience with these deep learning frameworks.

I'm no "Mark R.", of course, but perhaps an option to use my backlog?

BTW - the joke used to be that AI was 'the technology that didn't work.' Meaning once an AI technique proved feasible in the corpus they were ejected and relabeled as some domain of engineering. The script seems flipped today in that being labeled 'AI' is a compelling argument for the tech, irrespective of its efficacy.

So take the barbell day mentioned above and mix in  return to office (RTO). It's nice to see an office again. Sometimes I tell folks that I like the office since it's sort of like Pavlov's dog, but instead of 'ringing a bell' to get a response the stimulus is 'sitting in a cubicle.' An interesting observation, though, about others around me post-COVID. I'm not sure if folks are used to WFH and speaking into their USB speakers, or if we are just getting older and losing our hearing, but folks nearby in the office are pretty loud on the phone.  Since the bulk of the day is still on the phone for a global team, I'm getting complaints from the folks on the call that my neighbor conversations/background noise is too loud.  

From the file of neighbors in the past, Dupont circa late 90's, I sometimes recall Ken Wiletzki. He retired a week before his 40th bday so could say 'retired in my 30's'. In the following year he'd send pictures of himself mountain biking, etc, but after that he went dark. I guess retirement joy consumed any time of 'sharing retirement' with the folks still in office-land. One interesting tale from Ken is that he claimed that he tried to hire Linus Torvalds, then a computer science student in Finland, to work on his validation team at Intel.  Ken created 'kaos' - Ken's Arbitrary OS - for validation of the hardware devices. Ken claimed that Intel couldn't since Linus was overseas and didn't yet have his masters degree. I'm not so sure of this fact since there is no mention in the 'Just for fun' https://www.amazon.com/Just-Fun-Story-Accidental-Revolutionary/dp/0066620732 bio of Linus. Someone who is mentioned in that book is another Intel colleague H. Peter Anvin who in fact merits 2 appearances - once for getting Linus his first PC, and the second for bringing Linus to the US to work for Transmeta.

Other interesting meetings in the local region include the Rust meetup at the connector building on the MS campus. Nice finally meeting Ben Stoltz of Oxide in person after talking w/ him many a time during his Google Cloud security tenure. I liked when Ben asked one presenter 'what does that mean for a pertrified (or did he say 'prehistoric'?) C programmer.' My people.