Onscreen Keyboard for Windows CE
First programming job — integrating an onscreen keyboard into the Windows CE soft input panel, and building the version control system that kept its many targets straight.
My first programming job, at Innovation Management Group in Chatsworth, California, while finishing a computer science degree at Cal State Northridge.
IMG built onscreen keyboards — the kind used by people who cannot use a physical keyboard, and by the touchscreen kiosks, medical carts, and industrial panels that have no room for one. My work was to get that keyboard into Windows CE's SIP interface, the soft input panel that embedded Windows devices raise when a text field wants input.
That meant designing and building the user interface layer that made a desktop-era product behave like a native system component on a device with a fraction of the memory, a different input model, and an OS that expected the keyboard to appear and disappear on its own terms.
The build problem underneath it
The more durable piece of work was less visible. The codebase had to produce builds for a range of platforms and targets, and keeping those straight by hand was becoming the bottleneck.
I designed and built a code management system on top of Subversion that managed the codebase across all of them — so that a project targeting several platforms had one coherent source of truth rather than diverging copies. It was the first time I ran into the pattern that has shaped most of my work since: the thing slowing a team down is usually not the feature, it is the machinery around shipping the feature.
Interns and international layouts
I also supervised a team of interns building international keyboard layouts for the SIP interface — my first experience directing other people's engineering work, and a fast education in how much of a layout is convention rather than logic. Every locale has its own idea of where the keys go, what the modifiers do, and which characters deserve a dedicated key.