I was reading this article ’s section on “Function type as an interface” and thought this was a wild concept to see in any programming language. I created a different example here , that highlights the concept. Essentially, you create a type for a function signature, then add methods to that type. So a function….now has methods. Coming from any other language, this sounds absolutely insane. Hell even in go, this sounds insane when its first presented.

One of the core tenets of a good working engineering team is to limit the Work in Progress (WIP). This has been written about so many times, I could spend an entire article just documenting all the people who say this is the key to efficient flow, so lets assume that’s true. I was reading this article and was reminded of that once again. One of the tenets of this article is to create small, reversible changes.

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.