Jon Fox

The Year of Extremes

by jon Posted on January 1, 2009

It was the best of times, it was the worst of times…

– Opening line of A Tale of Two Cities

This was definitely true for me over this past year. This year has brought on the extremes of my experiences in my relatively short life. From some of the best experiences (building and selling my first company) to some of the worst (losing my father and my grandmother), this has truly been a wild ride. It’s also been one of the years when I feel I have learned the most, both about myself and in general.

This past year has truly shaped my life in amazing ways, and I can’t wait to see / dread what 2009 will bring. In either case though, I’m ready for it.

Posted in Introspective | Tagged 2008, year | 4 Comments

Measure what matters

by jon Posted on December 14, 2008

It’s tough to improve things you can’t measure (or know when they are improved). If something is worth improving it’s worth trying to find a way to measure it. In a startup you need to be conscious of how you allocate resources. My suggestion is that you determine a few goals for your team, determine what stats measure progress toward those goals, then build the tools to monitor your progress. Get the whole team involved to create a common sense of progress and get everyone thinking about this common goal.

Measure what matters – then improve it.

Posted in Entrepreneurship | Tagged goals, measure, stats | Comments Off

5 Things You Shouldn’t Do To A Developer Working On Fixing A Major Bug

by jon Posted on December 8, 2008

For all you non-developers out there that work with developers on a regular basis, here are a few quick tips of things NOT to do when the developer is working on fixing a major bug.

Ask for attendance at a meeting which we’re not really needed at.
Assign other work to us – we need more weight on our shoulders in these stressful moments!
Ask for some development work to be done on another project – if we have any available time it’ll be spent fixing the urgent issue, so by definition we don’t have time to work on anything else.
Ignore our requests for help solving the problem – it’s top priority for us, but your time is better spent asking for updates than helping…
Send us multiple emails pointing out how serious the bug is – if we’re working on fixing it already…as fast as we can…a reminder of how urgent it is doesn’t really help anything.

Posted in General | 2 Comments

Follow Through

by jon Posted on December 2, 2008

Do you have “follow through”?

When I say follow through, what I mean is that you can be trusted to do what you say you will do – on your own. One very important lesson I’ve learned is that it’s critical to find people that you can trust to follow through with what they tell you they will do when choosing partners/employees in a startup. It’s also critically important that you can be trusted in this regard as well.

Startups by their very nature have limited resources. Because of this, it is more important than anywhere else that startups are as efficient as possible with these resources. The most valuable resource for a young company is the time of the employees/founders. Since everyone is forced to wear many hats and there is always more to be done, time is often a bottleneck.

If you can’t trust your employees/partners to do what they say they will, then you’re forced to spend cycles on their problems. Suddenly, you need to keep track of their tasks so that you can be sure that they complete them all. You spend extra time checking up on the status of items to make sure they’re being done on time. And most importantly, you can’t give them very much freedom to do their tasks and make them their own because you’re constantly having to check up on them. This ends up wasting a lot of your time and a considerable amount of theirs. You basically end up doubling up your resources on these problems, which is not an efficient way to do things.

Instead, make your first criteria when choosing partners/employees their ability to follow through with what they say they will do. If you can’t trust them enough to assume that they’re doing what they say they will do then you should probably start looking elsewhere. A young company simply can’t afford to have resources piled up on a single problem. You can’t be second guessing other people in the company constantly or you’ll find progress slowing to a halt over time.

Find people you can trust to follow through, then give them the freedom to do it. It’s the most efficient use of company resources, and a lot less likely to cause blow ups between coworkers stepping on each others’ toes.

Here are a couple quick things to test if you trust your coworkers/have follow through:
1.) Do you find yourself frequently doubling back on a task to check the status of an item? For example, do you send a lot of emails like: “What’s the status on ______? Did this ever get resolved?”.
2.) Do you find yourself often asking people to run stuff by you?
3.) Do you find yourself constantly worried about other people’s tasks?

These are solid signs that you don’t trust these people to “follow through” on their required tasks. So make you and your company more efficient; find people you can trust and give them the freedom to complete the tasks on their own. It’ll make all the difference…

Posted in General | 7 Comments

The Tough Times

by jon Posted on November 22, 2008

How do you react when the going gets tough?

