I'm Ahmad, a software engineer in Paris. For the past ten years I've built systems that have to keep working under tight limits: a battery that must last 20 years, a radio that can only listen in short bursts, a block that must finish within a fixed time.
What I enjoy most is the layer underneath: how machines share work, how code meets hardware, and the infrastructure today's biggest workloads run on.
Smart meters relay each other's readings, and a meter can send to a neighbor at several speeds (modulation schemes), such as 600 or 200 kbps. If routing judges a neighbor at one speed while its traffic mostly uses another, it can pick the worse neighbor. At Itron, three co-inventors and I designed one score per neighbor: its tries per packet at each speed, weighted by each speed's share of the tries.
A virtual machine bills each program for the resources it uses. Moonbeam's EVM metered computation and proof data, but not storage, which every node keeps forever. Following Moonbeam's MBIP-5 rule, I added storage as a resource in the Rust EVM interpreter, Frontier and Moonbeam. Every node must reach the same count, so each SSTORE and CREATE is checked as it runs, against a limit set by what the transaction paid. Only new slots and code add bytes, a slot written twice counts once, and the interpreter now reports a new contract's code size. Each transaction pays for its dominant resource, so no block adds more than 160 KB. It runs on every Moonbeam node.
Battery-powered meters, like water and gas meters, have to run for 20 years on one battery, so their radio sleeps almost all the time and wakes only for short, scheduled listening windows. At Itron I developed, in C++, the firmware's RPL routing and parent selection, frequency hopping, retransmissions, and the scheduled wake-ups and receive windows that keep idle listening low.
A meter's radio sends at the speed that has worked best so far. Once one speed is preferred, the faster ones stop being tried, so the radio may never learn that one would now work. Six co-inventors and I patented the fix: send an occasional real packet at a faster speed, more often when the signal seems to have room to spare, and keep using that speed while its packets get through. At a faster speed, each reading spends less time on air.
A server can spread an offer cheaply by sending it to a few seed phones, which pass it to phones nearby over Wi-Fi. Picking the best-connected phones, the usual choice, reaches many people who don't care. In my master's research I modelled who cares about each topic on top of who is in radio range, and compared seed picks in simulation: phones whose neighbors care most reached 9 to 11 percentage points more of users' interest. It became a paper with my supervisors.