Jon Fox

Josh Fraser and I were discussing the other day the little tidbits of knowledge that we wished someone would’ve told us on day one instead of having to learn them on our own (later than we would’ve liked). He wrote a post here which highlights 5 specific things he wished someone would’ve told him. I’m going to chime in on the 3 he mentions that I also learned the hard way and then add in a few of my own to round it all out and add a tiny bit of originality rather than just steal his post 😉

So first off, his three that I’m stealing.
1.) UTF-8…just do it! It’s surprisingly easy to get your application to handle utf-8 encoding. Spend the extra 15 minutes up front to figure it out and save yourself the headache because you’ll have an international audience much sooner than you think.

2.) Memcache…it’s a beautiful thing. Memcache is a drop dead simple caching system. This is another one that’s worth spending the 15 minutes to learn how to set it all up as it will be hugely valuable down the line. I agree with Josh that it’s not a must have on your initial prototype, or even when you first roll out into production, but plan for it like you will so that when you do need it it’s as simple as possible to integrate. Many people use memcache in different ways, and there isn’t one use case for it that you have to follow. Just spend the time to think through what the items that would benefit the most from caching would be, and then leave an easy integration point (a specific function call comes to mind) for later on when you do want to implement it.

3.) Email is slow…send it later. Especially if you outsource your email, there will often be a noticeable latency when you go to send your email. When you’re just showing off your product to your friends this probably won’t be a big factor, but as you start to send more and more mail this latency begins to become a problem. Instead, setup a mail queue for post-precessing from the get go and send out the mail that way so that the latency isn’t as big of a factor.

Now for my own contributions:
1.) If you make a widget, the hosts file is your friend. This is a bit hard to explain, but basically, the idea is that you setup a devel server and then when you’re testing, modify your hosts file to resolve your real hostname to the devel server instead. So for us, we redirect www.intensedebate.com to our devel server via the hosts file to do testing. The advantage of this is it allows you to load the devel code on someone else’s blog (provided they’ve installed your widget of course) so that you can do real world testing before it’s ever released. I can’t over emphasize how valuable this is for a widget based product. You can see how all the other crazy js, css, etc on their blog will affect your application without your users ever knowing. Awesome.

2.) If you make a widget, spend some time learning basic JS optimization techniques. For example, is it fastest to create elements using the dom, use the innerHTML property, or document.write? How does the number of individual HTTP requests affect the load time? Etc. These simple techniques, if applied up front, can save you a ton of headaches down the line as speed and performance are critical in a widget.

3.) 90% < 0. Ok, so the math major in me had a really tough time learning this one. What I mean by that is that if your product/feature works 90% of the time, it’s worse than if you didn’t have it at all. The reason for this is that people expect stuff to work. So when your product/feature works, no one writes about it and nobody cares. If your product/feature doesn’t work, however, people freak out. Most are a lot faster to write a blog post complaining about something not working than about how it worked as expected. So if you can only get 90% accuracy, don’t release it…it may seem that it’s better to please the 90%, but in the end it’ll get you no where.

So that’s my take. Got another tidbit you wish someone had told you? Leave it in a comment for everyone’s benefit.

I’ve been playing with Greasemonkey again. For those that don’t know already, Greasemonkey is a Firefox add-on that lets you run javascript scripts in the browser to execute on various web pages. The scripts can be excluded to only run on certain pages, allowing you to modify the page’s contents, perform actions, etc.

I played with Greasemonkey a while back, and thought it was really interesting, but I couldn’t come up with a lot of practical applications for it at the time. The add-on came up in a conversation I was having with someone, and as a result I decided to revisit it. I still haven’t come up with anything amazing to do with it, but I have been finding it increasingly helpful to cutout a few clicks in my daily web browsing. For example, I now have it submit forms on login pages to automatically log me into sites I visit often. I also have it setup to navigate to a page from a site if I often go to the same page after login. For example, maybe you get dumped to a landing page when you first login, but you always want to go to a specific section right after that. In this case, I’d setup a script to run on the page that I land on that automatically takes me to the second page (that I really wanted to go to) instead. These kind of things might sound silly, but most often they’re a single line of js and they can save me a couple clicks a day. Those clicks add up! Not to mention the ease of use factor, since I don’t have to be annoyed by the fact that I have to find the silly link every time I login.

For any of you out there that know even a hint of JS I’d really recommend checking it out. It can be a great time saver on these little, trivial things and make your web browsing that much easier.

Tomorrow (or today technically, but it’s not the next day till I wake up as far as I’m concerned) is the last day to submit an application for TechStars. Since I’m a big procrastinator I thought I’d write this post for all the other procrastinators that haven’t quite gotten around to submitting their application. I’ll start off with a short and sweet bit of advice: make sure you get your application into TechStars! Alright, so you’re not convinced. Well, hopefully I’ll be able to better explain why TechStars is so great in the rest of this post…

