Nick P.

Developers weren’t just builders. They were gatekeepers. If you couldn’t code, you didn’t create. You waited. On engineering bandwidth. On roadmaps. On someone else’s priorities. Syntax was the wall. Know where the semicolon went? You shipped. Didn’t? You stood outside. That divide shaped more than workflows. It shaped status. Developers got the leverage. The scarcity gave them the power to decide what shipped and when. Everyone else adapted around them. It wasn’t about being smarter. It was about access — and access wasn’t evenly distributed. Some people were in the right rooms early, tripped into syntax, and built from there. Others never got the chance. That was the difference. But syntax was only the first kind of alpha. The second was quieter. Harder to see. More enduring. System knowledge. Knowing which database could survive Black Friday traffic. When to debounce vs. throttle. How to shard writes across regions. Not just writing code — architecting it. That’s the tacit layer. Built from war stories. Outages. Scaling pain. Years in the trenches. It’s still here. And it still matters. For now. I remember the first time I tried to shortcut it. I’d tell Claude what I wanted. It would spit out code. I’d paste it. It would break. I’d send back the error. It would try again. Loop by loop, something shifted. Reddit called it “copy-paste monkey.” They saw a hack. I saw a door opening. People who’d been locked out started building demos. Then products. Then real companies. The wall between “technical” and “non-technical” was never about intelligence. It was about translation. And now, translation is free. What matters now isn’t syntax. It’s clarity. How well you can think. Break things down. Iterate. That’s what the agent understands. And that’s what it rewards. The syntax advantage is gone. Developer privilege is flattening. System knowledge is next. Today, the agent can’t always choose the perfect database. But if you tell it the trade-offs, it will. If you give it context, it will architect with precision. That tacit edge still holds. But only for now. Soon, even that will be embedded. And leverage will shift again — to anyone who can think clearly enough to guide the machine. That shift isn’t coming. It’s here. And it’s not going away.

18

2 Comments

I gave a talk last night at the Remix Austin meetup on using Convex within React Router 7. I'll post the recording when I have it, but I'll share a quick summary in the meantime. One of my favorite things about being a developer is being able to code anything I want: personal software, side projects, SAAS ideas. However, I tend to start a project during a wave of motivation and then hit a snag and never finish it. So when I'm choosing my tech stack, I have to optimize for reducing friction. I need to spend as little energy as possible setting up the project and debugging my environments, so all my energy goes into creating. Previously, I've done this with template scaffolding tools like https://create.t3.gg/ which give you a type-safe, full-stack app with Next.js, React Query, TRPC, and Prisma or Drizzle. It's a really nice tool. However, that's an awful lot of boilerplate just to get a full-stack app, and you still have to choose your SQL flavor and deploy your database. This is where Convex comes in. It's an all-in-one backend-as-a-service. I can spin up a fully deployed backend in just two commands. I define my functions and schema, and Convex generates a type-safe client for my frontend. It gets even better from there. Convex is a sync engine (designed by the devs who built the Dropbox sync engine). When your client loads, it makes a WebSocket connection to your Convex backend, and the data is reactive. When the database updates, the client is automatically updated, so the user doesn't need to refresh. Convex has been a huge unlock for me. I'm able to iterate quickly with Claude and write full-stack features faster than ever. Most importantly, I'm actually finishing projects and shipping because deployment is easier than ever. I've got a page on my site below with some links to check out. The gold dashboard I built with Convex, the code repo, my Convex referral link, and a blog post on how Convex works. Check it out and let me know what you think! https://lnkd.in/gamjPFW5

12

amplified.dev is a single-page essay arguing developers are amplified, not automated. One HTML file, inline CSS, vanilla JS. No frameworks. We wrote 11 checks for it. Checks don't have to protect code; they can protect taste. "Editorial Voice & Narrative Arc" flags corporate language and enforces that the essay stays second-person, peer to peer, not product to customer. "No Product Creep" watches for the site drifting toward marketing. The site's power comes from what it is not. "Accessibility as Care" makes sure the site works for everyone, not just developers on MacBook Pros. "Resist Complexity" enforces that the CSS stays in a style tag: no npm, no Tailwind, no React. Not a problem to solve, a decision. There's even a check for the easter egg: type "amplify" and the page demonstrates its own thesis. 11 checks for one HTML file. Each protects a decision easy to violate when agents open PRs. Writing them forced us to say what "good" means for this project. Tests for your taste. https://amplified.dev #ContinuousAI #CodeReview #DevTools #OpenSource

58

5 Comments

Most developers think a successful payment API response means the money has moved. It usually doesn’t. A 200 OK just means the request was accepted. The actual movement of money depends on the payment rail behind the transaction, and every rail behaves differently. 📝 Cards authorize instantly but settle later. 📝 ACH might take days. 📝 Real-time rails settle in seconds. 📝 Cross-border transfers can pass through multiple intermediaries. If you don’t understand the rail your payment runs on, it becomes easy to misread transaction states, retry incorrectly, or show users the wrong status. I just published a new guide for developers that breaks this down: “What Are Payment Rails? A Guide for Developers.” In the article I cover: • What payment rails actually are • How money moves from initiation to settlement • Why a successful API call doesn’t always mean a successful transfer • Push vs pull rails and how they affect system design • How to handle rails properly in APIs, webhooks, and ledgers If you build fintech products, payment systems, or anything that moves money, this is one of those concepts that makes a lot of confusing behavior suddenly make sense. Link in comment 👇

13

1 Comment

If you’re a US startup hiring mobile this quarter: screen for release ownership, not Flutter trivia. Senior candidates don’t separate “engineering” from “shipping.” They own releases, hotfixes, and the messy production stuff that actually matters. One question that works: “Tell me about a release that went sideways. What broke, how did you diagnose it, and what did you change so it wouldn’t happen again?” The answer tells you if they’ve actually owned production when it broke.

17

5 Comments