Josh Goldberg's Speaker Profile @ Sessionize

AI Needs Linting

Today’s era of “AI”, better referred to as internet-enhanced autocomplete, is wonderful at producing lots of code - but terrible at producing correct code. And while AIs are getting better over time, we still need tooling to analyze generated code for defects. Do you know what parts of your of your toolchain run quickly, in editors, to provide configurable reports on likely bugs and best practice violations? Static analysis! Your linter and type checker were born for this.

This balanced, nuanced talk will walk through the best and worst cases for AI-generated code. We’ll start by contrasting the benefits to developer education and productivity with drawbacks of lower quality code, misconceptions, and outright “hallucinations” (also known as lies). We’ll see real-world cases where exuberant AI use led developers down bad paths and had a net negative impact on their ability to function.

We’ll then see how static analysis can help resolve many of those issues:

- Automatically re-prompting for better results by reporting detected defects back to AIs
- Configuring your linter to find issues tailored to your project’s needs - in and out of AI code
- Forcing prompts to act in “untrusted” modes for AIs, so user-provided misconceptions don’t taint results
- Increasing type safety for AI communications with projects like TypeChat

By linting both the inputs and the outputs of AI prompting, we can use this amazing new technology in the ways it’s made for - and avoid its all-to-common pitfalls.

Deeply Debugging React Rendering

Have you ever asked "why is my React app rendering so slowly?"? Did you get an answer around excessive re-renders, too many DOM elements, too much JavaScript, or something in data loading? Developers tend to micro-optimize for the first case because it's easy to think about - but oftentimes the real bottlenecks are the other potential issues. Let's really dig into power-debugging slow React interface performance:

1. Standardizing on a performance mindset and strategy with the following steps: identification, investigation, implementation, and confirmation
1. What those three common causes of performance issues look like, and how to diagnose which one(s) are impacting your app
2. For each performance issue, strategies for measuring and resolving them
3. Tips and tricks for adding in CI and team processes to prevent performance bottlenecks from appearing in the first place

Attendees may enter this talk hesitant to commit to deep performance investigations - but with these tips, tricks, and tantalizing temptation of success, they’ll emerge with an eagerness to dive into their own apps. 💪

Dynamic Schema-Driven Apps

Everybody loves making small changes easier: many apps have moved copy changes -even color schemes or page layouts- to be dynamic and data-driven. But what if we set up the entire app -navigation and all- based on server-provided information? Let's explore the concepts behind schema-driven applications: how they work, why they're awesome, and how to do them right.

Let's explore the world of server-driven layouts as a concepts-driven experience. We'll show how things work, rather than integrating with existing production-ready libraries or services.

For each of the following, we'll first cover why you'd want to do it, then an overview of minimal code to get it to work:

1. Moving small bits of app information such as text snippets to the server allows for easier experimentation and marketing changes
2. Allowing generating entire routes/screens/pages based on JSON descriptions of building blocks
3. Creating application templates that can be hooked up to generic data sources as straightforward as JSON files or as intense as business-grade CRMs
4. Performance concerns around intelligent caching & over-eager loading
5. Combining these techniques with realtime WebSocket-powered over-the-air updates, for truly dynamic applications

Attendees should take away an appreciation for the vast amount of time they can save by making their applications highly dynamic and data-driven. If at least a few developers are saved from having to manually do the same work repeatedly, this talk will have done its job!

Type-Safe Style Systems: The Future of CSS

Most CSS developers today write visual styles in terms of what you literally see: exact color values, size numbers, and so on. But what if you could write styles as a function of how they fit into your design system? And what if you could get type safety in specifying and using those values, including in responsive props?

This talk will dive into some of the key features and flaws in many design system builders today such as Chakra UI and Tailwind. We'll establish what the best next steps for design systems should be with type-safe TypeScript APIs and performance both for prebuilt pages and at runtime.

1. How'd We Get Here?
* An overview of that 'W' shape of effort in the modern landscape
* Brief history of how these systems all evolved
* Current trends of how each of those areas are evolving. In particular:
- Clean CSS: CSS variables, new CSS features, and Tailwind systems & abstractions
- Dynamic Systems: design systems and scalability patterns

2. Respective Strengths
* Clean CSS: Smaller repositories, static & performant content, building design systems
* Dynamic Systems: Multi-team organizations; complex sites; building design systems too

