Ryan Pendleton

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

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

And the gap between engineers who ignore the AI revolution and those who embrace it will only widen and compound over time 💯

2

It's really hard teaching new engineers that effective debugging is less about fixing code and more about methodically eliminating variables. That kind of reasoning ability only seems to come with experience. Which reminds me of one of my favorite parables. A homeowner calls a plumber to fix a boiler. The plumber tightens a single pipe and it starts working. He hands over a bill for $250. The homeowner protests, "that only took you five minutes!" The plumber replies: Tightening the pipe: $1 Knowing where to tighten: $249

78

20 Comments

"Your developers aren't slow. Your process is." Every founder I've met who thinks their dev team is underperforming is usually wrong about the cause. It's rarely skill. It's unclear requirements that change after the build starts. It's design files handed over with missing states. It's "quick calls" that fragment 4-hour deep work blocks into nothing. It's decisions that should take 10 minutes getting stuck in a 3-day approval chain. Bad process makes good developers look bad. We learned this the hard way on an early project. Talented team. Constant context switching. Missed deadline. We blamed velocity. The real problem was us, the way we were running the engagement. After that we built a delivery process we haven't changed much since: — Requirements locked before a single line of code — Design signed off before dev starts — One decision-maker on the client side, not five — Weekly demos, no surprise pivots Same developers. Completely different output. If your builds feel slow, look at the system before you look at the people. What's the one process change that made the biggest difference to your team's output? #startup #StartupLeadership #ProductManagement #DevProcess #TechFounders #BuildBetter

1

Hot Take: Its acceptable to push unpolished, "vibed" code to a branch. If you're like me and do a mix of pairing and soloing with another dev, you might find yourself saying: "this is the first pass I did with Claude, it needs work". It's not an excuse to push broken or insecure code! But by no means do I want my pair or me to be hoarding code because it's not perfect yet. Iteration is still king.

25

10 Comments

One thing I've heard a lot in junior dev interviews a lot lately: "I just want a mentor to show me how to design a system the right way." Unfortunately, there is no "right way." Much like intelligence, it's not about knowing the answer. It's about understanding why that's the answer. Teaching someone that a certain system design is "correct" is actually a disservice. Why? Because every system is a unique snowflake of requirements and constraints. A "perfect" architecture for a high-frequency trading platform is a disastrous architecture for a mobile video chat which would be different than an enterprise SaaS app which in turn... System design isn't about following a manual; it’s about asking questions and navigating tradeoffs: * Latency vs. Throughput: Do you need it fast or do you need a lot of it? * Consistency vs. Availability: Can the data be slightly old, or must it be 100% accurate 100% of the time? * Cost vs. Performance: Do you have a blank check for AWS, or are we running this on a shoestring budget? * Build vs. Buy: Is this core to our business, or should we just pay for a SaaS? Stop giving them the answers and start telling them about the disasters (best way to learn is falling on your face, but you can prevent some of that). Start asking them the "Why." Instead of saying "Use microservices," ask them: "What happens if the network fails here?" The goal shouldn't be to teach them how to build this system perfectly. It's to teach them how to ask the right questions, avoid the common pitfalls, and build every system better than the last.

18

10 Comments

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

Experienced developers: Stop saying you're "just a developer." You're not. You're a problem solver who happens to use code. I see 10+ year veterans underselling themselves every day: "I'm not ready to lead a team" "I'm never gonna be better than the 10x developers" "I'm not senior enough for that role" Meanwhile, you've: - Created products that made your boss rich - Prevented system outages that would cost millions - Built features used by thousands of users daily - Mentored junior developers who are now thriving But you focus on what you DON'T know instead of what you DO. Here's the truth: Imposter syndrome isn't about lacking skills. It's about lacking perspective. You compare your behind-the-scenes to everyone else's highlight reel. Stop it. Your experience IS valuable. Your solutions ARE needed. You DO belong in those senior roles. The companies that don't see your worth aren't worthy of your talent. Find the ones that are. ♻️ Repost if you needed to hear this today. What's one thing you accomplished this year that you're proud of? Share it below 👇

22

9 Comments

Another client telling me they're filtering out dev candidates who don't have significant "pre-AI" experience, after watching dozens crash and burn on code comprehension. Basically, they didn't understand the code they "wrote".

62

13 Comments

An engineer thought their manager had stopped giving feedback. No public corrections. No call-outs in meetings. Instead: Great work → praised publicly (Slack. Tagged. Specific.) Course correction → handled privately (1:1. No audience.) The impact? Quiet engineers spoke up. Junior devs became known for their strengths. Collaboration skyrocketed. Here’s the real lesson: People don’t leave for money. They leave when their work feels invisible. Public praise builds reputation. Private criticism builds safety. The best engineering managers don’t just ship products. They make engineers feel seen. What’s one thing a manager did that stuck with you?

79

3 Comments

