Ian Henry on Building Trader Tools, Functional UIs and Creative Coding

Ron Minsky introduces Ian Henry, a Jane Street software engineer. Henry joined in 2016 after building the iOS app and web frontend at Trello and working on iOS at Warby Parker. At Jane Street he moved from internal exchange software to tools for traders on the options desk.

Henry says Jane Street’s functional-programming reputation initially attracted him. Around 2013, ReactiveCocoa and functional reactive programming made complex interactive iOS interfaces easier to build. He later explored Clojure through Overtone, a creative coding environment for music.

With a programming language attached to music software, Henry could connect a MIDI keyboard to web requests or have a Slack bot trigger a synthesizer. That exploration led him to Haskell and the question of what a monad was. He had not expected to get a job at Jane Street, whose reputation seemed intimidating.

Minsky says the notion that everyone at Jane Street needs a PhD has never really been true, although some people working on OCaml and type theory have one. Henry adds that the company also likes hiring engineers. Asked about his music, he says he was more interested in the tools and theory of sound synthesis than in making actual music.

Henry’s first Jane Street role was a change of pace from iOS: low-latency software measured in microseconds instead of milliseconds. A millisecond was shorthand for something having gone horribly wrong. The system looked like an exchange, but was really a single-dealer platform.

Counterparties could place orders using exchange-like protocols, but they traded against Jane Street rather than one another. The software still had an order book, a matching engine and a way to report completed trades publicly, so much of the implementation resembled an exchange.

Although Henry came for functional programming, the performance-critical core was highly imperative. He says OCaml’s type-system features helped make that style safe. Around the tight loop, the team could write higher-level test and support code using the same language and types rather than crossing into a separate C interface.

Minsky calls OCaml a broad-spectrum language: it supports low-latency code, testing, web programming and hardware synthesis in a cohesive ecosystem. Henry then moved to Trader Tools, which helps manual options traders understand markets, configure automated systems and send orders.

Options create a large information problem. A trader following Nvidia stock may track one symbol, while an options trader considers hundreds of combinations of strike prices and expirations. An option gives a right to buy or sell at a specified price within its terms; the expiration determines when that right ends.

Minsky explains that although there may be many individual derivatives, traders care about underlying properties such as volatility and the distribution of possible future prices. Henry says there is a mismatch between thinking in those broad terms and expressing an opinion through many individual order books. Software helps bridge the two.

For years, the desk relied heavily on tools such as Excel, Bash and bespoke curses applications. The newer interfaces fall into two broad groups: exploration tools aggregate data and chart how markets move, while attention-management tools alert traders to interesting events or opportunities.

Routing the right event to the right person is also a workflow problem: different people and groups cover different responsibilities. Henry says this is not a glamorous technical problem, but it is surprisingly hard and very important.

Minsky asks how this differs from building Trello for a mass audience. Henry says the traders sit nearby, so engineers can watch them use a tool, discuss a request, ship a change and see it used the next day. That tight loop is valuable, but the small audience has highly specialized needs.

The engineers are not traders and must learn enough of the domain to understand what users are trying to accomplish. Minsky notes that a requested feature may reflect a narrow recent problem or an assumption about what is easy. A designer must identify a simpler solution that addresses the broader need.

Henry says traders are patient and want engineers to understand their problems. Internal educational resources help, as do senior people who combine trading experience with design intuition. The relationship is a collaboration, not simply a request passed across a wall.

Designing for experts changes ordinary UI choices. Traders may ask for text only six pixels high so more information fits on the screen, and they prefer keyboard access over reaching for a mouse. A consumer application with that density might be unreadable, but the users here live in these tools.

Keyboard-first interfaces can make features harder to discover. Henry says people often learn from colleagues and help documents rather than tutorials. Minsky points out that web UIs can add tooltips and links to editable wiki pages; as the organization grows, it becomes more useful for the tool itself to teach users.

Internal software also avoids much work that consumer internet products require: sign-up, forgotten passwords, payments and public distribution. Henry says the team can focus on application logic, and fast internal connections make even a large JavaScript download less consequential.

Because supporting infrastructure is readily available, teams can create many separate web applications rather than fit every feature into one product. Henry also spends less time on the constant dependency-update treadmill he encountered before. Minsky notes the trade-off: Jane Street has built a distinctive internal ecosystem and integrates less with external packages.

The company does bring in useful libraries, Minsky says, but wants more control over stability and security than indiscriminate package imports provide. Henry describes a full-stack OCaml environment in which client and server share types and generated serializers create stable protocols between them.

Rather than define a JSON API, write a separate parser and hope mirrored types remain compatible, engineers can reuse the same types and logic. They can move computation from server to client to distribute work among users, or in the other direction when server resources make that preferable.

The team carried its OCaml RPC ecosystem into the browser. Instead of relying on REST or GraphQL for these applications, generated protocols run over streaming RPC connections, including WebSockets. That speeds internal feature work, though Henry says supporting external conventions would pose a different challenge.

