austinshea

just explain your pattern.

what you are saying means you have a leaky chain of custody and are fine with that,

but you can show why i'm wrong.

This is so nice, and very generous.

I would like to be able to self host this, and, while this is absolutely not the best way for you to monetize this thing, if you put it up for some sub 100 dollar price, and I felt like I was getting a lifetime pass... I would do it.

It isn’t, but it’s not possible to get paid like that if your work isn’t a necessary component in the work that earns the company a lucrative payday.

A lot of people, who are on their way to doing truly professional work, have this epiphany.

The place you need to get to is understanding that you are being asked to ensure a problem is solved.

You’re only causing a larger problem by “solving” issues without both becoming an SME and ensuring that knowledge can be held by the organization, at all levels that the problem affects (onboarding, staff, project management, security, finance, auditors, c-suite.)

I agree with everything you're saying, and I think other archaeologists feel the same.

My opinionated take is: I wouldn't want to use this space for the information that this tool could provide, and rather leave it as the truth.

The truth is that it was committed without a meaningful message, and now I might recognize a chain of message-less commits, representing a moment in time where the authors were trying to figure out where they wanted to end up.

If the tool is producing this info simply by reading the diffs in the code, why not just use it when you need it, to help explain what you're digging through, instead of changing the commit history?

Either way, the critical detail is: People should get that detail out before the rice has been cooked, and that's what I do for myself, in my own private repos, and when others do that for future archaeologists, we all benefit.

I love it. A bit guided of assistance can really make all the difference.

It's not absurd, and it's also not gatekeeping.

Why do you want a summary of the changes? The bulk of the information in a commit is the diff itself.

The information that is not contained in the diff is the author's intent, and that's what the space is meant to contain.

I'm not convinced you actually believe that a summary is valuable because this whole comment is coming from a very defensive place.

The value of the space is the ability to glean the commit author's thoughts, at the time they committed it.

This is extremely dissimilar to the thoughts of the author.

The value of what this emits is already handled by evaluating the diffs in the per-file history.

It's not good to throw this sort of thing over the fence, and justifying it by considering it to be wasteful of your precious time doesn't change that.

It's better to leave it blank, but a tool like this looks perfect to help someone avoid scrutiny, while simultaneously avoiding providing a tiny depiction of what they were thinking when they committed the change, at the expense of injecting vast amounts of noise.

Some stuff is going to be provider-specific.

Let me explain why we’re not talking about an 80/20 split.

There’s no reason to treat something like a route53 record, or security group rule, in the same way that you treat the creation of IAM Policies/Roles and their associated attachments.

If you create a common interface for your engineers/auditors, using real primitives like the idea of a firewall rule, you’ve made it easy for everyone to avoid learning the idiosyncrasies of each deployment target, and feel empowered to write their own merge requests, or review the intended state of a given deployment target.

If you need to do something provider-specific, make a provider-specific module.

Most work isn’t greenfield.

AWS can be used in a different, cost effective, way.

It can be used as a middle-ground capable of serving the existing business, while building towards a cloud agnostic future.

The good AWS services (s3, ec2, acm, ssm, r53, RDS, metadata, IAM, and E/A/NLBs) are actually good, even if they are a concern in terms of tracking their billing changes.

If you architect with these primitives, you are not beholden to any cloud provider, and can cut over traffic to a non AWS provider as soon as you’re done with your work.

Thanks for this article. It feels like a huge problem to discuss the nuance described here.

There will be people who will carelessly create unmaintainable software, and they might do it to bamboozle someone who is paying for the work that experienced people can deliver.

Others might fire the sorts of people who would do that sort of work, and try to survive without paying the going rate.

These things are objectively bad.

It is not bad to use these tools, or any others, to do the best work you can provide.