Articles for category: Delivery

Two Approaches to Blisters

You can bandage them up and keep going; yes, they will irritate and eventually pop. You can wait for them to go away, however long that takes. One is pragmatic and pushes you back at the worry of further injury, one pushes the envelope, lets the skin heal over and harden. Whatever approach you take is up to you, but clearly, you need new shoes to prevent it from happening again.

Footwork and Repetition

If you want to be good at soccer in the long run, you need strong footwork. Over time, we all get slower; we can try to slow it down or improve our stamina, but we all get slower. It’s just life. But footwork, footwork isn’t built on speed, it’s built on control, repetition, and most importantly, being able to handle the ball without looking at it. Repetition and being able to handle the ball without looking at it – seems like an important skill for a job when speed fails.

Making Up Answers

I ran into this scenario with Claude a few weeks ago. I was trying to figure out what an API can and cannot do. In an effort to make me happy, it made up a method for an API that did not exist. You’re right to question it — I fabricated that endpoint. It doesn’t exist in the official Power Platform API. Sorry about that. And then it kept going on, until I went back to the piece about it, fabricating an endpoint. Yes, I did — and I shouldn’t have. I presented that URL with confidence as if it

Don’t Feel Guilty about Design

In anything, good design is what sets good work apart from itself. Did you take the time to learn the underlying structure? Did you look at the technology and libraries that were being used? Did you think about the usage scenarios that would be applied by your team? Did you run through multiple problems in your head to resolve them? In the early stages, we complain about design taking too long; it’s not a sexy billable either, but when the product ships, when it runs without falling over. Yeah, that’s good design, so make sure you give it the focus

Counting Token Shock

Counting Lines of Code became… Counting Number of Unit Tests Generated became… Generating the number of class files became… Ensuring we had everything commented, which became… An unlimited number of TODOs in our code. And now we are counting Tokens of usage and surprise, surprise – we are gamifying and overusing them so that our metrics look inflated. I AM SHOCKED!!!! Yes, your team should be using AI. But if you’re measuring your team by their token consumption, it’s a lazy, easy metric. Instead, why not look at; As with development metrics of the past, the first metric identified is