Richard Solomou

I’ve spent days optimizing something that turned out not to matter. Refactored, improved performance, cleaned architecture, reduced complexity. And the system behaved exactly the same. No visible impact. No measurable difference. That’s one of the hardest parts of engineering. You can do everything “right” and still move nothing. Sometimes the bottleneck isn’t the code. It’s the assumption.

2

🚀 GovTech at Scale: The Event-Driven Heartbeat on .NET 10 🚀 In the previous post, I detailed the synchronous "blocking I/O" nightmare we uncovered—where modern .NET 10 threads were paralyzed waiting on decades-old legacy systems, ensuring a total crash at Go-Live. We didn't need a faster server; we needed a fundamentally different architecture. We needed a shield. 🛡️ Our team designed a massive shift to an Event-Driven, decoupled engine. Here is the blueprint we proposed to scale this critical GovTech system for one of Latin America's largest cities: ⚡ Part 1: The "Via Expressa" (The Fast Path) We stripped the user's synchronous login path down to its absolute complexity: O(1). Modern Auth Service ➡️ Blazing-fast JWT generation (Reflection-free, compile-time optimized by .NET 10 Source Generators) ➡️ Done. The user is IN in milliseconds. 💥 But what about the essential profile syncing, legacy updates, and email generation? 📦 Part 2: The "Trabalhador de Fundo" (Decoupled Background Processing) This is where the engineering magic happens. Immediately after validating the user, the modern API publishes a lightweight event: "User [De-identified Login] Logged In" We introduced a Message Broker layer (RabbitMQ + MassTransit) to handle this asynchronously. The API is immediately free to serve the next user. 🛡️ Part 3: Engineering for Resilience (Seniority in Action) The final piece of the puzzle was protecting the fragile legacy infrastructure from an "Event Storm." - Shielding the Legacy (Rate Limiting): We configured the Background Worker to consume events at a controlled pace. MassTransit's Prefetch Count ensures we only send a steady pulse to the legacy system, not a DDoS. - Guaranteed Consistency (Idempotency): The worker is idempotent. We implemented Redis-backed state checks to ensure if the same event arrives multiple times, the legacy processing happens exactly ONCE. Scaling isn't about re-writing the past; it's about architecting a decoupled, resilient future around it. 🏗️⚡ In the final post of this series, I'll discuss the crucial Staff/Architect vision: defining clear technical boundaries and fostering collaboration between Software Engineering and DevOps teams to ensure Go-Live success. #DotNet10 #CSharp14 #GovTech #EventDrivenArchitecture #MassTransit #RabbitMQ #Scaling #HighPerformance #Decoupling #SoftwareEngineering #StaffEngineer #LegacySystems #Idempotency #RateLimiting #ArchitectureDesign

1

After AI has disrupted our industry causing us devs to be so much more productive, putting thousands out of work, and driving salaries through the floor it's at least refreshing to see that the few jobs being posted now have sane requirements unlike before....what's that? Oh, they haven't? You mean I can make 20% less at your company, still need to have mastery of multiple server side languages, a decade of experience in React, familiarity of multiple dialects of SQL, working knowledge of [insert cloud computing platform], and still have to go through five rounds of technical interviews? This industry needs to make up it's mind - either this profession has become more accessible and therefore the reqs and hiring practices become realistic OR our knowledge and expertise truly is valuable and we can feel safe and valued in our positions. This industry has been talking out of both sides of it's mouth since AI burst on the scene and justified cutting so many smart and capable people loose.

138

24 Comments

My state management was a mess last month. I obviously blamed React. Like, me? Writing bad code? No, never. Here's what was happening: - I changed something small, another part of the UI broke - Re-renders became impossible to reason about - Some requests started firing twice I wasn't shipping fast, I wasn't confident in my code, and I wasn't having a great time. Most of the time, it's not a React problem. It's a state management problem. When UI state and server state live together, everything ends up inside useState, context, or some improvised global store. But API data isn't just "state" - it's cache. Without treating it as such, you lose control over refetching, invalidation, and synchronization. That's when things get unpredictable. The fix is straightforward: 1. Keep UI interactions local (toggles, modals, form inputs). 2. Manage server state separately using React Query or TanStack Query. 3. Let the library handle caching and consistency. Once that boundary is clear, everything becomes predictable again. My solution wasn't complicated. No magic formula. Just clear separation of concerns.

11

Sincere question: why do many developers ignore linter tools? Last week, I worked on a project that had dozens of lint warnings. About 70% of them were fixed simply by running npm run lint:fix, and the remaining 30% required applying the same refactorings repeatedly. In total, I spent less than an hour fixing all the lint issues with Claude Code — yet the impact on code quality and readability was significant. #SoftwareDevelopment #Programming #CleanCode #CodeQuality #BestPractices #OracleACE #TechCommunity #OracleCommunity

5

2 Comments

We were having some interesting discussions about this at DataTune Conf! I strongly believe that most of us who hang out for this run on software engineering will see new languages written by agents, for agents. "The agents claim that we are now in the 10,205th generation of the code base, in any case no one could tell if that's right or wrong as the "code" is now a self-modifying binary that has grown beyond human comprehension" https://lnkd.in/gm9wKEvD Awesome walkthrough https://lnkd.in/g8cdAygf

4

I’m starting to think AI-assisted development has quietly killed the main argument for cross-platform frameworks. Writing truly native code for each platform is suddenly… not that expensive anymore.

4

3 Comments

GraphQL Federation is a powerful tool, but it hasn't yet been widely adopted. The advantages for huge organisations are clear - but what about smaller teams? I've written about our two-pizza team's experience of using GraphQL Federation in production at https://lnkd.in/e64UHr32

17

Moving beyond the "Vibe Check" in Software Engineering: Forget about Vibe Coding—the real shift is toward Agentic Engineering! I just finished the latest Lex Fridman podcast with 🦄 Peter Steinberger, the creator of OpenClaw. If you’re in the software space, this is a must-watch. We’re moving past simple prompt-and-pray workflows into a more sophisticated era of human-agent collaboration. My three biggest takeaways: - Domain Expertise is still King: You still need to know exactly how your system works. Agents don't replace architectural knowledge; they amplify it. - The "Conversation" is the Code: Don't just give orders. Engage in a dialogue. Helping the agent understand the why leads to significantly better how. - Wisdom over Syntax: Beyond the tech, Peter shares some grounded wisdom on the evolution of our industry that is incredibly refreshing. The tools are changing, but the engineering principles remain the same. Highly recommend giving this a listen! #AgenticEngineering #AI #OpenClaw

9

2 Comments