Originally this blog was built from a Pelican boilerplate. Why? No clue. I must have been looking for something free and fast that would plug right into the rest of my work. It does let me generate a blog site from markdown formatted post files which is an excellent feature I enjoy and want to keep. Coming back to this blog, I wanted to start making modifications to it, but everything about how it was built was buried in imported libraries. When I felt blocked on modifying the site, I decided to rewrite it because I'm an adult who can do what I want.

Windows would not let me fully remove Copilot, Office/365, or OneDrive. These services should be optional, and their behavior offended me. My focus kept being lost as I could never stop random window focus changes as Copilot tries to advertise itself to me, and 365 download browser tabs never stop opening.

A team of engineers is making a new service. One of them submits a peer review for a new web UI, just some boilerplate React to get things started. A few weeks later most of the team has touched the UI, and it is still rough around the edges, but it works fine when anyone on the team uses it. That is until one person on the team notices something off. Maybe some buttons are unlabeled vague icons, a popup menu requires high dexterity to navigate, or the site cannot be navigated via keyboard. This engineer may be quietly hiding their own disability that is now making it nearly impossible for them to use their own team's UI. So they create a backlog task to make the UI easier to use, and raise the issue to whoever is managing this project.

After having experienced vastly different office cultures in my career, I want to write out some of my thoughts on the impacts different aspects of office culture have on the productivity of engineers and how we work and collaborate.

AWS culture is highly explicit, that is written out, rather than unwritten rules. Everything is broken up neatly into Leadership Principles that are publicly available. I will go over all of those one at a time, including my perceptions of how I saw them reflected, used well, and used poorly, if not outright abused. Since the culture is written this way, I need to explain it this way.

I have been focused on Site Reliability Engineering (SRE) for the past few years while I have been in EBS. Previously, I was involved in full-stack web developing and architecting web-based services, but I had precious little understanding of this area. Startups building new services probably won’t find a need to invest heavily in monitoring until they have scaled. Established verticals might have little to no SRE because their SLAs may be too loose to warrant significant effort to defend. EBS is a different beast. This service needs to be available continuously for years on end with no downtime, not even from deployments, hardware failures, or network outages. We also need to get the tail of latency down to the point where we are tracking several nines worth of I/O latency outliers (e.g. having more than 99.9999% of I/O occur in less than 100ms is referred to as 100ms outliers above six-nines).

I have dealt with impostor syndrome quite a bit over my career. I have seen other engineers struggle with impostor syndrome. I have also seen engineers who were actually impostors who did not last long in their roles. I no longer have impostor syndrome and am embracing my success in the tech industry. These are the key learnings I came out of this experience with.

I recently took some time to create a small web application that I ended up calling Svadilfari. This was a project I worked on alone on some weekends around my full-time job. This project is a good example of how I have developed my process of developing personal projects alone. The way I tackled this project was informed by my experiences and failures over the years. I want to go over how I came up with the idea for this project, planned it out and built it. The most important part of this is how and why I made the decisions I did.

Misconceptions about how software engineers create value cause people to believe the darndest things. For instance, the public seems to believe machine learning will reduce the value and demand for software engineers, while competent software engineers seem to view machine learning as a new tool that makes them even more productive and versatile. Part of this is that people believe the actual writing of code to be a large part of the value of software engineers. I would argue that there are people who just write code for a living, but they are generally paid poorly and are not doing the same work as the new labor aristocracy that tech giants have formed.

Full stack web development can be daunting to get into until you reach the point where your development environment starts to feel like home. Docker has been the single most important tool for me to get to that point. Whenever I want to create a project that involves a web server and a database, I start with a Dockerfile that lets me spin up a test environment on the fly on my own desktop.