Scott Simontis

Teaching being my main gig for the last 16 years, I've seen so many times how developers don't do a thing (e.g., trunk-based development) not because it's too hard, or they think it's wrong for them or their situation, but literally because it had just never occurred to them. But this shouldn't be a surprise. If I think back to the early days of my career, there was a time when I'd never heard of Version Control Systems, had never thought to write code to perform my tests for me, hadn't given a second thought to the distribution of responsibilities in my design, or to coupling and cohesion etc etc. The game-changer in all these cases was just being made aware that they were things. "You can do that?" It's something I hear often from people who've taken one of my courses. Even very experienced developers have lightbulb moments on them.

70

7 Comments

It's been 20 years since #git was first available to the public. I recall attending a meetup that introduced git that touted the local independent branching as euphoric development. The thing is, branching wasn't even sort of new and innovative. Branches were available from a few decades prior and were promoted as the way to support custom features for product premium licensees. Then you "just" merge in the truck and voila, you've got custom and main in one. Do that five times, and maybe it works out. Try that 10, 20, 50 times, and you've got as many nightmares. As I sat through the presentation, I wondered how git could possibly be better than good ol' trunk locked checkout/checkin. It only required you to be considerate of your teammates and check in expediently. Yet, we had to endure the new enlightenment known as forks, branches, pull requests, "gitflow," etc. Fast forward 15-20 years, and "suddenly" daily commit+commit+...+push to main with possibly/likely a merge or three is the new checkout/checkin. That's called TBD for Trunk-based Development. And, at some point, you have to ask yourself why RCSHub, CVSHub, and SVNHub were nobody's idea. But a totally toxic uber-geek created git, so that makes users cult members, and that makes using it cool. Right? Right? Right?

63

125 Comments

Steve Yegge posted a blog in march that encapsulates the massive shift occurring in software engineering today. With Claude 4 and the recent improvements on Claude Code, we're entering a new phase. https://lnkd.in/gRtRidBr This year, I have pushed more code than you. But, ideally, I wouldn't need to. We are now in the phase of AI software development called the "Agent Clusters". Here's how it works: Each time our code in production fails, a github actions claude code job auto-starts to fix it. Each time we want a new functionality, as we're communicating over slack, I can tag in our slack bot to start a github actions claude code job. And I can make as many run in parallel as I want. The bottleneck has shifted to how many things can you think of to code at a time, and how to write a good meta-prompt like a CLAUDE.md or good cursor rules files to have good code architecture over many AI iters.

60

20 Comments

Developers: Are you your team’s silent safety net? Every dev team has that one engineer  The one who stays late fixing broken scripts. Reviews everyone’s pull requests. Debugs someone else’s code at 9PM. The unspoken catcher of all things dropped. But here’s the harsh truth: If you’re constantly doing their job… who’s doing yours? 🚨 Helping too much can hurt your growth. You’ll miss your own deliverables, delay feature launches, and even get overlooked in performance reviews all while untangling someone else’s tech debt. 🚫 You might be propping up bad practices. If others rely on you to fix their bugs, it hides deeper problems. Sometimes, they even get rewarded for work you quietly finished. 📉 You’re unknowingly weakening the team. If delivery depends on a hidden hero, you’re building a fragile culture ,not just fragile code. ✅ A better way? • Make your contributions visible. • Advocate clean processes. • Promote code ownership and accountability. And when someone falls short .let the system respond. They’ll either level up, or step aside. 💡 In tech, silent heroics don’t scale. Clarity and accountability do. Don’t just cover , contribute with visibility. #SoftwareEngineering #TeamCulture #Leadership #DevTips #CodeOwnership #EngineeringExcellence

31

16 Comments