"Observability vs Testing: Why Both Matter for Quality Software"

There’s nothing more permanent than a temporary feature. We all know how it goes: You create a route “just for testing.” You add a flag “only until the next release.” You push a quick fix “so the client can see it today.” Six months later — no one remembers why it’s there, but touching it feels dangerous. That taught me something: in software, temporary usually means permanent with bad documentation. If it’s meant to be temporary, document it. If it’s meant to be permanent, build it properly.

Claude Code: Skills vs Slash Commands vs Subagents — Which one to use? In short: ➡️ Slash Commands = Quick actions ➡️ Skills = Knowledge & workflows ➡️ Subagents = Independent specialists TL;DR: 🧩 Skills: Teach Claude a reusable capability or workflow. Skills are loaded automatically and applied on demand. Example: Describe how to start and use your application, including setup scripts for mocks of external services. 🔁 Slash Commands: Reuse prompts for repetitive tasks. Think keyboard shortcuts for Claude. Example: Define a /review command that represents your individual prompt for reviewing all uncommitted changes. 🧠 Subagents: Delegate specific work to subagents which use their own context window, system prompts, and tools. Example: Set up a dedicated subagent for research. It doesn't need to change code, but give it a good tool for web search like Perplexity's MCP.

We all know that exceptions are inevitable. Without a proper strategy, unhandled errors can break user experience, expose sensitive data, and make debugging a nightmare. That’s where Global Exception Handling in ASP .NET Core comes in. The IExceptionHandler interface makes centralized and consistent error handling super simple. It helps define custom logic for managing exceptions across the entire application, all in one place. The TryHandleAsync() method inside the interface decides whether an exception has been handled. It returns a boolean, providing complete control over which exceptions the global handler processes. The custom IExceptionHandler integrates seamlessly with the built-in ExceptionHandlerMiddleware. Register it in the Program.cs using AddExceptionHandler() and activate it with UseExceptionHandler(). Use the ProblemDetails class to return meaningful and structured error responses. It helps produce standardized messages (RFC 7807 compliant) that improve clarity and maintain consistency in API responses. Why does it matter? 1. Keep your app stable when unexpected errors occur 2. Centralize exception management for simplicity 3. Customize how each exception is handled 4. Use ProblemDetails to return structured, user-friendly error details 5. Improve observability and logging Implementation in 4 steps: 1. Create a custom handler that implements IExceptionHandler 2. Define logic inside TryHandleAsync() 3. Register it in Program.cs with AddExceptionHandler() 4. Add middleware using UseExceptionHandler() With this setup, handle exceptions gracefully, keep users informed, and ease debugging. Do you use the Global Exception Handling approach? ——— ♻️ Repost and help spread knowledge freely. 👉 Enable the notifications & Follow Elliot One.

Statement Coverage Is Not Enough Every now and then, I see someone say they’ve stopped caring about coverage metrics or that “50% coverage is good enough” (or other arbitrary number). But I think a major point is being missed. Coverage isn’t just a number. It’s a way to understand how much of your software’s behavior you actually know. If your coverage is 50%, it doesn’t mean your tests are “half decent”. It means that half of your code has never been executed while testing: its logic and behavior are unknown. And if we take that idea one step further, in safety-critical applications, that’s unacceptable. This is where Modified Condition / Decision Coverage (MC/DC) comes in. It ensures that every individual condition within a decision can independently affect the outcome. It’s not just about hitting lines or branches, it’s about proving that each logical factor has influence and is verified on its own. Whenever you stack conditions, combine flags or write complex if statements, you’re dealing with logic that can hide https://lnkd.in/gd7sbzdG

# Self-Hosted Push Notifications Part-6 Self-Hosted Push Notifications Specification Part 6: Monitoring, Debugging & Troubleshooting Version: 1.0 Last Updated: October 2025 Prerequisites: Part 5: Advanced Features & Production Deployment Author: Bunty9 License: MIT \(Free to use and adapt\) Metrics & Monitoring Logging Best Practices Performance Profiling Health Checks Error Tracking Alerting Strategies Debugging Tools Common Issues & Solutions Incident Response Analytics & Reporting -- Overall delivery rate \(last 24 hours\) SELECT status, COUNT\(\*\) as count, ROUND\(COUNT\(\*\) \* 100.0 / SUM\(COUNT\(\*\)\) OVER \(\), 2\) as percentage FROM push\_notification\_logs WHERE sent\_at \> NOW\(\) - INTERVAL '24 hours' GROUP BY status; -- Expected result: -- status \| count \| percentage -- --------+-------+----------- -- sent \| 8,543 \| 95.23 -- failed \| 234 \| 2.61 -- expired \| 193 \| 2.16 Target: \>90% success rate -- Active subscriptions by user type SELECT CASE WHEN user\_id IS NOT NULL THEN 'users' WHEN admin\_i https://lnkd.in/gt7eBtkE

