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.

Today I want to talk about project planning and when it can occur. Typically, you want to do all your project planning that you can at the start of a project. Some things will always come up, but its best to always have as much planned as possible. For example, if you get sixty percent of the work identified and planned before staring a project, the remaining forty percent doesn’t just disappear.

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.

Today’s post is going to be a short one, I just renewed my AWS Solutions Architect - Associate certification and gained the AWS AI Practitioner certification and thought I would share some tips that helped me through both. Read the questions thoroughly: there’s usually 1-2 keywords that will make one answer stand out. Read the answers thoroughly: I’ve found that the pattern is usually 1 off the wall answer, 2 that are similar, and one that seems plausible, but still kind of out there.