A Feature For One of My Apps – Time Clock Helper.

Since I brought up the idea of marketing yesterday, I thought I would show a bit about one of my apps.

This is my Time Clock Helper app that I wrote years ago to help myself quickly calculate the hours I was working each day. It was based on the older style paper punch cards with four punches for each day.

The original version of the app made the user type in their hours in 24 hour time. This was met some backlash, so I added a way for the user to enter their punches using a scroll wheel. The scroll wheel would use whatever time representation the user already had set up in their device – for the most part 12 hour time. This seemed to fix most of those issues, and didn’t hurt the purpose of the app at all. So, in all it was a successful change.

Thousands of copies of this app have been sold and it is used by hundreds of people a day as far as I can tell from Apple’s information.

This app can also track multiple days – simply press the “Add to Total” button and it will be added to the list of saved days and included in the total number of hours worked. You can view all of the saved days, along with the date they represent. If you need to change the dates, you can easily from the list. Also, you can email the list of days along with the total hours worked to anyone that you want.

At one point I had a request for the app to handle businesses that round their hour calculations either by 6 or 15 minute intervals. It wasn’t overly tricky to add the option, so the app fully supports those systems, too.

Click to bring up the Apple App Store

Rubber Duckies aren’t only for Bathtime – how to solve problems.

When you are stuck with a problem it usually helps to talk through what is happening. Often, simply talking through the problem will make a solution come to light. It’s technique that has been around for a long time, but often the credit goes to The Pragmatic Programmer book that I mentioned a week or so ago. The technique in the book is called rubber duck debugging.

If the problem is with a program that you are writing, simply talk through the code line by line outloud to an inanimate object. A person would also work, but that’s not often possible or the easiest solution. As you talk through each line and explain them you will often realize that the code might not be doing what you were planning for it to do – thus finding the problem and guiding yourself to a solution.

I’m going to post a link to an article that goes into a bit more detail about the psychology at play: https://www.thoughtfulcode.com/rubber-duck-debugging-psychology/

Talking about your problems with a rubber duck will often lead to a solution even if it seems a little foolish.