# Self-Hosted Push Notifications Part-6 Self-Hosted Push Notifications Specification Part 6: Monitoring, Debugging & Troubleshooting Version: 1.0 Last Updated: October 2025 Prerequisites: Part 5: Advanced Features & Production Deployment Author: Bunty9 License: MIT \(Free to use and adapt\) Metrics & Monitoring Logging Best Practices Performance Profiling Health Checks Error Tracking Alerting Strategies Debugging Tools Common Issues & Solutions Incident Response Analytics & Reporting -- Overall delivery rate \(last 24 hours\) SELECT status, COUNT\(\*\) as count, ROUND\(COUNT\(\*\) \* 100.0 / SUM\(COUNT\(\*\)\) OVER \(\), 2\) as percentage FROM push\_notification\_logs WHERE sent\_at \> NOW\(\) - INTERVAL '24 hours' GROUP BY status; -- Expected result: -- status \| count \| percentage -- --------+-------+----------- -- sent \| 8,543 \| 95.23 -- failed \| 234 \| 2.61 -- expired \| 193 \| 2.16 Target: \>90% success rate -- Active subscriptions by user type SELECT CASE WHEN user\_id IS NOT NULL THEN 'users' WHEN admin\_i https://lnkd.in/gt7eBtkE

Fr. 50'000 per hour lost due to a simple software update. 4 prevention measures to apply (before it hits).   This situation is more common than you’d think. A customer just learned a critical Python application crashed. So what? Their production line stopped. Fr. 50'000 per hour flushing away.   The developer who built it? Gone for 3 years. Documentation? What documentation. Backup plan? Zero.   The hidden damage goes deeper: → Delays ripple through customer orders. → Fear of touching "working" systems. → Emergency fixes at 3x normal cost. Critical applications may run quietly for years. Then one day, they don't!   Here are 4 prevention measures to apply:   1. Risk assessment → Identify critical applications in production. → Name single points and persons of failure.   2. Documentation → Document applications and their owners. → Take note of decision logic, not just code! 3. Diversify knowledge (like money!) → Spread knowledge across teams. → Create ''user manuals'' (use videos).   4. Approach modernization step by step → Prioritize applications by business impact. → Modernize incrementally, test extensively.   Prevention beats panic every time. Agree or disagree? 👇   📷: Cudos to xkcd.com for the visual.

Do you know what makes an application run stably? A key element is unit testing, which forms the foundation of our work on the code. Why is it so important? ✅ It allows us to detect errors at an early stage, which minimizes the cost of future fixes. ✅ It guarantees that your product works flawlessly, much like a well-built house. We use tools that automate testing, which lets us focus on delivering business value. This makes the software solid and ready for development. Would you like to learn more about our methods? Let us know!

Make just saved me hours of pointless debugging time by adding this small feature. They quietly added a new feature: "Run with existing data." If you’ve ever built scenarios in Make, you know the pain. You tweak something small, a filter, a mapping, a module, and now you have to: - Go back to your source app - Manually trigger the webhook again - Wait for the data to come through - Then finally, run your scenario All that just to test one change. Now you can simply re-run your scenario using data from a previous run. - Pick a past execution, hit run, done. - Same data, no new webhook, no wasted time. Perfect for debugging, iterating, or checking fixes without rebuilding test payloads. Maybe there was a workaround before. If so, I missed it. But this update makes building in Make feel 10x smoother. Small feature. Massive quality-of-life upgrade.

The Claude Agent SDK is an insanely low effort way to build pretty impressive agents Especially because most non-technical people have never experienced Claude Code. Most "roll-your-own" agents I've seen introduce complexity that's brittle under permissions, tool governance, and session state. Even when executed super well you end-up rebuilding a lot of wrappers for context management, tool selection logic etc. If you're building your company around your agent(s) this level of control is worth it. Most people are just adding agents to existing products (for better or worse). The SDK is opinionated though and lends itself towards technical workflows: - Default tools: Read, Write, Bash, Grep, Glob - MCP via @tool + create_sdk_mcp_server() - Hooks: PreToolUse/PostToolUse/UserPromptSubmit - Subagents with AgentDefinition I have a feeling many teams can ditch a lot of bespoke stuff and still ship highly specialised agents. Claude Code is a very competitive baseline.