Your code is on fire 🔥 - 123dev #12
Posted on September 17, 2021 • 3 minutes • 470 words
Shipping code that doesn’t catch fire
Sometimes I push code into production that I’m certain will work well. Not because of test coverage or PR reviews, but usually just because the change was so simple and obvious there couldn’t possibly be another way to do it.
Many times those pushes work fine and my false confidence is reinforced to do it again another day. Often times I end up paying for an undocumented quick fix later. Sometimes those guaranteed-not-to-fail code pushes catch fire and roll production down a hill. Those are good learning experiences.
It’s hard for me to let something go unfinished. I have plenty of things in my life that aren’t finished but I almost always have an intention of finishing it some day.
Some projects don’t need to be finished to teach you something. When learning to code, learning a new library or API, or even trying to automate something it might feel like a waste of time if we don’t finish our goal.
In reality you’ll learn something that later can help you in ways you would never expect. Some will give you more insight into how to do something, but often times the best insight is how not to do something.
I wrote about how documents play a key role to our meetings and design process at Amazon. There has been lots of articles about the document types we use but I’ve never seen someone write about how we use them or benefits they have.
The Document Culture of Amazon — www.justingarrison.com A look at Amazon’s culture of writing and reading
I can’t imagine maintaining a single open source project for 23 years! But that’s exactly what has happened with
curl. This article has a ton of great facts about the project and some great hindsight about the last 23 years maintaining the project.
curl is 23 years old today | daniel.haxx.se — daniel.haxx.se curl’s official birthday was March 20, 1998. That was the day the first ever tarball was made available that could build a tool named curl. I put it together and I called it curl 4.0 since I kept the version numbering from the previous names I had used for the tool. Or rather, I bumped it up from 3.12 which was the last version I used under the previous name: urlget.
I had never heard of the strangler fig migration pattern even though this article is quite old — 2004. There are quite a few newer articles on how you can put this monolith application migration pattern into use but I thought it would be best to link to the original article instead.
bliki: StranglerFigApplication — martinfowler.com Inspired by the strangler figs in Australia, a strangler fig application gradually draws behavior out of its host legacy application