Version compatibility still matters, but controlling the internal clients allows the team to require a browser refresh when necessary. Minsky observes that HTTP is not the only possible network protocol. Henry adds that the exchange-like system used UDP multicast, illustrating how the right transport depends on the job.

The frontend also uses Jane Street’s own framework, Bonsai. Minsky remarks that UI work is sometimes dismissed despite being both important and deeply difficult. Managing state, interactions such as drag and drop, and a changing DOM requires careful modeling.

Henry notes that his team can avoid some painful parts of public frontend work: it targets a controlled browser version rather than every browser and layout variation. Even so, no framework has completely solved UI design, and Bonsai represents the team’s own approach.

One advantage of OCaml is its type system. A frontend value may be loading, available or failed; a sum type represents those alternatives explicitly. Pattern matching then helps the programmer consider every case rather than silently assuming a value exists.

Minsky says case analysis is pervasive in software, and exhaustive pattern matching helps keep cases from being missed or confused. Henry gives the practical example of a string that failed to load: OCaml makes the developer decide what to show instead of forgetting the failure path.

Minsky frames this as a trade-off in explicitness. Many languages allow null implicitly, leaving developers to remember when it is possible. A more explicit type system asks them to write down and handle that possibility. The additional ceremony can prevent classes of mistakes.

Henry says Bonsai will look familiar to someone who knows React because it uses a virtual DOM and diffing. Its underlying model, however, is a more general graph of incremental computations with state. Virtual DOM nodes are values in that graph, and the framework connects them to browser updates.

Minsky says market data changes continuously, so the team needs to avoid recomputing not only the whole page but also expensive transformations behind it. Bonsai lets a developer express which pieces depend on which inputs and choose the granularity of recomputation and rendering.

Henry cautions that his React experience is old, so his comparison may miss subtleties. In his account, React hooks associate state with components through reconciliation and come with rules about when hooks can be called. Bonsai makes changing values and their dependencies explicit in the types.

A Bonsai computation declares its inputs; if an input is not registered, it cannot simply be used on the other side. A mistake produces a type error. Minsky compares that explicit discipline to Rust’s approach to memory management, although Henry says the analogy should not imply the same restrictions on what can be expressed.

Henry says Bonsai requires more explicit code, but the team can express what it needs. For example, rendering a dynamic collection requires keys, rather than merely warning when a programmer forgets them. The type system enforces a discipline that developers of other frameworks also need to follow.

Minsky returns to the information gap between engineers and traders. Henry calls learning options humbling: internal education is strong, but the tools team needs a broad understanding of many areas rather than the deep specialization of people working on pricing or implied volatility.

Henry says he can understand the pieces well enough to build a tool, but would still need to work through the mathematics of a specific early-exercise decision. The breadth is useful for connecting many parts of the desk, even if it does not make him an options trader.

One recent improvement involved alerts about interesting market events. The team must avoid both missed opportunities and constant interruptions. It can incorporate time-based rules, raise the threshold for a repeated event or take into account what has already been reported.

Improving an alert is full-stack work: engineers may need new market data and heuristics to estimate whether an event is unusual, then ask traders to try the result. Traders can adjust parameters, but the goal is not to make them solve the whole alerting problem themselves.

Minsky raises alert fatigue: traders may tolerate more pain than they complain about, even when it hurts their effectiveness. Henry says configurable controls help when a particularly busy day makes normal thresholds unsuitable, allowing people to adjust during the day.

Some systems rank events by an estimate of how valuable it is to tell a trader about them. A desk can raise an overall threshold or adjust it for an asset class. Settings tend to stabilize over time, with relative changes used to respond to current conditions.

Too many per-user settings create another problem: colleagues can end up using effectively different tools, and a newcomer may inherit poor defaults. Henry says the team has moved toward fewer individual knobs and more desk-wide configuration, because a concern shared by one trader is often shared by others.

The conversation turns to Henry’s personal project Bauble, a live coding environment for 3D images and animations. A short program compiles to an OpenGL shader, a function evaluated across image pixels. GPUs can run these calculations in parallel and render complex images interactively.

Writing GLSL directly is relatively low-level, so Henry wanted a concise language where he could describe a sphere, combine it with a cube and obtain a rendered result. Bauble compiles those high-level expressions into a much larger shader and uses signed distance functions to model shapes.

A signed distance function takes a point in 3D space and returns its distance to a surface, with a sign indicating which side of the surface it is on. For a sphere, the basic calculation is the distance from the point to the center minus the radius.

These functions can be composed. Evaluating two shapes at the same point and combining their values can produce an intermediate shape or a smooth blend. Transforming the input coordinates can twist a cube. Henry contrasts this with a triangle mesh, where smoothly joining surfaces requires additional geometry.

