Heads software engineering across delivery engagements: owns the quality bar, mentors the senior engineers, and keeps the codebase honest.
At home he stocks an indefensible shelf of bitters, spirits, and obscure liqueurs, and insists each one serves a distinct architectural purpose.
The background.
Carter has been writing software since 2011, when he joined the University of Alabama’s Center for Advanced Public Safety as a student programmer while finishing his computer science degrees. The work was ASP.NET MVC applications for state health and human services agencies, built on C#, SQL Server, and Entity Framework with jQuery and Knockout on the front end, and it got serious quickly: he was lead developer on several Alabama health and human services systems, briefly on a grant-management system for Arkansas, and was running a small team of mostly student developers, making the technical and architectural calls, before he had his master’s in hand. Along the way he helped build a form-building workflow management system with a Web API layer feeding multiple client applications, which is where he first learned that the shape of an integration decides how honest the systems on both sides of it get to be.
In 2014 he moved to Alabama CARES, the state’s integrated eligibility and enrollment program, as a lead developer. He helped interview, onboard, and organize a team of forty developers, then led, taught, and managed between twenty and forty of them for two years, sitting on the leadership panel that decided how scrum teams were composed, how the process changed, and how the developer-level staff were run day to day. He also kept writing code: with a small team he built the program’s custom worker portal on Dynamics CRM, forms, views, workflows, web resources, and plugins, along with SSIS packages exporting enrollment data to external systems and the public-facing citizen application portal on .NET MVC with a custom workflow engine. Forty people reading and extending the same codebase is a fast education in what maintainable actually means, and it is where his standard for a codebase that tells the truth about itself was set.
He co-founded Sigao in 2017 as its senior software engineer and has been Director of Development Services since 2018. The work has been as varied as a small firm’s work is: maintaining and extending an Ember and Rails application, building .NET web applications with AngularJS and Angular, writing the .NET REST APIs that stitched them into SQL Server, Azure Search, and CosmosDB, deploying services on Service Fabric with CI/CD in Azure DevOps, and building a custom enrollment-and-eligibility framework on Dynamics 365. He picked up Scrum Inc. Product Owner and Scrum Master certifications in 2020, less out of enthusiasm for frameworks than because it helped to know precisely what the process people were asking for.
Today he runs Sigao’s software engineering practice: he owns the quality bar across delivery engagements, mentors the senior engineers who hold it, and keeps the codebase honest. His mentoring is not a program. It is pairing, by default, on real work, because he takes Peter Naur seriously: a program is the theory in the heads of the people who built it, and the theory transfers by building the thing together, not by handing over documents. His writing on the site is the same argument from different angles: write the spec before anyone, human or agent, starts; put a named human owner on everything AI-influenced that ships; treat practice as paid time; and treat learning as the deliverable the client keeps after the code has been rewritten.
How Carter runs the work.
- i.Write down what done means before anyone, human or agent, starts.A spec doesn’t have to be a thirty-page PRD. It’s the behavior, the constraints, and a definition of done a second person can verify without re-deriving the intent. Skip it and review turns into archaeology, and at agent volume archaeology doesn’t scale.
- ii.The program is the theory in your team’s heads, so that’s where we build it.The text can be handed over; the theory can’t. So pairing is how we work by default, your engineers and ours, same problem, same screen. There’s no handoff cliff at the end because there’s nothing left to hand off.
- iii.“The agent shipped it” is never the answer.Everything AI-influenced in production has a named human owner, and the quality bar is enforced by guardrails, tests and gates every change has to clear, not by asking someone to hand-read every diff. When something gets through, the postmortem interrogates our harness, not the model.
- iv.Keeping the bar high and keeping people learning is one job.Practice and research time is paid time. Twenty years of experience can be one year repeated twenty times if all anyone does is deliver, and I’d rather the schedule visibly pay for an hour of trying something than have people’s skills freeze at whatever the last engagement demanded.
30 minutes, no pitch
The people on this site are the people on the call.
Book a discovery call and you’ll talk to one of the practitioners, not a sales team. We’ll ask hard questions and tell you honestly whether we’re the right fit.