My Engineering Practice
What I learned from building and maintaining software at the California State Legislature for over a decade.
I have built and maintained web applications and systems at the Legislative Data Center for over a decade, supporting the California State Legislature. The Legislative Data Center has provided technology services to the Legislature since the 1970s, and the pace of the work is faster than most people expect. These principles come from that environment, and from the mistakes that shaped how I operate within it.
I. Live With What You Ship
I still maintain systems I first architected at the start of my career. In an organization where some applications have been evolving for decades, that kind of continuity teaches you things that are hard to learn any other way.
You discover which abstractions held up under real use and which ones became the friction everyone works around. That experience compounds. It made me deliberate about longevity in ways that reading about maintainability never could. Every system I build now, I build with the assumption that anyone on the team should be able to maintain it five years from now. Sustainability is a shared responsibility, and the best way to future-proof a system is to make sure no single person has to carry it alone.
II. Solve the Problems That Need You
I have worked with Drupal my entire career. It provides authentication, role-based access control, and session management out of the box. These are solved problems, and I treat them that way. I lean on those foundations so I can spend my engineering time where it actually matters: the domain logic that requires institutional knowledge to get right. Multi-department procurement rules. Legislative workflow automation. Scheduling systems with constraints that only make sense if you understand how the Legislature operates.
The most valuable engineering I have done came from knowing which problem deserved my time and having the discipline to leave the rest alone.
III. Manage Essential Complexity
The systems I build support the legislative process: floor sessions, committee hearings, the publishing of legislative daily files, and the coordination that keeps all of it moving. Within that process, real-time use cases like member tracking, transportation, and scheduling carry their own complexity. Fred Brooks called this essential complexity: it lives in the problem domain itself and cannot be designed away, only managed well or managed poorly.
The part I can control is everything else. Whether the codebase accumulates unnecessary abstraction layers. Whether a clever pattern obscures the intent it was meant to clarify. Whether a new developer can trace a request through the system without a guided tour. I aim for codebases that are searchable, traceable, and logical. Large enough to handle what they need to handle, clear enough that the next person can work in them confidently.
IV. Know the Domain
Engineering for the legislative process requires more than technical ability. Bills move through a lifecycle, from drafting through committee hearings and floor debate to enrollment. The systems that support each stage carry their own rhythms and their own urgency during session, with constraints that only become visible through experience.
That familiarity is where my best work has come from. When I led the redesign of the Room Reservation Management System, I started by interviewing and observing the staff who operated it hands-on during peak legislative periods. Sitting with them through their actual workflow revealed what no requirements document would have surfaced: the same data entered into the same fields, repeatedly, while the queue backed up. The system functioned, but the process had friction that routine had made invisible. From those observations, I proposed a drag-and-drop interface that let staff move pending requests directly onto the reservation calendar with a single confirmation step, and designed the backend to support it. That kind of improvement comes from spending enough time inside the institution to ask the right questions and recognize the gaps.
V. Verify Honestly
I believe in testing, and I am candid about where my practice stands. Under legislative deadlines, where session calendars are fixed and deployment windows are narrow, test-driven development is not always realistic. We still maintain robust testing procedures, but they require more involvement and time than a TDD workflow assumes. I ensure critical paths have coverage, and I am building verification into my process more systematically with each project.
I would rather be straightforward about where I am than overstate a discipline I am still growing into. The goal is clear, the practice is evolving, and I am honest about the distance between them.
VI. Engineer for Accountability
I have spent enough time inside long-running production systems to know that when something goes wrong, recovery depends on whether the system can be questioned. That means structured logs that tell a coherent story, error paths that surface useful detail instead of swallowing it, and decisions encoded in code that a reader can follow without insider knowledge. Auditability and traceability are properties of mature production engineering, and I treat them that way from the first commit.
This connects to the first principle. A system someone else can maintain five years from now is the same system you can debug under pressure, and both rest on the codebase being readable by people who were not there when it was built. I aim for that readability deliberately.