This weekend, I was talking with a friend who runs their own small business, and we spent some time on the topic of scheduling time and how much of our time we spend on different tasks each week.
Of course, this isn’t unique to a few group of people. I mean, we all have the same amount of time, and we’re all spending it on something. When we’re trying to be productive, it’s often a matter of:
how much time are we spending on something,
and where are we spending it?
I mention this because we’ve all felt that bit of frustration, right? We’re trying to get something done but we get interrupted, and either can’t find the groove to get back into it, or we can’t finish what we set out to do by the end of the workday (or whatever deadline we’d set).
Whatever the case, we all have our things – those we want to do, those we don’t particularly want to do, those that prevent us from doing either, and those that are likely a waste of time.
And this year is one of those where I’m trying to be far more intentional and make a more concentrated effort on how I’m organizing spending my time.
It’s not enough, as programmers, to talk about code or to talking about committing code if we’re not also talking the best time to commit code, right?
Sure, some developers have their times dictated by outside circumstances. Maybe it’s an employer, maybe it’s a person who’s hired the developer under a contract, or maybe it’s some other external circumstance.
Whatever the case, I’ve found that having a set expectation as the best time to commit code can help take several aspects of the full sprint or milestone development process a bit easier especially regarding how it helps to scope a given release.
“What am I doing to move forward?” This question has been rattling around my mind since the beginning of this year. And much of it has to do with the amount of change and tension that I’m feeling for some things going on various things happening in a professional capacity (versus a personal capacity 🙂).
There are some [good] changes that have happened to Pressware. All the while, I’m doing what I can to make sure I’m investing not only in myself but the business, as well.
Of course, nothing I’m going to say is unique to web development, technology, or a software business in general.
This just happens to be the industry I know.
Here’s the challenge, though: There are more than a handful of things on which we can focus. But if we pick too many things on which to focus, it’s hard to really focus on anything to the degree that’s going to have any meaningful benefit.
That’s not revolutionary. It’s common sense, right?
I don’t write much about running a business on this blog, though it’s something I’m looking to change in 2017. So why not start now?
One of the conversations several of my friends and I have been discussing is finding quality people to employ (and this can be via contracting, full-time, part-time, whatever). And each of us – like any other business – have our criteria.
A topic that has come up is the stigma that’s attached to the idea of a “senior developer” or a “senior” anything for that matter.
The way that I’m currently running Pressware is simple:
I have two contractors. One is a developer. One is an implementer. It suits the needs of the business perfectly.
I have, like any organization who wants to be on the up and up with their taxes , a CPA. I also have a part-time person who helps me keep my books.
My role has changed into both software development and business management (and I’m still figuring out how to do that – thank God for people who have wisdom they are willing to share).
The way in which we all run our businesses vary (and some of these firms include Reaktiv, Sandhills, Zao, and MemberUp), but there are a few things that are common in a recent discussion: What is a senior developer in WordPress?