Privacy: where’s the limit?
Posted by Jon on Jun 29, 2008
I don’t think anyone can disagree that privacy is starting to become more and more rare. It’s an interesting evolution as we make more and more of ourselves public and freely available. There are already strong differences between generations about where the limits on privacy should be. For example, many people in my generation have no problem having their cell phone # on Facebook or their street address available on the internet. Many new services continue to break down these walls. Location based services like BrightKite post our current location to the internet and even keep a running log of where we tend to be. Profiles on social networks continue to collect more and more information about where we live, what we like/dislike, who we associate with, and where/how we work.
The trend of diminishing privacy is clear and definite. The question in my mind is how far can this be pushed before people start to push back? What are the long term ramifications of this new open lifestyle?
Some of the edge services coming out in this area include digitizing our health records. With sites like Mint.com are we really that far away from making even more of our financial and bank records public? This could have many long term ramifications if the trend continues. For example, imagine the change for potential employers. Already they can Google you and look you up on social networking sites like Facebook to get a feel for how you spend your personal life. What if they could find out your financial status and health records as well? They could determine your salary based on how desperate you are financially instead of purely on your merits and the job market. Employers could pick the healthiest employees to try to avoid the impact of major health issues on the business. This also starts to play into discrimination a bit. How do you defend against financial and/or health discrimination? Can you? Should you?
The level of privacy continues to degrade over time, but is there a point where society pushes back? Or instead, is the slow evolution completely imminent and uncontrollable? Continually dropping with each new generation…
Life without Google
Posted by Jon on Jun 25, 2008
I had an interesting discussion with Josh Fraser tonight during which a frightening proposition came up: how would your life be impacted if Google went away tomorrow? Now before you blow me off and say “I’d just use Yahoo!”, I’d like to encourage you to think about it in the broader sense of: what if we didn’t have a nice search interface to the internet?
It’s hard for me to imagine such a world, but it would definitely impact my life. I use Google dozens of times a day to look up functions, answer questions, and even spellcheck words I’m not sure about. It allows me to not have to keep reference books at my desk or keep a long list of bookmarks of sites with helpful tables of code. I even use Google as my calculator occasionally.
Often many people of the generation before me look at my generation’s dependence on the internet at large (and Google in particular) as a sign of the diminishing intellect among our youth. I couldn’t disagree with this notion more, however. The internet is a tool that frees our brains from having to memorize mindless trivia, remember hundreds of rarely used functions, and provides a seamless interface to a huge pool of knowledge. This allows us to become even more specialized in our thinking and spend more of our brain cycles solving problems as opposed to memorizing data or doing research. Not to say that we don’t still do research, but the process has just been immensely simplified.
I think of the internet as a tool…a base of knowledge “in the cloud” that is at my fingertips and frees my mind from having to remember some of the more rarely used bits that people of previous generations might’ve kept in their heads. Does this make us stupider? I think not, but I’m sure there are those out there that will disagree. The question still remains, though, how has the internet’s depth of knowledge and simplistic search interface impacted your life? And how would it impact it if it were suddenly gone?
Todo lists
Posted by Jon on Jun 16, 2008
Todo lists are a surprisingly effective tool that are often undervalued (especially by young folk like myself). Those of you that know me well (especially those of you that knew me in college) know that I’m somewhat overly concerned with efficiency. I often strive to find ways to squeeze out just a little more throughput in my work day. One of the simplest tools for this is a simple todo list. I know that right now half of you are saying, “Yeah, of course…”, and the other half of you are rolling your eyes thinking about how useless this blog post is. I’m writing this post for the latter group (so please roll yours eyes back into position and continue reading)…
Those of you that haven’t actually tried todo lists are probably thinking the same things I used to think about them:
- I don’t need to write it out…I know what I need to do
- How does writing it down make me more efficient…doesn’t it take longer because you have to make the list as well?
- What extra value does this list really create?
However writing out your daily list has many benefits that are often under appreciated. Here is just a sample:
- Writing out your list forces you to think through (at least at a high level) all of your tasks
- Often it forces you to come up with at least some type of rough prioritization of your tasks
- Allows you to free your memory for other, more important, stuff
- Keeps you moving rapidly as you never have to stop and think of what’s next to do…this allows you to stay in the zone when you get there
- Allows for a strange sense of satisfaction when you cross items off the list…it’s weird just how satisfying this can be
If you don’t already keep a todo list for yourself I would strongly encourage you to give it a try. It might just surprise you how much more productive you can be with such a simple tool.
Tips for TechStars Teams
Posted by Jon on Jun 8, 2008
Admittedly many of these are applicable to all startups, but I target the TechStars specifically because of my own experience with the program. This is also partially in response to Rob Johnson’s post where he calls out to me (among other previous TechStars) to share our advice to the new class. So, onto the tips…
1. Delegation - I can’t stress this one enough. Make sure that there is as little overlap in responsibilities within the team as possible. Also, just as importantly, make sure everyone knows their role. In our experience I ended up with a hand in just about everything we did as a young company. I attended every session, every meeting, and worked on every aspect of our project. Part of the reason in my case was situational, but in general I would highly stress that people should break up into at least two camps: the product/project and networking/business. Try to be as firm in this regard as possible, if there’s a session/meeting about Amazon and infrastructure then send the product/project people, but if it’s just about the best corporate structure for startups you probably don’t need to send them. The business/networking people should spend their time finding key mentors and building these relationships, while the product/project people need to be cranking out code as fast as possible. There is a lot of opportunity in a very short time, and the best way to capitalize on the experience is to divide and conquer.
2. Get your product out there - Even if this means releasing a product with an extremely stripped down feature set I think it’s extremely important to get something out as soon as possible. You’ll have tons of people around to give you feedback and help to build out the product and you want to use them as much as you can. It’s a lot harder to get feedback on an idea or a screenshot than it is to get feedback on a working (even if it’s only “working-ish”) product. You’ve got mentors, other teams/startups, and (hopefully) some early users all with plenty of helpful feedback that can save you a lot of time in the long run and overall make your product better. I would encourage stripping down the feature set instead of cutting back on quality and working around a prototype that finds its way into production. This is one area that I think we missed the mark on, trying to do too much too fast instead of perfecting a smaller feature set from the get go. People in general seem to have more tolerance for “we’re still young and that’s not done yet” than for “we’re working on fixing it”.
3. Don’t try to connect with everyone - When you’re working in a startup, if you’re lucky you’ll have tons of opportunity to connect with some really great people. In particular, in the TechStars program there are plenty of really amazing mentors that are all available at your fingertips. It is important, however, to remain focused and not try to connect with every single person. Instead, find a handful of mentors/people that you respect the most and that can help your startup succeed and focus on them. With relationships in general, quality over quantity is often underestimated. This is exceedingly true with mentors to early stage startups, as the level of attention and help is key.
4. Force feedback, and don’t take it personally - This one can be tough for people, but I think it’s very important. As you work your way through the startup, be sure to ask the people around you for feedback periodically. In particular, look for negative feedback. Positive feedback might make you feel good, but the truth is the negative feedback is much more valuable as it provides a plan for improvement. Be sure to ask the people you respect around that you respect the tough question: “What do I/we suck at?” Sometimes it’s tough to get a truly honest response to this question, but you can’t take it personally. Just focus on assuring that you understand their criticism, deciding if you agree with it (most likely you should), and finding the best method to address the issue. Improvement over time is an important characteristic. Most people won’t hold failure against you as long as you learn from it.
5. Know what is a competition and what isn’t (and act accordingly) - When we first got into TechStars we saw ourselves as competing with all the other teams. I think part of this was seeded by David and part of this was just that we didn’t know what to expect, but we definitely all learned over time that in general, we’re not competing with the other teams. In most cases the startups are different enough that competition is unnecessary. Instead, leverage the other teams for feedback, advice, and networking…you never know who will end up making it big. There are times, however, where there is a bit of a competition. The biggest examples of this in my mind are demo days and investor day. In these situations you’re fighting for the attention of the crowd which puts you in direct conflict with the other teams. You want to make sure you’re the one that is remembered. This can be hard, but be sure not to be caught blindsided by this. Have a plan and execute it, but don’t go too far; after the event you’re no longer competing, so be sure not to burn any bridges.
So that’s my list of tips (for now). Hopefully someone will find these helpful and can learn them from my short comings instead of going through them on their own.
Those dreadful early decisions
Posted by Jon on May 28, 2008
One thing that is widely known already, but deserves to be restated for everyone that thinks they understand it is that the quick and dirty, seemingly meaningless decisions that you make when you first start designing/building a website are going to be greatly magnified throughout the life of the company. I run into little things constantly that I wish I’d just thought through a bit more carefully in our early stages that would’ve been a quick fix originally that are now an annoying problem to resolve because it’s grown overtime.
I think there is a delicate balance, especially in the earliest stages of an application, between speed and just getting something out the door (there definitely is such a thing as over-analyzing a problem) and thinking the problem through and looking at the long term perspective to prevent a series of “gotchas” in the future. I certainly still haven’t mastered this balance, but what I am learning is a couple of (now obvious) clues as to what should be more thoroughly thought out and what should just be cranked out and refined as time goes on. So what are the clues?
- Anything involving the database should be thought out very carefully…and then thought out again. Changing the database schema after you’ve grown a bit is certainly possible, but is a nightmare of a thing to do. The application often ties so tightly to the database architecture that even relatively minor changes can be a major pain to implement down the line.
- Core processes (anything done many, many times on your site) should get a bit of extra foresight as well. Anything that happens constantly will generate large amounts of data which is always hard to fix in the future. Also, if it’s not well thought out you’ll probably run into scaling issues and the like down the line - a little time spent early on can save you from a nasty bottleneck 6 months later.
- Data collection and standardization definitely should get some extra cycles. Exactly how you store url’s (to normalize for inconsistencies) for example is something that is much easier to solve once, carefully, than to have to modify several times to ensure accuracy down the line. Any time you end up collecting large quantities of data, you want to be 110% sure you figure out the way you want to store it (including what it will be down the line). Having to modify large collections of data multiple times is murder on your server and extremely risky (playing with data always is). Save yourself the stress and figure this out from the get go.
- In contrast, the UI of the site is something that should be cranked out relatively quickly. I’m sure some will disagree with me on this point, but what I’ve found over and over again is that what we think is the best way is never really the best way. The UI is something that should be constantly tweaked and iterated over to give the user the best experience possible. It’s very, very hard to plan out the best possible UI on day one, but your users will help you figure this out along the way. Let them, and don’t waste all your time on this up front since you’re just going to change it every 1-3 months anyways.
- Formatting and copy (text) of the site/product should be done extremely quickly early on. Obviously you want to make your product usable from the beginning, and appropriate, understandable text is important to that, but this is so frighteningly easy to change that it’s just not worth all your focus up front. Instead, make sure it’s clear enough that it’s usable and then build off of the feedback of your user base a couple months in to clean it up and refine it.
So a quick summary would be that anything involving data, the database, or a core process should be handled with great care, but things like copy text and UI should be handled more iteratively instead. When phrased like this it seems completely obvious, right? Yet somehow in the moment it just doesn’t seem this cut and dry. Hopefully this will help someone else out there to make sure they spend their time on the right early decisions and prevent some headaches down the line.
Mod Rewrite Tip
Posted by Jon on May 20, 2008
Just a quick mod_rewrite tip for everyone out there. I spent a little time today working on some rewrite rules for an upcoming feature on IntenseDebate. I didn’t realize before today, however, that query parameters are not part of the expression matching in mod_rewrite. That is, http://www.domain.com/url/param1/param2?abc=123, will stop matching after param2 in this case. When you think about it, this makes a lot of sense really…unfortunately I didn’t realize this until I spent a good 30-45 minutes in frustration wondering what was wrong with my regular expression. If you do want to do something with the query parameters you can access them by using the variable %{QUERY_STRING} in your script.
Hopefully this helps someone else out there.
What I wish I’d known
Posted by Jon on Apr 24, 2008
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.
Greasemonkey to save time
Posted by Jon on Apr 6, 2008
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.
Calling all procrastinators
Posted by Jon on Mar 31, 2008
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.
Stats by email
Posted by Jon on Mar 30, 2008
As I’m sure most people do, I like to keep track of my Feedburner subscriber count. I don’t, however, want to display the subscriber count widget on my blog, and I definitely don’t want to have to log in to Feedburner just to check the current count. It’s just too much of a hassle and the truth is that I just end up forgetting and end up ignoring my blog. So instead, a little while back I setup a script to run once a week and go fetch the stats for my blog’s feed and email them to me. Getting the stats in my inbox allows me to stay current without having to remember to go check the site…if nothing else the email reminds me that I have subscribers and should probably get another post out (of course that doesn’t mean that I always do)…
All in all it’s the best method for me. I get the stats in my inbox and I don’t have to remember a thing, but I still get a constant, weekly reminder that I have a blog and that there are a few people that have (for whatever reason) subscribed to the feed.
I decided tonight to modify the script to email me my Twitter follower count once a week as well. It’s another stat I’d like to keep track of, but don’t want to go to the site to check. And of course another reminder to stay active. If you even remotely care about these stats I’d highly recommend doing something similar. It’s quick to setup (if you want the script I’d be happy to share it), and for me at least it makes all the difference in the world. I never used to keep track of these things, maybe check it once a month at most, and now I can get updates as frequently as I want without having to remember…freeing my mind to focus on other problems. Anytime I can do that it’s worth it for me.
Entries RSS