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’m not really sure where I’m going with this post, hopefully we’ll end up somewhere coherent by the end. I was thinking about skipping this week and give myself some more time for either more GO programming or next weeks post (more geese incoming!), but then the discipline part of my brain kicked in and said “you’ve made it 15 weeks, you will keep going”. This made me start thinking about how long it takes to make a habit and how discipline keeps you doing the things you may not want to in the short term, but will be beneficial in the long term.

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.

What is being approachable, and how is it a Staff+ Skill?

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.

In my second in the Staff Engineer Series , I want to write about a skill that I had been practicing unconsciously, but didn’t expect to make it a core part of my job: making my own work. Making my own work started small with research on my own, then progressed to creating an initiative on standardizing our database source control as Liquibase, automating manual processes, and helping define our IaC stack.

I think over the next month I’m going to start a series on what skills help make a staff engineer. Staff engineers responsibilities extend way beyond just coding expertise. Staff engineers rely heavily on many various soft skills; today we’ll be discussing translating. What do I mean by translating? It can have a couple of different meanings, depending on the context. First we’ll start with the simplest, in writing. Staff engineers are often tasked with breaking down product’s vision into an actionable plan.

Sometimes a small project is exactly what a developer needs. I think this is especially true after finishing a longer project. Short projects may not have the same impacts as large, multi team projects, but they have their place none the less. Smaller projects allow you to focus on something different, something new. Even if its a dumpster fire that everyone wants to ignore, its not the dumpster fire you’ve been fighting the past six months.