If you're already established with a public product, then you should just go get the trademark. It's not that expensive. If you're stealth, then you could wait, but only because of your stage of company, not anything to do with YC.
Upon using your name in commerce you acquire common law trademark rights. Filing a trademark before you are actually using it in commerce requires filing an Intent To Use trademark application and will cost you a few thousand dollars in legal fees (or a hell of a lot more if you are doing international) - either that or you are doing it yourself with trademarkia, and, in that case, I wish you bon chance.
Try to choose a strong name, but be prepared to change it.
"Strong" means, in order: a completely made up word, a word that has nothing to do with the product being offered, a word that is suggestive but not decriptive of the product. For more information, look up the "abercrombie" test. https://en.wikipedia.org/wiki/Abercrombie_%26_Fitch_Co._v._H....http://berryentertainmentlaw.com/the-abercrombie-formulation...
If you want to search for competing marks, please note that this is an extremely technical process. You can try to search on TESS, but it is very difficult. https://tess2.uspto.gov
Note that this is only US trademarks.
Additionally, if your question is "how do I know if my mark will be infringing?" The answer is "that is an extremely hard and expensive question to answer." The touchstone of trademark infringement is the "likelihood of consumer confusion test," which is ensconced in the sleekcraft / polaroid factors. http://www3.ce9.uscourts.gov/jury-instructions/node/244http://likelytocauseconfusion.com/likelihoodofconfusionfacto...
The point of all the above is that you really do need to be a professional at this in order to have the wherewithal to make judgments about the likelihood of a trademark's success. In addition, it takes a few business quarters to a year and a half for a registration to issue.
The point of all this is that domai.nr is as important a tool as TESS, that you can easily get lost in the weeds on this issue, that your own judgment is in no way a replacement or a substitute for a licensed attorney, that trademark strategy is hugely complicated and can be a total sinkhole. What does that mean? It means that, for a startup, like many, many other issues, you do the best you can but keep in mind that you are going to have to spend a lot of time and effort on it down the road.
Tl:dr:As a startup in general: IF YOU HAVE THE MONEY, it is worth starting this process this sooner rather than later. If you do NOT have the money, a reasonable strategy is to move forward with a name that you like but are willing to change. It is okay to change your name very early on. However, the goal is to avoid having to change your name when you already have a product out and some market presence. For YC: Do you need a trademark before you apply to YC? Almost definitely not - unless you are already selling your product. Do you need a trademark before you start selling your service to enterprises or spending money on marketing? It would be foolish not to at least engage an attorney and start the process.
Note that many other IP attorneys may have different opinions. That's fine - reasonable minds can differ on this subject, the above is an extremely short primer. Also please note that I AM NOT YOUR ATTORNEY AND IF YOU ARE THINKING ABOUT FILING A TRADEMARK YOU NEED AN ATTORNEY.
Edit: shoutout to https://news.ycombinator.com/user?id=27182818284 for posting this PG blog post - extremely on point: http://www.paulgraham.com/name.html
Unless you are expecting somebody to steal/abuse your name, there's no rush to TM.
It's really a cost issue. If money is no object then there is little downside other than a) alerting people to what you are doing (tm apps are public) b) deciding if you will do it yourself or have an attorney do it for you.
Creating a legal entity is a bit more involved. You can apply for a trademark, pay the nominal fee and assuming you do the application correctly (in the right class) etc. you can just simply abandon it later if you change your mind. You would only be out the fee. Not like state paperwork which is a bit more sticky.
The date a trademark is put in use is important. So assuming you file as 1a and are using the mark getting it in early could have benefits. Blocking potential competitors and so on.
If you are on a shoestring and have little money then it most likely doesn't pay to apply for the trademark and spend that money which you might need for other things.
It seems that using ANSI to make new standard is unadvisable. The process is cumbersome and there are copyright issues with ANSI.
If there is need to revise the standard. Common Lisp folks can for less byrocratic organization to do it. Library standardization can happen organically.
Raymond Chen's blog in particular was good enough to get me to buy his book (which definitely did not disappoint).
Other ones I subscribe to are the Microsoft Edge Dev Blog , Mark Russinovich and Games for Windows and the DirectX SDK
And there's a few that have unfortunately not been updated for a long time, such as Larry Osterman, or have come to an end, such as Rico Mariani
Toptal has extremely active and wonderful blog for developers, designers and finance experts.
The reason I can make that claim is because Toptal's blog posts are contributed by members of our network, all of whom are verified experts in their fields, and we guide them through the entire process to help them write the perfect blog post.
We publish new articles almost every day! We invest a lot of love into maintaining our publication and try to publish the most useful content for fellow experts.
As for actual companies, as an embedded dev I think Atomic Object (https://spin.atomicobject.com) and Free Electrons (http://free-electrons.com/blog/) both do a good job.
Disclaimer: I am currently employed by Percona, although that is not my motivation for sharing this.
A close friend who really knows his way around marketing has been advising us to write more fluff pieces. We're really torn over this because we strongly dislike vapid content as consumers. I would be really curious to hear any anecdotes on the relative merits of the different strategies.
 - http://sangaline.com
 - https://intoli.com/blog/
- Facebook: https://www.facebook.com/Engineering?sk=notes
- Google: http://google-engtools.blogspot.com/
- Twitter: http://engineering.twitter.com/
- Linkedin: http://engineering.linkedin.com/blog
- Dropbox: https://tech.dropbox.com/
- Instagram: http://instagram-engineering.tumblr.com/
- Netflix: http://techblog.netflix.com/
- Flickr: http://code.flickr.com
- Etsy: http://codeascraft.etsy.com/
- Yelp: http://engineeringblog.yelp.com/
- Heroku: https://blog.heroku.com/
- Airbnb: http://nerds.airbnb.com/
- Bitly: http://word.bitly.com/
- Evernote: https://blog.evernote.com/tech/
- Highscalability: http://highscalability.com/
As an example, our frontend engineering team just wrote up a series of posts about implementing graphing in React, migrating from Redux:
And I wrote about recent backend changes to our time series storage: https://blog.serverdensity.com/time-series-data-opentsdb-big...
They run a pretty modern cloud stack using fun technology like terraform, which gives me serious envy as well as inspiration. They also have some ridiculously high quality posts with open source code included such as:https://segment.com/blog/the-segment-aws-stack/ (highly recommended reading).
Autodesk Stingray (formerly Bitsquid): http://bitsquid.blogspot.de/
I love it because the articles are often small, one off tips re: vim, the command line, ruby, etc. Really neat stuff.
- Apollo/Meteor: https://dev-blog.apollodata.com/
- Auth0: https://auth0.com/blog/tech/
- Chroma: https://blog.hichroma.com/
- LogRocket (my company): https://blog.logrocket.com/
A bit self-promotional since I blog there too, but I'm greatly outnumbered.
Really surprised it wasn't mentioned yet. They do really in depth posts and show metrics too.
I'm trying to get our tech blog off the ground but it's difficult to get buy-in from everyone.
This series of posts below describes in details how they built their database engine from scratch and the data warehouse service.
start here: https://eng.lyft.com/matchmaking-in-lyft-line-9c2635fe62c4
...a pretty mixed bag with some product & PR posts inside, but the gems inside (especially SRE / CRE life lessons) are pretty awesome.
Also, we're getting started ourselves with some quality tech material - not too much there yet, but our Debugging Postgres post got a lot of love from the community: https://www.justwatch.com/blog/
Especially @rimusz, who is not technically part of Deis engineering team (?) :
Partially self-serving post because I'm also published here:
Unfortunately there doesn't seem to be an index of the posts on one page! There are links to relevant posts on the sidebar and both of those have good relevant links.
These guys I worked with for a long time, to get my post out! It kind of stung a bit when the v1 PAAS was officially deprecated before I got to put it online. But in terms of support, the newer solutions are only better. The lessons learned putting this post out are still valid, even if the specific product of the tutorial is no longer relevant. (I used this process to create my own CoreOS bare metal cluster, and I don't actually use DigitalOcean in my day-to-day work.)
But the other content on the blog really was a good, focused introduction to Kubernetes and friends for me. Deis is the team that created Helm and it was subsumed into Kubernetes (and Helm Classic, which was another iteration before it was part of Kubernetes proper.)
Disclosure: I work there and have written articles for the blog.
At the moment we mainly blog about our experiences with Golang (our language of choice right now). But really it's open to any topic someone in our engineering team is interested in writing about.
We aim to keep things visual, interactive and example-based. For example Jim Fisher created an interactive animation of Golang's GC algorithm here: https://making.pusher.com/golangs-real-time-gc-in-theory-and.... We also managed to embed Golang's trace visualiser within one of the posts: https://making.pusher.com/go-tool-trace/#tour-of-the-go-tool... (using some pretty dirty tricks).
Ok Grow! blog: https://www.okgrow.com/posts
Differential blog: https://differential.com/insights/
Thinking further on this.. Apple is totally not in the picture or i do not know.
FittedCloud is a small start-up that does automatic cloud resource optimization. They post regularly and go into topics ranging from technical details of machine learning to cost optimization for AWS resources (EBS, EC2, DynamoDB, etc).
As far as I can tell, they are the only company around that can automatically scale up and down EBS resources in a way that the customer only pays for what he or she uses, rather than paying for over-provisioned, unused storage...all without downtime or performance hic-cup. These guys know a lot about the cloud and storage.
 - https://engineering.doximity.com/
Square put out a lot of fantastic libraries, and much of their output is basically essential for Android.
Most Scala consultancies/companies have their own internal blogs and most are excellent, for instance, underscore: http://underscore.io/blog/
For web dev, Netlify posts frequently and even has podcasts: https://www.netlify.com/blog/
With posts like these one: https://blog.packagecloud.io/eng/2016/06/22/monitoring-tunin...
On the other hand, Cloudflare, Stripe and Netflix have some awesome articles too.
It's not a corporate blog, but if you're interested in Python, go check it out for recent postings from Python-related blogs.
Lots of DevOps focus currently but also contains some stuff we're working on with machine learning, blockchain, and we are working on a much broader range of content.
Plus we'd love more feedback on the posts :)
This is a good one
I also enjoy the Hacker Noon articles 
I'm not trying to be a snarky asshole: the best thing you can do is build some things.
Maybe you can start by automating some chore you do for work.
People love to talk about themselves and their businesses. You will get a ton of positive response by picking up the phone (or sending emails) saying "I'm new to this sector and I've been learning everything I can online and through books and trade magazines. But I know I would learn more by talking to someone working in the field. Could I stop by Monday morning for 15 minutes and learn about your business. I'm interested in finding out how you came to even be in this business, what parts are enjoyable, and what parts are challenging. Thank you for your consideration."
The first day I was in Palo Alto (and the US), I had absolutely no contacts and was severely jet lagged. I had just moved to the US to establish my startup (https://journeyapps.com) in the US, raise "Silicon Valley VC" and chase the dream ;) tl;dr - JourneyApps is a platform for businesses to quickly developer mobile apps for internal use.
I walked down University Avenue, and spotted Palo Alto bicycles. I walked in (very nervous) and asked one of the sales people if the manager is in. Jeff (the manager), was there and asked what I wanted. I explained I'd just moved here, and was working on a startup that eliminates paper forms.
He was kind enough to not kick me out, and (because it was closing time), spent some time talking to me about how they sell bicycles and which paper forms he uses. He also explained how much of a pain it is.
I kept delving into the details of his business, which he absolutely loves, so he was keen to keep talking. After forming a good idea of what his world looks like, I asked if he'd be keen to do an experiment with us. We'd make an app that does bicycle sales on a tablet, and bring it to him in a day or two. The experiment would be free, he just needs to tell us what works and what doesn't.
He was really keen, and gave me copies of the forms he uses. Overnight we built an app on our platform that acts like his paper forms. The next day we rolled out in his store, and waited for bicycle sales.
The app worked, and we learnt a heck of a lot about US business culture, even though it was just a "small family owned" bicycle store.
Eventually we raised the mythical Silicon Valley VC money and got our first Fortune 100 customers, but the process stayed remarkably similar:
1) Find someone who's passionate about their business
2) Talk to them with genuine interest and learn about their world
3) Be upfront and open about which problems you think you can help with, and which not
4) Over deliver.
Fwiw, I've become mildly obsessed with this topic, and have written up a couple articles that may help:
* How to talk to customers: http://customerdevlabs.com/2013/11/05/how-i-interview-custom...
* Which customers should you talk to first: http://customerdevlabs.com/2017/03/20/who-are-early-adopters...
* How to ask for conversations: http://customerdevlabs.com/2014/02/18/how-to-send-cold-email...
You have two ways to build it. One is always coming from the outside, hoping for nice/stupid people to explain it to you, hoping to get shitty contracts to make some kind of money. This way will be the slave road.
The alternative is becoming an excited new employee at a customer or another provider for your customers and work there for 5-10 years. You have rights (like laws working in your favour), you have regular income, you are at the table where things happen and get some tips from people who work in that area for 10+ years, and hell, you may even save a few bucks that later can be used to found a company.
Yes, you'll be your bosses bitch, but only to some degree, because of laws. Customers will be much, much more cruel. If you can't bow to a boss, you certainly won't be able to handle customers yourself.
If you neither have rich parents nor business value, don't attempt to build your own business. People just say that because they are part of the economy that makes money from the sacrifices you take on your own, or at least have rich parents themselves and therefore don't even know that it can be a problem if one is behind rent payment and lacks $20k in funds.
- still at the idea stage, I began talking to people online on iOS dev forums - iphonedevsdk forum, and reddit.com/r/ios /r/iphone, etc
- I asked my friends who I knew were devs. I live in Poland, and my target audience is mostly US, so their feedback was slightly limited, but still valuable, because I could talk to them in real life
- as soon as possible I went to San Francisco, and went to any meetup I could find through my contacts, on Meetup.com, and Startup Digest
- I try to follow news as closely as possible (e.g. there is iOS dev weekly newsletter), and look for opportunities to engage in the communication. Even without mentioning the name of my project (which is AppCodes.com -- a shameless plug here :D )
- Sometimes I write to bloggers and people who write about my subjects about something I work on, to honestly gather their feedback, and of course to ask if they want to know more about my project. It's always personal.
After a few years of doing various projects, I noticed that it almost always takes around 6 months for the word to go out that I do things, and people start coming back to me by themselves ("are you still doing X?"). With time, finding connections is easier, but not faster - it always takes exactly 6 months :)
If you go to a small retail business (say a cafe) when it is not the peak hour, you might find the owner working there. It is usually not hard to get them in a conversation, many of them will talk your ear off. (Sometimes this even works for a supermarket or a large chain store.)
On that front, people usually like to be heard so if you do a lot of listening that takes the pressure off you. Often a good sales call is 90% or more listening to the customer talk.
I've gotten good prospects through LinkedIn and simlar means and have had very good luck (much better than 80%) at sending a message or email and getting an appointment for a phone call.
If I have any challenge here it is that there are people out there who really like to talk and talk and you can easily wind up having an absurd number of calls over a long period of time and get no sales. However, almost always in B2B sales you will need to make several calls over a period of 2-3 months. Big companies lke IBM can tolerate a sales process that runs longer that, but you can't.
But if you try to build a company, I assume that you want to solve a problem.
If you solve a B2C problem: talk to friends affected by the problem, or launch a Meetup based on this problem. You'll get free feedbacks and people LOVE to talk about themselves.
If you solve a B2B problem: talk to friendly businesses affected by the problem, or go to events and conferences as a vendor with kakemonos talking about the problem you solve. If the problem you solve is really important, you'll get plenty of people coming to your stand to talk to you.
Once you'll have a few "leads", you will be able to refine the market segments that are the most affected by the problem you solve. THIS is really important: for B2C, you'll have to target this segment in your future ads, for B2B, you'll have to target this segment in leads generation.
- "Should I try to approach bosses or common workers of companies?"=> Talk to the guy affected by the problem you solve. It might be the CEO, or a manager, or the worker.
- "Should I phone them, ask for an appointment, explain my goals and if they let me in, do the talk?"=> Yes, phone is better than cold email. But be prepared, it's really harder than cold email.
- "What is the right approach to talk to my potential customers?"=> Beginner script: Hi, my name is X, I represent Y, we solve THE_PROBLEM_YOU_SOLVE. Are you affected by this problem? Could we talk about this in person at your office?
Ok, that wasn't helpful. So let me try to break it down, without knowing anything about what you are selling.
I will assume that your service is to solve some problem in a particular business domain. From that you can decide on who would have the problem you are solving and how critical it is for them. Hair on fire is good. Nicer typography on the menu - meh. Nevertheless, you can sketch your ideal customer. Potentially only a very small proportion of your town's business population is a possible prospect. Once you have identified the businesses, you could look at who in those businesses would be most motivated to do something about getting you to solve the problem(s) you have identified and are capable of solving.
Then you go an talk to the people you have identified. You listen more than you talk and refine your approach.
For a far more detailed approach you could read "Four Steps to Epiphany" by Steve Blank. Customer Development Method might be exactly what you need to help you maximise the productivity of your time when you are out of the office, talking with prospects.
If you provide some details about your business then some HNers might be able to give you specific advice.
- Include an invite for a quick 10-15 minute chat in the welcome email (more people than you would think actually take up the offer)
- Ask them why they signed up (this is key to help you determine what problem people want you to solve)
- Ask them their biggest frustrations about the solution so far
And just take it from there.
I would schedule a phone meeting or in person meeting, and I would run through the script. After the meeting I would quickly write down all the answers off the top of my head while it was still fresh.
I did this for about 30 interviews, and then I created an answer matrix in a spreadsheet. My goal was to try to see if there were any common problems among the majority of people I talked to. The answer ended up being a big NO, but I did not write a single line of code in this process. It did save me a ton of pain in the long run doing this up front.
To properly talk to customers to identify if there is a need for your product/idea requires for you to not bias them by telling them what you are working on. You should be able to talk to your mom about your idea without her ever knowing that you have an idea for a product.
For example, I've worked with clients where we would insert an NPS question at some strategic point in the digital parts of their service. Not at a point where it would be intrusive, but rather, for example, at the very end of completing a bank transfer. Make it very small: 1) The NPS 1-10 scale, 2) Field for free comments 3) Checkbox to the effect of "is it OK if we contact you for more questions?"
This serves the dual purpose of finding people who are willing to talk to you, as well as giving you an idea of what they think of your service at the current moment.
You can now contact the people who put less than 9 on the NPS scale to do two things: 1) find out what you can do to improve the service, and 2) take care of the complaints they might have and improve your relationship to the customer in question directly, potentially turning a negative impression into a promoter.
Obviously, if the product doesn't exist yet, you will have to find a different way to reach your potential customers rather than inserting it into the existing service.
"Hello, this is cosmorocket, and I'd like to learn more about your industry. Can I stop by sometime and ask you some questions? Perhaps shadow you for a little while? I'll bring coffee and danish."
Just watch and listen. If you see them get frustrated by something, give them a moment then ask "So, what just happened?"
If you need b2b: LinkedIn, conference and trade show lobbies (you don't need a ticket to hang out in the lobby), email lists you can buy online. There are also companies that maintain lists of experts with every imaginable background you can speak to for an hourly fee; not cheap but worth it.
If you need consumers: survey panel companies will let you field a simple survey to people who match your criteria, who you can then recruit into a phone/Skype call. You can also recruit people yourself through well-targeted Facebook and Twitter ads. Craigslist works well; set up a short survey to prequalify people.
Money is a great accelerant. You will always find people who would talk to you for free, but offering to pay them for their time and expertise makes things go a lot faster. Plus, if you are on the shy side, money changes the dynamic. You are now not asking for a favor, but are offering to engage in a business transaction.
Six people is often all you need to start seeing some common themes.
But on the topic of how to talk to people, I really want to recommend the book by Dale Carnegie 'How to make friends and influence people'. Ignore the corny title and read it. This book has changed how I talk to people.
The biggest takeaway for me from that book was that people love to talk about themselves. Make the conversation about them; focus on their situation instead of on your product.
You're talking to them in order to understand the problem that you're trying to solve.
The best book on this that I've read is "The Mom Test", well worth the price
First you need to figure out who you want your customers to be.
If your answer is local coffee shop owners, then it's easy to make a list of customers and you can call them, email them, or visit them in person.
There are many places on the internet that give free advice on how to do cold calls, emails, visits, etc. Steli Efti writes about it a lot on the close.io blog. There are numerous questions asked and answered on quora.
Start at those two places and once you know more of the basics, you can start learning more specific skills.
But if you don't know who to talk to, then you are trying to solve two problems at the same time: who to talk to and how to talk to them.
Solve one problem first, then the other.
Once you know who to talk to, then you can start talking to them to see if they have the problem that you are trying to solve.
If the service or product you are selling doesn't solve their problem you are not going to be able to sell it to them.
It's much, much easier if you are trying to sell to a customer base (market) that you understand well or already know some problems they face.
Then you can talk to them and verify that you are correct and they have the problem that you think they have.
Wrote to a bunch of strangers. Made it a point to stress that I've nothing to sell (not yet at least) and just want to talk and pick brain. Promised not to take more than 15 mins and never did. Most people never replied, a handful of them did and I had lovely conversations with them. One even became a friend (I referred her to the place I work) and we still keep in touch, even though the original reason I talked to her didn't work out. When I thanked one person, she simply said "no need, just promise me you'd do the same if a stranger reaches out to you".
From my limited experience, it is more or less a numbers game, unless you are willing to spend enormous amount of time looking for that specific set of people who is the perfect fit to help you. There is no guarantee that they would though (why should they? Everyone is busy with whatever they are upto anyways)
1. Make a list of fb friends who would be interested, add them to a group, a secret one.2. Try to validate the idea3. use reddit to validate the idea4. using HN is tricky because you can't guarantee that the post will get attention.
The advice is good but often it means talk to your users. You can use it to validate your idea, but it is helpful to validate your product.
If you are building something be damn sure it's something people want this is hard if you don't know those people
If you are making software for restaurants, go sit at the restaurant during peak and off hours, and be keen about what's actually going on, down to the minute detail.
If the problem you are solving is in the kitchen, see if you can offer a hand doing dishes for free and observe at a detailed level what everyone else is doing and what their problems also are.
Asking questions in survey format could potentially work, though I doubt it. It could also be high barrier if you are basically a nobody trying to talk to restaurant owners.
The worst thing that can happen is people telling you they have a problem they don't actually have, and you create an imaginary problem to solve that nobody cares about.
Then I'd call them up and chat.
At first I'd setup calls only with those who responded.
Then I began calling up people even if they did not respond.
Most people are happy to talk about problems.
Let me assume that you have a consumer product -- an app, or a piece of hardware. There are things out there that do something vaguely similar, but you think yours is better.
Go to the comments sections of various chat boards that are discussing the current way of doing things. Make note of the complaints.
Ask the people there if they will chat with you for 5-10 minutes about a product idea.
You might also find the UX book "Don't make me think" generally useful. I am mentioning it because it does talk about how to get effective feedback on your website. If you are doing an online thing, you may find it very pertinent.
Think of what you can do to support what your customers need to do rather than think of how you can get your customers to fill your pocket :)
I see the zero customers part. I would update my content marketing game until someone called me.
Improving here might be crucial.
Yes! That is exactly the point of the advice.
Go out in the field and you will learn something - because it will NOT be what you expected!
I am excited for you! Good luck!
Besides, erlang definitely gives you new perspective in building large scale system; supervision tree (let it crash), the actor concept, message passing, preemptive vm, built-in distributed erlang nodes, the repl, hot code swapping - any much more
The power comes from the whole ecosystem. Concurrency is built from ground up on language & vm level.
 - http://cs.newpaltz.edu/~dosreist/