I find most people fall into one of two categories. The first (and far more common) is a reaction of great distress. When your competitor comes out with something amazing and new, when you have a bad month for growth and stats are down, or when you have trouble raising money and things start to get tight, many people respond by getting depressed, giving up, and/or stressing out. “How are we ever going to compete with this, we might as well close up shop”, “With a month like this, and numbers like these, we’re never going to get the distribution/revenue we need to survive.”, and “How can we make any progress when we don’t even have the money to pay our current bills? If we can’t get some more money together now it’s all over.” are typical responses to these types of situations.

The other category of people respond in the exact opposite way. When times are tough they become more motivated and see the adverse situation as a challenge to overcome, as opposed to a death sentence. These people respond more along the lines of “Our competition might have the leg up now, but we’re going to destroy them when we do….”, “The numbers might be down now, but it just means we need to push a little harder next month and take things to the next level”, and “Money is tight, but that just means we need to trim the fat and figure out what we can do to make a better case to potential investors…we know there’s a business here, we just need to figure out how to convey that to them.”

The truth is every startup is full of ups and downs…it’s unavoidable. The question is, how will you, and the rest of your company, react? When the chips are down, the last thing your company needs is someone reinforcing the bad situation with depressing attitudes and loss of passion. A team full of these people will create a downward spiral of dreadfulness as each member reinforces the rest of the team’s “loss of hope” attitude. Trying to recover from a bad situation and simultaneously rebuild company moral is a daunting task that many don’t overcome.

Instead, the company needs people who will see the current adversity as a challenge to do better. This not only eliminates the need for a team cheerleader to boost company moral, but actually creates a deeper drive to push the envelope. A team full of this type of person actually has a positive feedback loop, as members feed off the energy and ambition of the others to ensure that you beat the competition, have better numbers next month, or close the resource gap. This category of team rises to surmount a challenging situation instead of letting it destroy them.

Admittedly this trait can be tough to spot in an interview. Many people might not even know themselves which type of reaction they’ll have to a situation until they’re actually in it. That being said though, this has become clear to me to be a key determining factor in the performance of a team and can’t be underestimated. The difficult times are what really determine a company’s fate, and having the right personality type on the team is a factor completely within our control that will have a huge impact on this outcome.

So which type of person are you? How would you classify your company’s culture in this respect? It could very well mean the difference between the success or failure of your company.

Posted in Entrepreneurship | 2 Comments

Uploading vs Downloading

by jon Posted on November 11, 2008

When the internet first started out it was really hard to do much of anything. Browsing in its current form didn’t exist, and just basic navigation around the web was difficult. Fortunately, we’ve gotten really good at downloading. With web browsers, search engines, and news feeds it’s easier than ever to consume tons of content online.

A bit slower to rise was the ease of uploading, or contributing new things, to the web. Although downloading has been easy for the average guy for years, it’s really just now starting to get to a place where uploading is as easy. With the rise of WordPress, Flickr, YouTube, Twitter, and IntenseDebate (among others) it’s become progressively easier to upload your content to the web (in whatever form) and contribute.

So please, don’t just consume the internet – help build it by being an uploader too.

Posted in General | 1 Comment

Automattic Acquires IntenseDebate

by jon Posted on September 23, 2008

I’m very excited to announce the acquisition of IntenseDebate by Automattic. IntenseDebate has been my entire life for the last 1.5 years (and a good chunk of it the 3-6 months before that). If you don’t believe me just ask my girlfriend who had to put up with barely seeing me during this time.

This company has had a hugely significant impact on my life. When I look back to how things were when this project got started it is amazing to think how much has happened in a relatively short time. I’ve learned a lot from this experience (expect to see a series of blog posts elaborating on this), and I consider it a real blessing that it’s worked as well as it has.

I owe a big thanks to David and Brad of TechStars for believing in me (and the rest of the team) and giving us a huge jump start (as well as plenty of advice/help along the way). I also have to thank Josh who helped get this whole thing off the ground and pushed for us to apply to TechStars in the first place. And of course the rest of the current team: Isaac, Michael, Tom, and Austin who all played an integral role in getting us to where we are today.

So now that I’ve made the blog post equivalent of an acceptance speech, let me wrap this up by just restating how great this opportunity has been. I’ve learned a ton (which is really all I wanted out of this company/experience anyways…the rest has been a bonus) and hope to be able to share that with those around me so that someone else can learn the easy way.

This is not an ending, but rather a new begining…and I can’t wait to see where this path takes me.

Posted in work | Tagged acquisition, automattic, company, intensedebate | 6 Comments

Ubiquity: PHP function lookup

by jon Posted on September 22, 2008

