1 week ago
When my chainsaw gets too hot, I give it a rest and go off for a bit, then let it cool down before doing more work. After all, I don’t want the motor to overheat and then have to buy a whole new one and have it cost even more. Does the same apply to our AI interactions? Let AI go to town for a bit, but then put it on pause over lunch so it can cool down and come back at it? Or do we keep expanding infinitum so it is always online, all the time, consuming everything?
1 week ago
Last week I was scrolling through social media and found this cool video of a guy on a kayak, tons of camera gear, catching a fish, and cooking it on the kayak. Each time it got more elaborate with what he was cooking. Then my feed popped up with someone else doing it, with a different take on the trend; they were on a jetski, zipping around and doing the same thing. Then I saw more posts that flipped the trend a bit more, as each person had to take their crack at the trend. But in the end, there
2 weeks ago
Overload today? Not a bad problem; tomorrow you might not be. What is your “too much,” and someone else’s “too much” might be completely different, and as a result, we have different levels of what being overloaded is. It’s not good to have “Too Much To Do” all the time; that’s a sign you need help, and the team needs to grow. But in the short term, it’s a sign people trust your opinion and thoughts and want to see more from you. Don’t let that opportunity slip away.
3 weeks ago
There are some days when my role is to fill in gaps. We don’t have “X,” and no one knows “X”? Looks like I’m spending some time learning “X” today. I have zero complaints about filling gaps, because I think it’s where you can get the best opportunity to learn a new thing and figure out how it connects to everything else you do. It can seem stressful; it’s akin to someone dropping a stack of files on your desk – “Here, figure it out”. That’s okay, we need more of “Here, figure it out”.
3 weeks ago
LLMs keep learning, growing, and improving. But they are only as good as the scenarios that they are dropped into. For instance; A new code library that doesn’t log errors- great when it works, not great when it fails. Requirements that use “generic” nomenclature and not what everyone else uses, only good if you’re a senior dev. QA Test Cases that generate failure scenarios for tests which don’t apply to your stack? Add extra work. Diagrams that point to systems that don’t exist (but should), don’t give you the current state. If you’re not cleaning up and working with your