"By the end of October 2016, before its official release and after only three pre-release screenings in September 2016 at the Toronto International Film Festival to small audiences, IMDb had registered over 86,000 ratings for the film. 55,126 of which were one-star and 30,639 of which were 10-star, with very few ratings falling anywhere in between. The majority of these votes had been cast by males outside of the US. By mid-November the total was over 91,000 votes, with over 57,000 one-star votes. Commentators assessed that these were mostly votes by people who had never seen the film, and that the one star voting was part of an orchestrated campaign by Armenian Genocide deniers to downrate the movie, which had then initiated an Armenian response to highly rate the movie."
Sadly, the campaign is working. In a time where we are as interconnected as we are, a political film with tens of thousands of fake reviews should send out a huge red flag: someone doesn't want this movie to be seen. However the reality is that not many people are even aware there are so many fake reviews. The mainstream media is not covering this issue. IMDB has not responded. I'm not sure why this is, but can guess that it's related to the subject not being newsworthy & risk of harm with Turkish relations (i.e. why the U.S. refuses to officially acknowledge the genocide).
Many people are going to visit the ratings page before deciding to watch the film, and of those some will decide it's not worth their time because of the overwhelmingly negative score.
For example, one common clause that 'offends' a developer might be something starting any work done whilst under their employment remains the IP of the employer.
It's one thing to tell the recruiter something offends you, but another to negotiate an alternative.
For that's what negotiation is. Understanding why the employer requested what they did, and suggesting something that achieves that reasoning but satisfies your concern too.
And neither are you (the recruiter) and this bothers me.
If your working with a recruiter who isn't working for the company, your making extra work for them. But at the end of the day YOU are their ticket to a paycheck. Don't like the contract, simply say "this changes or I walk", they will work their butt off to be accommodating.
My favorite thing to say to recruiters when it is about money is this: "If you want me to take this job go back and get me another 10k, it isn't a lot of money on your bottom line, hell it is probably only a dinner out, but it is going to make me happy and take the job." Watch how quickly a final offer changes!
Personally I think contracts should just be a series of bullet points in clear language so each party knows where they stand but it's a convention that contracts should be in legalese or it's not a proper contract. Lawyers use legalese to increase or decrease ambiguity or to hide unfair contractual terms. It's also gives the impression that only lawyers can draw up contracts, though most of them at this level are just copied and pasted from somewhere else.
You won't get the nuances (and they matter a huge amount!), and you won't be able to write a good contract, but you can usually notice grossly bad clauses.
So: on the one hand, no, you don't understand it enough for many purposes. But then neither can the recruiter. On the other hand, you can notice really bad things.
ii) If you make an Invention in the course of your duties for us, you must disclose it to us at once. That Invention will belong to us. If we obtain a patent for that Invention, however, you may be entitled to compensation for it in accordance with the Patents Act 1977 s.40.
iii) Subject to ii), all Intellectual Property Rights that come into existence during the normal course of your employment or by using materials, tools or knowledge made available through your employment, will belong to us or any of the Group Companies which we nominate. If required to do so (whether during or after the termination of your employment), you must sign any document and do anything necessary to vest ownership in these rights in us as sole beneficial owner. Where ownership does not automatic ally vest by Act of Parliament, you must immediately assign all your interests to us. You irrevocably waive all your rights pursuant to sections 77 to 83 inclusive of the Copyright Designs and Patents Act 1988.
iv) The provisions of this clause 3 (c) shall remain in full force and effect following any termination of this agreement for any reason, whether such termination is lawful or not.
But every few months (weeks?) I see a post by a founder-type essentially trying to mine the Hacker News collective brains for startup ideas. It doesn't work that way. The best startups are ones that solve a pain point you yourself have experienced.
The idea of a savior who comes in and solving the major problems of an industry they have never worked in is not a myth but close to one. (Elon Musk being a notable exception with cars and space flight... but he has the capital to attract domain experts to fill in the gaps)
I'd point out the problems in my industry except I am actively working to solve them :)
With that said. Don't let a "know-it-all" on HN (myself included) tell you what to do. If you want to tackle a hard problem in an industry you don't have experience in, please do. You might be the next Elon Musk, I don't know you so I don't know.
If that wasn't your goal with this question... again I apologize.
I've said this a few times but we're going through a growth period like AAA video games have over the past 20 years.
I used to be that 2 guys could make a video game, then it went to 10, then 50, now its around 200 from what I've last heard.
Hedge funds are going through a similar shift.
It used to be that one person could manage data cleaning, and algo generation for a fund.
Then cleaning got split out into its own job.
Then the number of data streams exploded growing by a couple orders of magnitude.
Then the data types diverged so that each new data stream needs its own special cleaning, and normalization and even data storage, ie some data isn't suitable for a sql or non sql database storage, like satellite images.
Nowadays a typical algo fund might make use of 100 different algos for trading, each of which has 20 different inputs, some real time, some updated irregularly.
It takes those signals and weights them to come up with a trading signal, which then gets mixed with a portfolio balancing signals and risk signals.
It can be tough to disentangle each individual signal from the algos themselves so even things like detecting if a signal still has alpha generating abilities is tough.
You can have 10 people just back testing signals and monitoring risk levels.
And the growth of data and data sources isn't slowing down.
This is good if you are one of the larger players, see Virtu buying out competitor KCG, who previously ate competitor Knight Capital, yes that fund with the huge blowup, but not so great news if you want to remain a small, person wise, fund.
Not sure how to run a quant fund anymore with only 4 people. Not sure anything an be done about.
In the "good old days" where 2 people could make a video game, odds are that just shipping something guaranteed you'd make money. But that's no the case anymore now that 1000+ apps come out every day on iOS / Google Play. Of course most of those are crap. But you could be making a great game that caters well to a particular audience or niche, and yet you might still fail just because no one can find it or really just be aware of its existence.
The "simple" answer to this is marketing. Hustle your way to some visibility, partner up with some publishers or some platforms holders, and get as many eyeballs in front of your game as possible. However this effort is very close to being "zero-sum." Either you win and get your promo art banner at the top of the app store, or someone else does, but you can't both get it. It's less obvious when it comes to PR and having articles or game review written about you, but it's still there: with so much noise now on the internet, it's hard to generate a meaningful signal.
The harder solution is being tackled by the app stores themselves. Steam, iOS, etc. have all been improving the way games are presented in their stores. There's more focus on specific genre features, more flash sales, more suggestions based on what you already play. It's a decent effort but I don't think it's enough yet.
What can we do about it? Not sure. Algorithms that try to discover what you might like based on your previous purchases are nice and all, but most of my favourite gaming experiences were surprises that came out of genres I didn't expect (e.g. Rocket League), so this can only go so far.
2. Excessive costs, lack of performance among professionals
3. Change in attitude seems to be the biggest factor. If lawyers stop being about fighting and competing and persuading and more about tackling problems, getting to the truth and finding solutions, we can have a much better chance of succeeding.
There is a lot of opportunity for automation that no one seems to want to get involved in. A good example is document discovery which has been largely automated.
Other areas that could be automated include divorce. For example, in my jurisdiction what each partner is entitled to on divorce in terms of child support and alimony and division of property are set. There is some room to argue about custodial arrangements but not very much.
Given this - there is absolutely no reason to have many years of contentious divorce suits. If there was someone way of just entering the information into a computer and informing both couples of what they are entitled to and then working from there - I believe we would be much better off, because, although I haven't done alot of divorce suits, but in my limited experience it seems to me that lawyers certainly have a large role in exacerbating them and needlessly.
Already done successfully
And, it seems Perl IDEs/debugging tools aren't as good as they should be. We're still using the command line debug tools for Perl, and can't even set a breakpoint before that line has been executed.
* Reproducibility -- running code months or years later, on another machine.
Current tools, like VMs tend to be too heavy-weight. Docker is too hard to set up.
The main problem with these various tools is that exploration is slow -- Often I'll take an experiment, tweak it a few dozen times, then finally get the code for a paper. At that point I don't want to package it up, I want to be able to "freeze" where my last execution.
You might think that there's no shortage of phone Repairer's out there and your right but you can bet that 90% of them are self taught or eventually taught by someone.
Considering the amount of important information we store in phones and the price of the devices it has now become more important to ensure that your phone repairer knows what they are doing and of course has a reliable supplier
Homelessness is on the rise nationwide in part due to a serious lack of genuinely affordable housing. Among other things, in the 1960s and 70s, we tore down a lot of SROs. The Baby Boom generation was an anomaly. The unprecedented wealth of their parents was due to WW2. Yet, expectations from that era still shape housing policy and infrastructure, much to our detriment.
You do not necessarily need to be a construction company to play a role in addressing this issue. Another very serious problem is the lack of financing mechanisms for housing alternatives. For example, co-housing projects in the US tend to be self financed because we do not have financial products that fit them. This actively undermines their ability to add affordable housing to the system, a purpose they successfully serve in other countries, from what I have read.
There are, no doubt, many other things one could do to work on this issue.
I highlighted passages of note here:
It's a great opportunity in a field that, despite budget cuts and under-funding, still has millions of dollars to put into software that could meet the needs of school districts across the country. Most of what's out there now is sorely lacking, leaving teachers and schools to use a patchwork of solutions to meet their needs.
2. Most people don't like their jobs but suck it up. The 9-5 grind, climb-ladder, can't switch careers, lack of meaning, social pressure to have job. Getting laid off, searching new job, financial downsides of being unemployed
3. Restructure the job model/market (flexible choices, live comfortably, security)
Unengaged workers- Gallup poll on American workforce trends http://www.gallup.com/reports/199961/state-american-workplac...
2. Oligopoly just a few companies who deliver live results.
You would need a ton of cash upfront, to hire people who would watch the games and would press buttons in order to inform you about results so you could parse them and deliver live results which eventually would become a live API.
But as you can see, there are people involved in this, who watch all those games, if you can manage to automate this, without requiring too many people, you are a rich man.
Let's put in that way, almost everyone consumes their API if they are offline, we are offline.
3. SystemVerilog is not really at the right abstraction level and still has many of the problems that face Verilog. It is sort of what C++ is to C and what I need is more the equivalent to rust.
2. I don't know if it's stopping the industry from growing, but existing communication tools (specifically chat, email) are a serious drain on attention and productivity. See http://www.paulgraham.com/makersschedule.html.
3. I'm working on it. Might be better tooling, might be educating people on how harmful they can be.
2. Cost of launch locks out potential customers and limits R&D uses. Global launch cadence is slow; getting into orbit is a multi-year adventure.
3. Yes, we're working on reusable rockets.
However, this only goes so far. Personally, I think that more money needs to be put into non-rocket modes of space travel, so that there's some competition. The fundamental problem is that it takes so much energy (and, with rockets, so much mass fraction optimization) to get to space, so it's difficult to engineer things with physical margin.
If you could build a rocket like a car (just toss some more steel in the frame and call it a day, with no need for the obsessive mass savings), getting to space would be a bit easier. If you had a power source that doesn't shake and bake its surroundings, getting to space would be a lot easier.
2. Not enough companies want to use newer web technologies and advancements in AI & machine learning to train their workforce
3. Yes but I think it'll require younger incumbents 'eating the lunch' of more established companies for this to change
2.1 Access to energy / energy density of fuels (batteries included). This is the case across a wide range of industries and problem areas of course, not just transportation. But incremental optimizations in efficiency have lead to squeezing more performance out of the margins, but no Moore's-law type growth will ever happen without some kind of energy breakthrough.
2.2 Going forward, tightly coupled systems will be the norm. The traditional tube-and-wing aircraft with bolted on nacelles is a bit of a dead end for civil aviation. Systems to enable a more complex design workflow (e.g. graph based dataflow with accurate gradients) will be more paramount.
3. Research into the next generation of energy storage materials, and improved large-scale gradient-based numerical optimization algorithms.
I think there's a massive opportunity to lower costs and improve user experience in every area. I wish Apple used their pile of cash to invest in a big vertically integrated healthcare service - a chain of hospitals, in-house-developed software throughout, improve user experience, integration and tech on every level. Basically healthcare rethought from the ground-up with Silicon Valley consumer-oriented mentality. Yes, extremely daring, but they're in a unique position to pull that off.
2) A lot. Publishers relying on clickbait to generate money. Advertisers creating invasive ads with autoplay sound and video. Ignoring do-not-track requests as part of the industry (even if some technology providers respect DNT, it seems like a lot don't). Malware. A lot of useless metrics. Bandwidth usage. Etc...
3) Micro-payments vs delivering content only when an ad has been seen? Validating content delivered through exchanges. A better way to anonymize data used for tracking? Smaller ads. Honestly, I'm not too sure, there's probably a lot that can be done but I feel the industry did too little too late.
2. Product complexity, legacy IT & culture and regulation
3. Provide regulated banking services as a lean platform / utility, let others play on top
(3) is not easy to execute and no, blockchain is not the answer
2. Hiring Process
3. Replace meaningless whiteboarding interviews AND silly notepad algorithm questions, with a live coding interview on a laptop and a real development environment.
Companies would be surprised how fast and efficient the hiring process would be. They would stop eliminating a bunch of great candidates by running relevant technical interviews and not silly CS academic stuff. I can spend 3 month memorizing 500 algorithm solutions and nail all your 45min technical interviews. I would get an offer, a kick ass package and I would join your team. Then, on my first day I'd ask for help from my colleagues because I can't even setup my development environment. I'd write buggy code that doesn't integrate well and wouldn't be able to understand how to design a system. All I'd know is how to write text in a notepad and how to flip a linked list on a whiteboard.
But hey... I'm smart! And now I'm rich :)
2. Seamless, lossless, low-cost interoperability
3. Doubtful. Many companies profit by providing custom products and services to address the problem.
2) Massive underfunding from central and local government; entrenched ways of working; incorrectly defensive working; dysfunctional cheerleading of incorrect approaches
3) Yes. Improve efficiency. Move to better ways of serious incident analysis. Challenge people who cheerlead incorrect approaches. Push for more funding, especially using Spend-to-Save data.
Tenure is a huge cost to the university and not every professor is both an amazing researcher and an amazing teacher. So you have a chunk of the budget spent on old researchers while poorly paid adjuncts fill in for undergraduate classes. Not sure if fixable.
Politics runs everything. Broken clock Ayn Rand was at least somewhat right in Atlas Shrugged when she speculated that bringing about the end of money would usher in an age of pull. That's exactly how higher ed works: unless you can justify your work with student evaluations and big $$$ research grants, politics runs a lot of decisions. Not sure if ever fixable.
No two American universities are alike. Colleges within universities have major differences too. Good luck getting any real traction consolidating IT services. Everyone has different needs and cut-outs for their work.
Higher education is a hydra. It cannot be fixed or reformed at the drop of the hat or with the use of an app.
Abandon simple solutions, all ye who enter here.
3. More money.
In the publishing industry (where I have worked since 1997), the transition from print-only to print-plus-digital that began around 1999 and really got underway after Amazon released the Kindle in 2007 has finished. Now we have an industry in which print and digital co-exist (at different levels 50/50 for fiction, but more like 80/20 for non-fiction, and even less of digital for more complex product types like Bibles). Currently the growth area is audiobooks, led (of course) by Audible.
2. What are the biggest problems stopping your industry from growing?
Publishers have not really solved these problems:
(a) How to distribute very small publications and receive very small payments? We're still reliant on credit cards for payments, which pushes us to a smallest payment size of about $1.99 or so.
(b) How to increase discoverability? Most publishers are reluctant to post all of their content in a web-searchable and social-shareable form (for somewhat obvious reasons). However, this means that it's hard for them to draw direct traffic to their books.
(c) How to reduce reliance on the behemoth of online retailing? As physical bookstores have died away, publishers have recognized that they are too reliant on one distributor, which is a dangerous position to be in (as that retailer has shown itself very ready to use monopsony powers to bully their suppliers). Most publishers have direct-to-consumer selling operations. But (a) and (b) and other factors mean that they find it extremely difficult to draw traffic to their sites.
3. Can something be done about it?
I have been working on some of these problems in my business (http://blackearthgroup.com). Here is a sketch outline of how I would encourage publishers to solve these problems:
(a) Micropayments are needed, and to do that we need an online currency that can be used to buy content without going through the credit card processing network. Publishers should invest in the development of an online token that they would support on their sites. Customers could then purchase a supply of tokens and use them on publishers' sites to buy content. There are a couple of projects like this in the works. The simplest approach would be to create a coin based on the Ethereum network, and then support that coin for all purchases. (The hardest part of this is probably that the value of the coin would not be completely stable, because Ethereum is not, which means that publishers would have to either adjust their token prices regularly, or would have to live with variability in revenues to sales this problem is solvable, but it requires a lot of capital to create a value stabilization mechanism.)
(b) Publishers should put all their content online in excerpt chunks using non-discoverable public URLs, then submit it all to the search engines, and start sharing excerpts through social channels. It is true that some of the content would be given away, but that would be limited because each excerpt chunk would not be linked to the others in the same publication access to one would not grant access to all. Using full-content search and sharing is one of the best ways for them to draw more organic traffic to their own sites. (They'll need to invest in better discovery mechanisms on their sites, too.)
(c) Publishers have a real chance of building a customer base in their own content niches, if they invest in developing a content discovery and purchase experience that is significantly better in that niche than what customers experience on Amazon.
(Cross-posted to my blog: http://blackearthgroup.com/2017/04/20/what-are-the-greatest-... .)
2. Knowledge sharing within companies/organizations. Formal methods (primarily their absence). Effective use of simulations in design, development, and V&V efforts. Requirements traceability (this is mundane and seems bureaucratic, but it's critical here).
3. Yes, to everything.
For the first, break down information silos and project fiefdoms. Allow for greater flexibility for staff to move across project boundaries so knowledge can be shared more equitably, and people can see other teams work (learn both good and bad things here). Training. Make it a recurring event. Not the crap training many organizations do. Have a seminar series where people come in and present on something, not always directly related to work. Encourage people to write up their lessons learned, and perform and publish post mortems on projects. Take the approach of avoiding blame, focus on correctable errors and faults along the way (these are primarily process faults, not technical ones; where technical they're typically design and not implementation errors).
Formal methods and simulations are much easier to get started with today than ever. I'm not even talking about making a full-blown simulation of the final system, just high level "is this protocol sound" models. Presently working on radios. I don't need to implement a simulation of every detail of the protocol, I just need to know things like: If we add this new message, that must be sent so often, can it actually get broadcast at the correct frequency within the physical constraints of the radio? This turned out to be NO on one project I saw (not worked on), but not discovered until it was implemented (several man-months wasted). A message was supposed to be sent out every X time slots, containing N bytes of data. Each slot allowed you to send MAX size. Other messages also had to be sent out, say every X4 slots with size M. N+M > MAX, meant something wasn't sent. Both were mandatory, by design the protocol couldn't function. Another similar issue, though requiring a more complete simulation/model, was that one of the processors handling some of the messages simply wasn't fast enough. It was required to (worst-case) process N messages within X microseconds, but could actually only process ~N0.75 messages. Admittedly, this was worst case behavior, but by the system's design (protocol requirements, selected hardware, selected data bus, selected program design) it could not achieve the required performance.
The more complete the simulation, though, the better off you are. Technical solutions already exist, it's primarily an issue of finding good case studies or getting an amenable manager to sign off on trying it to demonstrate the cost savings (versus the typical approaches, which in my experience are often significantly late and errorful). Also being at the right stage in a project. Being at the maintenance end, constructing these models/simulations is harder than when you're taking on a novel project.
But, simulations also aid V&V efforts. If you can construct a full(er) simulation of the radio network, your V&V team can start creating test cases, procedures, and models and verifying that they're reasonable. From a protocol perspective, this is relatively easy on our radios, setting aside timing. So ignore time (as a strict concept) and instead focus on time slots. Create a simulation where each tick corresponds to one time slot, let computation run as long as needed. At the end, you'll see what should show up from the radios given some inputs. Run these through your data analysis tools to exercise them, and when you have functioning radios you can use these tools to create simulated network peers (pre-generated network data played back to the radio being tested).
For requirements traceability, just stop using Word and Excel. Use an actual requirements database. I know DOORS sucks, but it's infinitely better than Word and Excel.
Say your bot misbehaves and effectively starts DOSing a site with a whole lot of pages, like a small Reddit clone or something. And say Reddit doesn't have another way to determine between your bot and the Googlebot. You have now put Reddit in a position where they have to either block the Googlebot (and possibly lose a huge pile of money in the process) or else buy up a lot more hardware and bandwidth to pay for your crawler as well. That's not cool, to put it bluntly.
Most important argument: the chrome user-agent contains the word 'mozilla'. Obviously (we argue) google isn't intending these to be accurate and instead are some kind of compatibility mark.
Are you committing trademark violation? Given the nature of trademarks, it's not clear that you are.
Are you misrepresenting yourself to the site in a way that violates the CFAA? This is probably your biggest area of risk. But you can argue the site is giving away information to google, a company whose slogan until recently was 'free the world's information'. Therefore they weren't taking plausible steps to secure the information you've scraped.
I know of a few sites that use this as the first step (of many!) to add bots to their "naughty" list.
However, consider what your ultimate end game is, if it's a website you expect visitors to find through Google or the Play store, good luck once web masters start reporting your misbehaving "Googlebot" crawler.
In my home country, it's actually quite interesting: fraud usually requires (a) a lie (conveying wrong information with intent), and (b) a financial cost to the other party, and (c) a financial gain for you.
It's debatable at that level, already, because their loss is rather hard to quantify, and probably small. Plus, I believe your financial gain must be directly related to their cost.
And, finally, you actually have to lie to a human being. Lying to a machine doesn't qualify. There was a guy who earned some 5-digit Euros amount by producing fake bottles and feeding them into deposit machinesno crime!
As for the site owner, it's on them to decide what to do with your traffic. HTTP is an open protocol and extensible. You could send almost anything in your request, as allowed by the protocol. The site owner has opened their service to the HTTP protocol and it's on them to decide what to do with your traffic.
If the sites in question only add an exception for googlebot and not other crawlers (e.g. Yahoo, bing, etc.) I would say that it is against the site owner's consent.
However if the site owner adds this exception also for other crawlers, you could argue that the site owner's intent of only allowing certain crawlers has not been made explicit. In that case you'd have a chance against the claims from the site's owner.
On the other hand Google could possibly sue you for using the user-agent "Googlebot".
The important question here is: would they? If you stay under the radar no one -even the courts- would bother.
PS: I am only a law student, I am not familiar with any laws/regulations/precedents governing this specific issue. I think from the site owner's perspective it's a grey area. From google's perspective brands and ip are established concepts in law. This is a student's very personal opinion at first sight, take it with a grain of salt :).
"I left my door unlocked and told my friends they could use my living room, but then they put their feet up on my coffee table... Not cool, man!" Pretty much the equivalent situation.
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.
But some top tips stand out for me over time:
* Talking to people, networking > Not talking to people
* Bug free > Elegant code
* UX > UI
* Simple products that do one thing well > Complex products
* Understanding entire market > understanding some people
* Building brand > Making quick money (for the long run)
* Sleep, exercise & healthy food > late night coding
* Solving your problem first > Solving the worlds problems
* Adaptability, pivoting > Ego
* Knowledge of where the money is > No knowledge of it
* Overestimating cost/expenses > Underestimating it
* Patience > No Patience
* No procrastination > Procrastination
* Reading books > Not reading books
Business, like developing software, is a strict discipline, and there is a vast amount of knowledge that only comes from experience.
I found myself trying to do everything, until a friend taught me a clever trick:
1) Write down all of the tasks you have to do on a daily, weekly and monthly basis.
2) Write a short paragraph for each task's job description.
3) Write a job application from yourself for each of the jobs.
4) Contemplate why on earth you would ever hire _you_ for the job!
My advice is to work out exactly what tasks there are in running your business that you are not an expert at, such as accounting, sales and marketing, copy writing, etc. and hire people to do those parts for you. You'll see a return in no time... unless you don't... in which case your business model would never work.
Scream it in a loud voice, IF YOU BUILD IT, THEY WILL NOT COME!
You are going to have to build it, find them, plead with them, fight their refusals and shove it down their throat.
There are many unknown "unicorns" that currently exist as code. The code is done, there's just no users, because the world doesn't even know it's a thing and those that do know have not being convinced that it's needed.
My opinion, my advice. Forget the code, find the customers/market first.
A software developer with complete code and no customers is just a software developer.
A business person with tons of customers and no software/product is in business.
So decide if you want to be in business or to be a software developer. I suspect that most developers just dream about business as a means of escape from their day to day reality, but secretly don't even want to be in business, they love writing code more than being in business.
You need to get your company to 10k USD monthly product revenue within three months. If you can't, either the product, target market or team needs to be revised drastically.
It's hard advice to follow, but it will save you a lot of time because you can't wait months and years doing unessential tweaks to the product and marketing, hoping that sales miraculously grow.
It's also useful as a pricing yardstick early on. If you have very few customers, they need to be paying enough that you reach $10k almost immediately. If your product isn't worth that much, then you need to scale out. It's best to figure this out right from the start.
If it feels like you can't do $10k MRR in three months on your own, then you need to find a cofounder who can do it together with you... So it's a good way to calibrate cofounder expectations as well.
2) Banks will loan you money when you don't need it and won't loan money when you do need it. Apply for a loan or line of credit when you're flush with cash in case of a rainy day.
3) Running a business is a different skill than developing software. Be prepared to learn a lot of new skills.
4) Don't hire too quickly. Payroll + benefits can eat through profits like crazy in a software business. The counter-point is that a good salesperson will bring in far more revenue than they cost in salary and commission.
5) Know your numbers. You should have good accounting records and know from week to week if you are on track or slipping.
6) Don't hire a 'marketing' firm. They will charge 10's of thousands of dollars to ask you questions like 'What do you think we should do?' and then feed it back to you. If the product is positioned well with customers, you know more than the marketing company ever will.
7) Don't let a single customer account for more than 10% of your revenue. If that customer leaves, you'll be in a painful situation. It's difficult to do this at first but it keeps you from chasing a big fish to the detriment of the rest of your business.
8) A good reputation and word-of-mouth is better than buying the #1 spot on Adwords.
9) Figure out how to sell again and again to the same customers. A one time sale makes means a high cost of customer acquisition. Once the customer likes your company you should see what complimentary products and services you can sell too.
10) Once you've had a taste of the freedom (and stress) of working for yourself, it will be very difficult to go back to a regular job and work for anyone else.
1) Customers don't care about the technologies you're using, the elegance of your XYZ algorithm, or the novelty of feature ABC. What they care about is solving some problem they have, making their day easier, becoming more productive, etc. When you're pitching your product, talk about how it helps the customer, not about how it's built. A great 5-minute video on this is "Understanding the Job" by Clayton Christensen: https://www.youtube.com/watch?v=f84LymEs67Y
2) Think about monetization early on. Like most engineers, I had dozens of side project and business ideas. For each idea, I had thought about the features I'd build and how I'd build them, but not the business viability: who would I sell to? What would the pricing model be? How much money would that translate to for a typical user? Would users have the work/personal budgets to pay what I wanted to charge? Was the price enough to cover marketing and user acquisition costs? I haven't read it, but have heard that a great book on this topic is Monetizing Innovation (https://www.amazon.com/dp/B01F4DYY1I). Another good book to think about business models is The Art of Profitability (https://www.amazon.com/dp/B000FA5TTM, brief notes: https://codingvc.com/the-art-of-profitability)
3) Finally, think about marketing and customer acquisition in parallel with product. After almost 5 years as a VC, I can readily confirm that most products don't sell themselves. Even the really good products need sales, marketing, etc. A great book to get started on marketing is Traction by Gabriel Weinberg (of DuckDuckGo) and Justin Mares (https://www.amazon.com/gp/aw/d/B00TY3ZOMS/)
- Shoot for between 3 and 10 clients. Any less and you'll be very stressed about losing a client. Any more and you'll be overwhelmed with juggling too many balls.
- Fire bad clients. They aren't worth the stress, frustration, and opportunity cost.
- Work on your process. Doing an hour of client works earns you one hour of revenue. Improving your agency processes can earn you a large multiple of that.
- Don't be a <insert software technology> shop. Be a solver of a specific business problem for a specific type of business. Example: "We streamline backend processes for multi-million dollar trucking companies." The most valuable contracts are for solving expensive problems.
* Execution>Idea. Don't work on multiple projects till at least one is shipped.
* Pairing up with other like minded folks is better than going solo, but only if you can get along really well.
* The highs are higher, and the lows are lower.
* Develop good habits
* Make your first project a small one
* Failure (at least small ones) is not a problem. Failing to recover is.
* Sales and Marketing are very important. They need as much time as working on your products/ideas
* Start now, you'll never feel ready
This is the tl;dr version of a longer blog post I wrote about my personal experience http://www.dotnetsurfers.com/blog/2016/03/29/lessons-learned...
Your first MVP is simply a static website describing problem, solution and signup, with Google Adwords and analytics.
* Given that your target market are going to be ideally using Google to search their problem or solution, with Adwords, you can test exactly what they are actually searching for when they are looking for your product.
* Analytics will be powerful to measure the engagement of the user to your desired product. Have buttons or measure scroll for engagement. Do they read your problem and leave? Obviously not relevant. Do they continue onto your solution but leave? Wrong market-product fit. Have options on the website for easy A/B testing to figure out your demographic.
* Static website is super easy to change and make pretty as so many templates out there, and even if you don't use A/B testing tools, you note when you make changes, so you can compare sets of user analytics data.
This approach was popularised by lean startup methodologies, but what I love about it is it takes a couple of hours to setup, and an hour each week to tweak and monitor, and you'll know early on whether it's worth even developing the software from the very beginning. The saved time is worth the adwords cost (you can set a budget per day on their dashboard) and cost of static website hosting.
Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.
Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".
Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.
Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.
I've written a little more about this on Medium - https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...
1. Your idea and your software will probably not be aligned to your market needs at first;
2. Go out and talk to your customers;
3. Do not just focus on code;
4. When your customer really needs something that is not in your software, do not hesitate to bill this customer for special developments: it will finance the feature for all your customers and keep your feet on the ground;
5. CIO are overstretched by sales rep, so B2B sales cycles can be really long (at least in France).
Disclaimer: CEO of a French Cybersecurity software company.French market is known to prefer service over software and "On Premise software" over "SaaS". As a result, we switched from SaaS mode to On Premise, and we started with Penetration Testing to join the end of the month.While my advices might not be the best, we are in our third year of business and should finally reach profitability :)
2) Pick an idea that you would pay to use (product champion). If you are not the target market, you need to find a product champion who will join your team prior to the MVP creation.
3) Do things that don't scale. don't future proof your MVP, just make it so you can validate that your product has a market beyond your product champion.
4) Create a website for your MVP and make sure you can run it at low/now cost for at least 6 months before you decide to abandon. Marketing is hard and product discovery might be the biggest challenge you face. As long as you have more customers every month you are doing ok.
5) Even if you give your product away for free during MVP/beta, figure out some way that customers who want to pay you can. This is very valuable for determining product fit. if nobody wants to pay, figure out what would make them decide to, and use that for determining how to pivot.
source: myself, I made/make phantomjscloud.com
Let me elaborate on that a bit. Seeking more and more knowledge and wisdom in an effort to learn some kind of system or trodden path to success is understandable but can quickly consume all of your time & energy and likely won't provide much real value over the long term. Nothing, and I mean absolutely nothing, beats jumping in, doing stuff, being objective and introspective enough to identify what works and what doesn't, and iterating. What people are doing now will change. What people are using to do those things will change. What won't change, though, is the value of being able to take action and move through that world with confidence and resilience.
Reading, research, and listening to people is good but you should trust the laboratory of action above all else, especially over other people's opinions. Why, if you're a normal, intelligent, rational human being, would you ever put the opinion of some arbitrary person above what you can observe yourself? Because it's on the web or in a book? That's silly. Be extremely selective in who you allow to be your advisors - you wouldn't indiscriminately sleep with just anyone at the drop of a hat, would you? Don't just take advice from everyone, either.
Don't let people pigeonhole you, don't let people project their ideas onto your passion, and learn to identify where you should spend your precious time & attention - most of the time, you should spend those on action, not navel gazing and not "preparation" for action.
There are maybe a handful of books and blog posts that are really worthwhile. Once you have read those, everything else is simply other people regurgitating what they have read and is therefore not very useful. Also, on points that are very crucial, like legal and financial matters, I would hope you have an attorney and accountant to help you make those decisions - don't try to learn everything yourself and carefully establish and nurture your inner circle so that you can focus on - you guessed it - action.
I made this mistake in 2012 thinking that my product would no longer be wanted by 2016 and so didn't invest in expanding sales. 2017 has arrived and our sales are at an all time high and I have no idea when the market will start to decline. I lost a huge amount of money getting this wrong.
In my defence eveyone else in our industry thought the same thing and made the same mistake.
1) It takes longer than you think/imagine
2) Start smaller, no smaller still
3) Self fund for as long as possible
4) Be positive, stay positive
5) Identify people you can talk to about your work
6) Be honest with yourself, hard/brutal honesty
Thus technical debt, scalability etc. simply don't matter until you iterate your way to solving a problem other people care about. That's much better than solving a problem well, a problem that not enough people have.
Ie. in short, stop engineering software and start figuring out what people actually need. Not just 'nice to have', but a real need that causes real pain. To see if enough people need what you are planning to build - you don't need to built at all, just draw it out, explain it in a doc, and go ask people. You have to really ask them and push beyond their initial "sure yeah, it'd be nice to have". Ask them how they do the task / fulfill the need now. Ask them how much that costs. How much would they pay if you built a better one, etc. Really try to get a "no i don't actually need it" instead of being content with the polite lie of people wanting the product.
The other advice that has been invaluable to me is NEVER EVER reveal your salary to recruiters. Always state what you want to be paid and go from there. When you reveal what you are earning, you are immediately weakening your negotiating position. This may seem obvious but it would surprise you how many people just go along with their very invasive questioning.
I've seen what happens when you keep the product secret, trying to perfect it before you show it to the world. You'll run out of money making a pretty baby that no one wants.
A developer with marketing skills can build products and achieve revenues far in excess of their skill set.
* Look after yourself. The body supports the mind and vice versa. Neglecting one is neglecting both.
* Create a distraction-free environment. Co-working space, public library, converted garage/shed, quiet cafe. Only work from home if it is truly free of distractions & interruptions.
* You can't be an expert in everything. Focus on the value creating activities.
* Serve people, not problems.
* Solve problems, not people.
I wish I knew that I could start saving and investing the money I was already earningand retire while still young. Your odds of success as an entrepreneur are basically zero. (I know some of you are going to do the startup or nights/weekends project anyway and I wish you the best of luck.)
If I knew this I could probably have shaved years off of my FI date.
The most useful piece of software that is used by almost all Software Developers around the world was created using Microsoft.NET -> That piece if software is StackOverflow.com. Microsoft .NET is not a sexy and cool tech. Solving problems is hard enough. Don't make it even harder by chosing technology you hardly know.
You won't get anywhere solving any problem.
Find a niche for what you can offer, and only go forwards once you've saturated that niche. For example, find a specific line of business that you're passionate about and approach them. Get a name for yourself and excel.
When I came to the Bay Area I knew I wanted to be entrepreneur but I also knew I had a lot of gaps in my understanding. The two big ones were sales and marketing, and the other end production and release. I took positions at established companies (Intel and Sun) to learn what these functions do in "real" companies. I then joined as an early employee a start-up, and learned everything I could about funding and equity and the unique environment of small groups tackling big problems. Then did it again and got to learn about the whole acquisition process, the challenges of taking things public (or not), and learned I still had a huge gap in what MBAs called the 'business model.' I went to work at a company that had an excellent leader and business model at the time (NetApp) and started internalizing what adds value, what doesn't, and what is and what isn't a reasonable way to look at things.
If I had to do it again, I would probably have gotten an MBA while I was at Sun (my second job). While there is a lot to dislike about 'MBA culture' that would have been a faster way to accumulate an understanding of how to evaluate a business to see where it could be improved.
Learn how to do sales end-to-end.
How to listen to a customer and understand their needs, how to market to those needs, how to convert those leads into contracts, how to bill those customers, how to make them feel valued and show value to them, how to upsell when the contract expires (how to get more value from them).
Learn sales. Mostly because it helps you understand the whole of a business, and will guide any prioritisation of your engineering like nothing else.
It turns out, you really don't need to build a great thing, you just need customers who pay.
- Some of that quick & dirty temporary code would be used for the next 18-19 years.
- I might as well have used PHP instead of Perl. Same (bad, messy) code quality, but even faster development and much easier hiring.
- Costly hardware early on was a waste of money (we outgrew it so fast that a beefy desktop PC would have been a saner investment at that point).
- Managing people is the one thing that you can't "fix" permanently. It's always an uphill battle unless (presumably) you're naturally talented/charismatic/psychopathic.
- don't bother with marketing people, advisors, business consultants early on and don't create product dependencies (e.g. by building a specific version of your product for others). It's not worth it until your product is polished and proven.
- Don't hire people carelessly because you don't want to invest precious time. Don't hire friends/acquaintances unless you've seen them working. Firing people is one of the most difficult tasks.
- Bad things will happen. Don't spend too much time trying to prevent them, or worrying to much. Just make sure you know what your options are when you need to put out fires and manage basic info (don't go searching for your hosting provider's phone number when you need it).
4 years later, happy to report that I have a successful startup.
> Startups don't create new technology, they create new technology-dependent business models.
I wouldn't say this is 100% true, but it is probably 95% true.
Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..
Now if I think about the intersection of an IP marketplace with super-buyers and super-sellers, the obvious candidates would be businesses in the patent portfolios business. That's probably the place to begin research into existing markets and values and players.
The basic problem is people are more attached to their own crappy ideas than someone else's brilliant idea.
In any sort of leadership role you're supposed to be trying to extract the best work from your people. Generally you are not going to be able to do that effectively if you are looking down on them. Give them a bit of respect, encourage incentives and comaraderie. Your new job is to be explaining stuff to them so they can work better. If you don't like them figure out how to make them better - its usually easier and way less expensive than firing and hiring.
1. They're motivated.
2. They're doing activities that lead to the right kind of learning.
So if you can teach well (or learn how to teach well) and they're motivated, this is a problem that will be solved in time.
The problem with a startup is that you're often on a tight deadline. The nice thing about a startup is that often software development's goal is learning (e.g. "are there any customers for this product?"), not building something that lasts, and so "quality" may not matter.
So it's very hard to say in the abstract without understanding the constraints you're under and the company goals.
Mitigate risk by having everyone write test code and do peer code reviews.
You'll probably do a lot of fire fighting initially. If your team is >7 and truly none of your devs are "competent" (unlikely), then hire someone who is, even as a contractor. If you don't have headcount, then fire someone to get headcount. You need at least one other person you can rely on to fix urgent problems if you don't have bandwidth to do it.
You said "very small start up" so I'm assuming team is <15, but if it's that size then you prob need sr devs to help you lead the team. With a couple good hires, you can wrangle a fairly large team of very junior devs.
I've had dozens of devs (~30) report directly to me, and a lot more than that indirectly. I've never seen one who was totally incompetent. There was one guy, and no matter how much I tried to encourage him, he was performing way too poorly so I removed him from my team. Years later by coincidence I found out that he was working at a friend's company. I asked about him, and it turned out that he was a strong contributor on his team.
People sense when you don't respect them and once that happens the interpersonal dynamic will negatively affect the team, so you have to police your own attitude. Maybe you don't have much experience leading a team. You could say, possibly, that you are as incompetent leading the team as they are in swdev. Please try to respect them regardless of their competence level.
Find out your dev's strengths/weaknesses, so you know who to use when. I had one eng who wrote the absolute most heinous code imaginable, but he got tasks done super fast. I had to rely on him several times to meet customer delivery dates -- and had to accept the technical debt too. You make those tradeoffs.
As team leader, facilitate their growth. It's actually a good learning opportunity for you.
Well that's not so much just management. That's also how teams work. Somebody has to play goalkeeper and hopefully there's someone who can kick the ball in the net and a bunch of people in between able to run (a lot). And some people who can come off the bench when someone gets injured.
Sure I hate sports analogies. Being a good teammate is about more than technical skill or resume. It's about playing well with others.
The first question is, are they teachable? If they are, the best answer is to teach/train them so that they become more competent. If not, the only options are to fire them or quit.
The second question is, presuming they're trainable, are you able and willing to train them? This isn't just a question of your knowledge. Do you have the willingness to do so? Do you have the patience to do it? If not, you're back to fire them or quit. But in this case, the problem is not just the team. Part of the problem is that you aren't able or willing to do part of what leads do.
That said, there are certainly engineers who particularly excel at working on legacy code bases. Refactoring and modernising an existing codebase poses an interesting challenge and it provides actual business value. Anyone can start a new greenfield application. Working on a legacy codebase takes at least a bit of courage and a deep understanding of the business involved.
People often seem to forget that a supposedly shitty but working codebase for the most part probably didn't become that way because its original developers were just stupid but because the business requirements are inherently complex and contain a lot of edge cases. By decrying legacy code you might throw out years or even decades of expert knowledge about the business.
First off not all legacy code is "shitty." The main reason I am 10 or 100 or 1000 times more effective with legacy code is that I'm usually the only programmer the customer has talked to who will work with it. Everyone else has one solution: Throw it away and start over with [insert favorite cool language/framework/ideology]. So at least in my experience it's not that I'm 10X more effective, it's that everyone else is 0X effective because they won't even try.
It's easy and maybe fun to simply dismiss legacy systems as junk and shit and catastrophes, but when a business has a system that mostly works and they need some debugging, enhancement, improvement it's usually irresponsible to tell them to start over. When you do that you are telling the customer to throw away something that works, even though it has problems, and take a huge gamble on a new system that is 75% unlikely to even go live. You are telling your customer that your one hour reading of some code that you declare "shitty" is more informed than all of the cumulative experience of previous developers. You are telling your customer to change business processes, retrain staff, all on your word that you are more clever than the last team.
Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. That's a story I hear about software systems every month.
The most important metric of software is whether it solves a business problem and adds value or not. What language it's written in, or whether the last programmer used spaces or tabs or camelCase or knew OOP as well as you think you do are not relevant metrics from the customer's perspective.
And since a lot of the code I work on is not actually that old -- in fact it's just as likely to be the unfinished remains of the last green fields team -- I can say without hesitating that the worst code to work on comes from programmers who are so committed to an ideology or language or toolkit they lose sight of requirements and the only goal that matters: adding value to the business.
For example, we had a 10x guy recommend that we re-write our health insurance web app back-end in Golang, but then, we realized that meant we couldn't cover generic prescriptions.
In that case, he wouldn't have remained 10x over the older Python/Django code.
Usually someone described (probably by themselves) as a 10xer are the ones responsible for the code base being so bad in the first place. 10xers only work on green fields, they never get a chance to see what a catastrophe their ideas turned out to be.
Sometimes that means fixing existing codebase instead of the massive effort to do a rewrite (see gregjor's great comment).
Sometimes that means figuring out that the custom legacy software can be replaced by an off-the-shelf solution.
Sometimes that means figuring out that only some of the legacy software is actually important, so only that part needs to be maintained and the rest can be deprecated.
See also https://codewithoutrules.com/2016/08/25/the-01x-programmer/
Advertising an IPO on CNBC? That is insane.
The front to the scam is deep.
https://www.youtube.com/watch?v=pQg6WPlAQWE (Master P - Yayo Theme song).
I noticed in the videos that nothing ever goes in front of the animated objects, so they're probably not identifying objects, and trying to figure out object boundaries or anything like that. It's a simple, well-polished trick.
But just plain old analysis of "parallax" (things closer move faster etc) can quickly give you a workable understanding of the general geometry of a space.
The new MR headsets like Magic Leap and HoloLens likely use both types of sensors (like the kinect camera) to determine this stuff. But Snap just wants the widest push possible, and since it is not mounted on your eyes, the 'pixel stick' being off is not as much of an issue.
- Pick "unique" points currently in view
- Track how they move as the camera moves
- Combine this data with the accelerometer to get an accurate movement reading of the phone.
- You can get the depth of any point by comparing two images and knowing the change in user position.
Simple algorithm, but their results were astonishingly good. Snap don't need to model the entire room, they just need to work out where these points are to keep the image appearing still.
- Be a train. (realized that I was 3)
- Be a breakdancer. (realized that bodies age)
- Be a DJ. (realized I liked employ-ability and stability)
- Be a classicist/anthropologist (realized once again that I liked employ-ability, and wasn't excited about becoming a Vatican priest)
- Be retired so I can go back to A. (still working on it.)
You may have wanted to focus on specific occurrences, but all my biggest/most unfulfilled "regrets" are by nature more long term, and don't have "easy fixes" as e.g. my dream of doing a cross country road trip, or starting a massive fruit garden (I've partially realized both those goals)
I gave up running my own server about 15 years ago. Best decision ever!
I use Fastmail and I add domains whenever I need and it doesn't cost anymore. I assume many other services are similar.
If its just for you it can be done quite cheaply with a account at fastmail or mailbox.org
I'm asking because, in order for the new data to be useful, it must include both successes and failures, which would allow Jessica to test her hypotheses.
Some of the companies I'd be thrilled to see included:
AirbnbStripeUberLyftSlackRobinhoodPalantirSnapInstacartSpaceXGitHub DraftKingsWarby ParkerOfferUp
Ben Chestnut Co-founder and CEO of @mailchimp (aka mailkimp aka mailshrimp), seems a worthy subject. > https://twitter.com/benchestnut?lang=en
For the most part, the stories were great but all revolved around folks who growing consumer/developer-focused companies.
I'd buy the 2nd edition in a heartbeat.
Min-Liang TanPaul EremenkoTravis KalanickBen ChestnutDaniel Stewart
I dont know the founders but the idea that you could start the apts section of craigslist that out values real established businesses itself is a huge motivator.
Of course with close examination, nothing more than a repeat of near zero interest rate capital flooding a crowding market.
Some will strike the lotto, most will not. Hindsight bias is not at all being discussed here.
Tempted to try https://draculatheme.com/
Since I use both editors numerous times throughout the day depending on what I'm doing it's very convenient having both look similar.
But I switch frequently
We interviewed in-person for W17 in October and got rejected because we didn't articulate a good plan for growth. - we grew 4,000% since October- launched huge features for both sides of our marketplace- received acquisition interest in < 3 months of being live- most importantly, made something that people are loving and using on a daily basis.
It's a bummer for sure but not the end of the world.
To anyone who got an interview,Figure out your biggest weakness and a plan for how you overcome it. Your interviewers will exploit it.
Here's some notes on our experience going through the interviewhttps://paper.dropbox.com/doc/YC-Interview-Experience-L45KzT...
Good luck all
We're now sending the rest of the response emails. You should get yours by 7PM.
Please check your post rejection applications - do you see these questions? Did you answer these questions, or does it look like they were added after submission? If I am wrong or misunderstand, I apologize. I submitted my application on 3/22.
Would have our own presentation day, pitch feedback, try out each other's products, etc. I think it would be great! :)
I would even pay for it. I know that's absolutely not within YC's context and mindset, but I'd pay to just read one short line that helps us see what you saw (or hoped to see but didn't).
I totally get rejection, I've been rejected for all sorts of things, but normally for rejection I can understand on some level why.
This I don't get. Not only are we applying with a company that fits with an RFS, not only is our team really solid, not only is concept proven, but we have a possibility to do real social good that both makes money and helps people.
Even in talking to other people, the reaction was either "why are you even doing YC" or "Sheesh I'm embarassed to by applying next to you". I know that sounds really arrogant, and Im sorry for sounding like that. I'm just...confused, I guess? I really wish that the applications came with a reason why they were rejected, even if it was one sentence.
I can't honestly believe that typing a one sentence "rejection for reason" would take that much extra time. Even a drop down of "we rejected you for this one of the following 5 canned reasons" (your team was bad, your idea was bad, you have no revenue, etc.) would be helpful.
Is it because my cofounder is from another country? Or because we don't live in the bay area?
I seriously do not understand this. I know that sounds a little bit whiney, but it's just frustrating to have put this much emotional investment into something and to get rejected for it without even a brief explanation of why.
: For people that don't live in the bay, applying to this program is a big deal. I skipped out on events next week because we might have to block out time for an interview, I moved things around this week specifically so that I could schedule an interview if possible, I moved things around this summer so that if I needed to be in SF I could etc.
I get not counting your chickens and all of that, I don't think we did. Nothing is lost for us here, and moving events and things around isn't a big deal, obviously that is just part of doing business. It is just frustrating to get a rejection email that doesn't even include a few seconds explaining why.
Forever onward, obviously. It just really sucks not having feedback on why you were rejected.
As I read through the comments, I believe many businesses forget the fact that business is ran by the numbers. Yes, can YC help you get attractive numbers for investors, but you can do the exact same thing on your own if you build something people need (love). I find it hard to believe that any investor that YC can introduce you to will turn down your meeting if you have built a business that has attractive numbers. That's what they look for anyway...YC funded or not.
For those that got an interview, congrats. For those that didn't, keep going and be great in what you are doing.
Till then have your lunch, breathe, work on your product and check your emails later this evening. :)
Anybody else in Phoenix? My cofounder and I are going to hang out and get some beers/lunch together while we try to wear out the refresh buttons on our laptops if anybody wants to join us.
When will the invites/rejections be sent out anyway?
> It has to scale to tens, possibly hundreds of thousands of simultaneous users
My suggestion : just use a database you are familiar with and start building. Most comment systems use a rdbms, so that's a safe bet. Use a graph database only if you find a strong technical reason to do so, not because another company is using it.
I just used SQLite, but psql/mysql would work just as well. Handling comments, even threaded ones, isn't likely to be too heavyweight.
If you need extra performance later on, you can always add an extra layer.
Then consider how the technology actually works.
Me, I'm hot. So, a Tempurpedic mattress would be a really bad idea, since they use body heat as a way to alter the viscosity of the material, and thus also reflect that body heat back at you. I tried one briefly at a store, and after just a few minutes, I was burning up.
My wife has always been intrinsically cold, so for her a Tempurpedic mattress would be perfect.
But we weren't just buying a mattress for just one or the other of us. We had to find one that worked for us both.
If you have a SO though I've no data on how well it would work out. :'(
In the UK you can find smaller companies hand making them with only natural layers (and telling you what each layer is made of!) offering 10 year guarantees. They're not cheap though, you're looking at minimum $1,500 and easily $3,000 for a larger size.
I've also slept on an expensive latex mattress and it gave me shoulder and lower back ache. Initially it felt great but the pain started after a couple of nights.
http://www.sleeplikethedead.com/bed-mattress-review-home.htm... might be useful
There's an old-school outfit in NYC called Dixie Foam that sells amazing firm latex mattresses and toppers. (They also sell less expensive polyurethane mattresses, which have a slightly different feel, and are warmer, but come in both softer and even firmer modes. You might combine a poly mattress with a latex topper.)
And I really like the latex foam pillows from Talatech/Latex International, which I could only find online at one place.
 https://dixiefoam.com http://www.sleeplikeabear.com
My present mattress is a firm Tempur Pedic mattress. I probably could've gone with anything of similar firmness. I live in a one-bedroom apartment. I give up my bed for (most) company and sleep on the couch, I got a softer topper for it (can't remember the brand) that some people prefer to the firmness of my bed.
There was a more recent version, but it seems to be down.
Best sleep ever was on a king size mattress at a high end Marriott before they switched to foam toppers. Avoid "memory" foam at all costs if possible.
Invest in a high quality latex mattress topper and pillows. As long as you don't have an allergy it will change your life. If you have lots of money to spend, full latex mattresses are amazing.
It's an amazing piece of materials science, and it feels luxurious as hell, but it was waaaaay too soft for both of us. She woke up in considerable pain. Also, it was pretty hot.
Fortunately, the Leesa customer service people were awesome, and they immediately took it away again and refunded us.
This was once my plan.... a year later I was still sleeping on the first one I bought. :P
Do you have an email record of your booking confirmations? Why not ask the hostel/hotel/bnb operators?
My wife and I ended up with a foam mattress, which we really like. Our only complaint is that it's noticeably warmer in the summer than our previous regular mattress.
You need to figure out whether you prefer a soft mattress or firm. You could go demo a Sleep Number in their store and see which level is best.
After a trip to Japan I found sleeping on a futon was the best sleep I've ever had. After returning home, the first thing I did was buy a roll-out futon. Been sleeping on it ever since. It's cheap, I can store it during the day to "reclaim" space in my room.
I'd probably do just as fine on a firm mattress - but the futon is cheaper than a mattress. I can also roll it up and take it with me when visiting friends or relatives who do not have the luxury of having a "guest room".
I don't miss my bed.
If you're thinking about the RPLIDAR, get it from DF-Robot and not Seeed Studio (DF have better shipping).
I made a handful of units for one company last summer, so the dev cost is covered already. I'd be willing to build a few more. How many do you need?