> A good developer can pick up any language or platform in a few weeks
Yes and no. There's a major difference between "picking up" and actually being good at something. If you have nobody on the team that is either already intimately familiar with the language/platform, or has experience with various languages/platforms, you're going to be spending a lot of time figuring out how to do stuff properly instead of just building stuff. And if you are a startup with a limited runway, that difference is crucial.
The famous Norvig piece "Teach Yourself Programming In Ten Years" touches on this:
> In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
I've always liked that quote, because it really goes both ways. We see languages change over time, when we learn what one language is good for and start to incorporate some of that thinking into another. e.g. we're seeing `class` syntax in es6, but that's been present in many other languages for a while. PHP has been adding improved support for `list()`, which is basically its way for managing tuples, something very popular in the Python world. The right way to make this progress isn't by just blindly dumping syntax from one language into another, but by learning many and having it change the way you think.
> In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.
A couple of things:
- A good programmer won't just write C++ in the style of Basic.
- A good programmer wouldn't just use C++ to accomplish a task, there must be a legitimate reason, performance, etc.
I myself have done exactly this, I just wrote a Ruby C-extension to make my program faster and I definitely didn't write it in the style of Ruby.
Well even the best programmers have deadlines or have to work with something outside their main expertise. I've written and deployed CSS and Windows batch scripts but I'd be pretty stuck trying to compose either without reference materials.
Thanks for the "Teach Yourself Programming In Ten Years" article, just read it. Yeah I've seen first hand how people code after "Teach Yourself Programming In X Hours/Days" absolutely horrible. There is no quick way to learn GOOD programming. Between, good article OP.
If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.
In two ten year sprints you will be due for retirement.
No offense, but you are living in a kind of unfortunate corner of "industry".
Where I am sitting, you absolutely have 10 years (or more) to give toward a specific cause, and the path of the software developer is one of lifelong improvement.
Stuff like "the rate at which tools are changing" doesn't matter too much, because that stuff is just surface-level knowledge, not deep knowledge.
I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.
This is why I got out of areas of webdev etc that don't value deeper knowledge. I can't say how much more satisfying it is to be learning stuff that is useful for 10 years instead of the webdev framework of the day/month/year.
webdev requires deep knowledge, it just may be a kind of knowledge you aren't interested in. Placing more value in your own pet interests is more than a little condescending.
Deep knowledge of what? The way different browsers render things?
All of the Web dev I've been involved in is pretty straight forward stuff to manage records in a database or make it easier to interact with the records on a browser.
The only thing remotely complex was 3d rendering. Perhaps I have a narrow view of what is considered web dev now.
"Webdev" is not fundamentally any different from any other kind of development that involves a client and server component. It just happens to be served in a web browser. You need the same underlying knowledge as for other (common) types of software development.
It certainly can. But it feels like a lot of the Web dev scene is people chasing their tails around writing yet another JavaScript library that does the same thing as one they're replacing but with slightly different syntax.
>>I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.
I didn't mean to say that. Everybody has individual choices, and I respect yours.
And not all of us would like to code when we are 50+. Personally I would like to retire early to take time off for other things. This is entirely a personal perspective, and might change from person to person.
This is the sort of attitude that is responsible for the proliferation of "cargo cult" style programmers. People in industry who don't understand anything at a deep level and barely understand what and/or why they do what they do most of the time. They just find code -> paste code -> tweak here, tweak there -> quick test -> move on. Now you have systems which contain massive technical debt and are not well understood or designed. People like this view everything as a black box.
No, no thanks. I work in the medical device industry, but this applied everywhere. If you don't understood your tools at a deep level please, study. Go off and write some trivial stuff before you infect important systems with your ignorance.
I think it's a trend in that today we have a lot more programmers than we did 30 years ago, and much of today's programming languages and tools are highly abstracted. Most programmers don't have to know much about how their computer or OS works to get something up and running. It's good for productivity, and I'm not recommending that we go backward, but there is a consequence to making things (seem) easier.
It's much worse for contracted stuff, in-house development, or B2B products, because in all of those cases user experience is not really a big deal and barely-functional, slow systems will continue to be used. In addition, many developers being hired at such places are being hired by people who are not, themselves, programmers, and therefore aren't screened the way they would be at a software company.
Our tools keep changing but we're all still relying on the same 50-year-old data structures and algorithms (or, I guess, in many cases, solving the same problems in a less effective way because many of us aren't familiar with them). That one gives me pause.
Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.
Its not just about having math and other computer science information. Age related discrimination is a huge problem in this industry. Most of the programming jobs out there don't involve detailed interaction with algorithms and data structures in every day work. And if it does, its not like the 80's where you had to visit a library to learn about an algorithm. Access to knowledge has become very cheap and quick. Having a lot of information in your brain in itself has no value.
Young people are ready to work lower salaries, will do work on weekends, late nights and in general a lot more agile in a lot of issues.
In fact the 10000 hour/10 year rule itself is subject to a lot of assumptions like access to information being expensive in terms of time and effort, so having someone on the team with that information would help. These days you have stack overflow and a dozen places on the internet who can much of that at a far more lesser price.
Its getting easier over time to build systems and solve problems.
I can't tell if you're trolling or naive. No serious SDK, Framework or API is built without deep know-how of the domain. You atleast need to be great at data structures (or OOP), design patterns, language design.
Unless you're doing the literal bottom-barrel of engineering work where you don't involve algorithmic know-how, there's no escaping having deep engineering.
Perhaps what offends me most is the notion that "you can just google/stackoverflow it". No you can't. If you don't know your tools, every problem will be a nail and your only tool a hammer. You're not being fast, you're being hasty and creating a lot of waste by moving very slow on the aggregate. It's this attitude that introduces massive bugs in the system because an engineer copy/pasted code without knowing it's implications.
Development is knowledge working; you need to invest in your knowledge tools else you're just moving really slow and you don't even know it.
> Having a lot of information in your brain in itself has no value.
Having a lot of unstructured information in your brain has no value.
If you learn a lot, and then start putting patterns together and build more complex rules out of that - that has value. And by the way, the result of that process is the kind of thing that could be easily transferred to other particular areas.
Looking things up won't do you any good if you don't understand what you find, and you're going to waste time flailing around if you're unable to recognize the class of problem you have (which is what algorithms are for -- they're solutions for classes of problems).
Also, people without understanding of CS fundamentals often unwittingly write dog-slow code.
> Having a lot of information in your brain in itself has no value.
If you think of it as inert info, the accessing of which in the brain is equivalent to reading it on a web site...
But it isn't. Brains, especially in respect to deeply understood domain knowledge, change in response to how they're used.
Experts' minds create shortcuts to information in their area of expertise.
Having more information means having the ability to synthesize it, gain epiphanies that would otherwise be overlooked--and reading someone's blog post about their epiphany isn't the same as having it yourself.
I don't know where all this "age related discrimination" is happening, but I'm well past your "due for retirement" cutoff and I haven't seen any of it. Maybe it's because I stay out of the frothy race that is web-dev, and focus on system software, where experience is valuable and it's not just possible but mandatory to take your time learning the fundamentals.
As someone who just 'picked up' a rails 3 app to add an online order form, I agree that, while you may be able to 'get stuff done', you'll be slower than someone who has experience, no matter how senior you are. At least for a few months. I banged my head against tasks that a RoR developer would have finished far quicker.
However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.)
How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well).
Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later.
I have to agree with you... we all go through it. I always considered myself pretty good with JS (very senior), when Node/npm started getting bigger (3-4 years ago), a lot of things really made me feel out of my depth. You get used to it, you observe, learn and adapt.
Most of the concepts of application development will always apply, and context is everything.
On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.
Interesting, I read this as being open to hiring good developers even if they don't know your current platform/language. You can train that, and if you have existing expertise then you can pair them with someone who is experienced to teach them the nuances.
This is definitely what I was getting at. My admittedly fairly small sample makes me think I'd rather hire someone who appears to be an excellent developer in general and train them on a new language/ framework than someone who appears mediocre but already has experience.
I think the same applies to junior developers as well. Someone who is eager to learn, and does so on their own time to try and learn new things will give you far better results than someone who only has whatever experience they gained via internships, or as classroom assignments.
The best developers I've ever met all have one thing in common. They've all written stuff outside of school and the workplace. Not that everyone keeps doing so, but they all have at least when starting out.
Totally agree. Good programmers have a lot of knowledge that transfers well between different languages and environments in my opinion. Put another way: language syntax is accidental knowledge, but how to program is essential knowledge.
Your ability to train an employee is going to be hampered by the size of your company. You need someone with both the experience and the time to already be on payroll.
If that's the case, most companies would just give that person the work to do. If they've already got the time and experience, very few managers [in the real world, at least from my experienced] have the foresight to use that person to train another developer. Usually they'd just give that person the work until there's so much work they can't scale and then someone else would be hired to pick up the shortfall... Of course, the first developer is still so snowed under that they have little to no time to mentor the new guy. So they look for someone who may be experienced in the language but only a mediocre developer by definition. In real world terms, it appears to be expected that a senior developer can just be dumped into the empty seat and get on with it - thus, the expectation also appears to be that this senior developer needs to understand the language and pick up the business knowledge quickly enough to be productive without costing more than absolutely necessary.
If one of the intended features of a language is that it can be picked up quickly, that certainly helps. I'd suggest that this is a feature of golang and historically modula-2.
I don't think there will be meaningful slowdown from taking a 'good developer' with a lot of experience in Rails and throwing them into Django development. It takes very little time to figure out the proper way to do something when you're already heavily versed in the core concepts and ideas behind what your doing, in this case MVC web development in an OO imperative language.
Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question.
I think the author is primarily referencing the former situation, not the later.
I love Rich Hickey's analogy of the language as an instrument. I am a pretty good musician and can make decent sound from most instruments within a few hours. That doesn't mean I can make music with it. For example, the tambourine has over 90 unique sounds it can generate in the hands of a master. Concertos have been written for the instrument. I can do about 3 of them rather poorly.
Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.
Seems like an odd caveat. Why would you pick something nobody on the team is good at? Who made that silly decision to begin with. I'd expect at least one person is good/familiar with the language chosen.
> Why would you pick something nobody on the team is good at?
This is more likely than you may think...
"I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase."
Though I doubt that a warning on HN will deter such people.
I'm sure that the investors in such ventures are thrilled at the idea of paying developers to spin their wheels for a few months in order to create material for a "lessons learned" blog post.
sometimes I get the impression that a large portion of software developers act like consumers in their professional lives. Find shiny, try shiny, discard for new shiny. Doesn't matter if it's a personal gadget or something the company is counting on.
Well, I've been in the situation where nobody knows any of the frameworks around to achieve your goal and you just kind of have to pick one and hope you're right so that's another possibility.
Well, that's a different can of worms than, "I have a tool in front of me that I know how to use and is an appropriate tool for the job, but I will consciously decide not to use it. This will cause me much grief."
I've worked at a couple of startups that failed for that reason. The CTO picked something he wanted to pad his resume with, rather than a good technical choice.
Fair enough. I seems like a terrible decision from the start. But to me that connects deeply with people shipping stuff. If you're all learning the intricacies of some new tech, you're probably not shipping as much as you could be.
Oh, I agree that it's a terrible decision, but people make horrible decisions all the time. Many times they won't even admit it was a bad decision in hindsight.
Resume-building, probably. Or else nobody on the team is familiar with any of the tools to accomplish the desired goal (e.g., you want to make a SPA and none of you have ever done it before).
There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please.
But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.
That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.
"No good developer would choose to start a new project in earnest in a new language they don't understand well."
There are plenty of developers who chose to do just that, eg:
PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET).
WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang).
Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).
Whatsapp certainly wasn't a weekend project that took on a life of it's own. More of a multiyear project where the guy figured he may as well use the best technology because he'd have plenty of time to learn it. From startup school:
..why did you choose Erlang?
Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.
Picking up a language for me involves reading the O'Reily book cover to cover -- every single word. That way I get familiar enough with the language that I don't spend weeks doing things "the wrong way" just because I'm used to doing things a different way in another language. This, and the initial ramp-up time usually takes a few weeks. For really big languages like modern C++ it would probably take longer than for node or something like that.
I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).
I think that different languages have their own level of how much edge-case there is in total, as well as how much may be exposed edge there is visible now vs later. It's akin to having icebergs of different volume, but unlike icebergs, also different proportions of 'ice' below and above the water.
I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.
This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.
I totally agree with that, in theory. In practice, sometimes teams can be spread too thinly to allow adequate code reviews, developers can have egos associated with their titles that prohibit constructive criticism, and management can favor "if it looks like it works, it works" style of project delivery. These real world scenarios bias me towards people who know the language they will be using daily.
I think the the context of this statement refers to hiring, as opposed to choosing what language/platforms your team should build with.
All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in.
Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)
I think the point is that a good developer is happy to start using a language/framework because it is the best tool for the job (regardless of their experience using it), rather than just sticking to what they know.
I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for.
"Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks?
Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>
Can we say this? A startup is more likely to fail because it couldn't iterate fast enough than because it didn't start with a powerful enough platform/stack?
If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...
Is that really the lesson to take away? They have lots of projects that are not in PHP and designed a superset of the language with features it didn't have and their own VM for it, among other things, so, while they may have overcome the issues, I'm not sure that it didn't matter.
this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.
I thought it meant "as long as s/he has done something similar with a similar tool".
Ruby/Python/PHP web CRUD, that kind of thing.
I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port.
Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.
I'm glad you made this distinction. With enough time, yeah, sure, we can be "good" at any of them, but I've seen companies bring people on without a developed skill set in a particular technology only to find out the ramp-up time to be as efficient as someone familiar with it to be much longer than they bargained for.
near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.
In a startup context it doesn't matter, the technical founders should be able to whip something up in whatever tech stack as you're ramping up. Once you have some funding, employee #1 or 2 should be an expert and be able to bring in all the cargo-cult best practices for that tech stack and teach the rest of the team.
Depends on the platform. To me, that's a big measure of how well-designed a platform is that I can pick it up quickly and stop being bitten by its idiosyncrasies.
For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.
true. this can be compared with learning math(or any foreign language for that matter). you can have a one page cheat-sheet of all the rules and formulas, but that can only help you solve textbook problems. there are tricks and caveats that are learnt only by practice. googling 'how-to' is a very slow process, even with stackoverflow.
Going through this now after a few false starts. I initially picked a problem that everyone's been complaining about forever --HR/Recruiting/Resumes. Seems riped for solving but...
1) Getting engagement is tough in any idea. Extra tough here b/c writing/submitting resumes is not an everyday thing and really a pain point!
2) I knew very few people in the Recruiting industry (see #1) which made getting spun up that much harder.
3) While I agree HR/Recruiting has lots of problems, I really wasn't passionate about the space. What this means is that during the down times, and you'll have plenty of those when you think to yourself if all this work is really worth it, you really need to draw deep. And if you can't convince yourself to keep moving forward, it eventually spirals from there.
I'm now playing in the local space and much happier (even though getting engagement is still a btch!) :-)
I do have a question to the community
1) When is it time to "start the company"? (eg through IRS)
2) If you have an existing company entity (from another failed startup attempt) that didn't have a lot of entanglements, is it better to change the name of that company to your new startup (after passing #1 test) or better to shutdown and restart? Just trying to understand if there are any (longterm) downside to a simple rename.
2) If you have an existing company entity (from another failed startup attempt) that didn't have a lot of entanglements, is it better to change the name of that company to your new startup (after passing #1 test) or better to shutdown and restart? Just trying to understand if there are any (longterm) downside to a simple rename.
Your products and your business do not need to have the same name. Ever seen a shop called Yum Brands? You can just trademark your new brand and continue.
If it didn't completely fail then you have the benefits of trading history for getting credit terms with suppliers. That's the only reason we kept the company entity when totally changing direction and it was worth it.
WRT when you start the company - I only have experience from the UK market, but here you're doing a tradeoff; on the one hand there are a lot of programs and benefits for startups (like SEIS tax relief), so it's beneficial to be 'young' for as long as possible, but on the other hand, some big companies have purchasing requirements that, to protect them from immature, risky startups, only permit them to purchase from a company that has been around for a certain period of time, often years.
As a caveat to that, however, most people tend not to use incorporation date to decide whether you're a startup - start of trading, or fundraising rounds are the most common alternatives, so if you've not done either of those things your previous startup would be, for most purposes, a clean start.
I personally would set up a new one just for cleanliness, but then that's a very cheap, easy process in the UK, I don't know if that's also the case in the US.
My local incubator's advice was "incorporate as soon as you can afford it, maybe slightly sooner than that".
Incorporating limits your liability. If your businesses screws up before you're incorporated, then you are a sole proprietor, then you can lose everything (say, your house, if you own one).
Granted, it was a college incubator, so they gave that advice knowing that a bunch of students were at an exploratory stage that doesn't warrant the overhead (fees, taxes) of a company.
There are a couple of distinctions to make here, both practical and probable.
First, forming an LLC does not protect you from liability in and of itself. The idea of creating an LLC is to create a legal entity that is separate from yourself. However you still must act as if you are separate from the business by creating a separate bank account and using it for all business purchases, for example. If you form an LLC but then buy all your supplies and hosting with your personal credit card, in the eyes of the law you are a sole proprietorship.
Ideally this would be done early on, as there isn't much downside. However there is some. First, there are filing fees and a lot of times you must pay a representative for your business (especially if you are filing in a different state). Then if you want to dissolve your LLC, this can cost hundreds of dollars.
Practically speaking you won't get sued unless you're already successful. The reason is quite simple. If you don't have anything worth going after (assets, an insurance policy, etc.), no lawyer is going to take the case without charging sizable fees. For most people, paying an attorney out of principle isn't going to be a realistic option. Therefore, I would say it really depends on your business and the potential liability. If you are starting a company that catalogs baby pictures, your potential liability is probably pretty low. I wouldn't worry about filing for an LLC before I had a decent set of customers. If you are starting a company storing sensitive financial data, I'd definitely file for an LLC and probably take out a large insurance policy to boot (see how those are correlated?).
I've talked to a couple lawyers about this and their advice, somewhat surprisingly, was that you don't need to incorporate until you're past the "project" stage. Specifically:
1.) You're handling money. As soon as money's involved your liability goes up significantly - plus, the corporation needs its own bank account.
2.) You have investors. They need an entity to be able to invest.
3.) You need the business to continue if one of the people involved backs out. If you're a few guys in a garage, your startup is probably screwed if any of you back out, and so having a formal shareholder agreement and property owned by the corporation doesn't really gain you anything. If you're an operating unincorporated business with something of value and your tech cofounder backs out, he holds the business hostage, because he owns the IP.
4.) You're doing anything that's risky and may piss people off, eg. spammy marketing campaigns, crashing peoples' conventions, abusing another company's API, scraping data where the ownership is unclear. You can get a lot of protection from lawsuits simply by not pissing people off; people who aren't mad at you and don't think you've wronged them don't sue you. But if you're doing something that's a grey area, you really really don't want your personal assets at risk.
The main downside of incorporating is that then you have to deal with all the administrative details of being a corporation. You have to pay yourself minimum wage, or else you're in violation of minimum wage laws. You're taxed on the income you receive as wages (even though it's just a transfer from yourself to yourself), so the IRS is taking 15% or so of your runway off the top. You have to file both corporate and individual taxes, which is a big distraction when you want to be working on your product. You need to have at least nominal board meetings (in the beginning, this can be just you and your cofounder sitting down at the table), where minutes are kept. It also costs a few hundred in fees, which is money you don't get back if the startup never finds any customers (as most don't).
Basically - you can and should be "just a person working on a project" when you're building. When you release it to the world and let people who you don't personally know use it, it's probably time to incorporate.
Just to clarify- if you are incorporating as an S-Corp or C-Corp you do pay taxes off the top, but if you file as an LLC you have pass-through taxation, meaning that you only pay tax on your income, the business doesn't have to pay taxes on top of that.
Further clarification: that depends on your election as an LLC. You can elect to be taxed as a corporation as an LLC, in which case the taxation will not be pass-through as a disregarded entity or partnership, and you'll need to file the normal 1120 corporate return.
Thanks. Just a point of clarification on (1). Is that just for taking IN money as opposed to just paying out for things like purchasing computers, software, freelance to design your website, etc?
Yes, but you probably also want to incorporate if you're paying out money. The business relationship a third-party supplier has is with the entity that pays them. If you buy something from a supplier on your personal credit card, they're unhappy with the transaction, and they sue, they sue you and not the corporation.
You're probably fine if you're buying commodity products like, say, web-hosting. You might get into trouble if you do it with negotiated purchases like contractors. YMMV; again, "not pissing people off" is a pretty good legal defense, and I certainly know folks that have hired artists or app developers before incorporation without anything bad happening.
http://hired.com already does this, and they seem to be doing it pretty well. I don't want to dissuade you, as they have not upended the industry yet, but check them out.
Oh that's the other thing. There are lots of players in this space! But, that's not a bad thing... Someone just pointed me to nsphire (tinder for recruiting?) which seemed interesting too.
Brilliant post. Most of these points hit home for me. One of the things I've been honing in on recently - which you do as well - is effectiveness. Brilliant developers who don't ship aren't effective. People who don't distill a product down to just what's necessary aren't effective. You hit on this concept - and many others - in a number of spots. Thanks for sharing.
I've always referred to this as "realized output". The brilliant engineer might have capacity for greater realized output, but there is little value in the potential. After a certain point, the output must be realized.
This is closely related to the "Raw Technology Persona"[1]
A developer who can talk you through an entire stack and why specific tradeoffs were made on specific pieces of the architecture... yet hoards code on their box without committing, works on stuff without telling other people, and claims that things are progressed much further than they actually are. It's an ego and accountability problem.
Someone like this might prefer to refactor your entire stack multiple times, partly due to shiny-new-framework, and partly due to the lack of understanding that from a business perspective you often have to work with what you've got. I think it's less about perfectionism and more about inexperience with balancing business tradeoffs with technology.
There's a great series in Forbes specific to CTOs undergoing this "meltdown" [2]. In it, they mention a few warning signs including: never saying no, missing deadlines, low morale, and poor estimation of timelines.
Perhaps someone who is brilliant but perfectionist and not interested or capable of doing the work to glue/shim a canonical example into a working product.
Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.
True, and this is one of the harder lessons to act on. Brilliance in = brilliance out, right? At the most basic level shipping product can be the difference between fail-pivot-success and fail.
The people who are really getting somewhere aren't the people who are always out for drinks
Too true.
As a side note, there are an awful lot of people who seem to go to a different startup event every night of the week, and then some hackathon over the weekend.
I generally find it's the other people who are getting stuff done.
> A nice thought, as a lot of people view networking only through the lens of "what can I gain?"
One thing that stuck out to me as a founder going through TechStars was the advice: "Ask them [mentor|investor|founder] if there is anything you can do for them."
"It's really easy to become hyper-critical and respond to every idea with "yeah but that won't work because of x". This is lazy, don't do it."
I'd say that while this is true, there's an important "other side" to this, that not everything is a world-changing, ground-shaking idea that's going to revolutionize the way the world works. Sometimes ideas are indeed stupid, and one of the things I don't love about HN is the echo chamber effect. If everyone is telling you how great things are, coupled with 17 ("Constantly exaggerating how well you're doing can be very tiring.") things can disconnect from reality quickly.
> Sometimes ideas are indeed stupid, and one of the things I don't love about HN is the echo chamber effect.
However, Hacker News is one of the surprisingly few communities that will tell you if your idea is terrible, which is one of the reasons for the recent "gratuitous negativity" controversies.
I'd always rather work with someone who ships over someone who's technically brilliant
Lets define what ships means then. Does that mean that they are just really good at debugging so that the limited features you do have don't break? Does it mean they know how to distill exactly the use cases needed so that you don't develop more than necessary?
I can think of many ways to ship something that is incomplete, but that doesn't mean it's worth anything so I am curious about this statement.
I've known a few great starters, a few great finishers and a lot of neithers.
The starters could rapidly invent brilliant tech and get it to a prototype phase that looks beautiful on the surface, but is unshippable under the hood. When it came time to clean, polish and fill out all the annoying details, the starters got bored and distracted. They either slowed to a crawl or convinced themselves that some new invention is necessary to ship what they are supposed to be finishing.
Good finishers are actually more rare than good starters in my experience. The finishers I've known are terriblely uncomfortable at the start. Everything is too vague and open ended. They weren't terribly imaginative or inventive. But, when it came time to ship they got in gear. Here's the burn-down list. Fill in the details. Check the schedule. Get it wrapped up, put a bow on it and shove it out the door!
Some companies die before they even ship a product to customers, and actually getting your imperfect product out there in front of customers is a really important and difficult step to take, and usually results in you finding out you need to change it in significant ways you hadn't even considered.
Some companies die after they ship because they used up all their money just getting to the shipping stage and run out of time.
What you are defining is a single event. Shipping is a constant process. "ABS" always be shipping is pretty much the standard, so your definition makes no sense.
Maybe I am just crazy though because isn't that the whole point of Lean startup, MVP etc...? You ship before things are ready in the "pretotype" phase?
I'm not so sure if it's the standard? I've seen many startups that took 6-12 months to ship the first version of their product. Usually the owners had read Lean Startup but still wanted to fix that one more thing before releasing anything.
Coding something for more than half a year without any real users makes selling the idea difficult, and makes any setbacks bigger in terms of lost morale and keeping momentum.
getting the product out is one of the hardest things for a early stage startup. people who can ship will increase the possibility of the product being released .
small example :
Business guy : guys we need to send a welcome email after a user registers.
coder1: adds code in the registration controller . ( 10 mins ) done.
coder2 : I think its better to use a event system to create an event for user registration and use a spool to send the email.
coder2's "idea" might be technically better than coder1's implementation but its waste as Coder2 doesn't actually take the initiative to code ..he knows just about everything in CS and for some reason prefers not to code . And still argues that coder1's solution is not correct.
"coder1: adds code in the registration controller . ( 10 mins ) done."
And once your code accumulates enough of these 10-minute hack jobs, it becomes incomprehensible and unmaintainable, and every little change will break something. At that point, progress grinds to a halt. You'll then need someone like coder2, who has a talent for system architecture, to refactor them back to a sane state again. (I've been both coder1 and coder2, under different circumstances.)
This is a pretty good example of what does it mean to be good at shipping. Sometimes you have to acknowledge that what you are doing right now is not the best solution architecture/design/whatever wise, but it provides the best quality/cost ratio.
Of course, it shouldn't be used as an excuse for releasing simply crap solutions. Experience comes handy when it comes to deciding whether it should be improved or it is good enough and should be refactored some time later.
Well, coder1 is leveraging technical debt. You have to find a balance because that 10 minute hack will come bite you in the ass later - sometimes only days later!
I interpret the author's use of "ships" to mean "gets shit done" - which I agree 100% with. It's too easy to get seduced by the dazzling technical mind, and in my experience these folks are great on paper but have an odd way of causing nothing but chaos outside of their specific talent.
Have you been around people who own a project from start to finish and nothing but their name is on it? The most common holdup is that it's never good enough for them. I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years. The reason for things like that is usually they don't ship a product and when you don't ship you don't have feedback motivation to work on the important things (or sometimes no motivation to work on anything at all)
I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years.
Perhaps speaking to the net result of the product, you maybe could have done that in a couple months... But there is far more to building product and a company than one developer coding in a room. I highly doubt that you as an individual can create a solution that matches a good team with domain knogwledge, in fractions of the time it took them.
This makes me think of 2048 the game, where the Dev took some time to build it, released it, and in hours there were clones in the App Store. Sure anyone can reverse engineer anything. Especially web sites where you are given their code. But thinking through, debating features and functionality, truly solving a hard problem takes time.
That's precisely my point, although reading back I did a terrible job at making my point. I'm not a quick awesome rockstar or w.e. - I just know the value of getting something into users hands fast and finding out what my users think is important. With that motivation you don't sit around all day theorizing and rewriting your perfect little flawless gem and you get something out there that is always a little dirty, but continually meeting a need rather than sitting around fluffing someones ego.
Their end product took quite a few iterations because they saw things they thought were better and started over so many times. You don't do that when you are solving problems for people, you can't just throw something away so you get dirty and you solve real problems. Sure, you're not going to win internet points on hacker news for the most pornographic code base, but you're actually helping someone with your code.
Haha, you have a good point, but 2048 is a terrible example because it's one of many clones of Threes. What you said applies very well to Threes, though.
The classic example was RMS cloning the features Symbolics created. It was possible because once you have figured out what to do, doing it is just code, that is the easy part.
Have you been around people who own a project from start to finish and nothing but their name is on it?
I actually have never seen this. Everyone I have ever interacted with who was working on a project either had it in a customer's hands (so they said) or had it available on github for people to look at.
I am sure it exists, but I have never run into anyone who refuses to release their work to anyone at all. In fact it's generally the exact opposite, they can't stop telling people about it.
This one is huge. I had a manger once who confused linear growth with vertical growth, and as a result our entire engineering staff was spread thin trying to make progress on a large variety of mediocre products.
You get fooled into thinking you're on to something, when in reality it's a zombie. Which can be a great lifestyle business, but your (potential) VC backer may be less enthusiastic.
Sounds like the company I currently work for, sadly. We have .NET, Python, PHP, Java, Node, and front end developers. Most of them are entry and mid level. Owners are constantly trying to get anything and everything through the door. It makes for a frustrating work environment and usually unhappy clients. Sure, we are growing ... just not in the right direction.
I think the key phrase is "can be worse than no growth". Linear growth of 5% a year on small base sucks and can be worse than no growth because it provides an illusion of progress. A team could be working on something with a much greater return instead. If a team saw no growth they may have abandoned the project entirely instead of pushing onwards through mediocre or lackluster growth (relatively speaking) for a longer period of time.
5% a year isn't linear growth. It's exponential growth, but with small factor. $1,000,000 a year or 1000 customers a month are linear growth. I'm not sure what exactly OP meant but I've definitely seen cases where there was definitely a non-compounding ROI for marketing efforts, e.g. if the company spent $100K on ads they might get $200K of sales (or $50K :(), but as soon as they stopped the advertising there was no lasting boost to growth. This can lead to really unhealthy investment cycles where money is poured into the company, it's spent on promotion and generates corresponding growth, but as soon as the money is used up growth trails off and another round of investment is needed.
It would be exponential if it was compounding, I stated "Linear growth of 5% a year on small base". As in, a 5% growth on a $100 base each year which would be $105, $110, $115. Contrasted with 5% compounded growth on $100 of $105, $110.25, $115.76.
People don't steal ideas. Tell as many people as possible. Never ask someone to sign an NDA before hearing your idea, you'll instantly lose all credibility
I find this hard to believe and can see why experienced people would keep startup ideas close to their chest.
People copy success, not ideas from random people they meet at parties. It's really that simple. Once your idea turns into a success (that's a lot of work), then people will start wanting to copy you.
I can assure you no one wanted to copy Pinterest when it was just an idea. Most people think your idea is bad, they are just too polite to tell you.
Experienced people don't keep their ideas to themselves. They don't tweet about them or write blog posts about them, but they definitely do discuss them with their peers, networks and mentors. That's the critical point. You should tell people whose opinions you trust and value because without their input your idea is worth much less, and the chance of them stealing the idea and executing it better is absolutely tiny. If you genuinely trust someone there's no need for an NDA.
Plus, the number of times anyone has been burned by not having an NDA in place is probably a million times fewer than a person has been helped by someone they shared their idea with. Sharing is helpful far more than it hurts anyone.
I believe the source of the confusion is the difference between your secret sauce and your elevator pitch. They're talking about the elevator pitch. If "everyone" doesn't already know your elevator pitch, or at least doesn't hear it soon, you've probably failed. They're not talking about your secret sauce like, I donno, your AWS login credentials or a really interesting development roadmap or your financial or marketing strategy or something like that. If you can't separate your secret sauce and your elevator pitch that's also a serious problem.
The elevator pitch for facebook is we're gonna get prime demographic young people to look at advertisements on our social website.
The secret sauce in the roll out was to try aspirational marketing where only ivy students can join and diffuse out thru cool/rich. The medium term secret sauce was something like the pages don't look as foul and obnoxious as myspace pages by dramatically limiting them and the real name policies. The longer term secret sauce is the content they view is sneakily going to be provided by the viewers for free via social networking effects luring them on.
The idea stealing myth originates from people (cubicle drones) who have so few ideas of their own, that when they finally have one, since it seems so scarce to them, it obviously must be valuable and thus worth "stealing". Unfortunately, this kind of people also lack the ideas necessary to realize the few "precious" ones they have.
Who does have a chance of realizing them, are people with lots of ideas, also about how to actually implement ideas. However, when you reach and surpass the "idea a day" treshold, while being able to implement maybe 1 or 10 each month, you get to discard hundreds of your own ideas each year, making them pretty much worthless.
So you should never be afraid of sharing your ideas; whoever you're telling them to, will either not care, or fail miserably trying to "steal" them. In each case you're safe. As for the monthly surplus ideas, if you're not implementing them, you risk nothing by sharing them either... except maybe feeling dumb in the off chance of seeing someone else successfully implementing an idea you thought was worthless.
PS: in the even rarer case of sharing an idea you're implementing, and someone else beating you to it... you suck, do something at what you suck less.
All true, and I would add that the sharing of ideas helps you to refine them, in the same way that describing a programming problem to someone else often helps you resolve it, because you have to structure the problem in language that makes sense to the other person. Sometimes simply structuring a concept in a way suitable for speech presents obvious answers that weren't possible when it was a ton of internal dialogue.
Yeah, exactly. If you have just a couple ideas and you think they're great what are the chances they're actually great? you should have dozens and be pretty sceptical and critical to filter out the really good ones.
Context: Rocket Internet is the name of the German company operated by the Samwer brothers, who have a reputation of cloning silicon valley's latest and greatest ideas for the German\EU market. Not technically doing anything illegal but certainly not held in the highest regard.
However they also consider their strength to be execution not innovation. That doesn't rule out ideas that seem like "obvious wins" but have yet to be tested.
Edit: Apparently in their mission statement they claim to only use proven ideas, but I still wouldn't do business with them regardless.
I agree, though I've never really agreed with the concept that idea and execution are separate things. I see an "idea" for a software application they way I see an idea for a novel. The execution and idea are very closely intertwined. Even intertwined is probably the wrong word, because that conjures up an image of two different things that are too tangled up to separate. I'd go even farther. The idea becomes the idea through the execution.
I suppose there is a sort of genesis of an idea, but even that probably already arrives with images of a UI and perhaps code in your head...
Even in Rocket Internet, the value is mostly in the execution, they have the resources and the expertise to copy any kind of project and they can create a whole team from scratch really quickly. And they are not going to spend anything on an unproven idea, before being copied by Rocket Internet you have definitely more important things to worry about.
> they are not going to spend anything on an unproven idea
Exactly!
It's even in their mission statement:
> Rocket identifies and builds proven Internet business models and transfers them to new, underserved or untapped markets where it seeks to scale them into market leading online companies.
This is the general motto for a majority of people. If you've done several startups with big exits, then yeah keep your idea behind NDA's because you can.
For everyone else, no one is going to steal your idea. Even in the remote possibility that they somehow would, then you better be more motivated then them and should be well enough ahead that they can't catch up.
I don't find it hard to believe at all. The simple fact is ideas are cheap and everyone is full of them. Execution matters. The idea does not.
An NDA is appropriate for something that is a bit closer to fully baked than just an idea. If you've got a proprietary algorithm or business database that you don't want to leak, then an NDA is appropriate. If you're demanding an NDA just to talk about an idea that you haven't even started working on yet then you're just wasting time and oxygen.
I agree with you 100%. I used to live in a small town and worked for a company whose CEO was infamous for stealing ideas. According to him, he wasn't actually stealing ideas, he was just implementing other people's ideas without them.
The typical scenario -- according to him -- was someone would pitch an idea to him, then he would counter that they should go half on the seed money. If the person wasn't able (or willing) to come up with the money, he'd implement the idea without them.
How many of those ideas were given the full attention of the CEO and turned into large businesses? It seems like it's easy to take an idea and start to implement it, the hard part is if it doesn't "go viral" or take off massively you now need to really invest more than just money in it.
Be careful about this one. Don't freely tell your idea to people who have the wherewithal to then go and build it, because they just might. What Mark Zuckerberg did to the Winklevoss twins should be enough of a cautionary tale for any entrepreneur.
The Winklevoss twins were destined to take their good idea and turn it into crap that Zuckerberg wouldn't want to be involved with and they did eventually turn out a turd.
Very much so. Friendster and MySpace were already prominent.
Zuckerberg got the inspiration to do Facebook from the project the Winklevoss twins were trying to get off the ground, and further to do an elite social network riding off of Harvard. That was their primary contribution to what became Facebook; which is to say, not much.
An idea alone is very hard to copy unless you have deep expertise in that area and can quickly understand the problems it solves.
For example, you describe me an idea for some SaaS startup targeted at constructions companies. I have no clue about this industry, so no matter how well you describe it to me I simply can't judge it and definitely can't implement it.
Even if you are an expert on the target audience and their problems, the small details that make the difference, you can call it vision, are normally not part of the 'idea'.
Everyone thinks this until they start pitching ideas. No one wants to steal your idea; in fact, the most common reaction is to explain why your idea is stupid.
I'd tell as many people as possible about what I have built, but I might stay a little quiet about what I am building until it is ready to show.
If I have what I consider to be a good idea, and I am actively pursing it (i.e., writing code to implement it), I would probably keep it close to my chest until I have something to show.
I think people are missing a key point a little bit. It's not about telling people your idea, giving them your idea, it's about getting feedback from them, its about learning from others.
Like everything else, it's a tradeoff. Knowledge about certain market topologies actually can constitute a tremendous advantage, although NDA's are employed far more than is actually necessary.
It is often inexperienced people or "business" guys without any technical background who think they have the billion dollar idea when in fact there are a thousand people who had the idea before who couldn't or wouldn't execute.
So, that advice goes for them: forget NDAs and get good feedback. On the other hand, if you really know what you're doing, you'll know if the idea has a lot of intrinsic value and/or potential for being easily stolen (infrequent and often unpredictable in those rare cases), and who you can to talk to about it.
More often than not, "ideas" are pretty simple and valueless and even the best execution can't do much to keep the business afloat. Many successful ideas come from something as simple as merging several different fields (only an expert in both fields is likely to come up with it), or simply from some enabling technologies maturing enough to have everyone and their dog execute the ideas they had but couldn't build successfully before (tablets come to mind, many mobile apps and so on).
Experienced people would know what to do with their ideas. Who to talk to to get advice, what to keep close to their chest or not. Others would benefit greatly from any advice at all they could get and for that they need to run the very small risk of telling their idea to others.
Somebody with more funds and connections could ship your idea before you rendering yours obsolete. In the case of a hardware based startup they could even patent the idea first.
Anyone with the resources and gumption to outperform you at your own idea is someone who has their own ideas. They aren't looking for ideas to steal, because ideas frankly aren't that hard. They're looking for progress on the ideas they have.
The one point I would elaborate on is listening to customers. This deserves more attention because listening to what customers _say_ can be a disaster. People will tell you all sorts of things about what they think they want and need. A lot of the time they're wrong. This can be worse than just building things you want or think are important.
Listening to customers really means measuring what they respond to. Or, to put it another way, ignore what they say, see what they do.
A lot of great items here, but number one resonates the most. One of the most common problems I've seen on any project I've ever worked on (my own side-projects included) is a difficulty in saying 'No' to things.
The list itself would benefit from the same advice -- cutting it down to half as many items would have upped the overall quality IMO.
In those cases, I fall in love with the projected result. Visualizing a bunch of people happier because some obstacle is removed is motivating. More so when they start emailing you their joy over this pain point being removed.
Do you have an unlovable problem in mind? I guarantee I can recast it as the sexiest most important problem there is.
Edit: On second though, if you can show that there is big money in solving [unlovable problem], I wont have to recast it. 1000 bay entrepreneurs will be stumbling over one another to recast it on their "Join The Team" page.
Farming would have fallen into this category until recently.
Pitching anything farm tech / data related in the bay area between 1994 - 2012 or so, would have mostly fallen on deaf ears.
Under no circumstances would you have run into a scenario of 1,000 bay area entrepreneurs stumbling over themselves to copy your farm tech startup ten years ago. You can be sure there are blind spots of opportunity today in the same way.
I work in enterprise myself, and I'm in love with my problem, not my code. But it's a problem of large-scale software development, not a business problem directly.
Not sure I get this one right. For me, some growth is better than nothing. If your growth is linear, it means that you have something like n new users every week, which is probably because they found it through ads or something, but they don't recommend it to their friends - otherwise, you would have every week n+knumber_of_users[previous week]* and the growth would be exponential. I suppose that's why OP is saying this, but I think the real metric is not growth, but retention. Better to have a few users who stick with your product.
Yeah you're totally right, it's a huge over simplification. I was specifically thinking of the scenario where you add roughly the same number of users each period, where that number isn't really enough for it to be a viable business but because there are some users, it becomes really hard to say "this isn't working" and either radically change something or quit. Agree that retention is often a much better metric.
Kongregate always had decent-but-linear growth and very good retention (of registered users, not so good for guests). Worked for us: here's a graph of web sessions per day with the units taken off.
It flattened out as mobile took all the growth out of browser-based games. It took us a while to figure mobile out but now we're doing well as a publisher/marketer/funder of indie free-to-play games.
Wow, I don't have anything useful to add, but I have to compliment the author. Every single one of these is spot on, and almost perfectly mirrors my experience. Great post.
These are some great points, yet this one made me scratch my head:
> 44. No-one has ever used a Bitcoin ATM for practical reasons
I've used one because it was more convenient and anonymous than giving a scan of my ID to an online exchange, or meeting a stranger in-person to do a trade.
It was moved from Workshop Cafe, it's now at 2415 Mission St. housed within "Nakamoto's", a Bitcoin-only store. They actually have two there now. http://nakamotos.io/
Personally, I found that my ROI for time on HN is a decaying function.
During my first year here, it was extremely valuable. I've read about many things that I didn't it exists, read comments written by far more experienced people. However, a few years later, there is a lot of repetition and normally I stick to HN newsletters and filters by points.
> 4. Like it or not, most networking in London is focused around drinking. Find a way to deal with that without having a constant hangover.
One of my classes at uni taught me that doing drugs (especially alcohol) is sometimes necessary for getting things done, but I still wish this wasn't the case.
I think Europe is more beer-centric than the US, but here you can always ask the bartender to put a lime in your club soda to make it look like a cocktail... Bartenders are usually pretty friendly to people that aren't actually drinking, whether you're the DD, recovering, or just don't want to actually drink.
This is my strategy at any networking event. Usually have one drink then switch to club soda and lime. While many others are pounding back drinks because "free bar", I'm slightly loose and able to hold intelligent conversations still.
This was an engineering leadership class at MIT. The advise specifically was first an anecdote about working in Japan and going out to get piss-drunk on sale after work and then a generalization of that to drinking as a means to networking in general. My generalization to other drugs is my own. Since there is no moral difference between alcohol and marijuana and there soon won't be a legal one.
The reason why alcohol culture frustrates me is that in high school, I had an older friend who started going to AA and brought me along for moral support sometimes. I've since grown up, developed a fondness for craft cider, and realized that I personally don't have much to worry about from addiction. But for the same reason I think startup events should be expected to be wheelchair-accessible, I think folks should be cool with teetotalers.
>This was an engineering leadership class at MIT. The advise specifically was first an anecdote about working in Japan and going out to get piss-drunk on sale after work and then a generalization of that to drinking as a means to networking in general. My generalization to other drugs is my own. Since there is no moral difference between alcohol and marijuana and there soon won't be a legal one.
Interestingly I read an article (perhaps it was posted here?) in recent days about westerners struggling in Japan and one key point was the expectation to go out drinking heavily after work every night.
I can see the merit in holding networking events surrounding drinking as alcohol will (perhaps) get people to put their guard down, relax and socialise more than if everyone were stone cold sober.
I will be interested to see what happens with regards to marijuana and networking events. Though the moral argument against marijuana is gone, there is still a stigma associated with the drug. In many professional circles cocaine is currently more likely to be the accepted drug of choice than marijuana (going by personal experience).
Marijuana is also different to alcohol in that one can have a few drinks over a reasonable amount of time and be more relaxed without getting intoxicated, however a few drags on a pipe with reasonable marijuana in it will cause rapid intoxication. How well that bears for networking events is something I'll certainly be interested to see!
I disagree with the generally accepted one- build something you want. This is a fine thing to do but the overwhelming majority of good software business ideas aren't for consumers or developers. The overwhelming majority of workers who have problems that could be fixed by software are not developers. Lots of opportunities out there...
Building something you want usually means that you have a deeper understanding of the problem. Also, chances are, that you are familiar with the market, alternative tools, etc. Which is a must for creating a good product. Actually wanting to use it adds a little bit of passion which definitely counts in the early stage.
clearly there are advantages if such an opportunity presents itself. Of course if you are a programming by trade, chances are it will present to a lot of your peers as well
> 5. The people who are really getting somewhere aren't the people who are always out for drinks
I would add that networking is ok (specially with your customers). But being always networking with the entrepreneurs in your area won't drive you anywhere near success.
Someone once told me this advice that I try to remember myself every once and then:
"Less networking and more working"
Also, although the list of advices nails it at mirroring my own experience, I know that I would not follow most of them. For an unexperienced entrepreneur it's difficult to discern good from bad advice.
Any first-person accounts to support "Linear growth can be worse than no growth"? Seems like something important, but not quite clear; a couple of real world examples would really help.
I guess the underlying message here is that a product can limp on with linear growth, sucking the team's time and energy that they could be investing elsewhere.
Conversely no growth is a clear call to action that the product sucks, and needs to be abandoned!
Very interesting points. I agree with many of them as they reflect my own experiences.
Assuming you are the author :) Could you elaborate on 3 "Always refuse if someone asks you to sign an NDA before hearing their idea".
This is something I always find frustrating, but I usually end up signing the NDA as it seems irrelevant to me anyway. I'd be interested to know how people react when you tell them that you don't want to hear their idea. Do they change their attitude towards it, or you don't follow up?
In my experience, if I explain that I won't sign an NDA and they don't return, I've dodged a bullet. Last one was an older guy who wanted to rebuild eBay on a strict budget and just wasn't at all comfortable talking about his idea without an NDA. I'm willing to bet, months later, he's made very little progress.
I don't think I've missed any quality opportunities with this approach.
I'm always very polite about it and explain my reasons.
Hey, author here. My logic is usually that an NDA is a restriction on me, so I won't usually sign one unless I'm getting something in return. E.g. I'm happy to sign one in the context of a piece of paid work.
Most people are quite receptive when I explain the above and that in practice I don't believe that ideas really get stolen. Well not (web/app)tech startup ideas anyway. I've never had what you'd call a "bad" reaction to it and in about 75% of cases, people have then gone on to explain their idea.
To add to the other comments, it also shows the requestor to have incredible hubris and/or naivete. An experienced entrepreneur understands that raw ideas have virtually zero value, it's the team and execution that matter. If an NDA enters the conversation it's possible that you're speaking to one of the perpetual "idea guys" in search of coders, and you should terminate the interaction quickly.
> It's really easy to become hyper-critical and respond to every idea with "yeah but that won't work because of x". This is lazy, don't do it.
I've a close friend who does this -- I wouldn't even call it being 'hyper-critical'; I call it snark. It's a really negative personality trait and one I take pains to avoid.
As Sam Altman said in his How To Start A Startup lectures: usually the best ideas are a little bit weird.
There are some gems in here, mixed with some highly-specific and perhaps contingent observations. I wish everything on the web, especially this, could be split apart and commented on it a sane way.
A few years ago, I used Diigo [1], it's an extension that let you share a website and comment on it, anywhere. It's been a long time since I used it, I don't really if it's still active.
A bit uneven as a post. Some really, really great advice, some more questionable I find.
>The logo doesn't matter at the start, find a simple text based logo you can re-use for different projects
Not convinced. Your logo will follow you around for a long time, regardless of what you tell yourself. People will see it and associate you and your startup with it. Doing a large rebrand is difficult, costly and time-consuming.
While on the flip side of that, investing a lot of time and money to get a logo done when there's a 50/50 chance the company might not make it another six months seems a waste of both.
This is the problem with startups, you just never know. Should I work on growing my brand and banking sales, or stop and spend a bunch of time deciding on a logo? The branding will come if the product and the business model are there. Also, some of the most famous brands have the simplest logos:
Yes, I thought the same. I enjoy pg's essays and, while not comparing both styles, it's refreshing to see a bullet-point blogpost with well thought content, unlike the usual "You won't believe these 10 tricks all successful startups have in common"
I'm not the author, but I think it's related to the following point about failing fast. It's not a good situation to be pouring yourself into a business that just plods along, never really in danger of going bankrupt but also never in danger of great success. A clear failure would be preferable because it would be a lot easier to walk away, pivot, start over, etc.
Sometimes startups are funded early based on track record and opportunity. If they instead launched and demonstrated lackluster (linear) growth before seeking funding, they could have a much harder time convincing investors of the exponential growth potential. If you're going for VC dollars, you really need to have a compelling story about how you will grow to be huge, and having some history of linear growth is a counter-argument to that.
Really great list. #61 can not be overemphasized and includes blogging. I got one of my blog posts in a phd thesis last year (tried so hard to hire that kid!).
Because comparative advantage. Do what you are good at, and pay for what you are not good at. Spending time on learning has an opportunity cost. If your opportunity cost is low i.e.: your current income is low, then maybe learning to program is a good idea. But if you make 200$/hour, you are better off finding a technical cofounder or outsourcing it. besides, having a technical cofounder lets you focus on other areas of the business. At least this is how I see it. The Woz/Jobs tandem would be a paradigmatic example of this.
1. They are probably extremely selfish.
2. If they think they need an NDA in a conversation, then they probably don't know how to think well enough to have an idea worth hearing.
1) NDAs are pretty much unenforceable. If someone asks you to sign one, that means they are very new to the business, and probably have a lot of other mistakes to make.
2) It shows they don't trust you. My rule of thumb is: distrust is a disease that NDAs won't cure, and indicates much deeper problems. If you don't trust someone, just don't share with them.
> It's really easy to automatically dismiss everyone who starts a conversation with "I'm looking for a technical co-founder". Doing this means you miss talking to some interesting people. But be upfront that you're not that co-founder so no-one feels like their time is wasted.
This is a good point. I suspect many people here have grown tired of hearing "dude I have this idea for an app..." I just graduated from college and many of my nontechnical friends who went into finance are realizing they hate it and want to get into tech startups. During college I was always busy so I shrugged off these conversations. Now I have time to listen, and it turns out, many of them actually do have good ideas and business models. They just don't know how to code them. But these are smart, well connected people who can raise money. Dismissing their ideas is foolish and could certainly be a waste.
I realized I can monetize all my friends asking me to help with apps. I have a team of programmers I've worked with overseas, and I know how to manage them to complete projects. I've started offering a service to my friends where I take them from idea to MVP (usually a basic CRUD web app). I translate ideas to technical requirements, write a spec, divide it into milestones, negotiate payment schedule, and manage the project to completion. I structure the price per milestone so that my team is rewarded for hitting deadlines, e.g. Milestone X (some subset of feature requirements) pays $1000 by 4/31, or $1500 by 4/24. This has worked well for me in the past and is a good way to keep projects on schedule.
I just started doing this, and I've gotten a new lead or two each week so far. None have been serious enough about the idea yet to immediately execute, but I suspect with some pressure applied they will be ready.
I spoke to an alumnus from my school who graduated 3 years ago and did this in an official capacity. He started a "product development consultancy" wih a hybrid employee/outsource model, and tapped his alumni network for projects. His company completed 39 projects in its first year, all sourced from networking.
If you are an engineer also blessed with a strong network and interpersonal skills, I suggest you look into this as well. You don't need to code every app that someone wants help with. Often you can help give direction, or even charge for your services of managing an overseas team. People who leave finance are a good match because they can raise funds to the point that you can offer cheap, quality service from a friend, but also pay your developers way more than median salary in their country. I think of it like arbitraging my networks and skillsets.
Regardless of whether you do that, I definitely recommend putting an end to the habit of ignoring the app ideas of your friends.
A lot of these 'problems' and 'lessons' seem to come as a byproduct of being a part of a 'scene' to do with startups, particularly uninspiring web and mobile startups. 'Uninspiring', to me, means people doing a startup for the sake of doing a startup, not because they're passionate about the problem, have found a good opportunity/market to exploit, etc.
One of the best pieces of advice I got was to not associated with losers. It's harsh, I know, but if you see people around you not being productive and successful, chances are you're in the wrong peer group. Better to have a smaller and higher quality social circle than to let your time be wasted by 'the scene'.
There's a good heuristic - anytime someone calls something a 'scene', it's time to leave. It means the people are interested more in the idea of what they're doing than the real thing.
It's also one of the hardest things to avoid - associating with losers. That is because the losers tend to look for company and make it easy to join their groups, while the achievers and doers jealously guard their time and acquaintances - which is why they are achievers and doers.
A neat way around this can be to start doing recreational activities that achievers do. Taking time to develop skills in whatever that is will help to make friendships and relationships that matter. This doesn't have to be as obvious as joining an expensive golf club - in fact, that club might be populated by losers in the 'golf scene' - golf is horrendously time-soaking. It could be an early morning cycling group, could be anything. It's most likely not a pub-visiting binge drinking group.
-1 co-founder was a designer and after I finished the product (I'm a developer), took 6 months to make changes that could have taken a week or two. Without a boss telling him what to do, he had no motivation to finish anything in a timely fashion. This failed before it got off the ground, but I built lots of nice libraries that I still use today.
-1 co-founder (a developer) gave up after he had to work on the boring parts. A few years later I gave him another chance. We were going to start a consulting business together and I figured, because he already had clients, that things would be different from our previous experience. Well, he took me to his lawyer and wanted me to sign these completely 1-sided contracts where everything I built in my off-time was owned by both of us (he knows I had other companies). He also wouldn't take any risk and give me ownership in his current contracts, but I had to give up mine. Before I even had a chance to tell him no, he changed his mind once again and wanted to "wait a month". 3 months later, I politely told him I wasn't interested and he now works a 9-5.
-The last time in my poor decision making was partnering up with someone that had no tech (besides checking email, etc) or business experience. I was to do all of the development and I figured he could learn the business and marketing skills along the way. His job in the beginning was to do all of the content-creation (which is not easy).
Well, after alpha 1 I built the entire site and he created 5 articles (which was enough to get some people testing it). He was unwilling to learn anything about marketing (because I was better at it as he said) and wanted to farm out all of the content creation to other people (which is a good idea, but not at this stage in the business..especially when we are strapped for cash).
So now we are in a situation where he has nothing to do and my job is to: get customers, design the website, fix bugs, and make business decisions. I'm basically running the entire business myself and he, as an equal partner, is sitting around waiting for things to happen.
So what does he decide to do? Comes up with un-realistic ideas for future business plans that of course only involve things that I will be working on and not him (since he has no tech experience). I also had to fight against his ideas and continue to convince him that we shouldn't be working on the next "Facebook for X" and on the task at hand that had a real chance at making money. This involved hours and hours of phone calls and meetings that took me away from the site that was in alpha. That was another issue: nothing could be explained by email to him, only by phone or in-person.
Everything eventually fell apart and it was a very frustrating experience. He was also a good friend, which made it even more difficult.
I feel like some people like the idea of running a business, but have these un-realistic expectations when it actually comes down to doing the work. I've learned some hard lessons, but I think it will help me in the future when it comes time to find another co-founder.
Maybe try going it alone. I know it's counterintuitive but sometimes building something by yourself is the best way to find a co-founder who's actually any good. I never would have joined the current project I'm on (which is going really well) had the designer not come to me with these amazingly beautiful mocks. Before working on programming projects I had similar experience with music projects -- I'd be trying to put a band together to write songs. I learned that it's a lot easier to get people to work on your projects if you've already started them. Incidentally, it seems to be the same with investors, employees, whatever -- they have the pick of the litter and they'd rather not be first money in. Everyone wants to feel like they're getting a deal and everyone responds to FOMO.
Take your time and find the right partners while you build your businesses - the same people who advocate having cofounders also take the position that the wrong cofounder is worse than none at all.
It's not gratiutously negative - or even negative at all. It's a matter of fact. The advice in that column will not lead you to create a successful company, so take it with a healthy dose of humility and with a grain of salt.
Indeed, while your post can be considered harmful, mine cannot.
Yes and no. There's a major difference between "picking up" and actually being good at something. If you have nobody on the team that is either already intimately familiar with the language/platform, or has experience with various languages/platforms, you're going to be spending a lot of time figuring out how to do stuff properly instead of just building stuff. And if you are a startup with a limited runway, that difference is crucial.