Kevin Hughes

One of my favourite WebGPU demos is the "deferred rendering" demo (or as I call it, "disco dragon"). It's pretty, and it demonstrates a cool rendering technique for highly complex scenes with lots of dynamic lights: https://lnkd.in/eVE226HN So I rewrote it in Toucan, my graphics-oriented programming language: https://lnkd.in/e2Kwe334 (runs in Chrome and Firefox Nightly). It's 424 lines of Toucan, versus 801 total lines of WGSL and TypeScript. Most of the savings come on the host side, where, having defined our vertex buffers, uniform buffers, bind groups and pipeline variables once for the device side, we don't need to re-declare them for the host side in a new syntax. Plus, a common type system means there's no need to compute byte offsets or vertex strides, match up group numbers or bindings numbers, re-declare attachments, or accommodate std140 or std430 memory layouts. All of that is done automatically by the compiler. Type safety means not only being able to assign to members of a vertex or uniform buffer on the host using the same syntax as the device, but also applies to the usage itself: since the "vertex" and "uniform" qualifiers are understood by the host side, they become part of the type. If a required qualifier is omitted on allocation, attempting to bind the buffer as such will result in a compile-time error, not a runtime one. Here's a diff of the two versions (with comments and whitespace added to help the diffs to match): https://lnkd.in/ew64MGGS

8

7 Comments

styled-components has entered maintenance mode. Its maintainer was refreshingly honest: "Don't use this for new projects." Respect. But what about the millions of components already in production? My colleague Cody recognized the problem immediately. He submitted a PR with React 18 optimizations back in July 2024. With maintenance mode, that PR wasn't going anywhere. So Cody did what great engineers do. He turned our lingering PR into a fork, optimized it further, then opened it up for everyone. Linear tested it: 40% faster initial renders. No big code changes needed. The kicker? styled-components never implemented React 18's useInsertionEffect - a hook specifically designed for CSS-in-JS performance. It shipped in March 2022. Cody PR'd it fixed it in a day. We're calling it styled-components-last-resort because that's what it is. Not a new maintenance path. Not a forever solution. Just a performance bridge while teams migrate properly. Sometimes open source isn't about building the future. Sometimes it's about helping each other manage the present. Massive credit to Cody Olsen for the implementation, Kenneth Skovhus at Linear for testing, and Evan Jacobs for maintaining styled-components for years. Technical deep dive: https://lnkd.in/dk4CfsP8 GitHub: https://lnkd.in/duzY-Vy6 What's your styled-components migration plan?

111

3 Comments

💩 𝗜 𝗰𝗮𝗹𝗹 𝗯𝘂𝗹𝗹 𝗰𝗿𝗮𝗽 𝗼𝗻 𝘁𝗵𝗶𝘀: "Engineers hate talking to people." I've been hearing this for years. And no, people don't always just joke it. For example, Every time I mention Rodeo Service—rotating engineers through high-contact duty triaging bugs and talking directly with stakeholders—someone says it. And every time, it's just as wrong. When we first implemented Rodeo Service, we asked: "Who's interested?" We got volunteers. Often the quiet engineers. Often people who'd never sought customer-facing work. Sometimes the most technically deep people on the team. Not everyone volunteered—and that was fine. But there was no shortage of people who wanted to try it. Here's what happens when you don't give engineers this opportunity: 🚫 They assume they're broken I've watched talented engineers think they're weird because they enjoy stakeholder conversations. They start to hide this interest. They conform to the stereotype instead of leaning into what energizes them. You lose access to people who could naturally bridge technical and commercial conversations. 🚪 They walk Many engineers want career paths beyond pure coding—solving problems, helping people, making impact. If you don't provide opportunities to gain experience outside their code editor, they'll find it elsewhere. You're not just losing an engineer—you're losing someone who could have become a technical leader who understands the business. 🎭 You hire externally for skills you already have When you need someone to interface with stakeholders, you assume you have to hire a Product Owner or Scrum Master. Meanwhile, engineers on your team are watching that job get posted, knowing they could do it, wondering why they were never asked. The engineers who volunteered for Rodeo Service developed cross-functional fluency. They understood business context. They could translate between technical and commercial language. These are leadership skills. You already have these people in your team. Just allow them to wear the cap. Allow them to grow. What assumptions about your team might be limiting what you try?

