Jordan Raine

Pull Requests shouldn’t feel like this. We’ve all opened a large PR review and thought: “Well... this is going to hurt.” Sure, small PRs are great, but sometimes you need the full picture. That’s where stacked PRs help (been using Graphite for that, a tool for managing PRs and code reviews). Stacked PRs treat your feature development as a chain of commits / PRs layered on top of each other. Think of it like a Jenga tower: each block (PR) builds on top of the previous one. pr1 → main pr2 → pr1 pr3 → pr2 Now it’s getting even better. I just got early access to Graphite Chat 👇 - I can literally ask it “what’s going on in this PR?” and it gives me the full story, codebase history, past PRs, even outside context. - I can just highlight it and ask “explain this”, instant breakdown. - Flags risks before reviewers even show up. - When someone leaves feedback, it helps me make sense of it and suggests fixes. - And the best part? When CI blows up, I can just ask “why did this break?” and actually get an answer. I’ll even be able to pop open the Graphite Editor right inside Chat to view and edit the codebase. Reviews feel lighter, more collaborative. Exactly how they should.

1,573

141 Comments

If you're looking for a new docs framework for your dev tool, I can't recommend Docusaurus enough. 1. You can change the appearance of any component—no matter how big or small—by ejecting its raw React code into your source tree. I've ejected almost all of its major components and restyled them with Tailwind. 2. It supports content written with MDX, which is like Markdown but better. MDX lets you write JSX tags so you can render React components (like badges and banners) directly inline your content. No more messy templating. 3. It bundles Prism for code snippet highlighting. So you if you want to change how each and every token of your language gets styled—which I do—you can override it with a simple centralized map—which I have. 4. You can swap out its on-site search engine with Algolia, now widely considered the best option for developer sites. It is, in other words, the perfect tool for people like me who are obsessed with every pixel.

118

16 Comments

You may see folks claiming that they can get "A.I." coding assistants to do exactly what they want by completely and precisely describing the software they require up-front, and hailing the return of Big Design Up-Front. Anyone who's spent more than a handful of hours using these tools will know that this simply isn't true.

103

116 Comments

We kept hearing the same frustration from teams using visual testing: "I spent an hour approving timestamp changes." "Our CI is blocked because of a rotating banner." "The real bug was buried under 200 irrelevant diffs." That's the reality of visual testing today. The tools work, they catch every pixel that moves. But they don't understand context. They can't tell you what actually matters for your product, your brand, your release. So we asked: what if the tool could help you focus on what you care about? Today, we're launching the Visual Review Agent for Percy. Here's what's different: it doesn't just flag changes, it helps teams understand them. Natural-language summaries explain what shifted. You can create custom review rules so the agent highlights only the visual changes relevant to your use case. And it tracks ROI at the build level, so you can show exactly how much time and effort you've saved. Early teams have cut their review cycles by up to 3x. The real impact? Teams are back to doing what they do best — improving quality, not chasing false positives.That's the unlock we've been chasing. Try BrowserStack's Visual Review Agent in your builds today: https://lnkd.in/d3NcbEDD

173

1 Comment

OK I'm full team sonnet now. If you really force it to test it's work in small chunks, and then run one more "review pass" after a large chunk of work is complete, it's much much much faster than Opus and the results are just as good, if not better. Here's a typical flow: * Iterate on a large design, with either Sonnet or Opus. * Have the model break it up into a few Milestones * Break each Milestone up into 4-6 steps. This part is key: *ask the model to include verifiable exit criteria for each step.* * Implement each step one at a time. * After each step, run another pass. Tell the model something like: "Another agent completed Step 2 from Milestone 1. You are a much much more experienced engineer than that agent. Review it's work for quality, maintainability, and fitness in the overall long-term project goals. Be harsh. List potential improvements, then make them. Re-verify all exit criteria have been met." It takes a lot of prompting to get the model to actually work in small chunks on each step, testing it's work along the way. I often have to kill it and remind it to not wait until the end of a step to write tests, but if you do this the results are amazing and the model can fly through large pieces of work.

73

13 Comments

There’s a lot of “AI” schadenfreude flying around about this article, and rightfully so. But at the same time, this is quite literally what deskilling looks like: use automation to displace experienced, well-paid workers, then underpay others to perform the same labor. Wages go down; work becomes more precarious. The system’s working as intended. https://lnkd.in/eh7enbPb

114

12 Comments

A big customer asked how to measure the business impact of Amp vs. other coding agents. Their Amp usage is growing crazy fast, and they want to make an informed decision. My answer was a bit surprising: This is all brand new. Amp and Claude Code (which are the latest generation of coding agents) have been widely used for ~60 days. Things are changing so fast and the impact has been so big that there has not been time or need for a set of measurement best practices to emerge. When orgs are adopting these tools, and they are adopting these rapidly, they are doing so because of very strong signals, usage, and feedback from devs who are trusted by the decision-makers. Amp’s team pages show you who’s using it, how much, and how often. And as the only coding agent with team thread sharing, only Amp lets you see what people are actually using it for (not just how much they're using it). Unlike the previous generation of seat-pricing-based coding assistants, Amp is purely usage-based pricing and doesn’t require you to make a big up-front $$/seat commit, so the decision here need not be as big as in the past. In fact, we are seeing a lot of customers who are already switching away from other seat-based coding tools they prepaid for a whole year for just ~2 months ago after a heavy impact measurement process that in hindsight yielded the wrong decision. Naturally they are nervous about making another big 12-month commitment. What we’ve seen work the best is to give devs access to a few tools, see what they like and use the most (based on # of threads, tokens, and daily usage), and then make those well-loved tool(s) more broadly available quickly. If that means staying pay-as-you-go or making a smaller enterprise commitment (such as for only 1-3 months of estimated usage, not a whole year), that is fine and all of the agentic coding tools that I’m aware of, Amp included, will allow that.

110

3 Comments

Hot take (with love): your To-Do app won’t get you hired. I’ve built them too. They’re great for learning CRUD, routes, and state. But the market’s seen a thousand. Hiring teams skim for signal. What they want to see: • You solved a real problem (yours or someone else’s) • End-to-end thinking (API design, auth, validation, tests) • You shipped (deploy + README + screenshots + a 60-sec demo) • You made it visible (why you built it, what’s next) It doesn’t have to be flashy—just useful and yours. How I’m doing it: FinLume. Not perfect. Not fancy. Still needs alot of work, But it solves my real headache (bills/subscriptions) and forced me into FastAPI, SQLAlchemy, auth, and testing. That’s the point. Simple non-To-Do ideas you could ship: • Renovation expense tracker with monthly summary (been living this! 🧱) • Job/quote scheduler for trades (my gardening days inspired this) • Interview tracker with follow-up email templates • Subscription cancel-reminder + renewal timeline Bottom line: Different > generic. Visible > invisible. Post progress. Ask for feedback. Make noise without screaming. #JuniorDeveloper #BuildInPublic #PortfolioProjects #LearnInPublic #PythonDeveloper #FastAPI

114

79 Comments

The biggest lie in tech hiring: "We hire the best developers." No, you don't. You hire the developers who interview the best. I've worked with brilliant developers who can build entire systems from scratch but freeze up in technical interviews. They know every design pattern. They've solved complex production issues. They've mentored entire teams. But they can't explain FizzBuzz under pressure. Meanwhile, less experienced developers who practiced mock interviews land the $150k+ offers. Here's what I discovered after helping 100+ developers: The interview is a completely different skill than actual development. And most experienced developers never learn it. They think their GitHub speaks for itself. They assume their experience is enough. They walk into interviews unprepared. Then they wonder why they're getting lowball offers or straight rejections. The solution isn't becoming a better developer. It's becoming a better interviewer. After working across different continents with developers at every level, I've seen the patterns. The ones who succeed treat interviews like any other skill: They practice. They prepare. They get feedback. They improve. Want my complete interview preparation framework that helped developers increase their offers by $50k-$80k? Comment "INTERVIEW" and I'll send you the free guide. Stop letting poor interview skills cap your career.

96

171 Comments

We're getting a lot of positive comments on Parlant's documentation quality. We've definitely put considerable effort into our docs, because, as a team of long-term engineers, we know just how valuable that is. For those writing technical documents, I'll share our top 2 technical writing principles. // 1 Don't seek to convince. Seek to be understood. // 2 Don't seek to sell. Seek to serve. For better open-source docs! parlant.io

53

3 Comments

AI won't make your team faster on its own. Better developer experience will. I sat down with Laura Tacho, CTO at DX, to talk about what actually improves engineering team performance and what just looks like it does. We covered: 1. Why most metrics fail (and how to use them properly). 2. What developer surveys can tell you that GitHub stats never will. 3. How to track DevEx without a fancy tool, even at a 10-person startup. 4. The real impact of AI on engineering workflows (spoiler: it’s not replacing your team). The big takeaway? Developer performance isn’t about shipping faster. It’s about removing friction. Whether it’s bad tooling, unclear goals, or noisy metrics, the teams that win are the ones that make it easier to do great work.

42

5 Comments

After a chat with a great contractor yesterday, we got on the topic of T-Shaped profiles in contractors. In today’s fast-paced tech landscape, the most impactful contractors aren’t just specialists, they’re T-shaped. A T-shaped JavaScript contractor combines deep expertise in core JS technologies (React, Node.js, TypeScript, etc.) with broad capabilities across adjacent areas like DevOps, UX, testing, and architecture. They don’t just write code, they solve problems holistically. 🔍 Why T-shaped contractors stand out: Adaptability: They can jump into unfamiliar territory and add value quickly. Collaboration: They speak the language of designers, product managers, and backend engineers. Efficiency: They reduce bottlenecks by bridging gaps across the stack. Strategic thinking: They understand how their work fits into the bigger picture. Whether you're scaling a product, modernising legacy systems, or building something new T-shaped contractors bring the agility and insight to move fast without breaking things. 💡 Looking to hire? Prioritise depth and breadth. The best contractors don’t just code, they connect dots. #JavaScript #Contractors #Hiring #TechTalent #TShapedSkills #Frontend #FullStack #React #NodeJS #TypeScript #AgileTeams

31

1 Comment

I've worked with 200+ engineers over the past 10 years. The greatest ones have these traits in common (not coding). They investigate 3 areas before touching any code. 1, Team dynamics - How well does the team communicate? - Do people support each other? 2, External dependencies that could be blockers - Third-party integrations - Legacy systems - Legal requirements 3, Leadership alignment - Are executives aware of technical costs? - Is there a clear decision-making process? The best engineers are the ones who spend more time understanding people than coding: - Ask tough questions upfront - Map out dependencies early - Build relationships before features Look for these traits if you want to hire good engineers.

67

64 Comments

Shout-out to 💻 Octavian Contis, who recently posted about the Shopify theme inspector being a bit tedious. I felt that, so I added a little something to Alfred to help out. You can now set Alfred to: - Automatically disable the inspector. - Restore your previous inspector state. - Or just let Shopify do its thing. The setting persists across all Shopify stores and browser sessions as long as Alfred remains active. It's a small change, but hopefully, it saves you a few clicks and a bit of frustration. Hope you find it useful! *Extension link available in description* #Shopify #ShopifyDev #ThemeDev #WebDev #Productivity #BrowserExtension

59

10 Comments

We did something cool the other day and I can't help bragging about it (names, details, etc, obfuscated a bit.) A client came to us with some big reliability problems. They had user behaviour monitoring, and they had mobile client stacktraces. But there were hundreds and hundreds of them, and the team had no idea where to start a fix! We discovered that we could map client errors to user behaviour metrics very closely. It turns out there's just tens of _those_ - and they have a much larger effect on user reliability than the others. Additionally, we found lots of clusters of issues that happen together, which suggests there's some contributing factor underneath them. Fixing them together is also much faster, since you're usually doing so without having to jump around lots of codebases. Now, we can turn your error logs into prioritised to-do lists for developers, directly focused at the user experience, SLOs, or 3rd party service availability. Let us know if this is interesting!

130

6 Comments

AI is everywhere. But it's not the first wave we've seen. The Evolution We've Witnessed: 1. We started with manual testing, that’s how most of us learned the craft 2. Then automation arrived: Selenium, Cypress, Playwright, CI/CD 3. Now AI dominates every discussion, every team, every meeting Here's what's different this time: Unlike automation, which took years to settle into the industry, AI is already transforming how we work today. But here's the constant truth: Those with strong fundamentals (problem-solving, critical thinking, domain knowledge) always adapt faster.So what do we do? 📌 We keep learning. 📌 We stay curious. 📌 We explore the new. But we also hold on to what really matters. Because the people who grow the fastest and last the longest, are the ones with strong fundamentals. Ready to start your AI journey? If you’re interested in AI but aren’t sure where to begin, I’ve put together a beginner-friendly playlist on YouTube that can help you get started: https://lnkd.in/gtTBT9rr #AI #Testing #Automation #CareerGrowth #QualityEngineering #Learning #ABAutomationHub

52

3 Comments