Summary of 956: Should I Keep Using WordPress?

Overview of 956: Should I Keep Using WordPress?

Hosts Wes Bos and Scott Tolinski answer listener questions in a potluck episode covering SSL certificates, the state of front-end jobs, the value of headless WordPress, TypeScript type organization, GitHub Actions/versioning (changesets), IDE alternatives to VS Code, career worries around AI/job stability, and how to get started contributing to open source. The episode mixes practical how-tos, hiring and career advice, and opinionated recommendations.

Meetup notes

• Hosts returned from a big GitHub meetup in San Francisco — great turnout, merch, and conversations (including industry folks and enthusiastic attendees).
• They met Zed editor folks and WebStorm people; mention of stickers causing an airport x-ray surprise.
• Encouragement for listeners to suggest cities for future meetups (Toronto, Seattle, Europe, etc.).

Q&A summary

1) Paid SSL vs Let's Encrypt

• Main point: Let's Encrypt is generally sufficient.
• Paid certificates mostly provide additional organization validation (OV/EV), which browsers don’t highlight as they used to; no material security benefit over a DV (domain-validated) cert for most sites.
• Use paid certs only if you specifically need organization validation or a vendor workflow that requires it.
• Reminder: SSL only protects transport (TLS); it doesn’t prevent DB leaks, credential issues, or other security problems.

2) Does a pure front-end developer role still exist?

• Yes — but expectations have shifted.
  • Front-end specialists now need deeper knowledge (React, SSR, performance, architecture).
  • In larger companies, roles are more specialized; in smaller teams you’ll often be expected to handle “front-to-back” tasks.
• Recommendation: Learn some backend fundamentals and systems design to make yourself more hireable; being able to ship end-to-end is valuable.

3) Is the software industry going to stabilize (job market worries)?

• Reality: “Good gravy years” (rapid, easy hiring/huge salaries) have tapered off. Every industry is feeling disruption (AI, market shifts).
• Advice:
  • Differentiate by becoming invaluable: systems design, problem solving, architecture, product thinking.
  • Build and ship projects — practice and public work helps you stand out.
  • AI is changing hiring; some teams now allow AI in interview tasks to see how candidates leverage tools.
  • Effort & reputation matter: put work in, publish consistently, and get real reps.

4) Automating versioning & Change Sets (monorepo vs simple repo)

• Change Sets is useful for automating changelogs, version bumps, and publish flows — it’s designed with monorepos in mind but works for single repos too.
• Basic flow:
  • npx changeset (to create a changeset)
  • npx changeset version (to apply the version bump and changelog)
• You can run the above in GitHub Actions (e.g., run npx changeset version in CI), have it commit/push tags, and publish.
• Change Sets makes contributor workflows easier (require a changeset PR) and can be automated with bots/agents.

5) Using an IDE other than VS Code (Zed, Warp, Cursor, WebStorm)

• Zed: hosts are excited — fast UI, many formerly-extension features built-in, snappy code actions. Still evolving but promising.
• Warp: moving from terminal to richer editor-like workflows (interesting experiments).
• Cursor: standout tab-completion and completions experience.
• VS Code: still solid and extensible, but some features now exist natively in newer editors. Try alternatives — you may find better speed/UX for certain tasks.
• Practical tip: Evaluate what extensions/features you actually rely on; many are now native across editors.

6) Should a WordPress dev go headless?

• Short answer: Generally, stay with classic WordPress (PHP templates) unless you have a clear architectural need to go headless.
• Reasons to stick with WordPress:
  • Batteries-included ecosystem (plugins, WooCommerce, page builders).
  • Simpler hosting and editing workflows for content-heavy, frequently edited sites.
  • Headless adds complexity: separate hosting for front/backend, reimplement many features, rebuild preview/editing workflows, rebuild login/auth, caching, image handling, etc.
• When headless makes sense:
  • You need a CMS feeding multiple channels (mobile apps, signage, multiple frontends).
  • You want to combine a custom backend (e.g., Supabase) with a modern static front end and can accept the tradeoffs.
