Working

Podcast 2 — In conversation

Speaker A: A working knowledge is one of those compound expressions that is enormously useful in practical contexts. When a job advertisement says that a working knowledge of Python is required, it means the applicant needs to be able to do useful work in Python — not that they need to be an expert or know the language in exhaustive depth, but that they can function effectively and solve real problems with it. Working knowledge occupies a practical middle ground between complete ignorance and expert mastery that corresponds to genuine professional usefulness.

Speaker B: The working class as a social and political category has a complex history in English-speaking societies. Originally referring specifically to industrial and manual workers in the nineteenth and early twentieth centuries, the term has been contested and redefined through the decades. Who counts as working class — is it defined by income, by occupation, by relationship to capital, by cultural identity, or by self-identification? The answer varies between political traditions, academic frameworks, and the individuals themselves. In contemporary Britain, working class is simultaneously a sociological description, a political identity, and a cultural marker.

Speaker A: Working versus functional — what is the distinction?

Speaker B: Both describe something that operates correctly, but with different emphases. Working typically describes something that operates well enough for practical use — a working solution may not be elegant or optimal, but it achieves the required result. Functional is similar but perhaps more neutral — it simply describes correct operation without any implication about quality or elegance. A working solution is one you can use; a functional one meets its specification. In practice, they overlap significantly, but working carries a slightly more pragmatic, get-things-done quality — it works, which is the important thing — while functional is more technical and neutral.

Speaker A: What is a common mistake about working?

Speaker B: Using working as a synonym for good or well-designed, when it specifically means operational — it functions, it does the required job. A working solution may be poorly designed, technically in debt, and in urgent need of replacement, but if it delivers the required output, it is working. Conflating working with good quality is a common error in engineering contexts — a team that declares a solution working may be technically correct about its functionality while being diplomatically silent about its quality. The distinction matters: something can be working and simultaneously in urgent need of improvement.

Speaker A: Any close synonyms?

Speaker B: Functional as discussed — operational in the neutral technical sense. Operational is close for currently in service and functioning. Practical is close for the working knowledge sense — knowledge that can be applied in practice. Active is close for the ongoing-activity sense. Live is close in computing — a live system is one that is currently running and serving users. In the working class sense: blue-collar, manual, labour, and proletarian are close synonyms with their own political and social connotations. Working is the most versatile and neutral of these, applicable across technical, social, and everyday contexts.

Podcast 3 — Prompt engineering

Speaker B: Welcome to the workshop. Today we prompt AI using the word working — building the operational status monitoring and system health tools, working prototype and feature-flag management systems, development workflow and CI-CD pipeline tools, real-time system operational dashboards, and working-knowledge documentation and onboarding platforms that track whether systems are working, keep teams working effectively, and document how things work.

Speaker A: So working tells the AI to build the operational and workflow management systems — the system health and uptime monitoring tools that confirm whether systems are working correctly, the feature flag and prototype management systems that track which features are working in production versus in development, and the CI-CD pipeline tools that automate the path from code to a working deployment?

Speaker B: Exactly. It signals operational status monitoring, workflow automation, and working-state management. Let me start with a system operational status and health monitoring system.

Build a system operational status and health monitoring system: continuously probe all registered services and endpoints for availability and correct response. Track uptime percentage for each service over rolling windows — last hour, last day, last thirty days. Alert immediately when a service transitions from working to not working. Record the duration of each outage. Generate status page content showing the current operational status of all services. Support multiple check types — HTTP status codes, response time thresholds, and content validation.

Speaker B: Operational monitoring system probes services for availability-and-correctness, tracks rolling-window uptime percentages, alerts on working-to-not-working transitions, records outage durations, generates status page content, and supports HTTP-response-time-content-validation check types — the AI builds the prober, the uptime tracker, the transition alerter, the outage recorder, the status page generator, and the check type handler.

Speaker A: Multiple check types — HTTP status codes, response time thresholds, and content validation — rather than only a simple ping are the genuine-functionality verification mechanism: a service that responds with HTTP 200 in fifty milliseconds but returns an error message in its response body is technically reachable but not actually working; content validation checks the response content, not just the status code, ensuring the service is genuinely operational.

Speaker B: Content validation as the HTTP-200-but-error-body technically-reachable-not-actually-working versus genuine-response-confirmation genuine-functionality verification mechanism. Now the operational status schema.

Design a service health monitoring and operational status schema: a monitored_services table recording each service with an ID, name, the check URL, the check type as HTTP, response-time, or content-validation, the check interval in seconds, the expected response code, the content match pattern if applicable, and the current status as working or degraded or down. A health_checks table recording each check result with the service ID, the check timestamp, the response time in milliseconds, the HTTP status received, the content match result, and the overall check result as pass or fail. A outages table recording each outage with the service ID, the start timestamp, the end timestamp, the duration in minutes, and the root cause if determined. A service_uptime_view computing per-service the uptime percentage over the last hour, last day, and last thirty days.

Speaker B: Operational status schema stores services with check-type-interval-expected-response-current-status, health checks with response-time-HTTP-status-content-match-result, outages with start-end-duration-root-cause, and an uptime view with per-service hourly-daily-monthly percentages — the AI builds the four-table schema.

