938: Hot Takes + Bike Shedding

Episode Summary

Executive Summary: Wes and Scott debate a series of developer “bike-shedding” preferences across CSS, JavaScript, TypeScript, Git, and editor settings. They consistently favor explicitness, readability, and practical workflow over convention, but admit many choices are taste-based and have shifted over time. The episode frames these minor-seeming decisions as meaningful because they affect maintainability, clarity, and day-to-day developer experience.

Main Topics: CSS naming conventions: They compare naming color tokens by actual color versus semantic roles like primary/secondary. Both prefer semantic names for themeable apps, while literal names can work for fixed-brand sites. JavaScript/TypeScript code style: They debate snake_case vs camelCase, default exports vs named exports, barrel files vs direct imports, function declarations vs expressions, inferred vs explicit types, and variable naming length/comments. The recurring preference is clarity and predictability. Git workflow preferences: They compare rebasing versus merge commits. Both lean toward merge commits or simple squashes because rebasing can complicate history and dependent work, especially for smaller teams. Editor formatting and readability: They discuss tabs vs spaces, line height, and hard line length/wrapping. Tabs, smaller line height, and either hard line limits or intentional wrapping are judged mostly by practicality and screen density. Naming and abbreviations: They prefer long, descriptive names in most cases, but allow short abbreviations for common event-handler variables like e, req, and res. They note these exceptions are mostly ergonomics-driven. Code comments and self-documentation: They push back on the idea that code should fully self-document, arguing comments remain useful for explaining quirks, integration details, and intent that names alone cannot capture. Taste evolves over time: They close by reflecting that many of these positions have changed over their careers, reinforcing that much of developer style is learned preference rather than objective truth.

Key Arguments: Semantic CSS variables (primary, foreground, background) are safer for theming and future changes than literal color names like red or yellow. Named exports are more predictable and easier to refactor than default exports, especially when a file grows beyond one main export. Direct imports are preferred over barrel files because they reduce hidden magic, improve explicitness, and avoid unnecessary loading or hunting through index files. Function declarations feel more intentional and less awkward than wrapping functions in variables, and they align better with the existence of the function keyword. Explicit TypeScript types are favored when APIs are shared externally or when AI/code assistants need clearer guidance, though inferred types remain useful internally. Long, descriptive variable names are preferred over comments or short abbreviations because the meaning travels with the code and remains clear in other files. Comments are still valuable for context, quirks, and integration details that variable names and type signatures cannot express. Merge commits are simpler for solo/small-team workflows and avoid the chain-rebase problems that can arise when shared code depends on rebased work. Tabs are preferred because indentation width can be adjusted in the editor while the tab character itself stays one character. Small line height increases information density and makes it easier to view and record more code on screen at once. Hard line limits or intentional wrapping are seen as better than letting code flow arbitrarily, though they disagree on the best visual behavior. Many of these choices are ultimately taste-driven, and the speakers acknowledge their own opinions have changed substantially over time.

Data Points: Color scheme example: light and dark mode - Discussing whether CSS variables should be literal color names or semantic names across themes Common shorthand variables: e, req, res - Short variable names accepted as exceptions for event, request, and response handlers Character limit example: 140 characters - Scott mentions using a 140-character formatter limit for line length Tab size: adjustable in editor - Tabs are defended because their display width can be changed visually in the editor Line height preference: small - Both prefer compact line height for more information density on screen Team/workflow size: small team or solo - Wes says merge commits work fine for his smaller collaboration style

Pivotal Quotes: "I am using the color names. Like on the syntax site, things that are yellow are yellow." — Scott: Arguing that literal color names are fine for fixed visual systems without theming "I 100% don't like barrel files." — Scott: Explaining a preference for explicit direct imports over directory-level re-export files "I love comments. Comments all day long." — Scott: Rejecting the idea that code should always be fully self-documenting

Implications: Listeners are encouraged to choose conventions that improve clarity, maintainability, and team workflow rather than follow style dogma. The episode suggests that many “minor” preferences materially affect development speed and code comprehension.