Musings on IT and programming

Ever experienced what Simon Wardley brilliantly describes in his talk on Wardley Mapping? I've lived through it myself. My journey began with a prompt to solve a problem using a CLI tool. AI suggested a wrapper which seemed promising. A few iterations later, we added a web UI and extra features missing from the original tool. I could've stopped there, but wanting to validate the system, I asked AI to generate test code. It tried but failed to run on my end. Hours of frustration followed as I pleaded with AI to simplify either the code or tests. It refused, claiming it would be too difficult, and we ended up in a circular conversation going nowhere. Completely frustrated, I started fresh with a crucial difference. My new prompt: "I want to do XYZ in the simplest manner and also need ABC, EFG capabilities. No code yet—let's explore solutions first." The result? AI suggested existing open-source tools I could connect to my environment. My head nearly exploded! This s...

There is no harder reality check that trying to use a mass marketed product you developed and finding it's hard edges for your particular necessities at a different point. Also it is really hard to get off your builder hat when it is not even in your turf to add those capabilites to the development roadmap of said product. It is impressive how many small and micro enterprises work with sub optimal solutions or the bare minimum functionallity and end up exporting information and doing the extra work on spreadsheets. It might look like small things but those are actual needs of a group of customers that are not being met; and I get the other side of the picture, there is no way that a product team can provide solutions for those needs while being constrained on resources and juggling with the needs of the high utilization volume users. This post I'm trying to be vague but for some examples here are somethings I'm currently missing. * In a cash payment to be able to record ret...

 What a wild ride these past few years have been! I've bounced from IC to staff engineer to principal and even director-level management where I was setting long-term strategy. Then came the layoff plot twist, which led me to launch two non-tech businesses before circling back to being an IC again—but this time in Operations and DevOps instead of programming. This shift has given me fresh perspective on what actually works and where effort gets wasted. The contrast between deep-pocketed organizations and bootstrapped startups is striking. One group is carefully carving out their niche while the other is in pure survival mode. What's fascinating (and frustrating) is seeing how much bureaucracy and inefficiency exists, especially for micro-enterprises. These smallest businesses often rely on pen-and-paper systems or basic spreadsheets—stuck with manual processes because there simply aren't tailored tools for their needs. It seems nobody's interested in serving the smalle...

TLDR: Bullet Journal rocks! Third is not a solely technical post.  Over almost 25 years of working in software development I've seen multiple practices, frameworks and processes for individuals and teams. Some implementations worked and others became so bureaucratic that they made for a very unhappy group of people. From free for all to things so complicated as rational unified processes (RUP) and Capability maturity model integrated (CMMi) passing through Personal Software Process (PSP) and Team Software Process (TSP). Some of those have their merits and can be used successfully in certain contexts but when it comes to really individual things they didn't quite help me a lot. They either required use of extra tools or even create new ones to be able to do what was required of the process in addition to do the value work which in turn adds to the inertia and extra effort.  The one practice that did really help me is Bullet Journaling (Ryder Carrol) precisely by being non techn...