His idea was to take the moving parts out of it. Measure the distance electrically instead, and you are working in microns rather than millimeters.
Eddy current · Klipper · Rust
It started during COVID as something Matt did in the evenings, and it took years to become a thing you could buy.
The version we shipped was called RevD, which tells you there were a RevA, a RevB and a RevC before it. Some of those redesigns were ours and some were forced on us: this was the chip shortage, and parts we had designed around simply stopped existing. Mostly it cost time, because Matt was doing it part time.
Annex Engineering helped it over the line, with software, with testing, and later with support. Dalegaard did the work that made Matt’s hardware actually speak Klipper, and he is a pure genius. He is only visible on GitHub, in the copyright header of the module, because that is where the work is. The store and the site are the part Matt and I built.
Beacon launched on 6 February 2023.
Thermal compensation · Coil design · PCB materials
An eddy current sensor works by driving a coil at high frequency, inducing currents in the metal underneath, and measuring how that loads the coil. The reading depends on the coil’s own inductance and resistance, and on the conductivity of the metal it is looking at.
Every one of those moves with temperature. And the sensor is bolted to a toolhead a few millimeters above a bed held at 60 to 110 degrees, soaking, for the entire print. So the zero wanders. On a 0.2mm layer, a few microns of wander is a first layer you can see.
It was really bad at first. The fix was not clever, it was expensive: a great deal of testing, and our own thermal compensation algorithm built from it.
RevH, at the end of 2023, attacked the same problem in the hardware. A redesigned coil, smarter PCB materials, a better shape. That bought about 40% less thermal drift and around 20% more sensitivity, and added an accelerometer on board so the same part could do input shaping.
Firmware 2.0.0 · TrueZero
Contact was Matt’s idea and it is the thing I would point people at.
The sensor is reading distance continuously at 1kHz. So if you drive the nozzle slowly down into the bed, you do not need a strain gauge or a switch to know when it touches. You just watch the distance signal stop changing. The nozzle has arrived. No moving parts, no added hardware, and it works on surfaces that are no good for scanning.
We did not ship it until it could find an egg without breaking the egg. That went in the release video.
It also carries the bluntest warning in our documentation, that a misconfiguration could ruin your day and you use it at your own risk. That language is there because people misconfigured it and drove nozzles into their build surfaces. We felt terrible. There was not much we could do except say so plainly.
Discord · Open source · DIY
Beacon has never had a support desk. Technical questions go to Annex Engineering’s Discord, which is not ours.
That was not a philosophy, it was arithmetic. Two people cannot support thousands of customers, and we had friends who already ran the room those customers were in.
The 3D printing community is open source and DIY by disposition. They design their own toolhead mounts and publish them. They expect to do some of the work. That is a different relationship with a customer than the one I ended up in at MbientLab, and it is better.
Not everything about it is comfortable. The real complaints are fair: we are more expensive than the alternatives, the cable is fragile and not rated for routing in a chain, and certain single-board computers have USB power designs that will damage a Beacon, which is why our product pages tell you not to use them.
Electrical beats mechanical when you need microns. That was the whole insight and it was Matt’s. Everything else was execution.
Physics does not care about your schedule. The solution to the thermal drift problem was long, boring and expensive: test until we understood it, then compensate for what we had measured.
Releasing something when it works on an egg is a good rule. Pick the test that would embarrass you to fail, and do not ship until you pass it.
Open source means someone else gets to build on it. We released the Klipper module under the GPL, so a competitor can take that work, attribute it, and undercut us with it, because they did not pay for the years of R&D that produced it. That is exactly what the license allows. Knowing it was coming does not make it feel good, and I would still release it the same way.
]]>Andrew is not my name. I picked it because customers were kinder to Andrew than they were to Laura. Andrew got the benefit of the doubt. Andrew’s answers were accepted the first time. Nobody explained to Andrew how their own product worked. When I eventually handed most of the first-line support to AI, I kept the signature, partly because it was easier and partly because by then it felt like the house style.
I want to be careful about what that story is evidence of. It is one person’s inbox. But I stopped running the experiment because I already knew the result.
The first customers were builders. They bought a development board because they wanted to make something out of it, and they arrived expecting to do work.
They read the documentation. They filed real bug reports, sometimes with a fix attached. They understood that a small sensor company was not going to have an answer to every question within the hour, and that some of what they were attempting had never been attempted with our hardware before, so we would be figuring it out together. When something worked, they told other people. When something did not, a fair number of them told us how to fix it.
That is not nostalgia for better people. It is a description of a filter. Early on, our product was hard enough to use that it selected for a certain kind of customer.
Then we got easier to buy from, and more people bought.
The requests changed shape. Free customization for one specific use case. Free consulting, delivered as a support ticket. Firmware treated as free because the SDK was open source, though the firmware never was. An answer within the hour, on a Sunday. Amazon shipping. A refund because the sensor did not do a thing we had never claimed it did, and a chargeback when the refund was declined.
The framing I keep coming back to is not that customers got worse. It is:
Growth diluted the contributor class and amplified the extractor class.
The average customer did not get less intelligent. The average interaction got less informed, less patient, and less reciprocal. What disappeared was not competence. It was reciprocity.
There is a name for this from the early internet. Every September, a new cohort of university students arrived on Usenet, behaved badly, and got socialized by the regulars until they knew the norms. Then in late 1993 commercial providers opened the gates, the flood stopped being seasonal, and it became known as the September that never ended.
The obvious reading is that newcomers ruin things. That is not what the research says, and the more interesting version is less flattering to me.
In 2016 a group of researchers studied a Reddit community that took an enormous newcomer surge and came out the other side intact. It survived because it had active, coordinated moderators, enough shared identity that existing members policed norms themselves, and technical systems that absorbed the rest. The surge was not the deciding factor. The capacity to absorb it was.
We had that capacity once. A forum with several of us answering on it, engineers who liked talking to customers, enough people that norms got transmitted rather than diluted. Then the team dispersed, and it was me. One person cannot socialize a growing customer base. One person can only answer tickets, and eventually not even all of those.
So the newcomers did not join our culture. They became it.
For a while I assumed this was a me problem, or a hardware problem.
Then Pew asked 9,609 Americans about it in late 2024 and 47% said public behavior had got ruder since the pandemic, one in five saying a lot ruder. That is about behavior in general rather than customers specifically, so it is context and not proof. But it matched what the inbox felt like.
The closer research is on customer incivility itself, and it is fairly bleak. A two-wave study of frontline service workers, surveyed before the pandemic and again in late 2020, found the path from customer rudeness to worse job performance, running through emotional exhaustion, became more pronounced after the pandemic began. One study, one country, 211 people. Not a law of nature. But the direction is the one everyone working a counter would guess.
At some point the bad interactions stopped feeling like exceptions and started feeling like the operating environment.
Publishing your SDKs does not mean you have agreed to work for free, forever, for anyone who downloads them. Maintainers know this. Tidelift’s 2024 survey of open source maintainers found 60% are unpaid hobbyists, 48% feel underappreciated or that the work is thankless, and 39% say users are too demanding and expect too much of them. Sixty percent have quit a project or considered it.
One maintainer quoted in their report put it better than I can:
Most users, even ones who require fixes, are not willing to roll up their sleeves to help. They just expect someone else to fix it for free.
People wanted the benefits of open source without any of its obligations, and were often annoyed to learn there were obligations.
The uncomfortable part, and the part that implicates me, is that bad behavior makes a company defensive. Every abused return policy tightens the return policy. Every chargeback adds a verification step. Every ticket demanding an immediate answer to a question already answered in the docs pushes you toward the canned reply, then toward the macro, then toward the bot. Warmth is expensive, and hostility raises the price.
Your customers then experience all of that as the company getting worse. Which it did. I did make it worse. I made it worse in direct response to what people were doing to me, and the people who got the colder version were mostly not the people who caused it.
We talk about enshittification as something platforms do to users, extracting more and giving less until the thing is hollow. Cory Doctorow named that, and he was right about it. But the arrow points both ways.
Sometimes companies enshittify because shareholders demand extraction. Sometimes they enshittify because customers teach them that trust is too expensive.
People used to argue for mandatory military service on the grounds that it built discipline and a sense of shared obligation.
I would like to propose an update. One semester of customer support, retail, or a fast food counter during the lunch rush. Not as punishment. Just long enough to learn that the person on the other side of the counter is also a person, and that they can tell when you are being unkind to them because of the name at the bottom of the email.
Andrew would like that very much.
]]>The team did not scatter because of Covid. It had been thinning for years before that.
One person went to Amazon in 2018. One person got a promotion from a job offer at Salesforce. One person got married and moved to Sacramento to become a stay at home dad. Another moved to Vegas to follow his heart. And so on.
Nobody was laid off. There was no severance. All these great employees moved on into other jobs. We had all understood by then that MbientLab was never going to be a unicorn with a billion dollar exit.
Then Covid landed on what was left.
MetaMotion RL · MetaMotion S · e-commerce · side-hustle
I kept it running as though it were still a startup, because I wanted customers to keep getting the star treatment they had always gotten. But it was more than one person could carry.
What was left was four of us, and the division of labor was simple. Sophie, our COO, ran HR, finance, contract manufacturing, and inventory and supply chain, and took customer support. Matt, our CTO, ran hardware engineering and manufacturing support. Mark ran order fulfillment until he left in 2024. I ran software, customer support and orders.
We stopped making new hardware and we dropped forum support. From that point on we built exactly two things, the MetaMotion RL and the MetaMotion S. The RL was the second generation of the original MetaMotion R, and we made it until it sold out a few months ago. The S is what is left.
The company was profitable. It always had been. But it had changed character. In the early years we took founder salaries that were basically pennies and pushed every dollar back into the company. It was exciting. It was a startup. Now there was no need to reinvest like that, just enough cash flow to keep ordering manufacturing batches and to pay ourselves salaries that cleared poverty and not much else.
By the time I took the job at Unit21 I was down to about five hours a week on MbientLab, doing most of the work on the weekend. It never once collided with a Unit21 or a Gradle meeting, and I would not have let it. Those jobs paid my bills and my insurance, and I loved the work. MbientLab took the back seat. I could afford to let it, because it was self sustaining by then, and because anything that caught fire, Sophie put out. They call these things “side-hustles” now.
Swift · iOS
Ryan Ferrell joined in 2021 and rebuilt the Swift APIs, and shipped a new iOS app with them.
I was at Unit21 by then, doing well, and quietly missing writing software. Ryan reignited something. Watching someone care about the SDKs again reminded me that I still did.
After he left I wanted to go back through all of it, clean up the apps and the APIs properly, finish the job. And then I started at Gradle and there was simply no time. I was busy. It sat there for years.
Swift 6 · Kotlin · AI · vibe-coding
When AI tools got good, I finally had the help I needed, so I went and did it. New Swift 6 and Kotlin APIs, written mostly by vibe coding in the evenings, pushed to GitHub this spring and summer.
We had already decided to close by then. We were getting ready to sell out the inventory and shut the doors. I wrote them anyway.
The honest reason is that it had bothered me for four years that the SDKs were not what they should be, and for the first time I had a way (and time) to fix it, and I did not want the last version of this thing to be the unfinished one.
The exact date is somewhere between now and the first of December. When I finish writing this, I am going to get up from my desk and solder some of the last batch of MetaMotion S boards.
I should have shut the doors earlier. Ryan gave me a burst of momentum and excitement, but I should have killed this long ago.
It takes a lot not to see this as a failure. Therapy? Maybe. Thirteen years, and I guess I know what it feels like when your kid flunks out of college.
I was on my way out of Unit21 in a layoff and already interviewing when Gradle came up on LinkedIn. They wanted someone who could write and who knew Gradle, which is a narrow enough intersection that I thought I had a real chance.
I did know Gradle, in the way most people know Gradle. I had used it building Android apps at MbientLab, where it was the part of the process that sits between you and the thing you actually want to do. A build file you edit when something breaks. Little did I know.
The interview process was long. Justin interviewed me, and so did Piotr, who is still my boss. I remember Piotr ended up talking to my ex Unit21 boss, Andrew, for over an hour. I joined in January 2023 as a technical writer, not a lead or an advocate. That came later.
Asciidoctor · Javadoc · Dokka · Markdown
There had been a writer before me, but he was long gone when I got there, and he had not been technical. He supported the engineers rather than owning the documentation. So in practice the docs had been written by engineers, when they felt like it or when they had to, for about a decade.
That produces a very particular kind of documentation. The subject matter was good. The people writing it knew more about Gradle than anyone alive. It had gaps, though, and it was written for people who already understood Gradle.
The numbers back that up more starkly than I expected. The user guide had 165 source pages in November 2022 and 166 when Gradle 8.0 shipped in February 2023. One page, in a year. Those pages were getting over a million visits a month.
Gradle 8.0 landed about a month after I did. Luckily it did not land on me. I needed the time to ramp up.
I also felt like I was paying the price of my predecessor’s failure, and I was under more scrutiny and micromanagement than I had ever been in my life.
When I joined I was also asked to take on the documentation for Gradle Enterprise, the commercial product, which was renamed Develocity that September.
I said yes happily. It took about six months to become obvious that this was not one job with some extra scope, it was two jobs. Luckily we hired someone on the Develocity side to do it properly, which was the right call.
I suffered for a bit though.
Information architecture · Getting Started · Core Concepts
Everything I changed that year came back to one problem: the documentation assumed you already knew Gradle.
It shipped in two waves, both tied to releases.
Gradle 8.3, August 2023. The flat cluster of Quick Start, Getting Started, Installing and Samples became a single numbered Getting Started tutorial that runs in order. If you have never used Gradle, there is now one path through the front door rather than four half-open ones.
Gradle 8.5, November 2023. The bigger one. I split the manual into two parallel tracks, running Gradle builds and authoring them, each with a Core Concepts sequence and a tutorial sequence. That is still the shape of the documentation today.
The landing page changed too. It had been a table of contents pretending to be a page. It became something written.
I also added a rating widget so readers could score a page. The scores were low at first, which was demoralizing in a way I had not braced for. Over time I got them up by about 40%. I took the widget out last year and put the attention into GitHub issues instead, which turned out to be a better signal.
By the end of 2023 the user guide was 202 pages. Thirty-six more than the year had started with, against one page the year before.
GitHub · Asciidoctor · DCO · Contributor guidelines
Gradle’s documentation lives inside the gradle/gradle repository, in Asciidoctor, alongside the code.
Every change is a pull request in a repo that thousands of developers watch.
I love this, and I did not expect to. There is the GitHub credibility of it, and there is the community, which is genuinely good. External contributors send documentation pull requests constantly, and they are good pull requests. That still surprises people when I tell them.
I am tagged automatically on anything touching docs, and I can block a change. Engineers on the team can override me, which happens rarely. The American English rule predates me. A lot of the contributor guidelines in there now do not.
Gradle is hard, and I underestimated it completely. I had used it for years and thought of it as a step in a build. It took me about two years to feel properly ramped up. The gap between using a tool and being able to explain it is much wider than it looks from the outside.
The hardest part of inheriting a decade of anything is deciding what to keep. Almost none of what I found was wrong. It was incomplete, and it was addressed to the wrong reader. Those are different problems from bad writing and they need different fixes.
There are too many ways to do one thing in Gradle. I try to hold a line on keeping it simple. It is harder than it sounds when every one of those ways is somebody’s legitimate use case.
Do it yourself. My entire team is in another time zone. Waiting for an answer costs you a day, so mostly I learn the thing and get on with it. I picked that habit up running my own company and it has been the single most useful one here.
Writing was not the first thing that came to mind. But I kept thinking about everything I had been doing at MbientLab, and a lot of it was writing. Docs, API references, support answers, release notes. I had been a technical writer for years without the title.
I had an offer to become a technical writer at C3.ai but I turned it down. The reason was the last interview: Clarence Chio, the CTO. I loved his intelligence and his attitude, and I wanted to work for him.
Unit21 built fraud detection and anti money laundering software, and it had just closed a $34M Series B led by Tiger Global. They were hiring for several roles on the back of it. I came in right after it closed, disclosed MbientLab in the IP paperwork on the way in, and started as the company’s only technical writer.
The plan, at the time, was that I would eventually build and lead a team of writers. That never happened.
ReadMe · OpenAPI · Swagger · Postman · Figma
There was no documentation to inherit. The only thing that existed was a three-year-old fork of somebody else’s docs theme, marked “NEEDS REVISION” and last touched in 2019, plus whatever scattered notes support and engineering had written for themselves.
ReadMe was already bought. Karen had purchased it just before I joined, so the tool was chosen for me. I did not mind. It was fun to use, and I ended up somewhere between customer and beta tester, pushing their support for things I wanted, including the newest OpenAPI spec.
I was the only writer on day one and the only writer on my last day.
Information architecture · API reference · Changelog · Release notes
What I inherited was split in two: a main site and a separate /developers sub-project living alongside it.
Over the following year I pulled it apart and put it back together as one thing, with product guides, an API reference and a changelog under a single roof.
The API reference was generated from our OpenAPI spec rather than hand-written, which is the only way one person keeps up with an engineering team. I owned the changelog and the release notes too.
By the time I left, it was 531 documentation pages, 292 API reference pages and 34 changelog entries. Engineers wrote none of it. All of it came through me.
There was a review process for certain features. For everything else it was a startup, and the process was: ship it.
Blog · Customer research · Surveys
Somewhere in there the job widened. I started writing for the company blog rather than just the docs, including a piece on link analysis in AML case management.
I also did a lot of product research. Customer interviews, and a great many surveys, some of them run from my own LinkedIn account because that was the audience we could actually reach. The results went to Sam or to whichever product manager needed them.
That was the first time any of my work looked like developer advocacy rather than documentation, and it is the reason the next job was possible.
Learning about money laundering was the best part. I did not expect that. It is a genuinely fascinating subject, and getting paid to understand it properly was the thing I enjoyed most about being there.
Next time I work at a startup, I want founders with more experience. That is the single thing I would change. The product, the market and the work were all fine.
I enjoyed this tech writing thing. Unit21 was a chance to try technical writing and find out whether it was a long-term thing or a one-time thing. It turned out to be something I really liked.
San Francisco was at its loudest. People in costumes outside VC offices, meetups worth going to, bootcamp season, and dropping out of college was cool. Everyone was riding the software vibe and startup wave.
My dad introduced me to a friend of a friend, Paul To, who had a company called Emota. I helped him design some of the hardware for his products and got into the scene. I made friends, and more usefully, I made relationships.
This was also the time of the iPhone explosion and the arrival of Bluetooth Low Energy (Apple was pushing hard). What I wanted was a development platform: sensors small enough to wear that could talk to the phone in your pocket. So I started building one, and then I started asking people whether they would actually buy it (they said yes).
I incorporated MbientLab in 2013. I could not do it alone, so I recruited Matt and Sophie. Stephen, Yu and Eric (ex-Intel colleagues) came later and became cofounders in everything but title.
Bluetooth Low Energy · Apple · Kickstarter · Hardware
The first MetaWear went up on Kickstarter in April 2014 asking for $8,000. It finished at $115,067 from 1,887 backers, a little over fourteen times the goal. Our first customers were those backers, and a good number of them were the friends and acquaintances I had been making since 2012.
Four more campaigns followed over the next two years:
Five funded campaigns, $327,583 from 4,583 backers. GigaOM called it a $30 Bluetooth module for wearables, and Make: and Fast Company picked it up too, which was exciting.
Almost none of the product roadmap was mine. It was dictated by what people asked for: more sensors, different form factors, coin batteries. The MetaWear RG added a gyro. The MetaWear Env added humidity and RGB color. The MetaWear Detect added proximity. We built the MetaTracker with a sturdy industrial case because customers kept putting our dev boards in places dev boards should not go.
Two did not make it. The MetaWear HR/PPG board funded, but not by enough to actually manufacture it, so it stayed a “coming soon” on our store and then quietly stopped being one. The MetaWear Mini, the size of a dime and meant to go into clothing, was a partnership where the partner would not fund their half. Both were the right idea. Neither shipped.
10-axis IMU · Sensor fusion · NSF grants · Marketing
After the two failures we stopped chasing new categories and went back to making the existing lines better. The MetaMotion R and MetaMotion C were supersets of the MetaWear R and MetaWear C, and they sold well for years. MetaMotion RL and MetaMotion S came later. By the end we had shipped thirteen distinct board models across nine generations.
In June 2016 we won an NSF SBIR Phase I grant, $225,000, to build cloud-based trend analysis on sensor data. We didn’t get a Phase II. It is the only outside money the company ever took that wasn’t a customer paying us for something.
The market we did not plan for turned out to be research. Our boards ended up in labs, and then in papers: more than 160 biomedical publications in Europe PMC alone cite MbientLab hardware, on stroke rehabilitation, gait analysis, fall detection, wearable textiles. Robert H. Grubbs, a Nobel laureate in chemistry, used our sensors in his research. One 2020 Sensors paper benchmarks seven IMUs head to head and ours is one of them, which is a strange and gratifying thing to read about your own board. Nestlé, BMW, UC Berkeley, Facebook, Philips, and thousands more all showed up as customers. So did a long tail of startups we helped build prototypes, several of which went on to raise rounds far larger than anything we ever had.
What I did not expect was the range. Once you sell a small, programmable thing that measures motion, people put it on whatever they are curious about.
None of that was on our roadmap, or on anyone’s.
Objective-C · C++ · Java · Swift · Python
Our software was always open source and always will be. It is all on GitHub.
I wrote the original Objective-C API, because I was in love with Apple and XCode was really fun and easy to use back then. Eric wrote the C++ and Java APIs. Stephen wrote the Swift ones. The Python and Javascript API we wrote collectively.
Every time an API shipped or changed, we put out updated Android and iOS apps to go with it. You can find both on the App store and the Play store today (well as of this writing anyways).
China · Encrypted firmware provisioning · Hand assembly · Customs and tariffs · Ex Works
We started contract manufacturing in the Bay Area while batches were around a thousand units. When batches got closer to ten thousand we moved to China and stayed there. Four separate companies handled it: one fabricated the bare PCBs, one soldered the components onto them, one made the batteries, one made the cases. Nothing was assembled at any of them. The pieces came back to our own lab in California and were put together by hand.
That was deliberate. So was the firmware. Each unit only receives a bootloader and firmware after our test rig completes an encrypted handshake with our servers in the US. A rig sitting on a factory floor cannot produce a working device on its own, and it cannot hand our firmware to anyone. People tried. We watched brute-force attempts land on the rigs and the servers.
We never shipped a bad batch and never ran a recall. Our defect rate stayed below industry norms for the entire life of the company.
Certification was easier than people expect, but only because we knew every piece of the product intimately, and because a small battery and a small antenna is an easy thing to certify. We used a lab in the Bay Area, spent real time building the test setup and fixtures, and then the testing itself took a few days and about $10,000.
The part I could not have done is the part Sophie did. She forecast demand so accurately that in ten years we hit zero stock exactly once. She worked out how to classify goods to minimize tariffs and how to route shipments to minimize freight, and she was doing this through tariff regimes and supply chain disruptions that long predate the ones people talk about now. An absolute master of the craft.
In the lifetime of the company, we manufactured and sold more than two and a half million sensors worldwide. Every single one of them passed through our own warehouse, where one of us tested it, boxed it, and printed the label. Never a third party.
San Francisco · San Jose · Eight people
We started in my house in San Francisco. Later we took an office downtown, and at our largest it held eight of us: me, Matt, Eric, Stephen, Yu, Gabriella, Mark and Sophie. A few people came through along the way, like my friend Jesse, but that core eight held the longest.
That was the whole company. Two and a half million units shipped, five language SDKs, thirteen board models, Kickstarters, a federal research grant, Fortune 500 customers, and prototypes that helped other startups raise up to $50M. Eight people.
Then life happened.
That is when I took a writing job at Unit21, and MbientLab stopped being the only thing I did.
Being a founder is lonely. Only the people who have gone down that road understand it, and there is no explaining it to anyone who hasn’t.
Would I do it again? Absolutely not. I would join Nvidia and ride that wave. But I don’t regret it either. I made lifelong friends, learned lessons I could not have learned any other way, stiffened my neck, and it led me to where I am today.
Work with family and friends. People caution against it constantly. In my experience they make excellent cofounders and they will always have your back. The founder disputes I have watched from the outside were all between strangers.
Hardware is hard, and the hardest part is not the engineering. In the early years I watched startup after startup get taken advantage of by their contract manufacturers. Held hostage, extorted for more money before the goods would ship out of China. Time and again these were software engineers with good degrees and good pedigrees walking straight into the grift, and some of them did not survive it.
Winning it and getting it turned out to be two different things. 2009 was a bad year to be competing for a single opening, and Intel offered the role to another woman graduating in my year. She was simply that good. She turned it down for AMD, went to Oracle after that, and remains one of the engineers I most admire in this field.
Which is how I came to turn down my own offer from GE’s locomotive division and move to Folsom, California. I have Skip Lindsay to thank for that, a damn good Principal Engineer, my recruiter, and still the best manager I have worked for.
x86 microarchitecture · RTL emulation · FPGAs · Perl
The job was debugging microarchitectural sightings, both on physical systems and in RTL emulation environments, and building the tooling that made that debugging possible. I worked across Sandy Bridge and Ivy Bridge, and across a wide set of IPs: CPU core, system agent, power management, microcode.
Most of it came down to a loop. A failure happens in silicon, and we had a backdoor that captured the state of the machine right before it went wrong. You replay that state on emulators and FPGAs, and then you find the bug by walking the system forward in slow time. And you cross your fingers that you know the system well enough, and are lucky enough to catch the failure in the act, to fix it at all.
SystemVerilog · DDR PHY · DFI & LPDDR protocols · mixed-signal design · lint/CDC/RDC
I moved to the MOD MEM team and to the other side of the fence, doing logic design for the DDR PHY on Atom-based SoCs instead of validating someone else’s work.
The job ran from defining the microarchitecture of a block, through implementing it in SystemVerilog, to holding the RTL to the front-end quality bars: lint, clock and reset domain crossings, voltage domain crossings, synthesis checks. Code and test. Code and test. And then more tests. Memory I/O is mixed-signal and it lives on a power budget, so area and power optimization was never a later phase.
The funniest part of my last year at Intel was moving my team off SVN and onto Git. Engineers can be notoriously pig-headed about new tooling, so I wrote a course on Git and made access to the codebase contingent on taking it. If you would not do the course and show some willingness to learn the thing, your credentials stopped working. Yes, it was a bit passive-aggressive. Git was still unfamiliar to most of the team back then, and I hope they look back on it as a good memory, and a great skill to have.
VLSI was my dream job. Then I got it. The thing I had been certain I wanted to do for the rest of my life turned out not to hold me once I was actually doing it, and that is a strange and useful thing to learn early.
Big company culture has to be experienced. Nothing prepares you for the scale, the process, or the number of people who have to agree before anything moves. I am glad I have four years of it in me, and I would not trade them, even knowing how it ended.
Intel’s Principal Engineers are some of the smartest people in the world. I mean that without qualification. Watching how they took a problem apart changed how I take problems apart.
I also got to travel to and work in Israel, which was not something I had expected the job to include.