Minsky observes that meshes force a choice of resolution early and can introduce artifacts at intersections. A function represents an idealized sphere until it is sampled. If needed for 3D printing or export, Henry says, it can later be converted into a triangle mesh.

Minsky challenges whether the results of arbitrary transformations are still true signed distance functions. Henry agrees: many interesting compositions only approximate distance. The name is useful for finding the relevant literature, but the invariant does not survive every operation.

Distance information makes ray marching efficient. If the nearest surface is 60 units away, a ray can skip that much empty space in one step. With approximations, a step may overshoot or enter a shape, so creators must account for rendering artifacts or use slower mitigations.

Approximations can also produce interesting visual effects. Extruding a shape along a Bézier curve may render well on its own but become inaccurate when composed with further operations. Henry says learning which combinations work is part of playing with the medium.

Minsky praises Bauble’s polished interface and asks how Henry found time to build it. Henry credits techniques developed by others, including work by Inigo Quilez and the ShaderToy community, as well as CodeMirror for the editor. He spent substantial effort on the compiler and interactive controls.

For example, a user can drag a number in the editor and watch the image change, making it easier to choose colors or positions. Henry estimates about five months of serious work in total, much of it during his child’s naps while he was on parental leave.

Henry also added mesh export for 3D printing and built electronic instruments and a mechanical keyboard. He enjoys connecting microcontrollers and buttons to create unusual MIDI instruments, even though he does not really play them. One experiment used combinations of keys to produce notes.

Electronic instruments allow unconventional controls, such as a button that moves a note up a semitone rather than selecting a fixed pitch. Henry jokes that designing the instruments—and Bauble itself—is often more fun for him than performing music or making art with them.

Bauble uses Janet, a small Lisp. Henry wanted concise notation and variadic functions for combining shapes. He also added some nontraditional syntax, including postfix and infix forms, to retain conveniences similar to GLSL’s vector operations.

Janet’s macros let Henry shape the language without writing a separate parser. It also compiles readily to WebAssembly, so he could write Bauble and its compiler in the same language used to express designs, rather than interpret the notation in JavaScript or OCaml.

Embedding Janet in the browser was pleasant once working but difficult to start. Henry wrote a book to help others and give the language more exposure. Someone used an example from it as the basis for a live music coding environment called Trane, which he was delighted to see.

Henry does not build personal projects as a career strategy, but knowledge acquired for fun has repeatedly proved useful at work. Exposure to different languages changes how he models problems. Haskell and immutable state, for instance, made him approach familiar applications in new ways.

Janet also gave him his first sustained experience with a powerful macro system: code can execute during compilation and generate code for runtime. It can produce an image containing program state, which can be saved and resumed later, including complex object graphs and suspended computations.

Minsky worries about image-based environments in which a long-lived mutable collection of code and data becomes hard to inspect or reproduce. Henry says his own use is more disciplined: run the program to a fixed point, save the image and always restart from that reproducible state, assuming deterministic compilation.

Minsky values Lisp’s macro and multi-stage programming ideas, while observing that OCaml and Haskell have tended to emphasize types. He says Jane Street is exploring more limited forms of runtime code generation in OCaml. These do not amount to freezing and restarting an entire program, but can still be useful.

Asked what he has carried from work into personal projects, Henry points to expect tests. A test runs code, captures its output in the same source file and compares it on later runs. During development, he can inspect the result, fix the code and accept the output once it is what he intended.

Minsky compares the experience to a plain-text notebook, with an important difference: notebook cells may have been run in any order, so displayed results need not match a clean run. An expect test reruns from beginning to end, flags differences and lets the developer decide whether to accept updated output.

Henry says exploratory use does not replace thoughtful testing of precise properties. A good expect test can also capture a useful view of program state. In a board game, printing the board after a sequence of moves reveals both that something changed and what the new and expected states look like.

Expect tests coexist with conventional assertions and property tests. A property-testing tool can insert a discovered failing case into the test source so future runs keep checking that regression. The shared idea is a convenient way to observe and retain interesting behavior.

Minsky contrasts compact source code, which hides the data flowing through it, with a spreadsheet, where data is visible but the program is scattered across cells. An expect test can retain compact code alongside selected execution traces. In review, a commit can show both the code change and the resulting behavioral difference.

Both warn that dumping enormous amounts of output is a failure mode. A useful test chooses and formats the relevant state so a human can read it. The work of building clear visualizations also makes later changes easier, giving engineers a reason to write tests for their own benefit.

Henry liked the workflow enough to implement a source-patching macro for Janet. Minsky traces their approach to Mercurial’s unified tests and the CRAM tool; Jane Street did not invent the idea but helped spread it. The technique is language-agnostic, although good editor integration can be difficult to build.

Minsky says that teaching his children programming exposed how poor testing tools can be, particularly for C and C++. Jane Street’s OCaml and Emacs integration shows a diff when a file is saved and provides a quick way to accept new output. Henry agrees that this tooling matters to making the workflow pleasant.