3. The Future
* Where both systems fail: type safety with responsive layouts; difficulty in creating variants
* A "perfect"(-ish) system proposal: the cleanliness of Tailwind and the scalability of Chakra UI
* Why continuing to iterate on these scalable systems is important for the industry

Attendees will leave the talk both with an appreciation for the systems of today and hope for the type-safe systems of the future.

Types Beyond TypeScript

Everybody seems to be talking about "types" these days. From the TypeScript language to type description utilities such as Zod, developers expect clear descriptions of the shapes of their data. Let's talk about the mindset shift that's happened over the last decade, and where types are taking us over the next one.

1. Thinking in Type(s|Script): How modeling value shapes helps raise predictability and understandability, especially in the wildest and wackiest of project architectures.
2. TypeScript's Limitations: By design, TypeScript can only act as a development-time type system and enforce what that system can represent. We'll want to go over what can't and/or shouldn't be represented in that type system.
3. Raising the Runtime: Moving those type thoughts into your runtime with programmatic frameworks or libraries such as tRPC and Zod.
4. Node.js Specifics: How this "types-first" theory works helps improve common parts of projects in the Node.js ecosystem: REST or RPC endpoints, testing, and documentation.
5. Ecosystem future: where the TC39 types-as-comments proposal will -and won't- take types at a language-level for JavaScript.

By allowing our types to be a reflection of the runtime reality, we embrace types-first thinking in designing code - making our Node.js code more clear to read and update. Hooray, types!

So You Want To Open Source A Project?

You've got a useful project you'd like to open source, but you're not sure all the steps you should take. What if someone wants to report a bug? Send a code change? Report a security issue? So many processes to set up! This session will walk you through the key behaviors, documentation, and tooling you'll want to set up to make that project shine:

* Documentation: prioritizing the key getting-started and how-does-this-work areas within your always-limited docs time budget
* Issue and pull request templates: helping users provide reports and in ways you can actually work with
* Tooling: setting up a formatter, linter, test harness, and other nifty tools to ease the costs of both contributing and reviewing code and docs changes
* Paperwork: finding the right CLA, licensing, and security terms for your company/individual and project types
* Politics: explaining why open source is worth it to internal stakeholders

By the end of this session, you'll be ready to confidently dip your toes into open source. Or dive right in.

Building a Design System In-Flight

Design systems -collections of common components, colors, and other constants- are a key way to scale teams and web applications on the modern web. They're particularly handy for deduplicating frontend development costs for microfrontends and remote teams. But how do you create one from scratch -- or, much more commonly, in-flight from an existing service?
This hands-on talk will take you through three stages of crafting your design system:

Stage 1: Extracting colors, spacing, and typography from your existing brand. We’ll cover how slight variances in behavior are generally not intentional, and you want to deduplicate as much as possible.

Stage 2: Creating components following using the first stage’s designs. We’ll start with low-level atom components such as buttons and text, then work up towards forms and other larger conglomerations.

Stage 3: Documentation is critical! TypeScript provides in-IDE developer hints and can enforce proper usage, while Storybook scaffolds gloriously interactive docs pages.

By creating and using a design system, you'll both help and enforce your designers and developers are creating their most consistent work at shockingly reduced costs.

Floating and Sinking Promises: Let's Fix Your Broken Async Code

Promises and async/await are the right way to work with asynchronous code in Node.js. They're also both the easiest code constructs to introduce bugs with -- and can be some of the hardest code to debug. We'll walk through:

* Refactoring pre-Promise callback hell to Promises
* Refactoring pre-async/await Promises to async/await
* Debugging with console logs and node --inspect
* "Floating" Promises (those created and not handled): detection with TypeScript ESLint, and error handling
* "Sinking" Promises (those created and handled improperly): detection with TypeScript ESLint, and error handling

Each of those classifications off issues will be resolved in three steps:
1. We'll look at how their need can develop in even the most type-safe, well-architected, well-intended projects
2. We'll see how to detect those issues - as bugs and/or development-time smells
3. We'll see how tools in TypeScript and/or typescript-eslint can detect them for us, and sometimes even automate the fixes.

