Spencer Post

recently Walmart asked all devs to use GitHub copilot. whether useful or not, the direct result is that GitHub is either incredibly slow or completely unreachable during business hours. the feeling I get is that some of that additional load on GitHub is producing value, but I highly doubt it outweighs the productivity loss of not being able to use GitHub for regular business.

We just released Taro's newest course about what life is really like at FAANG. So much of the discussion about working at FAANG focuses on things like the scale of the work or the free snacks. But on the day-to-day level, an engineer at Google or Facebook doesn't think about these topics. They are spending most of their waking hours on things like: - how much scope do they have? - how much control do they have vs just being a cog in the machine - what do their coworkers think about them? As a 5 year veteran of Meta, I break down the real pros and cons of working in Big Tech. Check it out here: https://lnkd.in/gfkwVDf9

58

4 Comments

When a dev leads with “clean architecture,” I pause. If they push for the perfect setup before writing a single feature, I ask why? It’s not that quality doesn’t matter. It’s that context does. Perfect code doesn’t help if no one needs what you built.

7

4 Comments

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 don't write dedicated "unit" tests for every public method or every function. Some might interpret that as not needing high test coverage. Just to be clear, my test coverage is usually 100% or as near as dammit. There's no code that isn't tested.

31

2 Comments

One of the more underrated things a Rails developer can do for their career is show up to an in-person event. The obvious value is learning. But the less obvious value is compounding. The conversations in the corridor between talks, the developer you get chatting to before a keynote, the hiring manager who notices your question during a panel — none of that happens on a Slack channel or in a GitHub thread. Sorcer were proud sponsors of Brighton Ruby last year, where we saw exactly this in action. The room was full of developers at every level, from juniors finding their feet to principals who’ve been writing Ruby since the early days. The quality of conversation across that range is something no conference livestream replicates. If you’re considering whether a developer event is worth the time away from the day job, the research backs what most experienced developers already know: career-defining roles are more likely to come from a hallway conversation than a job board. Brighton Ruby returns this year. If you haven’t been, put it on your list. #BrightonRuby #RubyOnRails #RailsDevelopers #DeveloperCommunity #TechEvents #RubyConference #Sorcer

5

Structured Events in Rails! OMG! I've been waiting for this for ~4 years. Want to send *proper* structured events? Yeah. Me too. This is the most exciting development in observability for Rails in... ...well, forever. This opens the door to proper OpenTelemetry instrumented Rails apps... ...with a single subscriber and an intuitive interface. But it's way more than that - it allows us to instrument *business* events. Things like: * Order Processed * Customer Paid * Invoice Created I'm beyond excited about the direction the Rails team has gone in. * Decoupled the subscriber from the instrumenter * Aligned the API with the ridiculously good error reporting * Namespaces for events This will open the door to massive improvements in the observability of Rails apps. A HUGE thanks to Adrianna Chang for leading this effort and getting a huge feature into Rails that's critical for modern observability. Kudos! Comment below with your questions about how to use observability and I'll answer what I can.

11

6 Comments

Peter Steinberger has also said that Claude is very eager to implement and that plan mode is a crunch. One of his assertions is that Codex is way better at reading a ton of files before starting to do things. (I've generally seen this too) After having used both Claude and Codex on their max/pro plans, I agree Claude is generally eager to implement and codex can be more deliberate and thorough in many cases. However, the skills (& mcps) you have enabled do change how the agents respond. With my set of skills (many of anthropic's skills and others; superpowers comes into play a lot) and the prompts I use, claude switches to plan mode on its own and takes me through lengthy planning sessions. I often prompt something like "use a team of agents to investigate X and make a plan". And it plans; a lot. Sometimes I don't even say plan and it drops into plan mode. I've seen Codex just go and implement things on its own when I just wanted it to poke around and come back with options. Each one of these different models have different "trigger words" and you have to have the right feel or intuition for how to prompt the model correct to get it to do what you want. That being said, some of these behaviors that have to be made up for by skills or other means are likely defects in the underlying model (as Peter Steinberger points out). They're a lot more dependable from prompt to prompt in 2026 compared to last year. Last year they would hop the rails and just start rolling on some tangent that they thought was a good idea. So is Claude Code more apt to eagerly go implement a bad idea? I think "it depends" 😊

