Bill Brocker

Software developer and instructor. Twenty years building technology, now teaching it — and making tools that help people see how systems actually work.

Jupiter, Florida

What I do Building, data, and explaining both to everyone else.

I build small (to start), careful software — and I explain it to the people who have to live with it.

Most of my career has been spent between two rooms: the one where the system gets built, and the one where somebody has to understand it well enough to decide something. I'm comfortable in both.

Web tools, end to end

Small sites and applications built to last: plain where plain works, no framework churn, and a deploy anyone can repeat.

Data and analysis

Turning a pile of records into something a person can act on, with the reasoning shown rather than asserted.

Teaching and translation

Classrooms and boardrooms both. Explaining technical work to people who don't share the vocabulary is its own skill.

Process How the work gets done — and what the method costs.

Three parties, one very fast loop: me, my notes, and Claude Code.

I decide what's worth building next and judge whether what came back is actually right. Claude Code writes the code, fixes the bug, and runs the deploy. An Obsidian vault sits underneath both of us: one idea per note, decisions recorded with the reasoning that produced them, and standing rules the assistant has to follow — so it begins each task already knowing what was settled and what it isn't allowed to do.

The cycle is the point. Build a change, deploy it, test it against the real thing, and go again — often several times in an hour. A bug found at 10:05 is usually fixed, deployed and verified before 10:20. What makes that compound rather than just churn is the last step: whatever the loop taught goes back into the vault as a note or a new rule, so the next pass starts from it instead of rediscovering it.

Me what next, and is it right? Build or fix Claude Code Deploy one command Test it live the real thing steer found a bug? go again — minutes, not sprints Obsidian vault decisions · designs · standing rules · what each pass taught what we decided rules it must follow what this pass taught
Note where the judgment sits. The assistant is fast and tireless and occasionally confidently wrong, so deciding what to build and whether it actually works stays with me. Speed comes from the cycle; correctness comes from testing every pass against the real thing, and from writing down what it taught.

What it's genuinely good at

  • Speed to something real. An idea reaches a working, deployed page in an afternoon rather than a month of evenings.
  • Nothing gets forgotten. The vault holds why a decision was made, so I don't relitigate it six months later or repeat a mistake I already paid for.
  • Rules stick. A lesson learned once becomes a written rule the assistant follows afterward, instead of something I have to remember to say again.

What it costs

  • It can be confidently wrong. A fluent answer with no hedging is still sometimes false. Verification isn't overhead; it's part of the method.
  • Generated code inherits old bugs. Code assembled from common patterns carries their common failures — I've had a site white-screen from exactly that.
  • Machine-written notes aren't my thinking. I keep them marked and separate, or the vault stops being a record of what I concluded.
Background Palm Beach Code School, Jupiter Christian, RuleStream, UT Automotive.

Twenty years of it, in rather more rooms than I expected.

  • Data Scientist & Instructor, Palm Beach Code School 2018 – present

    Working with students on data science and development.

  • Adjunct Teacher, AP Calculus AB & BC, Jupiter Christian School 2023 – 2024

    Juniors and seniors, both levels of the AP course. The most rewarding work I've done.

  • Co-Founder & VP, Field Operations, RuleStream 1999 – 2003

    Design-automation software for engineers. Grew from three founders to eighteen employees and $1.3M in revenue.

  • Manager, Advanced Information Technology, UT Automotive 1996 – 1999

    Led advanced technology projects and teams of up to fifteen developers.

Contact Something you'd like built, taught, or explained?

If you have something you'd like built, taught, or explained, I'd like to hear about it.

The best way to start is a short note about what you're trying to do — I'll tell you honestly whether I'm the right person for it.