Speaker A: The rolling uptime percentages at three timescales — last hour, last day, last thirty days — provide different operational perspectives: the hourly uptime reveals current reliability in real time; the daily uptime shows the pattern over a full operational cycle; the thirty-day uptime is the contractual SLA measurement window that determines whether service level agreements have been met.

Speaker B: Three-timescale uptime as the current-real-time-hourly versus operational-cycle-daily versus SLA-measurement-monthly different operational perspectives mechanism. Next, the status monitoring interface.

Design a public-facing service status page and internal operations dashboard: the public status page should show each service with a simple working, degraded, or down indicator and the uptime percentage for the last thirty days. Show an incident history with the last ten outages and their durations. The internal operations dashboard should add response time trend charts for each service over the last twenty-four hours, active alert notifications, and a current check results feed showing the most recent check for each service in real time.

Speaker B: Status page shows public working-degraded-down indicators with thirty-day uptime and ten-outage history, while internal dashboard adds response-time trend charts, active alert notifications, and real-time current-check feed — the AI builds the public status page, the indicators, the incident history, the internal dashboard, the trend charts, the alerts, and the check feed.

Speaker A: The public versus internal distinction — giving external users a simplified status view while giving the operations team detailed diagnostic information — is the appropriate information scoping mechanism: external users need to know if the service is working and when it last had a problem; the operations team needs response time trends, active alerts, and real-time check results to diagnose and resolve problems; one view serves both audiences poorly.

Speaker B: Public-simplified versus internal-detailed as the one-view-serves-both-poorly versus appropriate-audience-scoping information scoping mechanism. On to feature flags.

Create a feature flag and working-feature management system: define feature flags with a name, description, and current state — on or off globally, or enabled for specific users, user segments, or environments. Track which features are working in production versus in development or testing. Support gradual rollout — enable a feature for a percentage of users and increase the percentage incrementally. Log all flag state changes with the user who made the change and the timestamp. Alert on feature flags that have been in a partial rollout state for more than a defined number of days.

Speaker B: Feature flag system defines flags with global-or-segment-or-environment state, tracks production-versus-development working features, supports percentage-based gradual rollout, logs flag changes with user-and-timestamp, and alerts on stale-partial-rollout flags — the AI builds the flag definer, the state manager, the segment evaluator, the rollout engine, the change logger, and the stale alerter.

Speaker A: Alerting on feature flags in partial rollout for more than a defined number of days — surfacing flags that were enabled for gradual rollout but never completed — is the flag hygiene mechanism: a partial rollout that was started but not completed leaves the system in an inconsistent state where some users have a feature and others do not; the alert prompts the team to either complete the rollout or roll back the feature.

Speaker B: Stale-partial-rollout alert as the inconsistent-some-have-some-don't versus complete-or-rollback flag hygiene mechanism. Now something whole.

Build a software delivery and operational health platform: manage the full lifecycle from code commit to working production deployment. Track build status, test results, deployment progress, and post-deployment health checks. Manage feature flags for controlled feature rollout. Monitor operational health of all services with uptime tracking and alerting. Provide a unified view of what is currently working in production, what is being rolled out, and what is degraded. Generate weekly deployment and reliability reports for engineering and product leadership.

Speaker B: Software delivery platform manages commit-to-deployment lifecycle with build-test-deploy-health-check tracking, feature flag rollout management, service uptime monitoring with alerting, unified working-rolling-out-degraded production view, and weekly deployment-and-reliability reports — the AI builds the full software delivery and operational health platform.

Speaker A: The unified view of what is currently working in production, what is being rolled out, and what is degraded — a single screen showing the full state of the production system — is the situational awareness mechanism: in a complex system with many services, features, and deployments in progress simultaneously, no single person can hold all the state in their head; the unified view provides the shared situational awareness that enables coordinated response.

Speaker B: Unified working-rolling-degraded view as the complex-system nobody-holds-all-state versus coordinated-response-enables shared situational awareness mechanism. Last one — operational API.

Write a system operational status and feature flag REST API: provide endpoints for querying the current working status of all registered services with their uptime percentages, querying the status of a specific service including its recent check history, recording a new health check result for a service, querying the current state of all feature flags for a specified user or environment, updating a feature flag state, and retrieving the current rollout percentage for a feature. Return all results as structured JSON with timestamps and status metadata.

Speaker B: Operational API provides all-services working-status with uptime, specific-service status with recent history, health check result recording, per-user-or-environment feature flag state queries, flag state updates, feature rollout percentage retrieval, and structured JSON with timestamps and status metadata — the AI builds the full system operational status and feature flag REST API.

Speaker A: Querying feature flag state for a specified user — returning the flags as they apply to that specific user rather than the global default — is the personalised flag evaluation mechanism: a feature flag in partial rollout may be on for some users and off for others; a support agent investigating a user's experience needs to know what features that specific user sees, not the global flag state.

Speaker B: That is the goal — one operational adjective, better-designed system health monitoring and feature flag management systems. Keep it in your kit.