I’m not exaggerating in the least when I tell you that TechStars literally changed my life. It opened the door to a completely different direction in life that I’d always wanted to experience, but probably never would’ve (or not till I was quite a bit older) if it weren’t for this program. You see, I was that young kid that had all the ambition to take over the world. Entrepreneurship was something that always fascinated me. More specifically, tech entrepreneurship, but really the entire concept was something I was always passionate about. I’m that kid that read every biography for tech entrepreneurs: Bill Gates, Steve Jobs, even some of the shorter lived, but deep impacting stories like the history of Napster. All these stories got me excited because they were about people that were able to make a huge impact with relatively simple ideas by pursuing them relentlessly and passionately. This constantly led me to spend my days dreaming about what my big idea was going to be. I even remember joking with my parents about how I was going to need to hurry up and find it so that I could pursue it and drop out of college before I graduated like many of the greats did. The truth was, however, that I grew up in a small town in Illinois where no one knew about this world, and I had no idea how to get into it.

Then, through a rather random set of events, I and the rest of my team got accepted into TechStars. This one event completely changed the course of my life. I was going to Grad School and had lined up a great internship with a large company. It no doubt would’ve led to a cushy job that I would’ve been happy at for the foreseeable future had I wanted to. I know, however, that I never would be fully satisfied by this type of job. I’d still spend all my free time dreaming about my big idea and how I was going to break into that world. Of course, none of this came into fruition as part of accepting the TechStars opportunity involved backing out of my internship and moving out to Boulder, CO.

This was a completely new experience for me. I knew no one out here when I first arrived (I hadn’t even met my other team mates in person when I arrived…). I was quickly won over though. The area is gorgeous and the people are amazing. Everyone just wants to help everyone else out, and it seems there is very little competition among the people in the area. The other TechStars were also very welcoming, friendly, and smart. The thing that impressed me most, however, was the mentors. These are crazy smart people that took time out of their obviously busy lives just to help us out. Many of them even began to take a personal interest in us and our company; even going so far as to seek us out at times! Where else can you get that kind of help from this caliber of people?

The end result is that I was able to finally find my way into the world of entrepreneurship I’d always dreamed of. It was even better than that though, because I didn’t have to claw and scratch my way in as most starting out do…instead I was all but carried in. It really is an amazing thing. I also was given phenomenal resources through the mentors in the program, many of which still help me out long after the program has ended. And this doesn’t even include the great resource that the other TechStars teams turned out to be. They’re all smart guys that are great for getting feedback, helping to prepare for our investor pitch, and even helping work through coding problems.

So basically, what I’m trying to tell you is that TechStars was completely amazing. It literally took my life in a new direction (and a good one at that!) So go ahead and submit that TechStars application you’ve been putting off and let TechStars change your life too.

Bugs are a fact of life as a developer…there’s no avoiding it.  The really frustrating bugs, though, are the ones that drive you mad and then turn out to be the simplest little thing.  This is where having another fresh mind on the problem can do wonders.

I faced such a bug today.  I’d been looking over it off and on for a couple days and just sat there staring at the screen KNOWING that this code should work.  I’d run over it 1,000 times (approximately) in my head and run it through a battery of test cases trying to isolate the problem…all to no avail.  I then asked the always helpful Josh Fraser for a hand in hunting down the culprit.  He sat down with me, looked over the code, and fully agreed that it should work exactly as I’d expected (though not how it actually was).  He had asked me to run through some test cases, so I asked him for a couple minutes to allow me to hunt down all the samples I’d made the previous couple days.  Just to try to avoid a bit of embarrassment, I decided to look over the test cases and test code I’d setup before I called him back over.  During this process I realized that there was a slight difference between my test code and my code I was debugging that must’ve happened from an inadvertent file copy of an old version or something…in any case the problem became immediately evident after this realization.  Sadly, I then had to swallow my pride and call Josh back over and explain my blunder…so much for avoiding embarrassment.  Of course the embarrassment was a small price to pay to resolve the frustrating problem in my book.

So the moral of the story?  Get someone else to talk through the problem with.  Even if they don’t provide the solution, there’s a chance they’ll help you find it yourself by re-examining what you “knew” to be the case.

We’re still getting settled in to the new Intense Debate offices. Definitely an interesting time.

The other day we finally got our whiteboards put in (actually they’re psuedo-whiteboards, but that’s another topic for another day) and it’s completely changed how we work. Every meeting I’ve had since has in some way involved a whiteboard. Every new coding project (I think) has also leveraged the whiteboard to outline objects, work through a problem, etc.

It’s amazing what a difference such a simple addition can make.

I’m sure everyone already knows that collaboration is, in general, a good thing, but I often forget just how important it can be.  There’s a lot of advantages to sharing your ideas and working with someone else to flesh them out.  In my mind there are 3 key benefits that I hope to make clear below.