By the end of this workshop, you'll be fully prepared to debug even the gnarliest asynchronous shenanigans and write production quality asynchronous code.

Floating and Sinking Promises: Understanding Broken Async Code

Promises and async/await are the right way to work with asynchronous code in Node.js. They're also both the easiest code constructs to introduce bugs with -- and can be some of the hardest code to debug. We'll walk through:

* Refactoring pre-Promise callback hell to Promises
* Refactoring pre-async/await Promises to async/await
* Debugging with console logs and node --inspect
* "Floating" Promises (those created and not handled): detection with TypeScript ESLint, and error handling
* "Sinking" Promises (those created and handled improperly): detection with TypeScript ESLint, and error handling

Each of those classifications of issues will be understood in three steps:
1. We'll look at how their need can develop in even the most type-safe, well-architected, well-intended projects
2. We'll see how to detect those issues - as bugs and/or development-time smells
3. We'll see how tools in TypeScript and/or typescript-eslint can detect them for us, and sometimes even automate the fixes.

By the end of this session, you'll be fully prepared to debug even the gnarliest asynchronous shenanigans and write production quality asynchronous code.

Killing Mutants with Mutation Testing

Who tests your unit tests? Even if a line of code is covered by a test, you're not guaranteed the test verifies anything. Enter mutation testing: the practice of inserting "mutant" bugs into your code and checking whether any tests catch them.

This hands-on talk will walk you through real-world code issues detectable with mutation testing, how mutation testing catches them, and how to get started with it locally.

In particular, we'll cover:
* Where unit testing coverage does or does not act as an effective measure of behavioral coverage
* Common types of bugs and developer mishaps
* How mutation testing works at a theoretical level (AST analysis, mutators, and strategies for efficient re-testing)
* Running mutation testing on an example TypeScript repository
* Integrating mutation testing both into technical needs (i.e. CI/builds) and interpersonal (e.g. team culture)
* Creating our own custom mutators for business-specific use cases
* Where mutation testing does not catch code slipups and/or can be augmented with other forms of static or dynamic analysis

We'll view demos of TypeScript code with StrykerJS but the lessons learned will be applicable across any stack.

Building Engineering Influence

Being a great coder only gets you so far in software development. Most of the career ladder involves working with systems of people: mentoring, being mentored, and setting up team processes.

This talk from a seasoned staff developer with history on web platform teams in Codecademy and Microsoft will go over the various ways you can build -or accidentally destroy- good will, rapport, and influence amongst your teammates.

Lessons include:
* Active listening: so you understand what your teammates really are trying to say, and they understand that you understand
* Feedback and compassionate candor: the 2:1 or 3:1 ratio of positive to constructive, and how to phrase even the harshest feedback in positive ways
* Pairs, groups, and mobs: how group coding builds individuals and the team

We’ll end with a few actionable takeways to improve your working relationships with developers and nontechnical stakeholders alike.

Why Projects Fail: Five Real-World Retrospectives

I've been involved with professional teams for about a decade, and in that time I've seen some bizarre reasons for project failures. This talk will walk you through real-life project failures I've been in. All seem obvious in retrospective, but at the time weren't so clear.

Our framing context will be the "Five Why"s system of continuously asking questions to understanding failures. We'll use it to set up systems to prevent major mistakes.

The five situations we'll dig into will be:
1. Buggy releases: why obvious, even debilitating, bugs creep into so much software, and how release checklists can help
2. Bus people: avoiding centering too much knowledge on single team members, with tips for effective team knowledge building strategies
3. Jerk seniority: prioritizing cultures of collaboration and learning best practices, especially using Radical Candor
4. No seniority: getting team members the experience they need, and underloading schedules to ensure they have time to mentor and step up as rockstars and superstars
5. Great successes: learning from, sharing out, and appropriately rewarding team members for successful releases

Let's dig into why software projects fail!

Static Analysis: Shockingly Awesome! ⚡️

Wouldn’t you love to automatically zap code bugs before releasing to production? How about before your code even gets run? Static analysis tools scrutinize your code as you write it - giving you blazing fast feedback at development time. We’re going to go into how that works, why it’s useful, and -best of all- how to enable the best configurations for ESLint, TypeScript, and their associated tooling in your app.
In particular, we'll cover:

