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.

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.

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.

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.