There is but one question you should repeatedly ask yourself as a developer to ensure you're on the right track.
As a developer, there is one question that stands above the rest. One question that will keep you on track. One question that will ensure you're doing what you should be doing.
It's important to make a habit of stopping what you're working on for a minute, taking a breath, and asking yourself why you are doing whatever it is you are doing. And if you're honest with yourself and answer the question truthfully, you may just find your focus shift slightly over time, in turn helping you make more strategic decisions.
When asking why I also like to change up the scope in which I ask. Sometimes I may stay really focused and ask myself something like, Why do I have 20 lines of code in a single method? Other times I check in on the bigger-ticket items. Why am I a developer? or Why do I write code in my free time.
Changing the scope can help keep the question (and its answer) fresh so you don't fatigue and quit the habit.
If having an interval helps you determine when to ask these questions, then use some sort of forced-schedule method -- set a timer and check in with yourself regularly. For small-scoped items, this can be once every couple hours. For bigger-ticket items, maybe you ask those questions daily or weekly.
I tend to go off the cuff and look more for abnormalities -- if something doesn't feel right to me, that's my cue to step back and check in with myself. Of course, it's healthy to do this even when everything feels balanced, as answers tend to to come a little more honestly in the good times.
The question is pretty easy -- look at what you're doing within an array of different scopes and ask yourself why you're doing those things. But what do you do with the answer?
I've found that some answers mean everything's good and there's nothing else to do. Those usually sound something like:
In other words, asking why can be fleshed out to set yourself up for one of these answers. You can phrase the question more like: Why are you doing that? Are you learning something, does it make financial sense, or does it make you happy?
Whether one of these answers is good enough is up to you and your current scenario. For example, when I'm doing work I'm getting paid for, the answer better always at least contain making financial sense (it can have the other ones, too). Otherwise, I shouldn't be doing it because I'm wasting someone's money -- if I'm getting paid by a client or customer and I'm only doing the thing because it makes me happy, that's not good enough.
And in all scenarios, most other answers are not good enough and require some follow-up action. When the answer to the question calls for follow up action, I take that to mean the check-in was a success, because without the check-in you'd keep chugging along.
Here are some iffy answers:
Those, in themselves, are (usually) not good enough. They're taking the action out of your hands. The point of this check-in is to make sure you are doing what you should be doing. Just because your client wants something, just because your approach gets to a solution quicker, or just because you feel limited by the tools at your disposal -- those are not acceptable places to say okay and just keep chugging along. That's when it's time to ask another question: How can I do it better? And perhaps even ask, And what will it take for me to be able to do the thing that will make it better? Maybe that means you should come up with a better way and then propose it to your client. Maybe it means you should slow down and focus on quality over quantity. Or maybe you should be looking for a new tool or skill for attacking your problem.
Asking why regularly is a great way to check yourself to ensure what you're spending time on are the things you should be spending time on -- because they make you better, they make you money, or they make you happy, or preferably, all three.
Unsplash uses Imgix to serve its images, which means you can transform the images before downloading.
The difference between Ruby's class and class instance variables, and how you can use them to abstract functionality from inherited classes.
Oct 1, 2015: Day 1 of Month 1, The 15-Month Plan.