It’s been quite a year! I wanted to make a quick recap of what I’ve done this year (outside of work): Service Atlas has been the big project of the year with: Creating new organization in Github and learning all that Learning Go for the backend Learning neo4j Learning to effectively vibe code the frontend Created an MCP server to connect to the API Learning Go concurrency by building a file parser Built Plandicoot, a private project for project resource allocation This blog (46/52 isn’t half bad) Renewed all my AWS Certifications Gained a new Python certification from O’Reilly I’ve been using daily.

The above trailer’s last line is “Now you’re thinking with portals…” and honestly I think that that mentality is what separates a good engineer from a mediocre one. Good engineers are of course naturally curious, but they have an innate ability to see around corners and make the impossible possible. Take the trailer, then relate it to your day to day life, you’re put in impossible tasks and sometimes in excruciating mental pain, yet somehow a good engineer will take that scenario and turn it into a win.

Today I want to write about Architectural Decision Records and why everyone should be writing them, all the time. If you’re like me, you looked at the repo link and thought “dang, that’s alot. And everyone has opinions on them.” And I think you’re absolutely correct, and therefore you’ve already put ritual and taboo around them that you’re also thinking you don’t need in your life. But hear me out, I think the concept of the ADR needs to be less formal, and more of an every day occurrence.

I’ve been working on an MCP server for my service atlas api. My original idea was to do this in Golang, but I gave up on that path. I wanted to talk a bit more about the why and the alternative in this post. Go vs Python? Golang offers a very robust library for MCP server development. A library I really, really wanted to take advantage of. But as I got past HelloWorld, I found a major problem: the library was really clunky to use.

I’ve had this list laying around and honestly I don’t know that its worth putting into paragraph form, so I present it here in its raw form Being staff + is about: lifting up engineers helping teams find their voice, giving them agency and ownership helping architect the right problem at the right time for the tough problems thinking strategically understanding value to the company being approachable and working well with junior to c-suite being a role model being a leader having courage to say the tough things acknowledging limitations documenting and mapping keeping everyone in the loop turning groups of people into high functioning teams knowing when its “good enough” knowing when it will stop being “good enough” This list will probably grow as I think of more things, so I’ll probably keep editing this list

Its officially time for a new .Net LTS Release , and with it comes C# 14, a new iteration with quite a few fancy new features. One such is covered in this video , which shows the use of extension methods. I wanted to share my initial reaction of this video. First of all, this doesn’t read like old school C# anymore. This reads like golang. Take the below example

No post for this week, though I do want to say I’m almost done with phase 3 of my service dependency api (CMDB lite) project! This phase has been mainly about cleanup with osme minor improvements. I’ve very excited about what’s next, namely learning to program an MCP server

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?