Kate Catlin

Tribal knowledge is engineering teams' biggest bottleneck. Last week I spoke with Dennis Pilarinos, founder and CEO of Unblocked, on the podcast, and this quote stuck with me. Dennis spent his *whole career* working on dev tools: from Director roles at Microsoft and Amazon, to founding BuddyBuild and selling it to Apple, to now building Unblocked, which is one of the few AI dev tools that's specifically NOT about coding. Here are a few takeaways from our chat: ↳ 🎯 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗶𝘀 𝗸𝗶𝗻𝗴 — developers spend most of their time searching for the right information, not writing code. One customer's top engineer once spent 5 days writing just 12 lines of code! ↳ 🧠 𝗛𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗮 𝗯𝗮𝗱 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 — "there's no such thing as a bad answer from an LLM, it's just a bad question." We're learning to use these tools just like we learned to use Google effectively. ↳ 🔨 𝗔𝗜 𝗶𝘀 𝗮 𝗻𝗮𝗶𝗹 𝗴𝘂𝗻, 𝗻𝗼𝘁 𝗮 𝗷𝗼𝗯 𝗸𝗶𝗹𝗹𝗲𝗿 — when construction workers got nail guns, they didn't work less - they built more buildings. AI tools let developers tackle more ambitious projects. ↳ 📚 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗺𝗮𝘆 𝗯𝗲 𝗱𝗲𝗮𝗱 — why write docs when AI can extract knowledge from code, PRs, and Slack conversations? Semantic search beats traditional documentation. ↳ 🚀 𝗧𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗶𝘀 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺-𝘀𝗼𝗹𝘃𝗶𝗻𝗴 — imagine AI that not only triages CI failures but proposes and implements fixes. We're moving from writing code to orchestrating intelligent systems. Check out the full episode in the comments!

34

6 Comments

The speed at which we are transforming how DX work gets done is staggering. And we're doing it responsibly: scaling with AI agents while maintaining quality and keeping things human. I highly recommend this read from Pauline P. Narvas, community leader extraordinaire.

8

After almost a decade working in corporate tech, joining WhereWeGo was a heartening return to the social impact work that had kick-started my initial interest in this field. It's been a little over a year, and what I've appreciated most is the thoughtfulness with which our team engages with our client's biggest problems, from dreaming big of initial designs to continuing polish after launch. While celebrating a big update or using a hot new technology is nice, they're not the point - our north star is about making a real difference for the communities our clients serve. This report shows that level of care and has some great insights - I hope you give it a read!

17

One week until my *free* Maven Lightning Lesson: “Unstuck: Advanced Vibe Coding for Lovable Builders” 📅 March 26 at 12PM ET Sign up: 👉 https://lnkd.in/eWN7U5bc This is a taste of my upcoming full course and you’ll learn: → A Product-Building Mindset that prevents common traps  → Diagnostic Skills to find what's actually broken (not just guess)  → Practical Techniques to escape "stuck" and ship Can’t make it? Sign up to get a link to the recording afterward. #VibeCoding #NoCode #AI #ProductBuilding #Lovable #Maven

14

3 Comments

I thought this was a good and very reasonable talk by Eleanor Millman on how to prioritize projects for a platform engineering team: https://lnkd.in/gaYtUHRH A few insights I took from it: - Unlike product features which can be more directly tied to revenue, platform engineering work is a couple steps removed. But that doesn't mean it's unimportant! Far from it, platform engineering projects can make everyone at the company more efficient, able to produce higher quality software, etc. - While "urgency" is always going to be a factor, you don't want to just be putting out fires, you want be able to prioritize work which is "high impact" ... even if that impact isn't felt immediately. - Good rule of thumb: prioritize "highest impact for lowest effort". - The talk has some ideas on what factors to choose for impact, and how to blend them. For instance "speed of development" is one factor, "cloud cost optimization" might be another. The weighting of different impact factors can change over time, depending on the needs of the business. I would say that a lot of companies don't have much methodology here but I can really see the value in codifying it. You can always change the methodology or the weighting if it's spitting out results that don't pass the smell test or you really feel it is leading the company astray. Clarity can give the org more freedom to put resources behind projects that would otherwise never be taken on. When things are unclear, prioritization still happens implicitly, but the decisions tend to be a lot more random and fear-based and the org is worse off as a result.