First, and probably most underestimated, is that it forces you to verbalize your own thoughts and ideas.  When it’s all in your head it can be surprisingly easy to overlook small details or miss things.  Expressing your ideas, and hearing yourself say them out loud, can sometimes cause you to catch your own mistakes or missing pieces.  Yet there’s an even more valuable exercise in sharing your thoughts with someone else…mainly, that the other person has to be able to understand what your saying.  Often times this can mean that you’ll be forced to find a new way to express your thoughts, or put them in a new framework, in order to help make it clear to the other person.  It’s similar to teaching in this respect because you have to have a very deep understanding of whatever it is you’re trying to share in order to effectively communicate this to others.  Many times this will force you to think about something in a new way that you probably never would’ve considered if you were just brainstorming on your own.

Second, is that it provides a fresh perspective on your stale thoughts.  The longer you spend thinking/working on something on your own the more entrenched you become in a few initial assumptions/beliefs/ideas.  It quickly gets to the point that in your mind you no longer even consider any other possibilities.  Often I personally don’t even realize I’ve done it at all, but it very much shapes your future thinking as you can no longer think outside of these initial constraints.  By collaborating with someone who is not already in your frame of reference they can easily see, and point out, when these initial constraints are wrong or hindering. It’s a very similar idea to my previous post The importance of an outside perspective.

And finally, and most obviously, collaborating brings in a whole new mind (or several) on a problem.  Everyone has a different thought process and getting more people involved in solving a problem or thinking about an idea is going to give you more perspectives and thus more possibilities.  We all know that person that thinks in a completely different way than we do, and it is often times that person that provides the most contribution of new ideas to the discussion.  This is also important in providing new ways of thinking about a problem that can lead to solutions that no single individual could’ve come up with on their own (or wouldn’t have in a time frame comparable).  These are often the best solutions/ideas and are what most people think of when they think of collaboration.

So the moral of the story is this: collaboration is good.  Flesh out ideas with other people, and do it early in the process if possible (although adding a new person in down the line isn’t always bad either).  The added benefits make it well worth your while for key decisions.

I spent a good chunk of my day today diagnosing an odd problem with IE that I figured I’d share in case it might somehow help someone else out there.

I’ve known for a while that there are a few pluses and minuses to using the innerHTML property instead of DOM methods to create/modify page contents in javascript.  IE in particular has some oddities to avoid (for example tables have a read-only innerHTML property…attempting to set it will result in a nasty error).  All this considered though, there are many advantages as well.  I was testing some code I’d written and found that on some blogs this new code would crash (only in IE of course), but on others it’d be fine.  I checked the troublesome page for tables, but it didn’t have any.  I then went to the source of all knowledge, Google, and started my search for other odd situations with IE and innerHTML that might be causing my troubles.  

Unfortunately I didn’t find much of anything useful.  There were a lot of interesting articles about modifications to using the innerHTML property to speed up rendering, special instances where using innerHTML produced unexpected results, etc…but nothing that related to the error (and crash) that I was experiencing.  So I broke down to doing the trial and error method…what if I put the code here instead of there….ok, now how about there instead.  Eventually I ended up narrowing down the problem until I found it.  

The problem came from the style attribute “height:auto”.  It appears that if an element (in this case it was a <p> element, but it seems to be true of <em>, and probably others as well) has this attribute then setting the innerHTML property of a child of that element causes IE to crash and give a very unhelpful “an unknown runtime error has occurred” error message.  I tried it with <div>’s and <a>’s as the child nodes and it seems to break for both.

So not sure if this helps anyone else out there, but it definitely took me a while to hunt down.  The joys of web programming….

As I talked about in my previous post, this is a time of change in my life. I’ve had to make a lot of important and tough decisions in a relatively short time, and will continue to have to make several more in the coming weeks. It’s gotten me thinking about decision making in general and so I thought I’d spill some of those thoughts here.

In general, I’ve not always been good at being decisive. It’s often much easier to “wait it out”, “see how things go”, “or run with it”. Unfortunately though, not making a decision is in fact a decision…and rarely the right one. Basically since high school I’ve often found myself falling into leadership roles. Some are by chance, some are sought after, and some are out of pure necessity. One thing that has become overwhelmingly apparent, though, is that a good leader MUST be able to make decisions quickly and intelligently. It’s of the utmost important that a leader is able to quickly examine all possibilities and choose the best one in a short time. Also, just as importantly, a leader must be willing to stick to their guns and not shy away from the decision they’ve made, and be willing to accept responsibility if the decision turns out to be the wrong one. It’s very tempting to blame the information, the group, or just the individual circumstances for a wrong decision, but the truth is that none of that matters. Ultimately the leader made the decision for the group and the leader is responsible for the decision to the group.

Being able to make sound decisions quickly is a necessity, especially in the web startup space where things move so quickly. Although I feel I still have a long way to go in being able to quickly evaluate all possibilities and still be sure to choose the right ones more often than the wrong ones, I do feel I’ve made a lot of progress in a relatively short time. I’d really encourage everyone to take on a leadership role or two at some point and actively consider this topic. Or if you can’t find yourself a leadership role just practice being more decisive in your own life. Start by being the one to make a decision among friends when someone asks “What do you want to do tonight?”. Even these tiny steps can start you on a path to become a decisive, effective leader and should not be underestimated.