I haven’t written a retroactive diary in awhile (ever since Mattie was born), so I figured I’d resurrect the process for the birth of my second daughter, Macie.

As a technology professional on the development side of the house, I regularly have to provide estimates for when my work will be done. This work includes writing code, packaging up a deliverable, writing documentation, or anything in between. Following the estimate delivery, there is a level of trust that exists between the technology delivery team and the project/account management team in that the estimate 1) will not be inflated by the technology team, and 2) will not be altered by the project/account management team.

Back in the day (high school and early college), I ran one of the state’s largest track and field databases. All of the entries were entirely crowd-sourced (before crowd-sourcing was a thing), and it was used pretty heavily.

It’s been around two years since my mother, Kathy, passed away after an extended battle with lung cancer. Last year, I posted what I missed about her. To start a new tradition, I’m going to tell her what she’s missed in the past year.

Some background: I run a couple of websites in Amazon Web Services (AWS). These include my photography website project, MorrisPhotos.com. This post is a quick overview of how I managed to save ~$55/month in AWS charges.

The Death March

In most development walks of life, any given software developer will run into a project known as a Death March. These projects have any number of problems, but the most typical ones are:

• Too much scope for the timeline
• Not enough resources for the scope
• Resources have the wrong skillset for the project

In my current job, I’m frequently asked to interview new candidates to join our development organization. One of the first questions that always gets asked, either by me or one of my colleagues, is “What level is this person interviewing for?” There really are only two answers for this question where I work: Developer or Senior Developer.

Precursor: I’ve been working with a significantly large legacy codebase for over three years now. Here are some tips, tricks, and general pointers to make sure you don’t make the same mistakes I’ve made with legacy code.

Some backstory before I go into the details here: I am a track and field coach. I run a website that displays track and field statistics throughout the state of Ohio. I am a lead software engineer for a large ticketing company. All of these add up to my current project: building a competitive product to Hy-Tek’s Meet Manager.

I’ve written and rewritten logging providers about 300 times in my career. It’s something I know how to do, I know how to extend, and I know how to hate it. Every time I write it, I hope for some great abstraction layer that will allow me to reuse this library across every future application. I inevitably fail at this.

Along comes The Solution To All My Problems.