mike.mainguy

Strategy or Tactics? A Quick Gut-Check for Busy Builders Most teams move fast, talk louder than their calendars, and badge every decision as “strategic.” Speed feels good, and “strategy” sounds grown-up. The result is a blur of “initiatives” that last a quarter, retire quietly, and leave a litter of half-finished dashboards in their wake. After a few cycles you can’t tell whether you’re steering a ship or surfing debris. Getting clear on the difference matters because strategy is what lets you throw work away without losing your way . Tactics are the work. When you mix them up, short-term moves masquerade as destiny, and every pivot feels like starting over. What Real Strategy Looks Like Time horizon: Strategy: 12-36 months (or longer); Tactic: Days to quarters Purpose: Strategy defines the game you’re trying to win and how you’ll win it; Tactic executes a play given the current score Stability: Strategy endures market bumps and leadership changes; Tactic evolves or...

Was taking a peek at how to do this and I took a stab. Checked out gitlab project, fired up copilot and then (after a few iterations) hit upon this prompt: create a yaml file in openapi3 format that describes the methods and signatures of the contollers/admin/applications_controller controller assumes host are prod.myapi.com and stagin.myapi.com that host the api add detailed descriptions in the summaryfields that explain edge cases and any important side effects. Include list of tables accessed by api endpoints in the description. Format list of tables like the following (tables => {table 1}, {table 2}). Don't include character ':' in summaries, titles, or descriptions and what I got was openapi: 3.0.0 info: title: Dashboard API (Accesses various resources) version: 1.0.0 servers: - url: https://prod.myapi.com description: Production server - url: https://staging.myapi.com description: Staging server paths: /dashboard/appli...

I'm starting a new video series called The User Experience . Subscribe and comment to help guide the topics. Aside from prepared content, I will be hosting interactive experience to discuss and debate topics around customer centricity, user experience, and technology.

I've been working quite extensively on a webxr side project. Originally it was built with a-frame / threejs. You can take a look at it here at Immersive Idea . Recently I relized I was "fighting the framework" more than I was "getting things done". Originally, I chose a-frame because it was essentially a "no code" (well just html markup) way to build scenes. Additionally it's ECS framework was very well documented and easy to use. In an effort to broaden my perspective I started looking at alternatives (Unity with OpenXr, Babylonjs) as I was struggling to keep the pieces working together. This is my (slightly long) recap of my observations. A-Frame A-frame is wonderful...it is well documented, easy to use, and the community is super friendly and helpful. If I simplly wanted to render scenes in webxr with minimal ability to manipulate the environment, I wouldn't even think twice about using it.... Heck I still use it for quick m...

The MACH Alliance is a consortium of ISVs and SIs that advocate for a particular approach when building/integrating modern platforms. One gap/misunderstanding I keep bumping into is the intent behind MACH. In general, it's a technosophical approach to how PLATFORMS are build, run, deployed, marketed, not really well suited for large organizations who are simply trying to USE these platforms. Therefor I propose a "MACH TEN" Addendum TEN is an acronym that adds some context to adopting MACH platforms to use in your organization. These are high level recommendations I enccourage folks to take into consideration before jumping under the bandwagon. :p Transparent Pricing and contracts are computable, if special terms are negotiated, that's OK, but I shouldn't have to tell you my budget before you tell me how much you cost How I integrate/use your platform is easy to find, I don't need special training, I can just RTFM and begin using your system ...

Seymore Cray was famously quoted as asking: "If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?". While he was referring to the advantage of using a single processor solution over a massively parallel solution (which I happen to think he was wrong about) I'll steal this question to use in another context. Namely, when building teams to around technical solutions, you will almost always get a better solution if you use a limited number of smart, motivated, and experienced technical resources over a large number of folks who are inferior in one or more of those dimensions. In that regard, I think solving technical problems is a lot like plowing a field... it's actually difficult work that cannot be scaled by adding more low power resources. The problem isn't a scaling issue, it's a complexity issue. Controlling two strong ox and focusing their effort is a lot easier than trying to herd 1024 chickens. If you've ...