• Alternative: modernize WordPress workflows (Git-based deployment, CDNs, caching, page transitions) rather than abandoning it.

7) Organizing TypeScript types

• Practical approach:
  • Keep types local to the file/module if they are only used there.
  • If a type is shared across multiple files, move it to a central types directory (or types.ts) — aim to avoid duplicate slightly-different definitions.
  • Prefer inferred types where practical; use inference to avoid redundant definitions.
  • Use TypeScript’s refactoring tools to move types when they become shared.
• Rule of thumb: minimize duplicated definitions and prefer a single source of truth for domain types (e.g., DB schema → inferred types).

8) How to become someone who builds libraries / OSS — luck vs effort

• Main message: consistency and shipping matter far more than “luck.”
• Tactics:
  • Publish things to GitHub (even small, imperfect tools).
  • Share in communities (Discord, Twitter, relevant repos).
  • The act of building/publishing leads to follow-up work (bug fixes, process improvements, people noticing).
• Quote paraphrase: “There is nothing other than just doing it. Put stuff on GitHub.”

9) CTO of an agency considering product company move

• If you’re burned out or craving depth/specialization, a product company can be a good shift.
• Agency work builds broad experience; product roles let you go deeper in a domain.
• If you’re excited about learning and growth, switching makes sense. If you value flexibility and autonomy, weigh tradeoffs.
• Practical step: explore product roles that align with your interests and appetite for new challenges.

Key takeaways

• Use Let's Encrypt for most sites; paid certs rarely needed.
• Pure front-end roles still exist, but depth (React, performance, SSR) and broader skills help.
• The job market has cooled — stand out by shipping projects, learning systems design, and demonstrating problem solving.
• Change Sets + GitHub Actions = easy automated versioning and changelogs; start with the intro/to-use guide and the simple npx CLI usage.
• Try modern editors (Zed, Cursor, Warp) — many features you rely on in VS Code are becoming native elsewhere.
• Don’t headlessly decouple WordPress unless you need multi-channel content or specific architecture — modernize the WP workflow first.
• Organize TypeScript: local types for local use, central types for shared definitions, prefer inference when appropriate.
• Publish work and iterate — consistency beats waiting for luck.
• If you’re an overworked generalist CTO wanting depth, a move to a product company is a reasonable option.

Recommended action items (practical next steps)

• If hosting a site: use Let’s Encrypt for TLS and reserve paid certs for specific OV/EV needs.
• Try Change Sets in a test repo:
  • Run npx changeset to create a changeset
  • Automate npx changeset version in GitHub Actions
• Experiment with Zed or Cursor for a week; compare completion/latency and code action speed vs VS Code.
• If you’re job hunting:
  • Build and publish a small project in 6 weeks to showcase architecture & problem solving.
  • Practice system-design problems and real-app planning (use AI as a tool to speed learning).
• For TypeScript: create a types/ folder and migrate any types used in >3–5 files; rely on inference for ephemeral structures.
• Publish at least one small tool/library to GitHub and announce it in a relevant community channel.

Notable quotes / soundbites

• “Good gravy years are over.” — summary of past hiring boom.
• “There is nothing other than just doing it. Put stuff on GitHub.” — on getting started with OSS and libraries.
• “Let’s Encrypt is fine; paid SSL is mostly an old business model now.” — practical security advice.

Tools & names mentioned to explore

• Let’s Encrypt (free TLS certificates)
• Change Sets (npx changeset) + GitHub Actions
• Zed, Cursor, Warp, WebStorm, VS Code
• Sentry (error monitoring) — mentioned as a recommended monitoring tool
• Supabase / Sanity (as headless CMS/backend alternatives)
• WooCommerce (WordPress e-commerce)

If you want, I can extract a one-page checklist from these action items tailored to either (a) a freelance WordPress developer, (b) a developer job seeker, or (c) someone wanting to publish open-source libraries.