Our Workflows: Design, Development, Git, Deployment

Episode Summary

Executive Summary: Scott and Wes compare their end-to-end web development workflows: how they sketch and refine designs, translate them into code, manage Git branches and commits, deploy apps, and organize large projects. They emphasize batching work, reusing tooling and component systems, and choosing workflows that fit the project rather than forcing one universal process.

Main Topics: Design workflow and inspiration: Scott designs mostly in Sketch, starting from mood and inspiration, sketching rough ideas on paper, then refining colors, typography, texture, and layout before moving to code. Wes relies more on iterative design in Figma for an established site, borrowing inspiration and refining over time. Design-to-development transition: Both speakers advocate moving from broad layout to code in stages: set up tooling, implement HTML structure first, then style and refine. Scott stresses using as much HTML as possible before CSS; Wes emphasizes batching and reducing context switching. Tooling and responsive workflow: They discuss preferred tools like Sketch, Figma, BrowserSync, Parcel, styled-components, Sass/Stylus, React, Gatsby, Next.js, and Meteor. Breakpoint strategy is discussed, including mobile-first versus desktop-first depending on the project and inlining media queries for readability. Git workflow and branch strategy: Scott and Wes outline how they use branches, commits, rebasing, pull requests, and master/develop conventions. Scott uses develop as an integration branch and deploys from master; Wes branches directly from master by issue number and rebases frequently to stay current. Deployment and infrastructure: Deployment approaches vary widely: Scott uses rsync, Forever, Meteor Galaxy, CodeShip, and environment settings files; Wes uses a mix of deployment scripts and hosting services depending on the project. Both note the importance of minimizing downtime and keeping secrets out of source control. Project structure and organization: Scott describes a numbered-folder project organization with separate code, assets, and design folders. Wes explains a Meteor-centric structure with imports, API, UI, startup, utilities, and feature-based organization tied to a component-based system. Sponsors, resources, and personal recommendations: The episode includes sponsor mentions for View School and CoffeeCup CSS Grid Builder, plus personal recommendations like Overcooked and the Skyroam Solis hotspot. These serve as lighter interludes but still reinforce workflow and learning themes.

Key Arguments: Designing in dedicated tools can be faster and more flexible than coding visual layout directly, especially when exploring ideas and reusable components. Letting designers propose things that seem impossible can push developers to find creative solutions and improve the final product. A good workflow batches similar tasks together: build structure first, then style, then interactivity, to reduce context switching. HTML should be built as fully as possible before fine styling begins, because layout problems are easier to solve once the document structure is complete. Component-based design systems help keep large products consistent and scalable across many pages and teams. Git workflows should be chosen to match the team’s existing process; adapting to an established system is usually better than imposing a personal preference. Frequent commits and remote backups reduce the risk of lost work, and rebasing helps keep feature branches aligned with master. Deployment should aim for reliability, low downtime, and safe handling of secrets, even if the exact tools differ from project to project.

Data Points: View School discount: 25% off - First 50 people using the sponsor link get a discount on the Vue.js masterclass. View School course size: 5+ hours, 75 lessons - The sponsored Vue course was presented as currently in development with substantial content already available. Workshop duration: full-day - Wes describes teaching a full-day workshop at SparkBox in Dayton, Ohio. Photo booth application feature: offline with service workers - Wes mentions building a workshop app with lazy loading, code splitting, and offline support. Scott’s deployment downtime: 2 seconds - Scott notes his current rsync-based deployment can cause brief downtime that users occasionally notice. Skyroam Solis pricing: $8-9/day - Scott describes the hotspot service as costing about eight or nine dollars per day. Skyroam Solis data limit: 500 MB LTE - After 500 MB, the user can pay more or fall back to edge service. Level Up Pro discount: 25% off yearly - Scott promotes the yearly subscription savings for his course platform. Branch examples: dev113, dev114 - Wes uses issue-numbered branches as an example of his Git workflow. Target audience test group: ~50 people - Scott says he may open a course website to around 50 people for early feedback and bug finding.

Pivotal Quotes: "I don't design in code." — Scott: Scott explains why he prefers a dedicated design application over coding visual layouts directly. "The first thing I do is get into the code and into the project as soon as possible because that's where you're going to be inspired to work and actually like see things happening." — Wes: Wes summarizes his development philosophy and preference for reducing setup friction. "Try to do as much of your HTML first, then go into your CSS." — Scott: Scott gives advice on structuring the build process to avoid layout frustration.

Implications: Listeners can use these workflows as practical templates: design in layers, code structurally, batch tasks, adapt to team Git norms, and prioritize deployment reliability. The episode also hints that design systems and component libraries are becoming central to scalable web development.