Blog

As an independent contractor working on software projects, nobody is standing over your shoulder that you can call “boss.” There isn’t a strict set of coworkers around you. You won’t always know what to expect from day-to-day. Priorities will forever continue to change, but you still need to be focused on delivering exceptional value for your clients.

Who exactly is your client? A false Trichotomy:

• The Product Owner / Person paying for your work?
• The Product Owner’s Users / People who will use your software?
• Your teammates / People whose success depends on your delivery?

All of these people are your clients in one-way shape or form, but the only person whom you have contracted to work with and be paid by is the Product Owner.

Tracking Your Time

When should you be tracking your time? Always. No matter what you’re doing, you need to find a way to fit regular time monitoring into your workflow. Without the ability to consistently track your time, it will be impossible for you to have an accurate record of what you spend your time on.

Time tracking is essential. Are you checking the email? You should have a time log entry set up for that. You probably check email every day, so track that time.

Slack Driven Development

What about reading slack? It’s tough to track your time as you flip through slack channels, and no one is going to pay for that. An excellent question to ask yourself is “What am I working on right now?” As you get better at tracking your time throughout your workday, this will begin to come naturally. It will become more comfortable over time, and this discipline will improve your productivity, due to heightened focus.

As soon as you find yourself diving into the rabbit hole, you should quickly identify the task that you need to give your focus. Start logging time to it, and keep on that task until it’s complete. As you move through your work, it may become reasonable to switch to another function within the same project. Context Switching comes at the expense of productivity, so it’s important to do your best to stay focused on task once you start the clock on it. Over time, you’ll find yourself consciously assessing the tradeoff between switching projects and merely continuing on the project that you already started on.

Always Be Delivering Value

While you’re flowing through your tasks for the day, you may notice that you are already .75hrs into a task and you haven’t been able to create any value in the time you’ve spent thus far. It could be a good time to pause and consider the work that you’re doing and the reasons for the apparent lack of production during this time.

In some cases, you may find that this can be an indication that the approach needs to be re-thought. Many times I’ve seen myself in this situation, only to re-assess, and within the next .25hrs, discovered a new, more straightforward, more efficient way to deliver the same value that I had intended to when I sat down to work on that task. I’ve now managed to spend 1 hour and provide what I expected to. I’ll undoubtedly bill this full hour to my clients because I spent the first 45 minutes discovering how to deliver the value in the first place.

In other situations, after 45 minutes, you may realize that you’ve learned enough to produce some artifacts from your findings. This artifact can also suffice as value delivery in the right circumstances.

What If You Didn’t Accomplish Anything?

Sometimes, you’ll spend 45 minutes of work on a task that a client didn’t ask for, but you wanted to take the initiative. You should scrutinize this sort of work very carefully. How does the client receive this value?

If you can’t answer that question well, then don’t log the time to the client’s account. There is some risk we take on as freelancers, and if you’re not producing value, you cannot bill the time. Take what you learned from your investment of your time, reintegrate it with your understanding of the solution you’re implementing, and bring it to your team for consideration. Perhaps the team can find a way to make your initial research valuable, and if that’s the case, you’ll likely be the one tasked with working on the new deliverable.

First do one thing well. A simple rule, sure, but profound. Every disaster of a software project likely ignored this simple truism. By focusing on doing one thing well from the start, you’ll increase your confidence, your client’s confidence in your team, and your likelihood of success.

In general, business owners want software developed because they are in search of revenue. Maybe that revenue comes in the form of added internal efficiencies, or maybe it comes in the form of new customers. The fact of the matter is that the needs of the technology will continue to evolve. Your perfect software system from last year surely could use some improvement, still today.

Do One Thing and Do It Well

The rare case that this appears to be invalid is Unix tools. Most of these have been around since the 70s, like wget, sed, awk, curl, less, cat, etc. These tools have sustained their viability as long as they have due to their simple purpose and their persistence of reliability. These comparatively ancient tools should give us some insight into how to build software to last.

As a software team, the goal must always be to deliver working software. It can’t take six months. Every day when you sit down to write some code, by the end of that day, you must have some portion of some working software. Hard stop.

Six months of work won’t ever fit into a single coding session; however, if you don’t have a single portion of a functioning software, I mean what did you spend your time doing?

Sitting at the computer, physically writing code is only a fraction of the time. The other portion is called planning — and, it may be quite involved. Spending time with your colleagues to digest system requirements is fundamentally valuable time to determine your best approach for building a software system.

Remember, the goal of the system is to generate revenue for the business in some way.

By the time your plans are in place, you and your team must take the time to break down the work into small chunks. By sizing work appropriatley, you’ll increase your team’s ability to deliver. If each task can’t be completed in less than a day, the tasks aren’t small enough to be worked on.

In our experience, this is by far the most effective and reliable way to ensure that all time spent coding is productive and value producing. As long as you’re producing value on a daily basis, generally, client relationships should be easily maintainable, and there shouldn’t be much conflict.

Never manage to a failing goal.

It’s just that simple. As soon as you take $250,000 for a six-month project and plan to deliver the software at the end of six months, without frequent successful value delivery within the first week of adding coders to the project, red flags ought to be going off.

Setting up the underlying infrastructure to support value delivery

Getting from scratch to a fully operational CI/CD system capable of scaling up to hundreds of thousands of users will take months: It necessarily requires a feedback loop to improve. Before you go asking your contractors to build you this sort of ecosystem reliability, be sure to ask yourself: “Do I have hundreds of thousands of users? How many users do I have right now? How many users will I hope to have in a best-case scenario, six months from now?”

Any improvement that is made to a system away from the system’s constraints is an illusion.

If the best case scenario is you’ll have 100 users, then you should forget about your non-existent scaling issues. You can solve your scaling problem when you have a scaling problem. Paul Graham says to Do Things that Don’t Scale. If you need bank-level security, that’s great. Does your software do anything yet?

Bank level security is not a feature if you don’t have working software. Start at square one, not square nine. Once you have a fully functioning system, then you can start to work through security and scaling. You don’t even know if the software team was able to build what you wanted yet. Would you rather have bank-level security and a non-functioning system, or would you prefer a functioning software system that needs to have its security upgraded before launch? Trust us; you want the later.

So, if as a client you can’t understand that, then I’m sorry, I don’t know how to work with you. We won’t be successful, and although we’ll make some money on the project, it is a waste of everyone’s time.

Time is the only thing you can’t buy.