So I guess I’m getting into this Ubiquity thing a bit. I’ve created another one to lookup php functions on php.net. Simply subscribe to the command here to add it to your command list.

Once you’ve got the command installed you can lookup PHP functions by simply opening Ubiquity (CTRL+SPACE) and typing “php [function]”. This one was pretty simple to do, but very useful already. I look up syntax for PHP functions several times a day and saving my “Google step” is really nice.

Let me know what you think.

Posted in Code, Javascript, php | Tagged Javascript, php, Ubiquity | 5 Comments

Front End Optimization – Part 2

by jon Posted on September 21, 2008

One fairly common thing in javascript programming is the need to add/edit the html contents of an element on the page. It turns out that there’s actually a pretty significant performance impact on how quickly this update renders depending on how you do the actual edit. The main 5 ways to add/edit html via javascript are the following:

Document.write() method
element.innerHTML (before element is in the DOM)
element.innerHTML (after element is in the DOM)
DOM manipulations on the element (before element is in the DOM)
DOM manipulations on the element (after the element is in the DOM)

So the first thing to note is that whenever you’re faced with the question of adding/editing html before or after adding it to the DOM you should always make any changes BEFORE adding it to the DOM. The performance difference of this is pretty significant as if the element is in the DOM the browser must immediately render the changes as the edits are taking place. If you modify the html before attaching the element to the DOM, however, the updates stay only in memory and don’t get rendered until the edits are in place.

This is the single most important factor for performance in this task. In fact, the difference is often so drastic (particularly in IE browsers) that in many cases it’s actually better to remove the element from the DOM, edit the contents, and re-attach it instead of editing it directly. This also allows you to sidestep odd inconsistencies in IE with the innerHTML method (in some cases editing the innerHTML attribut7e of an object can cause a browser cache in IE – in particular when the element is a child of a table element).

Now that we know to edit contents before attaching elements to the DOM, which method should we use? In general, the order of speeds of the methods is as follows:

document.write() method
element.innerHTML attribute
DOM manipulations

Document.write is consistently the fastest across browsers and is often the best method to use when it’s possible. The main drawback of this method, however, is that it can only be used during initial browser load/rendering. If the method is used after the page has been initially rendered it will have the undesirable effect of either crashing the browser or clearing the current page and replacing the entire page contents with the write statement instead. This makes it unusable for adding elements after initial page load or editing the contents of an element after page load, but the pure speed/flexibility (it basically allows you to write any html to the page including inline css and javascript – though javascript tags must be written as a combined string instead a standard script tag [for example “<scr”+”ipt>”]) make it an option worth using when possible.

The next fastest method is the element.innerHTML method. This method is very readable and easy to construct quickly in general. One other suggestion is when concatenating strings to form the innerHTML use a temporary variable and apply it to the element only once. For example:
var innerHTML = "<div>"; innerHTML += "Inner Contents"; innerHTML += "</div>"; element.innerHTML = innerHTML;

This speeds up rendering (since it only has to update the DOM/render the change once) and prevents some inconsistencies when using the concatenation/assignment operators in certain browsers.

The last, and by far the slowest, method is to do direct DOM manipulations. This is a broad categorization of using methods like the following:
var element = document.createElement('DIV'); var element2 = document.createElement('DIV'); element.appendChild(element2);
This technique has many disadvantages. It renders slowly as each element is added and styled as it is appended to the DOM. Although you can improve this drastically by waiting to attach the top level element to the DOM until all the inner elements are completed, it still doesn’t compare with the previous methods described above. This code is also much harder to read (in general) than the above methods as each style, class, and attribute of the element must be assigned individually. This also leads to much larger code than the previous methods which adds to download time and parsing time. This method is really only suitable when you’re editing specific attributes or doing very minor manipulations.

And that wraps up the 5 different methods. Hopefully someone out there finds this helpful.

Posted in General | Tagged Javascript, optimization | 1 Comment

Ubiquity: Password Generator

by jon Posted on September 11, 2008

I recently made a stab at another Ubiquity command. This one is a password generator to generate site-specific passwords. Simply subscribe to the command here to get started. I’d suggest manually changing the “mypass” value to some unique string rather than use the default, but this is not technically required.

Once you’ve got the initial command setup you can generate a password by simply opening Ubiquity (CTRL+SPACE) and typing “password”. You can specify the site by adding it as a parameter after “password” or the command will use the current window’s location href as the default. Passwords are an 8 character hash based on the site and the “mypass” key set at install. The password will then be pasted at the current cursor location for your convenience.