Software Craft
-
Dynamic Alerting in Observability 2.0: Responding to Ever-Changing Systems
Static thresholds cause alert fatigue when they are tight and missed incidents when they are loose. Dynamic alerting adapts as the behavior of the system changes. Part of my observability series.
Software Craft · 3 min -
The Role of End-to-End Visibility in Observability 2.0
A request crosses many services before it fails. End-to-end visibility shows the whole path, from the interface to the infrastructure, so a team can find the bottleneck. Part of my observability series.
Software Craft · 2 min -
Observability-Driven Development: Aligning Monitoring and Software Development
Observability works best when it is designed in from the start. Build the logs, instrumentation, and monitoring hooks with the feature, and use that data to decide what to build next. Part of my observability series.
Software Craft · 2 min -
Embracing Context: The Power of Correlation in Observability 2.0
Metrics, logs, and traces say little alone. Correlation links them with events, configuration changes, and deployments, so a team finds the root cause faster. Part of my observability series.
Software Craft · 3 min -
The Pillars of Observability 2.0: Metrics, Logs, and Traces
Metrics show the health of a system. Logs record what happened. Traces show which component is responsible. Together they give a team one view. Part of my observability series.
Software Craft · 3 min -
From Observability 1.0 to 2.0: Why the Shift is Essential
Dive into the three pillars of observability 2.0 – metrics, logs, and traces – and understand their significance in enabling a comprehensive monitoring strategy.
Software Craft · 3 min -
The Dawn of Observability 1.0
Observability started in control theory: know the internal state of a system from its outputs. The first generation gave teams metrics, logs, and alerts, and then alert fatigue. This is where the series starts.
Software Craft · 2 min -
Always Be Cap Deploying (ABCD)
A fast startup cannot live on maintenance windows. My team deploys several times a day and can fix, change, and break production in minutes. It takes decoupled services, many tests, and serious code review.
Software Craft · 1 min -
Modules are not for Readability
A module is for shared code. If you move methods into one only because the class got long, you add indirection and confuse everyone.
Software Craft · 1 min -
Fix It Later
“Fix it later” is what is wrong with your software project. Doing the hard, tedious work now is the job. It is why people trust a senior developer to lead.
Software Craft · 2 min