Don't write code first
blog.reemer.com
blog.reemer.com
Hackers don't write code because they want to make lots of money. Hackers write code because they are hackers. Building a viable business on top of that code may be a nice side effect of this.
It may be true if you're on a lake or in a bay, know the area well, and your intention is to just go and flex your sailing muscles. To practice, enjoy, check out something you're aware of but haven't actually navigated, or something else that's similarly within easy reach.
It loses its applicability when you consider that, no, some sailors actually do have destinations. And some trips are long or difficult enough that they do in fact require planning, specific goals, timelines, and all manner of other preparation.
I'm sure it's not a perfect metaphor, but the point is that the artificial limitation of "hackers hack to hack" is short-sighted and fundamentally flawed. Some do, some don't, and I would say most are somewhere in between. But please don't make the mistake -- on behalf of others -- of defining the entire community in terms of your preconceptions about what hackers do or don't value or attempt in an absolute sense.
This article is aiming for entrepreneurs who are building a product for others because no where in the article did he infer any possibility that the product/service is something they want regardless of others.
No, Linus built git to address the needs of a large community of Linux kernel developers:
Git development began after many developers of the Linux kernel chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.
Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs, particularly in terms of performance. Torvalds took an example of an SCM system requiring thirty seconds to apply a patch and update all associated metadata, and noted that this would not scale to the needs of Linux kernel development, where syncing with fellow maintainers could require 250 such actions at a time. His goal was for patches to take three seconds.[1]
[1] https://en.wikipedia.org/wiki/Git_%28software%29#History
`Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs`
Just assume that any mention to 'hacker' in Hacker News has nothing to do with hacking, but with entrepreneurship.
There's always been a yin-yang between hacker and hustler here.
And I am glad this hasn't been destroyed as there is merit in the frame.
We hack and hustle customers and software.
We validate the market on both ends: business and product.
The problem I have with this article and your comment, is the generalization of the term "hackers". Is anyone that codes in their free time, a "hacker"? Is a software engineer that works full time at a company, a "hacker"? What about UI designers that write CSS? What about business guys who throw something together in HTML and jQuery? Are they hackers as well? Different people have different goals for what they are building or hacking on. I really don't understand how we are still throwing such vague terms around like we all fit in this one category of people, and we all want to achieve the same things.
I actually spent nearly an year writing a rather powerful and challenging mathmatical reasoning engine (heck it can not only solve but LEARN mathematics!) but i had no users in mind. So i could never explain to people why anyone wud want to use it. and that didnt really feel that good
There are no concrete rules in life, I get it. If you are trying to make money, all he is saying is find out if people are actually willing to pay for this. However, like other's have pointed out, sometimes we write code not driven by monetary rewards but just the joy of coding. There are no concrete rules, sometimes it's a great idea to write code when the idea comes into your head, sometimes it's not. The hard part is figuring out when to do which.
== Don't go looking for customers before you have working code. ==
Years of experience show sales and investment rounds go better if you can show an actual, working software. The solution doesn't have to be complete, nor perfect fit for this particular customer, but nonetheless, if you pitch, you better be able to back your words with something concrete.
Don't even attempt to set pricing or commiting to delivery deadlines unless you have at least sizeable chunk of code working. At the very least have third-party libraries ready and pick a platform (hardware, OS and UI toolkit) that provides most of what you need.
Beware that quite often what seems an easy endeavour upfront, show to be quite complex, perhaps even unachievable, as you start coding. Thanks to the halting problem, it's not possible to find that out without actually implementing the important parts of your software.
Last but not least, before you start selling, have had written and delivered at least a few similar pieces software. Having experience in problem domain is crucial for producing commercial-grade software.
# # #
Phew, easier than it seemed -- which goes to show how little value is in such generalizations. At least in general ;-)
The second assumption that seems to come into this argument is that ideas for products are stand-alone and don't evolve through experience in a domain and feedback of pain points on existing products (prior to where we form the idea).
You either put up a landing page and say give me your email, or you build a minimum viable product as with feedback as you build.
So we built the minimum viable _prototype_. It's not the MV product, anyone using it gives up within 3-4 minutes. But combined with me talking directly to the user, I can now hear that lightbulb turn on as they get what I'm talking about.
Simply, it's a continuous spectrum between the two boundaries and you need to pick the right point for your product. As a contextless headline, this is bad advice.
The point isn't to get them to confirm what you want to build is the right thing, it's to learn more about their problems to find out what you should build.
It seems like this is straightforward honest advice when you're trying to solve somebody else's problem(s). Some other folks have mentioned other products as examples of build first, but those all seem to have been people solving their own problem/desires.
If you're trying to create a business that attempts to solve other people's problems, this approach would be excellent. The example that the author used (Movie theater) illustrates the point of view perfectly. I suspect none of us have ever had the problem of watching a movie and being distracted by the fact that we didn't purchase enough snacks. That is not a problem a 'user' has ever thought of, but I would guess theater owners think about it a lot.
I'm glad HN moderates titles, it's super unproductive to react to a title but people do it anyways, rather than reacting to the content.
It's easier to just read the title though :)
All the same, I think in cases where responses start reacting to the title and not the content, it makes sense to moderate it, but then again, I am biased.
A hacker who has an idea will do it regardless of whether it'll make them money or not.
That's exactly the motivation that drives me to create side-projects. But it's still a bummer when nobody uses them.
The point is not about money, but creating value. Hackers don't always want to create things just for flexing their technical muscles. In the end, we all want to provide value in one form or another. If no one is using your software, then it's wasted effort.
You could modify the approach outlined in the post and just verify peoples' pain-point and see if they'd be willing to just use your software instead of asking them to commit to paying for it.
edit: I'm dissapointed this isn't about entity framework ;)
Hackers don't always know what people want. Hackers, having hammers, will only see the bits of problems that look most like a nail. Hackers, having hammers, will forget that other people don't like to deal with hammers. Hackers, having hammers, say things like: "For a Linux user, you can already build [Dropbox] yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem." (https://news.ycombinator.com/item?id=9224)
The real lesson is to integrate users in every part of development. Targeting a specific user group? Talk with them, try out products they use, and try to grok their needs, values, and relationship with technology. Trying an innovative interface? Throw together a minimal, flexible mockup (just enough to facilitate a conversation), and find out how people react.
Whether you should start with users depends highly on the product, but get users involved throughout the design process when user input is needed.
Also, the quick rise of this is a bit suspicious.
Minecraft is an example of a game at the right place, at the right time. Indie when indie was the hot new thing, 3d voxel, when gaming was tiring of FPS's, and cheaper than most console games.
It is not a model others, or even Mojang has been capable of replicating.
A great number of products and business ideas spring from noticing that something seemingly necessary doesn't exist, which, said another way, is recognizing that there is a right time out there waiting for the right thing to come along.
I see the battle here as a conservative/liberal one. Not politically, necessarily, but of personal effort. Do you research and line up customers and let people wait for the product to arrive, and in this way creating a right place for a product to occur in (hopefully) the right time? This i see as conservative with ones own efforts while beign liberal with other peoples' time and attention. Alternatively, being liberal with one's own efforts in creating a product that can be presented in a turnkey fashion, effectively treating the customer's time and attention conservatively. There's no right answer.
Mojangs model wasn't really a model, they needed money to continue the development of Minecraft. People really liked the idea of a voxel creative adventure game at the time and spread the word. Now the market is saturated with them, yet Minecraft is still on top.
Expecting the model to play out the same again is stupid, because the original conditions that caused Minecraft to be successful have changed.
At the time, Notch just wanted a game that played the way Minecraft did; he was focused on building something cool that played into his nostalgia.
The reason is that a lot of the time you need to technically validate an idea. You have a great idea for a product but you have no idea if it's even possible. You have to write code to understand what your product is even going to be ("these are the 3 most important features, can we actually do them?") Maybe these are features that depend on an external service and you need to make sure they provide the right info.
I feel much more willing to sell an idea when I have a vague idea that it's possible.
But yes, only write as little code as possible at first, and expect to throw it all away. It's just part of the research process.
> The reason is that a lot of the time you need to technically validate an idea. You have a great idea for a product but you have no idea if it's even possible.
I agree that things are rarely black and white, but because hackers tend to default to their comfort zone - code - and because (in my experience) technical risk is usually a non-issue, the biggest risks are finding a large enough market, a set of customers willing to pay, and a way to profitable reach them. Since they're usually the biggest risks, it makes sense to tackle them first.
There's the other end too, though: you get so wrapped up into an idea and sell it too hard and end up not delivering because you were detached from the technical reality.
I think you just need to be smart about switching contexts, especially early on in the game. Using a little bit of code here and there to stay well-grounded, while focusing on customers to validate the idea. Early on you definitely should be spending most of your time engaging future customers.
100% agree. Though my approach is less about selling and more about learning: are we solving a valuable problem? Are people willing to pay for it? Do we have some ideas about how to scalably reach those folks? Etc
I have a specific question, as I'm in this phase right now. I need to validate my product and demographic. It's a finance app targeted towards developers. I'm still working through the core feature-set (on paper, and a little code). It needs to differentiate itself in the details; the market is somewhat saturated. I also don't see how I can make a landing page without screenshots.
Now, how do I validate it without writing any code? I have already written some code because I need to make sure I could get certain info from banks. I need to make a landing page to get people to sign-up. Can I really do that without screenshots (even if it's mock-ups, I need to think about the UI a little)? I need to "sell" it on a few features; writing code has helped a ton to sift through my ideas. How do you flesh out a landing page when you just have an idea?
Obviously, I'm still learning about this.
Use thumbnails with copy about benefits. That's what we did.
> How do you flesh out a landing page when you just have an idea?
We talked to customers about their problems - we reached out to people through our networks and cold emailed them. We understood their problems first, then were able to create a landing page with fake thumbnails of the interface. We wrote copy detailing benefits (save time / save money / make money) of the product. The goal of the landing page was to get more people who we could talk to to validate our idea.
It didn't matter that the product didn't look anything like the thumbnails.
The only code we wrote was to hook up the landing page to Mailchimp.
You have to choose something to start with, and starting with a few tech features is absolutely valid.
Sketch first means you're thinking about a product and hunting for a customer. Customer first means you're thinking about a problem first then building a solution.
I published a Slideshare last week with some tactical tips on performing the interviews: http://www.slideshare.net/ZacharyCohn/18-customer-interview-...
[Full disclosure- my company teaches big companies about this stuff. We publish a lot of free content as A) Content marketing, but B) as a way to help our startup friends.]
- To provide a usable product for your customer you need to ask them what they want. I can't tell you how often I see tools that are practically unusable for the target audience because the devs were just writing with devs in mind and couldn't be bothered to take a couple days to do interviews. (I'm looking at you, every-open-source-tool-that-gets-shown-off-on-HN)
- Writing code first also means you probably didn't have a plan for the entire design flushed out, which means hacks on top of hacks, which is equivalent to a giant Jenga stack with half the pieces missing.
- How will this code be used in 10 years (if at all)? In 20? Is it going to be made obsolete, or will your users and their needs change? (think multimedia, transportation, competing market forces, legislation, etc)
"Talk is cheap. Show me the code" Torvalds, Linus (2000-08-25)
FWIW... on a first glance, i parsed the submitted title as
"don't write, code first".
On a more serious note, I wonder if the folks at Xerox Parc would have created the mouse/various interface hacks had they thought about the biz. On the contrary it was the "business concerns" that decided to not continue it further.
That said, code itself has its own consumers/customers who will use what you create. And that's selling in its own right. eg: jQuery's decision to incorporate chaining, selectors, more functional aspects.
When i write frameworks or libraries, I always try to start with the api/wrapper first, and then work on the internals. can't remember the threads, but am sure there have been a bunch of HN threads on just this subject.
~B
Just like pure Agile, Waterfall, etc methods aren't complete solutions, we seem to have the tendency to try and redefine "good software development" every other month.
The most important thing is to do what works the best with your team; and even this varies from project to project. Sometimes coding out a half baked idea into a POC is better than spending hours on a whiteboard, just to get stuck at some unforeseeable roadblock as soon as the code hits the editor.
Sometimes, you need to hash out a problem on paper before devoting coding time. Proclaiming absolutes as gospel is a little dangerous.
- Chatroulette
- Minecraft
There was widespread outcry for the administration to build what Zuckerberg realized he could build faster.
Further, there were existing prototypes in house facebooks.
Source: user number under 10k
If you're selling to consumers, you need to know what they want, because asking them won't yield useful answers. Who would have told you "I want a text box where I can type 140 characters about how I feel" 6 years ago?
If you're selling to businesses however, you need to do customer and market research.
It's not either-or, it can be a mix. But it's not beyond the capacity of some hackers to hack on something they care about and, at the same time, have it be something that others will care about, unless all they're doing is trying to make a quick buck in the startup rush.
It's almost comical these days when you read a blog article or pick up a magazine and it's just recycled ideas from that book.
I basically think it ties back to becoming an expert on the problem. Instead of the solution.
Just bummed I'm not getting karma for submitting it this time!
Contentious, heat-generating (as opposed to light-generating) discussions, often political and / or emotional in nature, tend to produce the most comments, and are the least useful to read or get involved in.
Though this is just a delicious linkbait-y title so that probably helps it...