Potluck — Do titles matter? × Should clients pay for plugins? × Can I debug my baby? × How we prepare for Syntax × Deno × Learning things quickly × More!

Episode Summary

Executive Summary: This Syntax potluck episode covers practical developer advice across async error handling, client project ownership, compensation/title negotiation, tooling expenses, debugging as a life skill, podcast workflow, scalability for reminder systems, rapid learning strategies, and several sponsor/sick-pick mentions. The hosts repeatedly emphasize choosing the simplest reliable architecture, communicating expectations clearly, and using small projects plus consistency to build expertise.

Main Topics: Promise.all rollback and error handling: A listener asked how to rollback side effects if one promise in Promise.all fails. The hosts argued this is usually a design smell for Promise.all and recommended sequential async flow, try/catch or .catch rollback handlers, and possibly Promise.allSettled when tasks are independent. Owning client repos and project infrastructure: A client-project question about Gatsby + WordPress + GitHub ownership led to advice on keeping repos under a controllable but transferable account setup. The hosts weighed convenience against client independence and argued clients should ultimately own their website assets and source control access. Full-stack work, titles, and compensation: A part-time front-end developer doing PHP/Node work asked whether they should be paid as full-stack. The hosts said title changes can matter internally, but raises should be requested based on expanded responsibility and market value, not title alone. Who pays for client tools and plugins: The hosts discussed whether developers should absorb or bill clients for plugin licenses and dev tools. Their consensus was to clarify costs up front, bake one-time tool costs into project pricing, and have clients directly pay for recurring subscriptions when possible. Debugging as a general life skill: A humorous listener asked whether the hosts try to debug their crying baby. The hosts answered yes, framing debugging as a transferable mindset: gather evidence, test hypotheses, iterate, and use structured checklists for real-world problems. Podcast preparation and consistency: A question about how the show is prepared revealed the hosts use Notion lists, decide topics mostly the morning of recording, and rely on a consistent weekly cadence. They stressed that schedules, repetition, and editorial cleanup are key to producing quality content and audience trust. Scaling reminder jobs with queues and serverless: A listener with a growing reminder system asked how to handle increasing cron job volume. The hosts recommended queues and scheduled/serverless functions so work can be split into smaller tasks, retried safely, and scaled independently of the rest of the app. Learning new technologies quickly: A listener asked how to efficiently learn new tools like Deno. The hosts suggested short, focused projects, immersion, and building utility tools like a contract generator to touch file I/O, text replacement, and CLI patterns.

Key Arguments: Promise.all is usually the wrong abstraction when tasks depend on each other; rollback logic should live in a centralized catch path. If tasks are independent, Promise.allSettled can be used to assess outcomes after all work finishes. Clients should generally own their codebase or at least have transferable repository access so future developers can understand and maintain the site. Job titles matter mostly because organizations often tie them to pay bands, but raises should be justified by actual scope and responsibility. Part-time status should not prevent someone from asking for a raise if their responsibilities have grown. One-off dev tool costs should be folded into the project price; recurring subscriptions are clearer when the client pays directly. Debugging is a transferable problem-solving habit applicable to code, babies, and support calls. Consistent publishing schedules create audience trust and long-term platform growth; laziness compounds if not corrected quickly. Large recurring jobs should be broken into queues or serverless scheduled functions to avoid timeouts and partial failures. The fastest way to learn a technology is to build several small, targeted projects that force you to confront real errors and workflows.

Data Points: Podcast schedule: Monday and Wednesday - The hosts referenced the regular Syntax publishing cadence and the recording routine around it. Recording time: 9 a.m. - Wes said Scott records at 9 a.m. his time, prompting early prep work. Tube content cadence: 3 nights per week for 2-3 years - Scott described consistently recording YouTube tutorials Monday, Wednesday, and Friday nights over multiple years. Subscriber growth: 300,000 subscribers - Scott attributed his YouTube growth to consistent output over time. Course release schedule: Last day of every single month - Scott said Level Up Tutorials courses are released on a fixed monthly schedule. Child age: 4 months - A listener mentioned having a four-month-old daughter and debugging her crying. Queue example volume: 500 items - Mike D described a daily cron job potentially sending about 500 notifications. Notification breakdown: 200 text messages and 300 emails - Scott used this as an example of mixed outbound jobs in a batch process. Serverless runtime limit: Up to 15 minutes - Scott mentioned a current AWS/serverless time limit while discussing long-running tasks. Accessibility base font note: 10px vs 62.5% - Scott corrected a prior statement, explaining that 62.5% respects user font preferences while a fixed 10px root size does not.

Pivotal Quotes: "I think most managers will not care about that because I don't think most managers worry too much about the job titles as long as you're not like, hey, can I become the CTO just because I'm doing CTO things?" — Scott: On whether a developer should request a title change from front-end to full-stack before asking for more pay. "If we miss one just because we're being lazy, we're going to miss two because we're lazy. And then we're going to miss three because we're lazy." — Wes: On why consistency and a fixed publishing schedule are critical for podcast and platform growth. "I don't think it matters that you're part-time or not because they're paying you for your time for your skill set." — Scott: On whether a part-time developer doing full-stack work should still ask for a raise.

Implications: Listeners should take away that scalable, maintainable systems usually come from clear ownership, explicit pricing, and the right abstraction for the job. For developers, consistent practice and small projects remain the fastest route to mastering new tools.