Something I’ve been more and more aware of lately is the tendency of engineers, good engineers, to over complicate the hell out of something. Is it a product of the time they were working? Or is it something else? Seeing engineers come out the other side of the age of monoliths, I wonder if this is a major contributing factor. It could be, old habits die hard. Before we had “the cloud”, you had to build your own queues, callers, etc.

Monday, 2025-10-20, was one hell of a day. The AWS outage started somewhere between the previous evening into the early morning. I was up at 4am trying to figure out how to get data out of Dynamodb. Then I spent the rest of the day babysitting services, desperately waiting for ENIs to become available. Supposedly the problem came from DNS records to DynamoDb. Honestly that seems very strange to me. Why would a rollback of DNS cause us to not have ENIs available?

I’ve been using Supabase lately for a new project and had the opportunity to work with postgres’s row level security (RLS). Its been interesting to say the least. I can see its usefulness, but it has some foot-gun properties that are kind of hard to get used to if you’ve never used it before. The Good Abstracts permissions down to the database layer Simplifies queries in the application layer Keeps users limited to only their data set The Bad Its really easy to forget to set up the proper policies Policies for complex relationships get complicated quickly Can cause really hard debug paths if you have an elevated login Conclusion So that seems like pretty significant cons, so is it worth it?

So lately I found a new pattern to increase my productivity. I work on APIs pretty extensively, and have adopted using Bruno to test with and store my test calls in my repo with the api. Since Bruno calls are basic text files, I found I can do the following: use a swagger page to collect curls for all the calls I make for setup and testing feed those calls into copilot, telling it to use them to set up the pre and post script runs then tell copilot what specifically to test for and have it create a bruno file for that call (or update one that has the bare bones for the call I’m making) additionally, I will tell copilot to update the docs section with how to manually run the test in case QA wants to review manually I’ve found that this process greatly speeds up how I test and has completely replaced integration tests in some instances.

This weeks post will be a bit of quick one, not too much going on. One thing of interest I’ve noted about myself is even successes in hard games (like SilkSong) aren’t as rewarding anymore. I play a few hours, got to and defeated Moorwing, and I haven’t even thought about it again. It was just “meh”. After that I picked up my secret project (which may stop being secret soon) and honestly I found that much more rewarding, even if AI was doing some of the heavy lifting.

What makes a team more productive? There are many aspects to increasing productivity, but I believe one of the most important ones is keeping the team focused on one thing. Teams that can keep single project flow have much more success in moving that project along. You hear it time and again about single piece flow and how that maximizes productivity, but how does that look practically? Business usually can’t afford to work on just one thing, so teams don’t get afforded that luxury either.

Been a long couple of weeks on a tight deadline project, and I’m just now having time to begin thinking about moving to the projects I was supposed to be working on. This work has been pretty exclusively in C#, with some minor reviews of JavaScript. This swapping languages, coupled with a new want to write more in Go, has me wanting to writing about languages and changing them frequently.

Obsidian released bases this week and honestly, I don’t know how I feel about it yet. If you’ve read my previous articles, you know I’m a huge Obsidian fan and use multiple vaults for various journals, posts, etc. I thought I would take this week to talk about bases and my initial thoughts. The Good The bases plugin provides native support for filtering and aggregating data on your files. It allows you to filter based on file names, folders, tags, and custom properties (there are more filter options as well).

I recently read the article Writing Code is not Software Engineering , which I highly recommend reading. I thought I would take this weeks article to share my personal experiences with it. First and foremost, context is king. If you don’t know why you’re writing something, you’re going to get the how wrong because you never had a good target in the first place. The language and methods don’t really matter.

The two work types that I see are odds more often than not are the business projects and the internal projects. Why can’t we easily integrate these two types of projects into a single roadmap? What I think is the problem is product and engineering see two very different views of the code. Most people think code is a stable, structured thing, like steel in a skyscraper. But that’s where everyone is wrong.