From 0c5a9c7e4a86bda1a02fc7db5c6f6d871ce43e4a Mon Sep 17 00:00:00 2001 From: Corey Alexander Date: Wed, 20 Mar 2024 10:17:31 -0400 Subject: [PATCH 1/2] Draft of Make the Change Easy post --- blog/make-the-change-easy/index.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 blog/make-the-change-easy/index.md diff --git a/blog/make-the-change-easy/index.md b/blog/make-the-change-easy/index.md new file mode 100644 index 0000000..4661ab7 --- /dev/null +++ b/blog/make-the-change-easy/index.md @@ -0,0 +1,23 @@ +--- + +title: Make the Change Easy, Then Make the Easy Change +subtitle: Refactoring +author: Corey Alexander +date: 2018-01-15 + +--- + +A manta I’ve repeated for a while in my software career has been “Make the Change Easy, Then make the Easy Change”. + +This phrase is about adding new features or options to your code, but what it really gets at is the constant need to refactor your code to make them amendable to changes. + +When you go to add a new feature to your codebase, you are often faced with a decision: +- Hack in the needed functionality to the existing structure +- Refactor some stuff to make the new feature fit nicely + +Me and this mantra are advocating for the second option here. And that’s not to say that there aren’t times when the first “hacky” option is the right choice. But more often than not doing one hacky thing is a slippery slope to continuing to hack in new features, since each time you are in those code paths they are worse than the time before. + +By refactoring BEFORE you add a new feature your codebase is getting cleaner and cleaner as you go! As opposed to creating more tech debt with each PR, you can actually clean up your codebase as you go! This will pay for itself in the long run, AND has the benefit of making the work more “predictable”. In a clean, well organized code base there are less chances of running into something unexpected that drastically shifts the timelines for a project. +In a messy codebase it’s common to find issues buried, or things that take longer to untangle than expected. + +Not only does cleaning up the codebase allow you to be more productive, it also helps me more predictable! And predictability is sometimes even more important than raw speed. Something being finished a day or two earlier is often not a deal breaker, but missing an agreed upon deadline because something unexpected came up can cause issues for the organization. From 8b4a7c19ab55a17afbc50869cb0e1e05eea94972 Mon Sep 17 00:00:00 2001 From: Corey Alexander Date: Wed, 20 Mar 2024 10:18:32 -0400 Subject: [PATCH 2/2] Correct the date --- blog/make-the-change-easy/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/make-the-change-easy/index.md b/blog/make-the-change-easy/index.md index 4661ab7..a4e5768 100644 --- a/blog/make-the-change-easy/index.md +++ b/blog/make-the-change-easy/index.md @@ -3,7 +3,7 @@ title: Make the Change Easy, Then Make the Easy Change subtitle: Refactoring author: Corey Alexander -date: 2018-01-15 +date: 2024-03-20 ---