Kolade Oluwadare | Software Engineer

Kotlin removes a whole category of mistake from your day. Nullability lives in the type system, so the compiler asks you about the empty case before a user finds it. Data classes mean equality behaves the way you assumed it did. Sealed types mean you get told when you forget a branch. What it cannot tell you is that two services disagree about what a completed order means, that a refund can go out before the charge has settled, or that a status field has quietly grown a sixth value nobody handles. Those bugs survive every language feature, because they live in the model rather than the syntax. The compiler checks that your code is consistent with itself. It has no opinion on whether your code is consistent with the money. So the best use of the time a better language gives you is the part it cannot help with. Write down the states a thing can be in and which transitions are legal. Decide who owns each piece of truth. Then let the type system hold that shape for you, which is where it genuinely earns its keep, rather than asking it to catch problems it was never looking for.

Netflix has added a single tenant mode to Titus, its container platform, where one task runs alone on its own right sized EC2 instance. Titus normally launches millions of containers a week across tens of thousands of instances, all sharing hosts, so this is a real change of position. The reasoning is the interesting part. Netflix says the usual tools for keeping noisy neighbours apart, cgroups, seccomp, the iocost controller and traffic shaping, cannot split shared hardware such as the last level cache and memory bandwidth. They tried predictive CPU pinning and eBPF detection, and their conclusion was that tuning a shared kernel narrows the gap without closing it. For a stateful streaming job, one badly behaved neighbour can mean minutes of checkpoint recovery, which is an outage rather than a slow afternoon. The honest part is the price they name out loud. A fresh instance needs tens of seconds to boot before the image is even pulled, so they recommend this for large, long running jobs that are sensitive to disruption, and not for small or bursty services. That is the shape of a good engineering decision: say what the isolation costs, then restrict it to the workloads worth paying for. Netflix is also clear that this is about performance between trusted internal teams, not about defending against hostile code.

Building Dalycs next to a full time job looks like: • ship small, ship often • talk to users every week, not every quarter • fix what people trip on before adding new things Nothing glamorous. Just consistent.

Worth remembering when you build for a Nigerian audience: the phone in your user's hand is probably not the phone on your desk. It has less memory, a battery a few years into its life, storage that is nearly full, and an operating system that will kill your background work without telling you. That changes real decisions. App size stops being a vanity metric when someone is paying for every megabyte of the download. Background sync stops being dependable when the system reclaims memory aggressively and your process is first to go, so anything you queue has to survive being killed and resumed later. Animations that feel smooth on a flagship can make a cheaper device feel broken, and the user does not conclude that their phone is slow. They conclude that your app is bad. None of this is exotic engineering. It is mostly choosing to test on the device your users actually have rather than the one work handed you, and treating memory, storage and battery as a budget you are spending rather than resources you are owed.

If you are building anything that moves money, one rule saves more pain than almost any other: never overwrite a balance. Store the events that changed it and work the balance out from them. A number sitting in a column tells you what somebody believed at the moment it was written, and nothing more. When a customer calls to ask why their balance is wrong, a single updated figure gives you nothing to reason with. A list of entries gives you the whole story, every credit and debit with a time and a reason attached, and the answer is usually visible in a minute. It also makes the harder question answerable. Not what the balance is, but how it came to be that. It does cost you something. Reads turn into sums, so you keep a cached balance for display and treat it as a convenience rather than the truth, which means it has to be rebuildable from the entries at any time. That tradeoff is almost always worth taking. Finance, support and auditors are all asking a history question, and a system that only stores the present cannot answer any of them. I build and write about AI, backend, fintech, cloud, mobile and modern software. Follow along and lets connect

Microsoft is retiring Azure Deployment Environments on 22 February 2027, and this one is unusual: there is no replacement product. The retirement guide tells teams to go back to writing Bicep or ARM templates directly. Microsoft Dev Box follows on 18 September 2028, pointed at Windows 365, and Microsoft's own FAQ says not to assume complete feature parity. The lesson is not really about Azure. Every platform product you adopt sits on top of primitives, and the primitives outlive the product. Templates, pipelines and the cloud API itself will still be there in 2027. The convenience layer wrapped around them might not be. So when you adopt a layer like this, the question worth asking on day one is what you would have to rebuild if it disappeared, and whether you could describe that work in an afternoon. If you cannot, you have not bought convenience. You have bought a migration that nobody has scheduled yet. What makes this one sting is that the guide lists alternatives and none of them is a product. Teams get the deployment part back with Bicep. The catalog, the approval rules and the self service portal are theirs to rebuild.

