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 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.

I’ve been watching Learn Go in 3 Hours this week and I’ve decided to make this blog post my observations on the language so far. I’ll compare this in a month or two after I finish this service dependency api project. Initial Observations The language is very strict with its typing, but feels very loosey goosey with its control structures (a for loop without a condition or stop point, really?). It kind of makes sense that you don’t need structures like while, it just feels wrong Channels seem like they hold great promise switch cases in place of if/else blocks is fancy, but it feels like it was taken too far It could be really hard to switch back to something like Python or C# after a while in this language The fact you don’t have to expressly define what implements an interface is weird Overall I think the gif below sums up how I feel.

I didn’t get a chance to work on another Staff+ engineer post this week, so I thought I would share how I’ve been using generative AIs and my experience with them for this week. Recently I’ve had the chance to compare Amazon Q and Copilot. Both seem pretty good, but I’ve found that Q has different ideas of what is a security concern over Copilot. Both do a pretty decent job with overall for the simpler things I ask.

Do you ever look at a commit message and think “this is just awful”? I’m sure you have, especially when doing a code review. git commit -m "stuff" might work for personal projects or when you’re frustrated, but you should work towards a standard way of doing your commit messages. Different places have various standards, but one open source standard I’ve adopted is conventional commits . It’s taken several months to get into the habit of using conventional commits, but now that I’ve gotten used to it, I can’t imagine not using this commit style.

I’ve recently started programming more in Python, and wanted to document how the process of getting more experience in a new language is. One of the first things I’ve done is go being skimming books on Python. I’m currently reading through Think Python , and have picked many interesting tidbits of info on Python. While some may think it’s a waste of time to start at the beginning of a language, its not.