Category Archives: Programming

Listen to Your Users, but Don’t Surrender Your Own Vision.

Posted on by

This post was inspired by one of my apps – Time Clock Helper. As I mentioned in a previous post, Time Clock Helper was written because I needed to calculate the hours I worked on a standard punch card. The app has been in the app store for a while and used by a lot of people. So, that being the case means that I get requests for features regularly. Some of these features are good ideas such as being able to track more than a single day, or emailing the hours worked to someone else. They weren’t aspects that I had originally planned on, but they have proven useful to many users. I didn’t have to give up the core reason for the app to implement them, or make it more complicated to use.

Well, sometimes the requested features don’t make as much sense. One example of this was making a way to track multiple employees using a central server. While, it would be possible to make that happen and I know it could be useful it would take away from the actual purpose of the app. There are many apps out there that do just that and probably do it better than I would have. That wasn’t as much the issue, though.

I wanted an app that would make it easy for a user to calculate the hours worked on a single time card using the standard four punches. Anything that makes that more difficult would take away from the actual purpose of the app. So, while I like giving people what they want, I make sure that it makes sense for the overall app and won’t hurt the original purpose for the app.

As you develop your own apps, it is important that you know what you want to accomplish, and who would most likely use it. Then, try to only implement features that will be needed to serve those users. It is really easy for features to creep into an app that make it more difficult to use, or hurt it in other ways such as clutter, or slowing it down.

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

Posted on by

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.

Just Keep Plugging Away, Even When You Don’t Feel It.

Posted on by

Today is one of those days that I am struggling to get much done. I debated if I should even write a blog post today. But, here we are.

As I stated before, come up with an achievable goal in the first place and then do what you can to make it happen. I will cut myself some slack since this won’t be a great post. But, you know what? A post is better than no post. If you let yourself get away with missing your goals, then it becomes easier the next time to do the same. Before you know it, the goals vanish and your progress goes with it.

So, make some effort to get toward your goal. It might not be anything major, but at the end of the day even a little bit counts.

You can do it! Just keep at it one step at a time. Results will happen.