Conventional

Podcast 2 — In conversation

Speaker A: We took the conventional approach of microservices first, then refactored. In hindsight, a modular monolith would have served us better for two years.

Speaker B: The conventional approach — what most teams in your situation would do. Conventional choices are lower-risk in terms of reputation: if you do what everyone does and it doesn't work, the failure is shared. If you try something unconventional and it fails, the blame lands on you.

Speaker A: The conventional wisdom was that batteries couldn't scale economically to power large vehicles. That turned out to be wrong.

Speaker B: Conventional wisdom — the shared background assumption that everyone treats as obvious until someone disproves it. Conventional wisdom is often right, but its danger is that it stops people asking whether it's still right as conditions change.

Speaker A: It's a very conventional CV — well-structured, lots of relevant experience, but nothing that makes it stand out.

Speaker B: Conventional as a gentle criticism — it meets all the requirements but offers no reason to choose it over other candidates who also meet all the requirements. Conventional and competent, but not distinctive.

Speaker A: People sometimes confuse conventional and traditional.

Speaker B: Traditional emphasises connection to the past — something traditional has a history and often a meaning beyond mere function. Conventional emphasises conformity to current norms — it's about what people generally do now, regardless of historical continuity. A traditional wedding involves historical customs; a conventional wedding follows current social expectations. You can have a conventional practice with no traditional significance at all.

Speaker A: And don't confuse conventional with orthodox. Orthodox carries a stronger sense of doctrinal correctness — especially in religious, philosophical, or scientific contexts. A conventional solution is the one most people would choose. An orthodox solution is the one that the relevant authorities or institutions would endorse as correct.

Podcast 3 — Prompt engineering

Speaker B: Scenario one — an architecture decision prompt.

Write an architectural decision record comparing a conventional REST API architecture with a GraphQL-based alternative for a new product API. The ADR covers: what makes REST the conventional choice (wide tooling support, team familiarity, simpler caching, well-understood security model), what GraphQL offers that departs from the conventional approach (client-specified queries, reduced over-fetching, a single endpoint), why departing from the conventional approach requires explicit justification and what the costs of that departure are (team learning curve, tooling immaturity, cache complexity), and the recommended decision with rationale.

Speaker B: Departing from the conventional approach requires explicit justification is the architectural principle — conventional choices carry a lower burden of proof because their failure modes are well understood.

Speaker A: Costs of departing from the conventional approach including team learning curve and tooling immaturity quantifies the unconventional tax.

Speaker B: Next — a conventional commits prompt.

Write a code review checklist for evaluating whether a pull request follows conventional practices for the team's TypeScript codebase. Conventional practices to check: error handling uses Result types or throws typed errors rather than silently swallowing exceptions, async functions are conventionally awaited or their promises are handled, conventional test file co-location (test files beside source files, not in a separate test directory), database queries use the conventional query builder rather than raw SQL unless there is a documented reason, and API responses follow the conventional response envelope structure.

Speaker A: Unless there is a documented reason for departing from the conventional approach is the escape hatch that distinguishes deliberate architectural choices from careless deviations.

Speaker B: Right. Now a database schema.

Create a PostgreSQL schema for a pharmaceutical clinical trial management system covering both conventional and experimental treatments. Tables: trials, treatment_arms, patients, outcomes, adverse_events. treatment_arms stores trial_id, arm_name, treatment_type enum conventional, experimental, placebo, treatment_description, and dosage_protocol. outcomes stores patient_id, arm_id, outcome_date, primary_outcome_measure, and outcome_value numeric. adverse_events stores patient_id, arm_id, event_date, event_severity enum mild, moderate, severe, and event_type. A summary view computes conventional arm outcomes versus experimental arm outcomes for the primary endpoint.

Speaker B: Conventional versus experimental arm comparison in the summary view is the primary clinical trial output — the whole point is to measure whether departing from the conventional treatment produces better outcomes.

Speaker B: Fourth — a design system prompt.

Write a guide to when to follow and when to depart from conventional UI patterns for a product design team. The guide covers: why conventional patterns (standard button positions, expected navigation locations, familiar form layouts) reduce cognitive load for users, when departing from conventional UI is justified (the conventional pattern doesn't solve the actual problem, or there is a meaningfully better alternative with evidence), how to validate unconventional UI patterns before shipping by testing with real users, and how to communicate to users when a UI departs from convention so they can adjust their expectations.

Speaker A: Validate unconventional UI with real users before shipping is the guard against designers underestimating how much users rely on conventional patterns — what seems obvious to the designer may baffle the user.

Speaker B: Fifth — a finance prompt.

Write an explainer on conventional versus unconventional monetary policy for an economics education platform. Cover: what conventional monetary policy is (adjusting the central bank's base interest rate to influence borrowing costs, inflation, and economic activity), why conventional policy reached its limit at the zero lower bound when interest rates were already near zero, the unconventional monetary policy tools deployed after 2008 (quantitative easing, forward guidance, negative interest rates), and the debate among economists about whether these unconventional tools are now becoming conventional given how frequently they are used.

Speaker B: Unconventional tools becoming conventional through frequent use is the reflexive point — what counts as conventional changes over time as novel tools are normalised.

Speaker B: Sixth — a full small app.

Build a single-page web app called Conventional vs Unconventional — a decision-making framework tool. User defines a decision they face. They assess the conventional option (what most people in this situation would do) and up to three unconventional alternatives. For each option, they rate: risk level, estimated upside, reversibility, and how well it fits their specific context. The app calculates a conventional premium (what extra benefit the unconventional option needs to offer to justify departing from the safe conventional choice) and displays a recommendation.

Speaker A: Conventional premium calculation quantifies the hurdle that unconventional options must clear — departing from convention has a real cost, and the alternative needs to explicitly outperform by enough to justify it.

Speaker B: That's the lesson — conventional means it follows the established way. Conventional choices are lower-risk, lower-explanation-cost, and often wiser than they appear. Unconventional choices get more attention and credit when they work, but the conventional approach has the advantage of tried, tested, and understood. Knowing which to choose — and being able to explain why — is one of the marks of a mature professional.

Speaker B: Prompt example: