Alex Ives

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

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

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

See the fastest LLM serving engine, 100% open source!!! If you’re running multi-round QA, RAG, or any long-context workload, you know the pain: slow time-to-first-token and expensive bills. You should take a look LMCache, a next-gen LLM serving engine extension designed to slash TTFT (time to first token) by 3–10x and boost throughput. How? LMCache stores KV caches from any reusable text (not just prefixes) across GPU, CPU DRAM, and disk, then shares them across serving instances. That means fewer recomputations, faster responses, and huge GPU savings. Key highlights: 🔥 Seamless integration with vLLM v1 ⚡ High-performance CPU KV offloading 🔗 P2P KVCache sharing across servers 💾 Storage on CPU, Disk, or NIXL ✅ Supported in vLLM production stack, llm-d, and KServe 📦 One-liner install: pip install lmcache If you’re scaling LLM inference, you should check it! 👉 GitHub link in the comments. #LLM #AI #Inference #OpenSource #RAG #AgenticAI

379

27 Comments

If you’re working through someone else’s code and feel completely lost… Welcome. That feeling never totally goes away. But here’s how I tackle it: 🔸 Start from the entry point 🔸 Trace the flow, one hop at a time 🔸 Don’t panic - debug with curiosity and intention Good engineers aren’t the ones who never feel lost. They’re the ones who keep moving anyway.

32

4 Comments

Leading a technical team is a thrilling, yet often challenging, transition. Many of us are asked to step into leadership because we've excelled at software development. But being an excellent individual contributor doesn't automatically make you an excellent leader. The skills required are fundamentally different. My career has shown me that true technical leadership isn't about being the best coder or making every technical decision. It's certainly not about micromanagement, which can quickly become a bottleneck, slowing your whole team down. Instead, the real mission of a leader is to make the entire team effective. Think of it like a captain of a sports team – their role isn't to play every position, but to amplify the collective performance and coordinate efforts. My advice for effective leadership boils down to a few key principles: • Empower your team • Be a servant leader • Teach them to find answers Want some more advice for how to set up your software development teams for peak performance? Get my FREE Guide to Organising Software Development Teams HERE ➡️ https://lnkd.in/exStwpbc This guide will help you tackle critical questions like: • What is the best team size? • What skills are essential for your teams? • How do you effectively divide work and foster seamless collaboration across teams? Sign up for my mail list to download your free guide and receive regular practical software development advice, guides, and newsletters. Get your guide here ➡️ https://lnkd.in/exStwpbc

137

6 Comments

It's rough out there in the tech industry for middle managers - folks high enough on the org chart to be far away from coding, but beneath the executive ranks. In large organizations, even directors are feeling the squeeze of de-layering. The good news is that it is possible to not only survive but thrive in times when the industry is constraining and flattening. But, you must take action! In today's post, I share three things that can make you an outstanding middle manager who is likely to gain additional responsibility. https://lnkd.in/gCzm95rY

51

2 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

Second to bad management, there's one thing that kills engineering productivity and morale more than anything else. Slowness in running and deploying code. This past Friday, someone asked for a non-urgent bug fix at 4:25pm. Got our local environment up and running in seconds, instantly refreshed as I made changes, got immediate code reviews from our team channel, and deployed in minutes. This was the difference between me responding a half hour later that the fix was live in prod vs. asking them to file a JIRA ticket for my team to handle next week. Here's the limits you want to stay under: Time to launch your local env - 30 seconds Time to refresh your local env - A few seconds Time to get a trivial code review - 10 minutes Time to get a beefier code review - A few hours Time to deploy - 15 minutes (pic from the early days of my startup Scoutlit when we were just shipping)

160

174 Comments

5 ARIA attributes every dev should know (and 2 to avoid) Most developers know ARIA exists, but which attributes actually matter for everyday accessibility work? Before we get started, remember the first rule of ARIA: Don't use ARIA unless you have to. If semantic HTML can do the job, use that instead. But when you do need ARIA, here are 5 ARIA attributes that are actually useful: 1. aria-labelledby - Describe the current element with the text from another element on the page. Better than aria-label because it allows you to reference existing visible text on the page and keep it translatable. 2. aria-describedby - Connects help text, error messages, or extra context to form fields and other elements. Screen readers announce this after the main label. 3. aria-expanded - Essential for dropdowns, accordions, mobile menus - anything that opens and closes. Bonus: pair it with aria-controls to define which element it's controlling. 4. aria-current - Perfect for programatically defining the current page in navigation, active step in a process, or current item in pagination. Much clearer than visual styling alone. 5. aria-live - Announces dynamic updates to screen readers. Use "polite" for status messages, "assertive" for urgent alerts. Two to avoid (or use carefully and thoughtfully): 1. aria-label - It's typically a better choice to choose another way to label elements, with text inside a button tag, a label tag associated with a form field, or visible text associated with the aria-labelledby attribute. Treat aria-label as a last resort when no other method of labeling an element can be used. 2. role - Most of the time, there's no need for that role attribute when you use semantic HTML. Skip adding role="button" on a div - just use a button tag. A proper heading tag doesn't need a heading role or an aria-level attribute. The best accessibility starts with good semantic HTML. ARIA is intended to fill in the gaps, not replace the foundation. What ARIA attributes do you find most useful? Any that trip up your team?

52

14 Comments

How do you choose what language to use? We’re building Lago with Ruby on Rails. It’s not trendy. Young grads think of Ruby like I think of COBOL. Here’s why we picked it anyway (and my framework for choosing the right language): -First, we knew Ruby best. With 10+ years of Ruby experience, it was the most practical choice. This is important: What enables YOUR team to ship well and quickly? -Second, we didn’t care what everyone else used. Just because everyone else uses Rust doesn’t mean Rust is the perfect choice for you. -Third, your language should match the product you’re building. Ruby is battle-tested for API products. -Fourth, you need talent. Choose a language that ensures you’ll find enough engineers to hire. For our product and team, Ruby checks all of those boxes. Today: Lago handles millions of API calls a day, we’ve upgraded across multiple Ruby/Rails versions, and yes—we’ve added Go and Rust where it makes sense. But if we were starting again in 2025? We’d still choose Rails.

35

11 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