For years when working on projects, both personally and professionally, I’d cripple myself with semantics and best practices. It’s far too common in the development industry to feel bombarded with best practices and receive backlash from the community/workplace when all of those best practices are not your standard.
What I have come to learn from this is that, at the end of the day the most important aspect is that the goal is met and that it works. Sure if it’s using some slick framework to manage requests, it could be better. Sure if the database was completely abstracted to it’s own server, it’d be safer.
To unpack this, we could use a quick application like a todo list app. The main goal of a todo list app is to add tasks. Sure you could add fancy features on top of that, but in the end you’re still working with tasks and the ability to complete them.
In the past I’d run around in circles until completely giving up on the project. It would look something like this:
- Choose a backend framework
- Spend a long time deciding db structure
- Spend a long time figuring out a front end framework
- Look for features I’d like to include
- Change db structure because there’s a feature I may want to implement in the future
- Change front end assets, framework or add a new plugin
- Spend time figuring out if I want to actually sell this
- Look at domain names
- Figure out server costs
- Start some actual backend code
This list goes on for about 4-5 more bullets before the project lays dormant in my private repositories.
The most important bullet isn’t even on the list. “Create a form that submits a task to a database or some storage system” should have been first on that list. From there I’d have a functional todo app.
Of course this doesn’t mean do completely sloppy work, especially when it’s for someone else, but to be aware where you place your priorities and time.
At that point I can make plenty of other decisions, like if I want to keep this for myself or roll out an API and build an app, if I want to be fancy with current frameworks.
This mentality was hard to break but once I did I notice a dramatic increase in my output. As long as I could make it work and I wasn’t writing myself into a corner, I could run with it.
Tickets at work are marked completed a lot quicker, heck even blog posts were written. Now whenever I find myself working on something I look at how I can make it work, then I can always refactor and make it cleaner.