#Engineering
Engineering practice articles cover the craft of building and operating production software. Topics include refactoring strategies, code review culture, and the day-to-day engineering habits that compound into reliable, maintainable systems over time.
11 posts tagged with engineering. ← All posts
The first decision in any financial system, and the one people get wrong most often: never store money in a floating-point number.
Never store money in a float. Use integer minor units or fixed-scale decimals, round half-even, allocate so splits sum exactly, and treat currency and the FX rate you used as first-class, auditable data.
The full pipeline should run in CI with zero API keys and zero network. A deterministic classifier is the test double that makes an agentic system testable.
Put the seam at the router: same interface, a deterministic classifier for tests. The whole orchestration, routing, gateway, human-in-the-loop, and checkpointing, runs in CI with zero API keys and zero network.
Same interface, two implementations: cloud-backed stores when config exists, in-memory when it doesn't. The whole service boots with zero external dependencies.
Same store interface, two implementations: cloud-backed when config exists, in-memory when it doesn't. Don't let a subscription be a hard dependency for make test, it's the ports-and-adapters move teams skip under pressure.
How split knowledge, dual control, and a layered key hierarchy keep a working key from ever appearing in the clear.
Teaches how to run cryptographic key management for payments: HSM-backed key hierarchies (LMK/ZMK/ZPK), key ceremonies with split knowledge and dual control, rotation, and PIN-block translation.
Securing bank-to-bank and scheme connectivity with mutual TLS, detached JWS signatures for non-repudiation, and replay protection built from nonces and timestamps.
Teaches how to secure bank-to-bank and scheme connectivity: mutual TLS with certificate pinning/rotation, detached JWS/XML message signing for non-repudiation, and replay protection with nonces and timestamps.
I built memory, communication, security, governance, and evals from scratch first. Then I deleted most of it and used the Microsoft Agent Framework-native packages. Here is the audit table and what survived.
You can't apply AI to a system you don't understand — and the grid, for all its ubiquity, is genuinely unfamiliar territory for most engineers. It runs on physics that permit no delay and no buffer: electricity flows at the speed of light, can't be meaningfully stored at scale, and must be balanced instant by instant or the whole system destabilizes. Before exploring how AI helps, it's worth understanding how the grid actually works — because its physical constraints are exactly what make it such a demanding problem.
You can't apply AI to a system you don't understand — and the grid is unfamiliar territory for most engineers. It runs on physics that permit no delay and no buffer: electricity can't be meaningfully stored at scale and must be balanced instant by instant or the whole system destabilizes.
Product management, seen up close, is less glamorous and more valuable than its reputation suggests: a lot of talking to people, deciding what matters, and helping a team build the right thing — mostly through influence, not authority. This closing post steps back to the day-to-day reality of the role, the path into it (especially from engineering), and how product thinking makes any engineer more effective. Whether you become a PM, work with one, or found a company, understanding product management pays off — because building the right thing is the point of building anything.
Product management, seen up close, is less glamorous and more valuable than its reputation: a lot of talking to people, deciding what matters, and helping a team build the right thing — mostly through influence, not authority. The day-to-day reality, the path in from engineering, and how product thinking makes any engineer more effective.
A product is built by a collaboration, not a handoff. The most productive product teams run on a tight partnership between three roles — product, engineering, and design — each owning a distinct concern and none simply taking orders from another. When that collaboration works, products get built that are valuable, usable, and feasible; when it breaks down into a handoff or a hierarchy, everyone is frustrated and the product suffers. For engineers, understanding this collaboration is understanding how to work well with PMs and designers.
A product is built by a collaboration, not a handoff. The most productive product teams run on a tight partnership between three roles — product, engineering, and design — each owning a distinct concern and none simply taking orders from another. For engineers, understanding this is understanding how to work well with PMs.
Here is one of the most profound and underappreciated ideas in all of software engineering, and it comes from operations, not code: the structure of your software will end up mirroring the structure of your organization. This is Conway's law, and its implication is startling — if you want to change your architecture, you may need to change your org chart first. Organizational design isn't just an HR concern; for technical organizations, it's an architectural decision. How you organize people shapes what you build.
Here is one of the most profound ideas in software engineering, and it comes from operations, not code: the structure of your software will end up mirroring the structure of your organization. This is Conway's law, and its implication is startling — to change your architecture, you may need to change your org chart first.
An agent that doesn't declare a tier defaults to Prototype, not Production. The flag is the code; the culture is what enforces "new code is not production until someone says so."
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse all posts or explore related topics using the tag cloud above.