A team member messaged me after a 4-hour call fixing dev issues. "I can't believe you were on that call." We have 100+ people at Genflow. I run a $100M agency. And I was right there debugging code with the team. It hit me how wrong most people get leadership. Everyone thinks being CEO means strategy sessions and vision boards. Wrong. Being CEO means being the captain who's still on the field. You show people how it's done by doing it alongside them. Not above them. The idea that you'll build a business and just work on "high-level stuff" while everyone else executes? That's not how you scale. You scale by staying close to the work. Understanding the actual problems. Building alongside your team. After 9 years of doing this, I've learned: The best CEOs aren't in corner offices. They're in the trenches when things break. They know the product inside out. They can still do the work if needed. Your team doesn't follow titles. They follow leaders who roll up their sleeves. What kind of leader are you trying to be?

45

16 Comments

Software Engineering has never been more accessible, and yet we're still clinging to this idea that the engineering team is this group of socially awkward, unwashed dudes sitting in a dark room. Yes, there are abrasive engineers still out there. But it's at the same proportion that abrasive people exist in almost every department. Most of your engineering team do not need to be shielded from customers, or vice versa. In 2026 if you have an engineer that can't interact with other humans, they are a bad engineer. It's a team sport, they need to learn these skills to act as part of a team. If you want to maximise your engineering teams potential, get them more involved with the people they're building for. Show them who their work is impacting.

34

4 Comments

I kept going back and forth: "Should this be a skill or a subagent?" Turns out the answer is dead simple once you see it. Think of it like a company: Subagents are your team members. The frontend dev. The backend engineer. The copywriter. Each has their own desk, their own focus, their own deliverables. You hand them a task, they go do it independently. Skills are your company playbook. The coding standards doc. The brand voice guide. The deployment checklist. Any team member can reference them. They don't do the work — they make sure the work gets done right. Now the magic: subagents automatically load relevant skills when they start working. Your backend subagent picks up a task → your api-design-patterns skill kicks in → the code follows your conventions without you saying a word. So next time you're stuck deciding: → Delegating a task to a specialist? Subagent. → Teaching a method or standard? Skill. They're not competing concepts. They're complementary layers. #ClaudeCode #AI #BuildInPublic #AgenticDevelopment

3

1 Comment

"Why is my Rails app doing that?" "Why is my Rails app down?" If it's not clear to the average web developer... ...even if your lone wolf on the team can figure it out? You're not in a great place. What's the answer? It's not an "improve logging" Jira card. It's adding instrumentation systematically so you can answer important questions of your app.

4

1 Comment

Tech friends, is anyone here actually using agent swarms for development? I mean automated, parallel agents building features, deploying them and testing them, end to end. If so, how. This *has* to be the next stage of software engineering but I can't find anyone doing it for real.

3

2 Comments

Exactly 6 months ago I was absolutely blasted for posting that we reject any engineering candidates that don't use coding agents effectively. I cannot fathom that there are other software companies where engineers are hand-crafting a for-loop. However, I am honestly surprised by the pace of change. To be an effective engineer now, you need to be able to handle a lot more responsibility. At a product company you need to: - Take ownership outside your domain (product marketing, docs, roadmap) - Engage with product design trade-offs - Grow your technical superpowers in new areas rapidly (web security? infra?) I genuinely don't think this new world will suit every engineer. At Lightdash, our product engineers were always hired for extreme autonomy and product intuition; the ability to talk directly to customers and distill the feedback; and the mindset to solve problems when you don't have all the prerequisites handed to you. We're rethinking what our roles look like now as the way we build software shifts so fast.

62

12 Comments

Picking a dev shop shouldn’t leave the success of your startup to chance. But let’s be real: one wrong hire and you’re stuck: → Scope creep burning $50k/month while they "figure it out"… → Missed deadlines pushing your launch into next year… → "Scalable" code that faceplants at 1,000 users… You’re not crazy... 74% of startups blow their dev budget 2X–3X over (thanks, Gartner). Why? Most shops: ❌ Stuff your MVP with "nice-to-haves" (that users ignore). ❌ Lock you into tech that can’t grow with you. ❌ Smother you in jargon while your cash evaporates. We got tired of the BS. So we built a dev shop for founders, by founders: Tight-Fisted MVP Sprints Ship in 90 days with ONLY what makes you money. Live performance dashboards → see exactly how healthy your tech is. Skin-in-the-Game Pricing... Fixed monthly fees. Zero surprise invoices. We don’t "exit" ’til you’re winning. Why this works when others flop: While rivals drown in tech debt, you’ll: → Deploy 3X faster (clean code ≠ rocket science). → Pivot over coffee – not corporate Zoom marathons. → Scale profitably while others beg for "just 6 more weeks!" Stop rolling dice with your company. 👉 "DM" us for a free tech autopsy : We’ll dissect your stack + show you 3 cash leaks bleeding you dry. PS: Choose the perfect dev partner and watch your startup soar. #NoMoreTechRegrets #MVPThatDoesntSuck #RealTalkDevs #SaaSFounders #ScaleWithoutTears #DevShopRehab #StartupTruths

2