If you’ve been building software for more than a few years then you’ve seen things change.
Web frameworks, IDEs, code editors, architectural approaches come, go, and sometimes come back again.
And this creates pressure, real pressure, to ‘keep up’.
You feel that growing frustration that there’s surely a ‘better’ way, and if you could just find it, you’d be so much more productive.
But herein lies a trap (into which I’ve fallen many, many, times).
In seeking the perfect framework, or tool, it’s all too easy to get stuck; to spend time trying to use something only to throw it out in a frenzied moment of panic when it falls down at a crucial hurdle.
As each framework (tool, or approach) is consigned to the bin of broken dreams, you end up back at square one, trying different approaches, but now with added guilt that you’ve wasted hours, days or even weeks trying to make that last framework work.
The project remains stuck, stalled, and pressure grows (alongside your frustration).
So what’s the solution?
Here are three tactics I’ve found help to dig myself out of this rut:
- Accept that there is no perfect solution
- Do the simplest thing to make progress
- Double down on fundamentals
First we need to accept that there are no perfect frameworks, that frameworks bring their own challenges (learning curves, bugs, inconsistencies, tooling).
Keeping this in mind shifts us towards a better question; what are this framework’s trade-offs, and they acceptable for this project.
The next, crucial step is to make progress, by taking the simplest possible approach for the feature you’re building.
Nothing slays procrastination, self-doubt and frustration like making progress with a project.
Sometimes all it takes is a V1 of a feature or two to completely change how you feel about the thing you’re building.
The key is to ask yourself what the simplest version of this feature looks like.
For example, let’s say you’re building an application form with lots of complex requirements (validation, optional sections, conditional fields)?
What if you started with a really simple form, with a few inputs and a submit button, and tried building that first?
You’ll learn a lot about your framework of choice building ‘simple’ versions of your features, and the complexities can be layered in later.
Finally, in all of this, remember there are some fundamentals that remain the same, whichever framework you’re using.
These days these are things like building web applications using components. If you can learn how to compose a more complex UI from smaller components, how to take a design and quickly iterate a functional UI for it, you’ll have skills which transcend the current framework de jour.
Personally this year I aim to focus on refactoring. I know refactoring is key when striving for simpler, scalable and maintainable applications, but rarely know how to approach it in practice.
You will have your own fundamentals that you know you can double down on. Take a moment to think about what those are, maybe write them down as you think of them.
Any time you’re working on a project, consider whether you might have a few moments to brush up on those fundamentals.
After all, it’s these foundational building blocks that follow you from project to project, framework to framework.
It’s time to build up those foundations!