One stressful thing about software development is that it is not always straightforward. Sometimes we build things that are similar to other things we’ve done in the past. The work is more predictable because we have a clear idea on what’s involved. Think of it like writing a blog post about something you are an expert in. There’s still some challenge in structuring your words to be coherent to others, but at least you know all the main points you would want or need to cover.


Often though, developers are tasked with building something where they know little to nothing about. This is like being asked to write a blog post on a topic of which you have only cursory knowledge about. It is not impossible, but there is an unknown amount of time that needs to be spent on research.

This isn’t going to be a post about how estimating software development is hard. There is plenty out there on the subject (here and here). What I have been thinking about lately though is figuring out how to decide whether a task with these unknowns is worthwhile. For professorbeekums.com, I am under no pressure from a boss to deliver anything. There is only my own desire. I would like to build the best product I can in the smallest amount of time. However, my background is mostly back end development. Building elaborate UIs has never been something I’ve been good at. Yet, 90% of what I wanted to do with ProfessorBeekums was going to be unknown because it was (and still is) mostly front end development. So I was and still am unable to properly estimate the vast majority of my work.


If I can’t judge how much time a feature will take, how do I judge whether something will be worth my time investment? The tried and true method is the time box. I can come up with a period of time, say 3 hours, and only spend that much amount of time on a project. If I don’t succeed when time is up, I can then decide to continue with a new timebox or just drop it. This works great for things that are only somewhat unknown. For example, if you’ve integrated apps with half a dozen APIs in the past (Facebook, Twitter, Flickr, etc.) then you already know the basics behind integrating with another API (say Twilio). Sure it will be a different company’s API so there are a ton of differences and that is where the unknown comes in. Yet, there are enough similarities that after 2-3 hours you should be able to confidently put a reasonably accurate estimate on it.

For a lot of ProfessorBeekums though, I had never done most of what I wanted to do. If I spent 3 hours on something, I would still have no idea how much longer it would take me. Even with several 3 hour timeboxes, I would still not know. This happened with the page slider on my lessons. There are plenty of page slider examples out on the internet. If I was ok with my lessons working exactly like those examples, then it would have been easy. The moment I wanted it to work slightly different, things got hard.


The danger I faced was that I could have gotten sucked into some black hole and where my time was just lost. So I should have chosen to call it at some point right? That’s an easier call to say than it is to make. Learning is not often linear. Many times you end up hitting your head against a brick wall until all of a sudden you get a Eureka moment that lets you jump over.

Give up too soon and you never hit that moment. Don’t give up and you may not hit that moment anyway and you lose out on the opportunity to do other things. Learning to become a software developer in the first place was LITTERED with these situations.

How then do I decide to continue going with something or giving up? I don’t have a great answer to that question. I do know that the habit I developed while working for companies with tight timelines is to err on the side of being “efficient” with my time. That translates to giving up on most hard things and going after easier ones with a guaranteed payoff. That habit is also why I put off making my own product even though that is something I’ve wanted to do for years. I knew that I didn’t have a front end skill set which is critical in building a consumer product. There is no way to predict the amount of time needed in developing that skillset either. There is only knowing that it will be time consuming. That fear of having my time “wasted” kept me from doing what I am very passionate about. That is why I now have changed my habit. Now my tendency is to err on the side of spending the time to research and learn. There is no question professorbeekums.com is better for it. professorbeekums.com wouldn’t have existed otherwise.