Frontend First

Sam and Ryan discuss an elegant solution to the async nested dropdown problem, a FastBoot success story regarding inlined CSS, pre-warming FastBoot's cache, and implementing a new design alongside an existing design language. Topics include: 01:11: Solving the nested dropdown by recursively currying an action 25:00: Inlined CSS and caching with FastBoot 40:22: Challenges implementing a new design in an existing design language Links: PurgeCSS

Sam and Ryan chat about the challenges of testing custom asynchronous code. They also talk about React's new Hooks API, and discuss situations where hooks might be more composable than yields and contextual components. Topics include: 00:00 – Testing custom asynchronous code, like an animated bar chart 25:23 – React's new Hooks API Links: EmberMap Async testing series API docs for Ember's testing helpers Overview of React Hooks with Dan Abramov and Sophie Alpert 90% Cleaner React with Hooks – Ryan Florence Sam Selikoff on Twitter Ryan Toronto on Twitter

Sam and Ryan talk about the challenges of building nested dropdowns, whether a component reading data from its children is an anti-pattern, how angle-bracket syntax encourages new components, and whether “CSS best practices” exist. Topics include: 00:40 – Thinking through a nested drop-down navigation menu 35:15 – Building an component & angle-bracket syntax 45:00 – Layout UI primitives 46:35 – What are CSS best practices? How might Tailwind encourage these? 52:17 – "Semantic" classes. Should developers have to name every UI element, if designers don't?

Sam and Ryan talk about their upcoming email course on Ember component patterns, wrapping up their EmberMap series on Functional CSS, refactoring some FastBoot code in Node, and how Mirage might be useful if it could run as a real server. Topics include: 0:30 - Email course in Ember Component Design 8:00 - EmberMap course on Functional CSS with Ember Do you have a preferred API for styled component variants? See Sam's tweet below. 14:00 - FastBoot, and refactoring and testing Node code 31:10 - Pushing Mirage to run as a non-production server Links: Using Functional CSS with Ember Sam's tweet on styled variants Art of Product Podcast

Sam and Ryan talk about lessons from Jason Fried's Q&A about scoping down product features, and how that applies to our open-source work. They also talk about inlining critical-path CSS with FastBoot. Topics include: Inlining CSS with FastBoot (0:08) Scoping down (14:26) Jason Fried's Q&A at Laracon Scoping down at work and in OSS How to handle OSS contributors who add scope How bugs indicate a larger-than-expected problem space How to say no to new features you can't commit to supporting Are there projects that can't be scoped down? Using OSS checkpoints to avoid burnout Links: Jason Fried Q&A at Laracon

Sam and Ryan chat about two new EmberMap series, Forms and Async testing, as well as Sam's keynote at EmberCamp and the best way to avoid product gaps in open-source software. They also answer some listener questions. Topics include: Forms (1:18) Splitting forms into containers and presenters Avoiding premature abstractions (7:03) Which components do you carry from project to project? Asynchronous testing (14:47) Testing animations Sam's keynote at EmberCamp on Product gaps (19:04) Product gaps at companies vs. in OSS Are small packages and convention over configuration at odds with each other? Convention over configuration that decomposes well The risk of bad high-level abstractions in OSS How to "finish" an OSS project Questions: What's the state of TypeScript support in Ember? (48:15) When are observers actually appropriate to use? (54:57) Any tips on refactoring async relationships? (59:34)

Sam and Ryan continue their discussion about the role of product in an engineer's daily working life. They talk about what product gaps are, the symptoms of product gaps on tech teams, and what you can do about product gaps if you're on a team with no product manager. Topics: 2:05 – All about product More product responsibilities fall on engineers than ever before Coders can help surface valuable info to business teams about the tradeoffs of their product decisions Learning product makes coders better because it influences what they code, it increases their chance of building software that will actually be used, and it helps them focus at work The symptoms of a product gap drives engineers to think that they need to code more Product gaps often creep up on medium-size teams that don't have dedicated product managers Symptoms of a product gap: Having three number one priorities Coding after hours Tons of work being done, but feeling like you're moving an inch in every direction Hard time estimating You finish a sprint, and you're not sure what the value was "We just need more engineers" If you're on a team with no product manager, and you have a product gap, what can you do? Ask a lot of questions, and push the product decisions up. Let the whole organization feel the pain of the product decisions that aren't being made. Surface the tradeoffs being made. "But this is not my job, I'm an engineer! I just want to code." If you ignore this stuff, your "just coding" won't be sustainable How to get your engineers out of meetings and firing on all cylinders: a product roadmap Make sure your product cards are not about implementation details How to recognize which decisions you can make as an engineer, and which you can't Why you shouldn't say yes to every work request How doubling your estimates can surface product issues

Sam and Ryan talk about the cost of using engineering as discovery, the consequences of embedding product decisions throughout the design and development phases of a project, and other lessons that software engineers can learn from product developers. They also chat about how they categorize Github issues. Topics: 0:00 – GitHub issue categorization The importance of issue triage Prioritizing bugs over features Getting Things Done 7:53 – Managing product 7:53 - Engineering issues as a symptom of product/process issues 13:05 - The 3 phases of a software feature: product, design, engineering 16:04 - What happens when you embed product decisions in the design/engineering phases of a project 29:27 – Who's the head of product? Design? Engineering? Who is the decision-maker? 31:22 – Falsely believing that all decisions are final. Stakeholder PTSD. 34:07 – Product and marketing decisions are getting made, whether you are making them explicitly or not. 37:00 – If we care about people being successful with Ember, we need to understand the product decisions that are being made on behalf of Ember. In OSS, we are making product decisions whether we realize it or not. Are we making them as a side effect of our work? If so, we could create better software by thinking explicitly about these decisions. 41:04 - What do you do when you've gone through this phase and you learn something new? 41:55 - Small batches (Lean startup). Envelope example. Unknown complexity at the end of software projects. 45:28 - Getting a cross-discipline team in the same room. Having a decision-maker to avoid design by committee. Links: The Lean Startup by Eric Ries

Sam and Ryan talk about the Ember 2018 Roadmap RFC and its focus on improving communication, completing in-progress work, and shipping Ember Octane. They also talk about how to verify complex addon behavior by using full-blown test apps and addons. Topics: 0:00 – Test apps Using full apps and addons in a subdirectory of an addon to facilitate testing complicated scenarios Avoiding implementation details of the build pipeline in testing 12:14 – Ember Octane The Ember 2018 Roadmap RFC The concept of Ember Editions & the first edition, Ember Octane Discussing the areas of focus from the RFC: better communication, shipping a ton of in-progress work, shipping Ember Octane Discussing non-goals for the year Links: Ember 2018 Roadmap RFC Matthew Beale's MU RFC with the {{use}} helper

Mel chats with Sam about getting into Ember, lessons learned from collaborating at work an in open source, and how to make it easier for JavaScript engineers to use better UI patterns. Topics: 0:00 – How Mel got into Ember at JPMorgan 4:45 – Feeling welcome in the Ember community 7:45 – Investing in Ember for the long-term 9:00 – Communicating vision, removing our ego, and empowering others to do work 17:07 – Learning team projects 19:30 – Improving the native accessibility story for Ember 27:25 – Making it easier for JavaScript engineers to use better UI patterns 34:55 – Ember Styleguide and Ember OSS infrastructure 49:10 – EmberCamp Chicago 51:20 – Leveling up in the Ember community Links: Melanie on Twitter: @melaniersumner EmberCamp, September 21, Chicago: http://embercamp.com Melanie's FizzBuzz in HBS How to talk so kids will listen & listen so kids will talk