Dalycs is live on the App Store 🎉 It started as an app I needed for myself, for the days when the plan falls apart by noon. Now it's on iPhone, and it's free. Download it and tell me what you think 🙏 apps.apple.com/app/id6826941…

And Android too!!! 🤖🎉 Google Play just granted Dalycs production access. iPhone yesterday, Android next 💚 Play Store link dropping very soon. Get on iPhone now 👇 apps.apple.com/app/id6826941…

Guys!!! Dalycs is officially on the App Store 🎉🍎 Apple approved it yesterday evening and I've not stopped smiling since 😅 It's free on iPhone 👇 apps.apple.com/app/id6826941…

People keep asking if Dalycs is free. Yes. Daily planning, routines, goals, focus sessions and Dalycs AI are free to start. If you want more, Lite is ₦1,500 ($2.99) a month and Pro is ₦4,000 ($6.99). Dalycs: Habit & Goal Tracker. Free to start at app.mydalycs.com

The rule I gave Dalycs AI: it never changes your plan on its own. You ask in plain words, it shows every change, you tap Apply. That's it. Dalycs: Habit & Goal Tracker. Free to start at app.mydalycs.com

Shipped a lot in Dalycs these past weeks: • An AI planner that only changes what you approve • Routines with icons, any length • One sentence at night sorts tomorrow iPhone coming soon. Dalycs: Habit & Goal Tracker. Free to start at app.mydalycs.com

I received help!!!!!!!!!!

Use @mydalycs to turn intention into progress. Plan your day, build better routines, and make every day count. 💚 Check mydalycs.com

A dependency that fails cleanly is a problem you can handle. A dependency that goes slow is the one that takes the whole system with it, and it surprises people every time. The reason is simple arithmetic. Your service holds a limited number of workers, connections or threads. Each request occupies one for as long as it takes. If a dependency that normally answers in fifty milliseconds starts taking thirty seconds, every request waiting on it is still holding its slot. Within a minute you have nothing left to serve anyone, including people asking for things unrelated to the slow dependency. Nothing crashed. Everything is simply occupied. Had it failed outright, your code would have taken the error path, returned something sensible, and the rest of the system would have carried on. Partial slowness spreads in a way that clean failure does not. The fixes are unglamorous and they work. Set a timeout on every call that leaves your process, and make it shorter than feels polite. Decide how many requests may wait on a slow dependency at once, and refuse the rest quickly rather than queueing them forever. Stop calling something that keeps timing out, for a few seconds, so it can recover instead of being hammered while it struggles. And separate the pools, so the feature that depends on a flaky service cannot eat the capacity your login path needs. None of this makes the dependency faster. It keeps the damage inside one feature instead of letting it reach the front page. I build and write about AI, backend, fintech, cloud, mobile and modern software. Follow along and lets connect

If you have only built ordinary software, the strangest habit in payments is reconciliation. A payments team does not assume its own database is correct. Every day it takes its own record of what happened, takes the bank or processor's record of what happened, lines them up, and investigates every row where the two disagree. From outside this looks like distrust of your own engineering. It is really an admission about the world. A payment is an agreement between systems you do not control, and each of them can fail in the middle. A transfer can leave your side, arrive at the bank, and the response confirming it can be lost on the way back. Now your record says pending and theirs says successful, and nothing in your code is broken. Both systems behaved correctly and they still disagree. So the design question is not how to prevent that, because you cannot. It is how quickly you find out. Teams that do this well give every transaction a reference both sides can quote, keep a status that moves forward and never quietly backwards, and run the comparison often enough that a mismatch is hours old rather than a month old when a customer calls. The wider lesson applies well outside money. Any time your system depends on something you do not own, you have two versions of the truth and no referee. Deciding in advance how you will notice the difference is far cheaper than learning it from a complaint.