👋🏻 Greetings from Sean Dinwiddie, founder of Sean Dinwiddie’s Webmastery: a lover of writing and a devoted enthusiast of functional reactive programs, crafted in Vim to the soothing sound of my mechanical keyboard.
Every lesson is for every level. Read the course in order, and come back to it as your practice grows; the same lesson goes deeper each time:
- Apprentice (beginner): learn what each lesson names, and try it once on a small example.
- Journeyman (intermediate): use each lesson on real work, and find the rule behind its examples.
- Master (advanced): read each lesson for its edges, where it bends and where it breaks, and for how to teach it.
Some lessons carry short passages that go deeper, headed The rule behind the examples and Where it bends. They are part of the lesson, for every reader. Sean’s Functional Programming Lectures run beneath the course, from Beginner to Advanced.
Are you an administrator who wants operations that run smoothly, or a developer who builds the software behind them?
The course teaches how the Sean Dinwiddie’s Webmastery team builds that software: user stories, the Gherkin scenarios that test them, Redux Toolkit state behind minimal React views and a typed Haskell Servant API, so it keeps serving the people who run it.
The course moves legacy processes onto modern, test-driven practice, one feature at a time.
Our shared objective
A business that runs its own systems after handover, with what its people know written down where the next person can find it.
Systems built with care leave an office more time for the people it serves.
Webmasters at any stage of the craft can build this way under the Sean Dinwiddie’s Webmastery name, keeping their own practice and 70% of the fee on their work: Joining the team sets out the terms.
The lessons teach the principles the team builds by, and are revised as the practice improves.
Where the course helps
The course teaches how the team builds an app: user stories, behavior-driven development and functional reactive programming, a module each, and a fourth module that carries one feature through all three to a typed API and back to the screen.
The lessons show how to build and refine the systems an office runs on, so what customers need matches what the business offers.
Each lesson in the modules starts from a real problem and ends in something a reader can check.
Technical documentation, kept current and shared with the people who use it, lets an office simplify its processes, make fewer errors and teach each new person what the last one knew.
A busy office, a tangled project or a system nobody fully remembers: clear, current direction keeps the work steady.
What the course covers
The course rests on three subjects:
- User stories: The needs, wants and expectations of the people you serve, written so the solution can be checked against them.
- BDD (behavior-driven development): The behavior your systems and processes should show, each piece written as a scenario the owner can read and a test can run.
- Functional reactive programming: Events as plain values, folded into state and derived values by pure functions (reducers and selectors), taught through the Redux Toolkit state layer the team builds with. The lecture The Simplest FP TypeScript Hello World is the first step on the code side: one pure function, then two composed.
Put together, the three subjects are one feature seen three ways, and Module 4 walks a single feature through all of them:
Beside the three subjects, on the same principles, Module 5: Business automation with AI (agentic skills) puts an agent to work on a business process, with a person approving what leaves the building, and Module 6: AI protocol ecosystem teaches the open protocols an AI system crosses and how the team trains and evaluates small language models.
The power of documentation for administrators
Documentation pays an office back four ways:
- Process efficiency: with the office’s processes written down and kept current, the work runs the same way whoever does it, with fewer errors and less time lost.
- Onboarding and training: a new team member learns the work at their own pace and finds answers without waiting on anyone.
- Problem solving: when a problem comes back, its solution is already written down. Nobody reinvents the wheel or loses hours to trial and error.
- Knowledge transfer: administrators come and go, but what they knew stays, because documentation kept current holds it.
The approach
Three habits run through it:
- Start from the people: every job starts with the people who use the result, and their needs go into the written scope as user stories.
- Write it down: each lesson ends in something the next person can use: a story, a scenario, a test or a note.
- Keep it current: technical documentation is a living resource, revised whenever a standard process or system changes, the way the lessons themselves are revised.
Training
The training refines the systems a local business runs on, one lesson at a time.
Do your systems feel heavier than the work they do, with layers nobody can explain?
Do steps run only because they always have?
The lessons answer both the same way: every layer and every step earns its place, or it goes.
The community supports administrators facing development challenges, and the webmasters who build for them, with practice and guidance in crafting niche software.
Members meet at meetups such as the KFalls AI Meetup, bring their questions and learn from one another.
Every lesson is written to be put to work in your own business.
The community is a steady reference for the work that most often stalls an office:
- Scoping a feature as user stories
- Writing the scenarios that test it
- Building the state behind its screens
- Carrying it from the API to the view
Where the course leads
Clear documentation turns an office’s habits into a practice the whole team can follow, with fewer errors and less time lost to guesswork.
The course aims at mastery that spreads: from the lessons into the team’s work, and from the team to every owner who runs their own site after handover.
Vision and mission
Our vision: Business challenges resolved in systems their owners run.
Our mission: Strengthening the service industry of Jefferson State.
Why it matters
Our niche: Software built for the way one office works, so its administrators spend less time on the system, and a search presence that brings it the customers already looking nearby.
The results: every problem solved for a client moves the mission one step on. Every member of the community knows their work means something: each site handed over is one more business its owner can run.
The craft and the people it serves keep the team at it, and the mission moves forward one handover at a time.
I’ll leave you with some food for thought.
Systems thinking.
Evaluate choices through these principles:
- Leverage: how much a choice returns for what goes in, the way a lever or an engine multiplies effort
- Duration: how long a choice keeps paying, and how fast its value decays
- Fallibility: how a choice can go wrong beyond what it was for, through its side effects and second-order consequences, the way an impure function reaches past its result
- Compounding: whether a choice feeds back into itself, so each use makes the next one cheaper or better and the gain grows with scale
High-return examples:
- Capital/asset allocation
- Incentive structures
- Restructuring
- Long-term partnerships
- Radical innovation
Low-return examples:
- Non-consistent, micro-managed, spontaneous actions
- Daily meals
- Wardrobe choices
Read the two lists as a business does. The high-return choices deserve its best thinking: each multiplies effort, keeps paying and compounds, and each can go wrong far past what it was for. The low-return ones come up every day and never compound, so they’re best decided once and made routine, the way an automation takes over a repeated task, leaving judgment free for the choices that pay.
If our vision resonates with you…
Then begin with the next lesson, on user stories.
P.S. Did I mention my fondness for coding Redux.js apps? And that I also love Sublime Text! ✌🏻