5

How to write the best prompts for a coding AGENT: Pair with another HUMAN on understanding and describing the problem. Still the same as before.

6

There is a specific kind of Principal Engineer every serious engineering org eventually needs. Not the loudest. Not the most political. The one who improves the whole system by shipping: cleaner interfaces, safer releases, fewer surprises, faster iteration. They influence by writing code, setting patterns, and lifting the bar through delivery. If you are that kind of hands-on Principal Engineer, message me. I have a question. 📩 #PrincipalEngineer #Java

13

1 Comment

We don’t hire software engineers to solve LeetCode problems. We hire them to design scalable architectures. Debug complex systems. Balance speed with security. Collaborate with humans. And navigate messy, ambiguous problems. But too many interviews still boil down to: “Solve this algorithm puzzle under time pressure.” LeetCode rewards memorization, not engineering judgment. It filters for people who had time to cram, not the ones who’ve built secure, reliable systems. If you want to hire great engineers: Give them real-world scenarios. Let them talk through constraints and risk. Watch how they think—not how fast they recall a pattern. Because building software—especially secure software—isn’t about regurgitating solutions. It’s about understanding the problem well enough to solve it.

87

19 Comments

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

I see so many startups claiming they want to hire elite Software Engineers, but then demanding a coding task before even having an intro call. That’s not how you attract top talent.

27

17 Comments

Your best engineers aren’t coding. And it’s not their fault. If you ask a senior engineer what they did today, the answer usually isn’t “I wrote code all day.” It’s more like: • Debugged a CI failure • Chased down logs • Updated tickets • Waited on a build • Sat in a meeting for an unspecced feature This is the hidden tax of modern engineering: developer friction. We love to talk about "10x engineers," but ignore the 100x distractions that neutralize them. Every context switch—leaving the IDE, digging through dashboards, hunting for docs—comes with a cognitive cost. After a few interruptions an hour, flow state never happens. And the worst friction comes from the "boring but critical" work: • PII and compliance checks • On-call firefighting at 2am • Triaging duplicate bugs Current AI tools don’t fix this. They optimize typing. Typing isn’t the bottleneck—context is. The real opportunity isn’t faster code generation. It’s automating the friction around the code. Imagine agents that: • Pull the right logs before you even open your laptop • Flag PII directly in a PR • Auto-close duplicate issues before you see them Strip away the context-draining work and something interesting happens: engineers don’t just move faster—they actually get to build again. I wrote a longer piece on why this matters and how specialized AI agents can reclaim that lost time. 👉 Read the full post: https://lnkd.in/gvTKHd-v 👉 Join the Guild.ai waitlist: https://www.guild.ai/

39

via Andre Lockhart Here is the 3-step software engineering technical vetting process for hiring engineers who write great code, with a quickness. There are clearly measurable assessment criteria for each step. Use the same tech stack they'll be working in. 1. Engineer 1: Give them a sheet of paper or a screen filled with messy code and have them talk through the refactor. 2. Engineer 2: Pair with the candidate to find/fix a bug. 3. Engineer 3: Pair with the candidate to add a feature.

1

"Backend is easy." Oh... yeah... totally... Easy like: Wrangling Redis like it's Gandalf at the gate. Slicing transactions into bite sized commit snacks so your DB doesn't choke to death. Playing 4D chess with phased micro batched transactions while the clock screams timeout. Writing saga style rollback code to deal with distributed transaction failure, that feels less like code and more like a voodoo ritual. Do it right? No one notices. Do it wrong? PagerDuty speedruns your REM cycle. Backend isn’t "just CRUD." Backend is Dark Souls on production mode. Backend is yoga with knives. Backend is building a sand mandala and then setting it on fire for consistency guarantees. But sure. "Easy."

168

107 Comments

Answer this question before asking your dev team to build anything. Can you 100% guarantee that someone will use this feature? Most senior engineers have shipped dozens, if not hundreds of features that were never used. It's crushing. Do your discovery work. Give them the evidence that someone will use the thing they're about to put 2 months of their lives into. That means something concrete. A real person from a real company. Otherwise you'll lose the trust of your engineers and they'll start to prioritize their technical debt above your features

17

9 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