14

2 Comments

I don't usually have good advice for junior engineers. This market sucks for juniors, and telling them to do side projects or whatever is useless at best and disingenuous at worst. But today I learned about an actually useful thing. And of course it's in the Rust community. There's an awesome company called Zed Industries. Zed is a native, fast, multiplayer code editor written in Rust. They have an open source program that they actually recruit from. "The alternative path starts in our GitHub repository. We regularly notice community members who consistently ship quality PRs: fixing bugs, implementing requested features, and improving the editor. These contributors become familiar names in our internal Slack." If you're a junior engineer, consider learning Rust -- it's increasingly the future for high performance enterprise applications. Unlike many other languages, it has a tight-knit community around it, and unlike (very) high-level languages like Python, it'll actually force you to learn how things work under the hood. And consider contributing to Zed. Link with more information in the comments.

322

48 Comments

Switched from ts-node-dev to tsx — Never Going Back A few weeks ago, I was setting up a basic TypeScript + Express backend — and I hit the same old problems: ❌ Slow reloads ❌ Config struggles ❌ ts-node-dev just wasn’t cutting it So I looked for something better… I found tsx — and it completely changed my workflow. ✅ What Makes tsx Better ✅ Lightning-fast reloads (powered by ESBuild) ✅ No config needed — works out of the box ✅ Full support for ESM and TypeScript Setup Guide (Step-by-Step) 1. Initialize your project: npm init -y 2. Install your dependencies: npm install express npm install -D typescript tsx @types/express 3. Create a tsconfig.json: npx tsc --init Then uncomment rootDir and outDir and update it in your recent generated tsconfig.json. add include["/src/**/.*ts"] and exclude["node_modues"] after compileroption or simply Update your tsconfig.json with this: {   "compilerOptions": {     "target": "es2020",     "module": "commonjs",     "rootDir": "./",     "outDir": "./dist",     "esModuleInterop": true,     "forceConsistentCasingInFileNames": true,     "strict": true,     "skipLibCheck": true,     "allowSyntheticDefaultImports": true,     "noImplicitAny": true,     "noImplicitThis": true,     "strictNullChecks": true,     "strictFunctionTypes": true,     "strictBindCallApply": true,     "strictPropertyInitialization": true,     "strictBuiltinIteratorReturn": true,     "alwaysStrict": true,     "useUnknownInCatchVariables": true   },   "files": [     "./app.ts",     "./server.ts"   ],   "include": [     "*.ts"   ],   "exclude": [     "node_modules"   ] } Don’t worry about ESM configuration — tsx handles it. 4. Update your package.json scripts: "scripts": { "dev": "tsx watch src/server.ts", "build": "tsc", "start": "node dist/server.js" } ✅ That’s it! You’ve got a fast, clean, modern TypeScript + Express setup — no hacks, no headaches. Want a copy of my starter template? Drop a comment or DM — happy to share it!

1

Hiring engineers for hard operational problems is different. Most candidates can write clean code. Fewer can sit with a dispatcher at 7am and understand why their shift planning breaks down. Fewer still can go back to the codebase and design something that actually works in production with those constraints. What I look for at Mirage Metrics is not just skill with Python, SQL, or distributed systems. It is a willingness to go into environments that are messy, sometimes chaotic, and keep digging until the real bottleneck shows up. That can mean inventory mismatches hidden in Excel, planning rules written on a whiteboard, or API endpoints that return inconsistent data depending on who queries them. The best engineers I have worked with are the ones who do not flinch at this. They treat debugging a customs declaration pipeline with the same seriousness as debugging a memory leak. They know that solving “boring” problems in data quality or workflow mapping is what unlocks everything else. On the technical side, I test for clarity. Can someone explain the trade-offs between running a model via an API versus hosting it on GPUs without getting lost in jargon. Can they design a schema validator that will still make sense six months later when requirements change. Can they write glue code that is robust, not fragile. On the personal side, I look for stamina. These projects are rarely about building a shiny feature in isolation. They require iteration with operators, late-night debugging of OCR failures, and the patience to integrate into legacy systems that were never designed for AI. If you want to work on AI for logistics, manufacturing, or mining, the question is not only whether you can code. It is whether you can hold your ground in the real world, in front of the people whose work depends on your system. That is the bar.

17

5 Comments