Maybe Your Particular Case Isn’t So Unique
Hey, my name is Juntao. I am a developer, a YouTuber and an author. I help people write better code. In this SubStack, I share tips and tricks I've learned along the way, including best practices for writing clean code, techniques for effective refactoring, and strategies for implementing TDD in your projects.
I'll also share some of my favourite productivity tips for staying organized and efficient so that you can be your best developer.
Whether the discussion revolves around JavaScript design patterns, continuous delivery, hourly production releases, or Test-Driven Development (TDD), there are two types of people. Some are eager to delve in, experiment, and overcome obstacles. On the opposite end, some argue that these approaches won't apply to their "unique" challenges. While special cases do exist, often, this resistance is more an excuse to avoid the discomfort of change.
"Wise people embrace the path when they hear of it;
The average are torn between belief and doubt;
And the foolish laugh outright.
For if it were not for laughter, it would not be the Dao."
— Tao Te Ching, Chapter 41
Too often, I hear comments like, "That makes sense in theory, but it won't work for my project," or "Your techniques look great, but they can't be applied to a real-world codebase." when I teach TDD or refactoring into someone. While it's true that instructional examples are often simplified for teaching purposes, this doesn't negate their applicability to more complex systems. I mean, these techniques work fine in different types of projects, small and large, simple and complicated, although you need to put more effort into complicated projects for a longer time to see some good results.
Take boxing as an analogy. It consists of basic moves—jab, crosse, uppercut, and hook. Footwork involves moving forward, backward, left, right, and pivoting. You'll also learn to slip and duck. These foundational techniques are all you need to start a boxing career. When you see masters like Mike Tyson, Floyd Mayweather, or Manny Pacquiao in action, they're not doing anything drastically different; they're executing these basic moves more swiftly, accurately, and timely.
Similarly, refactoring relies on fundamental techniques—renaming variables, extracting functions, moving functions, and altering declarations. These "basic moves" comprise the majority of substantial changes in any real-world project. While additional techniques may be specific to particular languages or frameworks, the core principles remain the same.
Same thing as TDD. You do tasking, break requirements into smaller chunks and iterate. Once you have a task list (it doesn’t have to be perfect first), you can run your Red-Green-Refactor loop.
The bottom line is that no magic bullets will instantly resolve your “unique” challenges. However, you will likely find a viable solution by analysing your situation and adapting general techniques. So the next time you're tempted to dismiss a technique as irrelevant to your "special case," consider giving it a try—you might be surprised your case isn’t so particular.