Kinds of hacking involved in startups
14 comments
I think what he's referring to is not so much 'small nasty' vs 'big hard' but rather the work to reward ratio.
If you solve P = NP, your work and reward are high.
If you solve 'My website is having performance issues' the work may be hard, but the reward is getting to do it again next week (if you're lucky)
If you solve P = NP, your work and reward are high.
If you solve 'My website is having performance issues' the work may be hard, but the reward is getting to do it again next week (if you're lucky)
You really shouldn't do the parts you don't find interesting. Pay someone else to do those parts. I like internet startups -- imagine what it must have been like to own one of the first printing presses... that's what I feel like when I'm working on a website. Imagine you're writing a novel, except that you know what page every single one of your readers is looking at, and you can talk to them about the page.
So, as discussed elsewhere, I'm not immediately planning on starting a startup, but I am in favor of the idea in theory. One thing that bugs me about it, however, is that one of the advertisements in favor of starting it is that you can get real, serious, no-kidding hacking done, in at least a quarter of your time, while you aren't running frantic errands.
That sounds pretty good to me. However, all the hacking I hear about in relation to startups is either a) UI design (e.g. Wufoo) or b) server scaling. Server scaling is about as boring and unhappy to me as you could get without mandating that it be in Java; UI design is better, but still not appealing.
There are obviously exceptions; search engines come to mind. But overall, the average successful startup seems heavy on nasty little problems and light on big, hard problems. Is this perception correct? Anecdotes for or against?
That sounds pretty good to me. However, all the hacking I hear about in relation to startups is either a) UI design (e.g. Wufoo) or b) server scaling. Server scaling is about as boring and unhappy to me as you could get without mandating that it be in Java; UI design is better, but still not appealing.
There are obviously exceptions; search engines come to mind. But overall, the average successful startup seems heavy on nasty little problems and light on big, hard problems. Is this perception correct? Anecdotes for or against?
I would have to imagine that the interesting hacking comes into effect when, instead of writing the interface by hand, you abstract the interface into code that makes interfaces trivial.
In the words of Jeannette Wing, the two A's of "computational thinking" are "abstraction" and "automation"
(from http://www.cs.cmu.edu/afs/cs/usr/wing/www/ct-short.pdf)
In other words, interesting hacking occurs when you realize that a certain task can be automated (e.g. writing UIs or administering servers), you create a useful abstraction for it, and then you write the code that performs the task largely automatically.
This is why pg champions Lisp as a great language for startups: Lisp is perfect for building other languages because of its powerful macro facilities, among other things.
I guess what I'm saying is that "startup hacking" is as interesting as you make it. Sure, you can toil away writing similar code over and over again to create various facets of the UI, but the more interesting thing to do is to write the program that writes that code for you.
In the words of Jeannette Wing, the two A's of "computational thinking" are "abstraction" and "automation"
(from http://www.cs.cmu.edu/afs/cs/usr/wing/www/ct-short.pdf)
In other words, interesting hacking occurs when you realize that a certain task can be automated (e.g. writing UIs or administering servers), you create a useful abstraction for it, and then you write the code that performs the task largely automatically.
This is why pg champions Lisp as a great language for startups: Lisp is perfect for building other languages because of its powerful macro facilities, among other things.
I guess what I'm saying is that "startup hacking" is as interesting as you make it. Sure, you can toil away writing similar code over and over again to create various facets of the UI, but the more interesting thing to do is to write the program that writes that code for you.
As either Alexis or Aaron of reddit said "it's just a website, it's just a list of links."
In building our startup I haven't come across any monumental, super mathematically/computer science involved problems, but it's still been extremely challenging and fun. I'd say the challenge/fun comes more from trying to do all the things you listed at once, instead of any one of them singularly.
If nothing else, CSS and IE will teach you patience.
In building our startup I haven't come across any monumental, super mathematically/computer science involved problems, but it's still been extremely challenging and fun. I'd say the challenge/fun comes more from trying to do all the things you listed at once, instead of any one of them singularly.
If nothing else, CSS and IE will teach you patience.
Oh God, the CSS/IE patience comment is true but also for Firefox. I bet that I've spent more than a week's time in the past two years just dealing with these issues on my various sites :( Part of that is a learning curve but the other part is just the various browsers deciding to implement "standards" in unexpected ways (or ignoring them all together).
If "big hard problems" without "nasty little problems" is what you want, you should go to grad school. Even companies that look like they're dealing with the "big and hard" are actually mostly dealing with the "nasty and little". Trust me, I've spent 5 years at such a place.
Yes, you absolutely must expect someone in the startup to spend a lot of time on UI design. If HCI (Human-Computer Interaction) is not an area of interest to you, your role in the success of the product will probably be secondary.
I think that completely depends on the startup. There are broad classes of startups in which UI design is not relevant, or at best a secondary concern that can be handled by a single member of the team.
What's such a class other than search?
Off the top of my head, I'd think that the UI would be of secondary importance in any startup that is writing systems software: if you can solve an important business problem, a fancy demo is impressive (and important!), but the basic problem you're solving often doesn't require a UI. For example, enterprise data integration (conversion between data stored in heterogeneous formats and systems), or natural language translation/processing. Many startups in information management / data warehousing: if you build a Teradata killer, the UI is certainly a component of your product, but it is pretty secondary. A startup building hardware (say, networking stuff) might not need to pay much attention to the UI, depending on the target market. etc.
If by "startup" you just mean "implementing the Web 2.0 idea-of-the-week", then yeah, I agree UI is usually pretty important.
If by "startup" you just mean "implementing the Web 2.0 idea-of-the-week", then yeah, I agree UI is usually pretty important.
"What's such a class other than search?"
Why "other than search"? Seems to me that at least half of the reason Google won was because every other search engined was tarted up with "portal" BS. That's UI.
So, since it's clear to me that search isn't one of those classes, and the examples given ("systems" stuff) is the area my startup is working in and I'm absolutely certain that UI is going to be 50% of the success or failure of our company, I'm not seeing any area where UI isn't vitally important.
One of the WFP2007 groups is working on a new language for mobile app development...and they're spending plenty of time on the "UI" even in that case. UI, of course, being anything that involves a user interacting with your system.
I guess someone somewhere in this thread is treating UI as "pretty things on a web page"...but UI hacking is important no matter what you're doing, if you want to sell it.
Why "other than search"? Seems to me that at least half of the reason Google won was because every other search engined was tarted up with "portal" BS. That's UI.
So, since it's clear to me that search isn't one of those classes, and the examples given ("systems" stuff) is the area my startup is working in and I'm absolutely certain that UI is going to be 50% of the success or failure of our company, I'm not seeing any area where UI isn't vitally important.
One of the WFP2007 groups is working on a new language for mobile app development...and they're spending plenty of time on the "UI" even in that case. UI, of course, being anything that involves a user interacting with your system.
I guess someone somewhere in this thread is treating UI as "pretty things on a web page"...but UI hacking is important no matter what you're doing, if you want to sell it.
A startup has a lot in common with a garage band making pop songs. I.e.:
"A couple of young, talented people, working out of their garage, create a product in the hope that a big company will buy their effort, and make them a lot of money."
Make Something People Want is not fun. The alternative is to go Indy. I'm considering moving to a low-cost country, living a student life, and working on my own projects for a while. If I happen to make Something I Can Make Money From, great. But that's not the point. I'll get to pursue my own ideas, 100% of the time. I'll see just how far I can go.
"A couple of young, talented people, working out of their garage, create a product in the hope that a big company will buy their effort, and make them a lot of money."
Make Something People Want is not fun. The alternative is to go Indy. I'm considering moving to a low-cost country, living a student life, and working on my own projects for a while. If I happen to make Something I Can Make Money From, great. But that's not the point. I'll get to pursue my own ideas, 100% of the time. I'll see just how far I can go.
The UI presents your service, and the scaled out servers power your service, but without the service, all you have are some pretty pictures and a bunch of hardware.
Also, scaling is not a solved problem in the general sense. You have to find ways to elegantly and efficiently solve _your_ problems specifically. I say with confidence that if you aren't willing to be very involved in the scale out of your service, you'll likely design a service that won't scale out.
(For an example of an elegant tool used in scale out, see Facebook's thrift.)
Also, if service agnostic scale out is a small problem for you to solve, I encourage you to get rich by solving it. I'll buy your solution if it works.