15

3 Comments

Last week, Adam Jacob (creator of Chef, CEO of System Initiative) and I got to chatting about the flood of LLM slop pull requests, and how even vetting well-fleshed-out contributions is becoming too challenging to scale. Our conversation illuminated something I've been circling around for a while. Open-source contribution has always assumed a particular model: someone submits a pull request, a maintainer reviews it, and if the code is good enough, it gets merged. But that model is breaking down. With LLM-generated PRs flooding repositories, you're now reviewing code of unknown provenance from contributors who may not even understand what they submitted. The trust model is inverted; you're doing more work to verify than the contributor did to create. What if the answer is to stop accepting outside code entirely? Instead, maintainers could have their own trusted language models triage incoming bug reports, feature requests, and minimum reproduction cases, then compose the fix themselves. You review code your own tooling generated against your own specifications, not a stranger's. The provenance is known. The context is preserved. This is already happening. Gavriel Conjack's nanoclaw project keeps its core small enough to hand-audit, with everything else as library calls to well-vetted subsystems. He's rejecting almost every pull request. His message to contributors: fork it and have Claude implement your feature yourself, rather than expecting to upstream someone else's solution. The installation instructions are literally "ask Claude to install this itself." The implications go further. Once you're generating code rather than hand-authoring every line, observability becomes even more critical. You need to instrument the generated code, watch how it actually behaves in production, and feed those graphs and telemetry data back in: "this deployment increased error rates by 12%; here's the trace data; what's your proposed fix?" Then assign the model to do that work. Close the loop between generation and production reality. The most ironic thing: Kelsey Hightower, who has been one of the more vocal LLM sceptics in our industry, may have been the most prescient of all. His nocode repository (64,000+ GitHub stars, zero lines of code) was a joke, but the punchline landed in the wrong decade. The best codebase really might be one that contains only specifications and not implementations. Yes, you duplicate implementation work across forks. But if generating code is genuinely cheaper than reviewing it, that duplication is a feature, not a bug. I wrote "Code Less, Engineer More" for Increment back in 2019 (link in comment). The argument then was about buying what you can and focusing engineering effort on your unique value. The version for 2026 might be: specify what you need, generate what you must, observe what you shipped, and keep the codebase small enough that a human can still reason about it.

443

39 Comments

From Corporate Ladder to Classroom Impact: How Eric Coronado is Transforming Suffern Central School District through Human-Centric Tech Eric Coronado (in the light purple shirt) with his team during the district's Cybersecurity Academy. (Image credit: Suffern Central School District) In the rapidly evolving landscape of K-12 education, the role of a Technology Director often fluctuates between maintaining infrastructure and shaping pedagogy. For Eric Coronado, Director of Technology for Suffern Central School District in Rockland County in New York, and a recent winner of Tech & Learning’s Innovative Leader Award, the mission is clear. While his responsibilities cover everything from cybersecurity to student devices—"If it has a plug, that's me," he jokes—his core philosophy is rooted in a much softer skill set: supporting people. Coronado’s path to educational leadership was non-traditional. Like many in the tech sector, he began his career climbing the corporate ladder. A short-term leadership experiment in a school district, however, turned into a long-term calling. "Once I was in K-12, I realized how meaningful the work was, completely different from corporate,” he says. “When you help schools succeed, you're helping the next generation and it's incredibly rewarding." Now leading a diverse district with a growing multilingual population, Coronado is leveraging strategic partnerships and cutting-edge tools to bridge the gap between complex technology and student success. AI Integration: Guidelines Over Rigid Policy (Image credit: Future) One of the most pressing challenges in modern districts is the rise of AI. Rather than shying away from it, SCSD has leaned into AI, particularly to support their expanding community of English as a New Language (ENL) learners. Coronado and his team were early adopters of SchoolAI and MagicSchool, identifying these as powerful allies in bridging communication gaps. However, the implementation strategy was just as important as the tools themselves. The district avoided creating hard-and-fast policies that would inevitably become obsolete within weeks. Instead, they established flexible guidelines focused on responsible use. "Our goal was never to replace learning but to actually support it," Coronado says. He highlights SchoolAI specifically for its ability to create "translation agents." These agents allow for robust language support while maintaining strict educational guardrails. "Students could poke at it and try to break it, but it always stayed educationally focused," he says. Tools and ideas to transform education. Sign up below. Building the Next Generation of Cyber Defenders The Cybersecurity Academy in action. (Image credit: Suffern Central School District) A standout among SCSD’s initiatives is the launch of a three-year Cybersecurity Academy at the high school. This program was born out of a partnership with the League of Innovative Schools and Digital Promise, a...