* The tooling differences between formatters, linters, and type checkers
* How to appropriately set up each of those tools for local development and CI/builds
* A brief overview of using recommended rulesets from ESLint and TypeScript-ESLint -- and why you'd want to
* The kinds of development-time issues each of those tools catch
* Using ESLint and TypeScript as documentation sources and to educate developers on general and team-specific best practices
* Longer-form demo showing lint rules catching three classifications of async/Promise bugs in a React app

A primary goal of the talk is to get the audience excited about the tooling they can run on their code. A lot of developers don't see static analysis as something they need to care about -or are even scared of the term- despite how useful it is day-to-day. This talk will have you detecting bugs, bad practices, and code smells in your web apps at lightning speed! ⚡️

TypeScript for JavaScripties: Full Day Edition

You've heard about TypeScript and maybe poked at a docs page or two. But it's still a mystery for you. Not to worry! Josh Goldberg -author of the O'Reilly Learning TypeScript book- will walk you through the foundations of "types" and a "type system" up through the important language features you'll need to get started understanding TypeScript.

This workshop will go through through topics equivalent to the Learning TypeScript book table of contents - a battle-tested, intentional set of topics that build on each other to teach TypeScript. We'll cover each of the chapters:

1. From JavaScript to TypeScript: Why JavaScript is the way it is with respect to types (or lack thereof), and where TypeScript does or does not fit in
2. The Type System: Foundations of how TypeScript's type system fits in to JavaScript code and understands your values
3. Unions and Literals: How TypeScript understands values that can be one or multiple possible primitives, along with strict null checking (the "billion dollar mistake") and the powerful concept of "type narrowing"
4. Objects: How TypeScript's "structural typing" allows it to understand objects by their shape and intent, not just by their declaration forms
5. Functions: How TypeScript understands function inputs, outputs, and quirks around "void" and "never" types
6. Arrays: TypeScript's understanding of fixed type, evolving any, and fixed size ("tuple") arrays
7. Interfaces: Akin to types, but with advantages on readability and performance, and an excuse to look at various property modifiers allowed on both
8. Classes: Broadly how TypeScript models class inheritance, properties, and static fields -- even if your framework of choice doesn't go deeply into them
9. Type modifiers: Various keywords such as 'keyof' and 'typeof' that bend the type system to your will
10. Generics: Adding in type parameters that allow constructs such as functions and interfaces to be flexible on what types and values they're used for
11. Declaration files: How external JavaScript -and your own built outputs- can still be described in the type system
12. Using IDE features: Code navigation, name completions, and error debugging that level up any JavaScript and/or TypeScript developer
13. Type Operations: Introducing logic in the type system with mapped and conditional types

Each session consists of a 25-30 minute interactive lecture+workshop, with 5-10 minutes in-between for bio breaks and miscellaneous questions, and a lunch break in the middle.

TypeScript for JavaScripties: Half Day Edition

You've heard about TypeScript and maybe poked at a docs page or two. But it's still a mystery for you. Not to worry! Josh Goldberg -author of the O'Reilly Learning TypeScript book- will walk you through the foundations of "types" and a "type system" up through the important language features you'll need to get started understanding TypeScript.

This workshop will go through topics equivalent to the first half of the Learning TypeScript book table of contents - a battle-tested, intentional set of topics that build on each other to teach TypeScript. We'll cover each of the chapters:

1. From JavaScript to TypeScript: Why JavaScript is the way it is with respect to types (or lack thereof), and where TypeScript does or does not fit in
2. The Type System: Foundations of how TypeScript's type system fits in to JavaScript code and understands your values
3. Unions and Literals: How TypeScript understands values that can be one or multiple possible primitives, along with strict null checking (the "billion dollar mistake") and the powerful concept of "type narrowing"
4. Objects: How TypeScript's "structural typing" allows it to understand objects by their shape and intent, not just by their declaration forms
5. Functions: How TypeScript understands function inputs, outputs, and quirks around "void" and "never" types
6. Arrays: TypeScript's understanding of fixed type, evolving any, and fixed size ("tuple") arrays

Each session consists of a 30-35 minute interactive lecture + workshop, with 5-10 minutes in-between for bio breaks and miscellaneous questions.

Most Active Speaker

Josh Goldberg

Actions

Links

Awards

Area of Expertise

Topics

Sessions