Not posting anything of interest this week. Most of my energy is going to designing a new project I’ll quickly note that I’m in that weird spot between projects. The go parsing experiments project is done, with pretty good results given my limited knowledge of go. Hopefully this pattern can be helpful to someone in the future. The space between projects is weird to me, and I don’t 100% like it.

Synopsis Content I’ve been using Bruno for about six months now, and I’m really enjoying it. I wanted to write a few examples of why its better than Postman (or others). I love the assertion mechanism. Assertions allow you to check basic properties of responses, such as status code, number of elements in the body, etc. Its much more convenient and approachable than a full javascript test. It has a massive amount of validators as well, making it very robust.

I’ve spent several months and two side projects working with Go, so I think its time to revisit this post . Overall I’ve come to really enjoy the language and think about it differently now. The good The concurrency system is extremely good and allows you to do things very quickly. It also allows you to not worry about if something is done, just when its done. I like that so much is built in.

I’m back after a little break last week (sorry I couldn’t think of anything good to write for last week) and I just had a thought about 20 minutes ago. I’m winging this entire post, more than I usually do, but here goes. What is a common problem that many companies have? I think its communication. Engineers don’t have an easy way to gather info about what’s going on in their company.

As code grows, it evolves; that is the natural progression of software. New features get added and older unused ones get removed. But what happens if they don’t? More often than not, this happens because “we might need this in the future!”. It ends up like a sheep that hasn’t been sheared in years, covered in matted wool that makes it three times the size it needs to be. Why do we do this to ourselves?

I messed up. Full stop. I had planned to write an article about basic coding. I had some idea in my mind, driven by rage, but I did the thing I call people out for: I didn’t write down enough context for myself to come back to that article. I wrote a few sentences, but I don’t know why I was writing it. So today I’m going to write about the importance of good note taking.

It feels kind of strange to write this one, and the following post, because it seems like it should be self explanatory. Today’s topic is on trust, and why its foundational to a team. More importantly, how teams may not recover if trust is broken. Effective teams need to be able to trust each other. We’ve all heard that multiple times, but why? That’s what I want to explore in this topic, not as some BS productivity coach, but as a guy trying to keep his team together.

I was recently asked to review a proof of concept for a new design. It was frankly, a mess. The core tenet of this design is that it tried to solve problems the team has or may encounter. Ever. Full stop. The day after I was asked to look into a legacy system, written by someone completely different. It suffers the exact same problem, but this one was “successfully executed” and now contains a confusing net of data that will frankly take some of the best minds a long time to decipher what’s going on.

I subscribe to the JetBrains all IDEs package. Recently, I learned that JetBrains released a new agentic AI named Junie via this video (which is strangely unlisted now). I thought I would give it a try since I’m technically already paying for it and I have to say I’m quite impressed. I installed it in GoLand to help me on a project I’m learning to use Go on and overall it seems much better than other AIs I’ve used.

I was working with ChatGPT to better understand Golang, and I asked it about inheritance with interfaces. It spit out the following gem. It made me think though, can you define aspects of languages as more loosey goosey than others? We’ll explore that in this post. What is loosey goosey? What do I mean by “loosey goosey” is the first question you’re probably thinking of. We’ll start with the first definition I thought of, which is simply “how strict is the data(and types) in a language…” A good example is JavaScript.