2

There is a growing, uneasy conversation happening in the Seattle tech community right now. Two recent articles in GeekWire have laid out a warning that everyone in our ecosystem should be paying attention to. The "Cleveland" Warning: Investor Charles Fitzgerald recently drew a chilling parallel between 2026 Seattle and 1950s Cleveland. At its peak, Cleveland was the "Big Tech" hub of its era, home to the world’s most valuable companies. But a frayed partnership between city government and business, combined with a "bottomless source of revenue" mindset, triggered a 20-year unraveling that the city is still digging out of today. For decades, Washington has been cited by groups like ITEP as having the most regressive tax code in the U.S. Because we have no income tax, the bottom 20% of earners pay ~14% of their income in sales and excise taxes, while the top 1% pay just ~4%. The current legislative push is an attempt to "fix" this overnight. But the "fix" is creating a paradox. The swing to an extreme by layering a 9.9% Millionaire Tax on top of capital gains, estate taxes, and city-level payroll taxes, Washington isn't just becoming "fairer", it’s becoming an outlier. The reality, as the latest GeekWire and Tax Foundation reports show, the "Tax Stack" in Seattle would reach a top marginal rate of 18.03%. We are swinging from a state with "no income tax" to a city with a higher rate than New York City (14.8%) and California (14.4%). True tax reform usually involves a "trade", lowering regressive sales taxes in exchange for a progressive income tax. Instead, Seattle is keeping its fourth-highest sales tax in the nation and simply adding a record-breaking income tax on top. We are trying to solve "regressivity" by becoming the most non-competitive state for innovation. It’s a move that risks fixing the "inequality" problem by simply driving the "engine" of the economy across the lake to Bellevue or out of the state entirely. While education is the primary pitch for these new taxes, Seattle has a documented history of diverting "dedicated" funds, such as the gogging $305 million siphoned from JumpStart revenue to cover general city expenses this cycle alone. Despite record city budgets, Seattle Public Schools continues to face nearly $100 million deficits and has previously resorted to unusual inter-fund loans and proposed school closures to patch holes created by years of administrative overspending. Giving more money to a system that consistently "raids" its own priority funds to mask fiscal mismanagement isn't a solution; it's just a blank check for more of the same. We cannot fix a regressive tax system by simply building a non-competitive one that punishes success and rewards mismanagement. It’s time to stop asking for more "blank checks" and start demanding the fiscal discipline that keeps our greatest innovators and our children’s future in Seattle.

65

22 Comments

If your audience can't do something useful with your product in less than 10 mins, you are at a significant disadvantage. No amount of DevRel will fix this.

4

Learning DevOps taught me that caching isn’t a tool -> it’s a strategy. Implementing caching in a cart system and exploring WebSockets for the first time showed me how temporary state, TTLs, and real-time updates actually work in production-like systems. Small implementations, big learning. #LearningInPublic #DevOpsJourney #BackendDevelopment #Caching #SystemDesign #WebSockets

3