Tell HN: Dealing with VCs, my experience - <AUTHOR> There are a bunch of steps to dealing with VCs that you should be familiar with before stepping in to the fray.
My background in this is that I did several pitches to VCs and have worked for several VCs in the last couple of years, mostly on the technical side but you get to see a good part of the process as perceived by the companies pitching.  I also helped one company get seed capital, because I thought they showed great promise.
So, the following is from personal experience, which is limited but it may be useful.
Some VC's are more forgiving than others when it comes to following proper form, but even if they're forgiving they'll appreciate it if you know your stuff before you apply. Their agendas are almost always quite full and the amount of time they have to spend on you is limited, so you should use it wisely to maximize your chances of success.
== before you start pitching ==
- First off, let's dispel a popular mistaken belief, getting an investment
 is not 'success'. It's a step towards a possible success, and it may
 give you a better chance, but it basically comes down to another
 party estimating that you have a chance of success and that they
 want a piece of that success in return for an investment.
- You have to know your stuff. This of course, sounds completely
 obvious but it really is surprising how many people will pitch
 to a VC (in itself something of an opportunity) and completely
 blow it by not having done basic homework. A fairly recent
 example, someone wrote a businessplan around a certain
 type of person and was pitching for capital. Halfway through
 the presentation one of the partners of the company being
 pitched interrupted and asked 'And how many of these people
 do you know ?'. A sensible question. The answer '0', more or
 less ended the interview, even though it went on for a while
 beyond that point, for politeness' sake.
Not knowing your target market, not having done any basic
 research in to the demographic that you intend to sell your
 product to is lethal.
As is not knowing your competive arena. If you come up with a
 brilliant plan that looks like some successful competitor is already executing and
 you don't know they exist that's probably the end of the ride for you. You
 really need to spend solid time on mapping out the competition. Know their weak points, know your strong points.
In short, know your stuff, expect to be challenged.
- Make sure you inform your partners about all your moves and get
  them on board before approaching a new party. To find out that
  someone isn't on board after you approach a VC is a real problem.
If there is any problem between the founders get it ironed out
 before you start making pitches, and make sure problems
 are resolved to all parties satisfaction.
- It isn't a must to be incorporated before approaching VCs, but it
  can be a problem if you picked the wrong form.
- if there are pending lawsuits it is usually a good idea to get
 those resolved before pitching as well. This can royally screw
 up your timing, a window of opportunity can easily close while
 you attend to this.
- you have to know what it is that you want that investment for,
 no matter how sure you are that you'll be able to spend it
 wisely, you need to pretty much lay out how you intend to
 use the money an investment will bring. This is where a
 businessplan comes in. These are no longer the 90's, so please
 no columns with more than 9 0's in it. Keep it realistic and
 make sure that it contains realistic estimates for the costs
 of the various components of your business. Factor in
 market rates for salaries, office space and so on. Get a feel
 for what it costs a business of a similar size to operate.
- scouting for capital takes  time. Sometimes LOTS of time. Make
 sure you have that time, and make sure that your business
 does not suffer from this. Farm out as much of the work to your
 co-founders as you can, spread that load. It will give them more
 insight in the process and it will get them more involved.
== approaching target VCs ==
- when approaching a VC try to find out the names of their 'spotters',
 and pitch the spotters first. That way, you essentially get two
 chances, the spotters might be able to tell you how to shape
 up your presentation in areas where it is perceived as weak.
- VCs are busy. Most of them are very busy, you have exactly
 one shot at making a first impression. One good way to get
 their attention is to send a single sheet executive summary
 to one of the junior partners if there are multiple partners,
 otherwise to a senior partner. If they're interested they'll
 hand it off to one of their underlings who will contact you,
 or they might contact you directly. Don't harrass them, but
 do mail two weeks or so later if you haven't had a response
 to inquire what they thought of it.
== a word of warning ==
- There are 'middle-men' in the VC world that sell their
 services to unsuspecting young companies in order to
 get them capital - so they say. The trick is that once they
 have your signature on a piece of paper that gives them
 exclusivity they no longer have to do anything. If you find
 your own capital they will claim their pound of flesh.
Selling 'access' is meaningless. For the price of a google
 search you can find more VCs than you could possibly hope
 to pitch, if your stuff is good and you can present it well
 you will most likely succeed in finding funding, even if
 you do not have an inside track. Work your network, get
 on that phone. It's a lot cheaper than giving some loser
 equity for doing nothing.
If you can't find anybody to refer you then maybe your
 product isn't that good, or maybe your team has a red
 flag. Ask why if you won't get a reference.
== you've been spotted ==
- If a VC approaches you because one of their spotters has
 alerted them to your existence then don't panic. They are
 simply interested, you've materialized on their radar and
 they would probably like to establish some kind of contact
 to be kept in the loop. Give them a bit of backstory about
 your company, don't gush out anything that you would not
 want a competitor to know.
If at some point you feel that the time for approaching investors
 is ripe then inform them. Until then simply keep them up to
 date of major public developments, if you get to know them
 a bit better you can ask for advice on business issues.
- make sure the VC that is asking you for information has not
 invested in a competitor! A bit of googling goes a long way
 before you start giving out confidential data. This is
 obviously not the normal case, but it does occasionally happen.
== pitching ==
- get an NDA signed by everybody that you are going to give
 confidential information if you think that there is something
 non-obvious about what you are going to present. Most people
 are over protective in this respect, but every now and then there
 is a bit of data that is really crucial. Think about if you
 even need to reveal it at this stage.
- Don't assume anything. You are pitching to people that are
 probably whip smart, but they don't have your background in
 your field. They will know business, but they may not know
 a thing about what it is that you are doing. So when you use
 words that are 'obvious' to the incrowd keep in mind that
 you are not talking to the incrowd. Get out of your techie
 mindset (unless the VC you're pitching to is extremely
 technical) and present your company as though building up
 from the ground.
- if you're the CEO of your fledgeling company keep in mind that
 you are speaking for everyone, not just for yourself, and make
 sure that you do not let any conflict of interest arise between
 you and the other founders (you really should have at least one
 co-founder). One of you should speak for all of you, but that one
 person should have the unconditional backing of the others.
- You pay your way (and they pay theirs). A VC is not under any
 obligation to refund you air-fare, hotel costs, legal, presentational
 or any other costs associated with the pitch. Conversely, you
 are not obliged to pay for any of their costs, such as legal
 and technical due dilligence, transportation and so on.
If you're short on cash and you want to pitch to a VC that is
 in an out of the way location for you, then the reality is that
 you may not be able to afford to pitch to them.
A recent weirdness is VCs charging an 'entrance fee', this is
 something to stay very far away from, anybody that wants an
 entrance fee is making money OF you, not WITH you and that
 is why they shouldn't be able to call themselves Venture
 Capitalists. Maybe Vulture Capitalists is a better term for
 such characters.
- know the terminology. If you don't know an NDA from a MOU
 then you will have to spend some time on that. Having your
 eyes glaze over halfway an interview or agreeing to something
 because you do not know what it means and you don't want to
 admit your ignorance is simply stupid. It does not mean that
 you have to know everything, it simply means that it is a lot
 easier to have a conversation with people if everybody is aware
 of the meaning of all the terms. It saves time, and makes you
 come across more professional, and hence will increase your
 chances of success (both to find capital as well as in succeeding
 with your venture).
- Other than NDA's nobody expects anything to be signed
 when it is delivered. So, do not sign stuff that you haven't
 had the time to go over, with your partners and your lawyer.
- When pitching time comes around: Sleep! Again, dead obvious,
 for sure. But the best way to get around being nervous is to
 be well rested. If you have to pitch several parties then
 try to schedule a break between them. I know that when I
 was done with a pitch I would literally be exhausted, unable
 to drive back to the office. It takes every bit of concentration
 and energy from you in a few hours time.
- never go alone. Bring someone along that you can trust  and that
 will give you a no-holds barred evaluation of how you performed.
- if it doesn't work out, don't despair. No angry letters to a VC that
 rejected you, instead, thank them for the opportunity and ask them
 if it is ok to keep them informed of your further development.
Ask them why they rejected you, in as much detail as possible.
Not as a way to get the door to open again, but simply because that
 is the best you can take away from this pitch, a lesson on what went
 wrong or why you did not make the grade.
Try again, and do it better next time.
== due dilligence ==
- Due Dilligence usually consists of several parallel jobs. There
 are legal, technical and financial stages.
Legal is to make sure that you own what you're selling, that all
 the proper procedures and contracts are in place and that
 there are no hidden liabilities. Usually this will also look at
 intellectual property issues and patents if applicable.
Technical is to make sure that what you've built is solid and that
 it will not open up the investor to a potential liability because of
 technical weaknesses.
Financial is to make sure that your books are in order and up to
 date and that there are no skeletons in the closet.
Due Dilligence is a VERY invasive process, depending on the
 quality of the people that the VC hires. My own specialty,
 technical due dilligence usually takes the form of a several hour
 long grilling of the CTO of a company with anybody they wish
 to call on, subsequently they get a long list of follow up questions
 via email. I will want to see your code, meet your developers,
 look at your documentation, inspect your physical security if
 you store private information and so on.
The questions range from simple ones to very complicated
 ones and I've seen at least one CTO flee the room to fix a SPOF
 that became apparent only during the interview. (what do you mean
 you run a single database server and you've never tried to restore
 a backup ? What if that drive crashes and it turns out that none of
 your backups are restorable ?)
== getting to a deal ==
- You have to get your own legal representation. Remember, in
 this phase of the process you are on opposite sides of the table,
 and if you are lax and let the VCs handle your legal bill you are
 effectively using a lawyer who is not working in your interest.
This will cost you dearly.
Pay your own lawyer, and pay him out-of-pocket, not out of
 a deal that hasn't been done yet, the situation should be the
 same if you walk away from it or if you take it. That's important
 because otherwise you might have to do a bad deal just to pay
 the legal fees.
- Nothing is binding until it is signed. Even a LOI isn't as strong
 as a real contract, and money in the bank. That goes both
 ways, but it is considered very bad form to back out once a
 LOI is signed. Still, a letter of intent is not a contract and VCs
 have been known to bow out in spite of signing and if anything
 major happens to your company between the LOI and a real
 deal you will probably be able to back out. But forget about
 pitching that VC ever again.
- Stay in constant touch with your co-founders during the whole
 process, if possible have them there when you're pitching and
 discussing the deal. People kept in the dark are usually not
 going to be happy with a fait-accompli that is not in their
 best interests. By bringing them in on the negotiations you
 stand a much better chance of not messing up your internal
 affairs.
- Feel free to request a better deal! Remember, the VCs will
 negotiate what's best for them. You have to be in control of
 your side, you have to know what it is that you want and how
 much you are willing to give up for it. There is no 'bad' deal
 that was not done, the only deals people regret are the ones
 that they did do, for too little money or too large a stake in
 the company.
This phase can take quite a while, don't feel rushed.
- be careful, there doesn't seem to be much difference from a
  funding perspective between a convertible loan and giving
  out equity, but in practice the difference is huge, especially
  if there are survival clauses and the company goes bust.
== the data room ==
- when preparing a larger deal there will usually be a data room
 set up, a centralized spot at your lawyers, or their lawyers office
 where all the documentation that both parties provide gets
 integrated in to a seamless whole
- you have the fiduciary obligation to inform the other party of
 anything material that you think may influence the deal. If
 someone has threatened to sue you recently then state it,
 make it part of the record. If you don't and the suit does
 happen you are going to be in big trouble.
- the VC has the obligation to do their research as thorough as
 they can, time permitting.
== doing the deal ==
- Once all the details are ironed out, there will be a concept investment
 contract. Usually this will involve changes to the articles of incorporation
 or the shareholder agreements of the company that is being invested in.
Unless you are a legal eagle I'd suggest you spend a lot of quality
 time ( ;) ) with your lawyer during this phase.
- have all your co-founders go over the contract, if they're unsure about
 the language get them to bring their lawyers at their expense. Make
 sure everybody knows exactly what will happen.
Best of luck!
thanks to Mahmud for the critique. <comment><USER2> This post begs the question that going the VC rout is right for "you," which is rarely the case.

Most founders and startups are better off bootstrapping and positioning for an early exit than chasing VCs. If you don't know what an early exit is, why it's a good option to have, and why VC's will usually block it, see Basil Peter's blog, <http://www.angelblog.net/> (he's compiled much of the info on his blog into a PDF called "Early Exits," which you can find there, too).

I'm digressing, but the point is, VCs are wrong for 99% of startups, and that's a good thing. You do not want them unless you don't need them, in which case they will be chasing you and pitching you, which is the way it should be. Bootstrap or get an angel investor.

Signed, Former Venture Investor, now startup founder

<comment><AUTHOR> That's actually a really good point.

But even with angel investors plenty of these points still apply.

</comment></comment><comment><USER3> NDA's just aren't going to happen. And you're going to expose yourself as a noob if you ask for one. No VC (at least here in the US) will sign one. If you really have something that special, get your IP in order first. Provisionals at least. Then, you have some measure of protection. In any case, engage a real IP lawyer. No someone who plays on on HN ... That said, 10 other people have had your idea and might have already pitched these very same VCs. You need to be the best of the 10.

<comment><USER2> You do want them to confirm that they do not have a conflict of interest. if they are not willing to do that, you're probably dealing with one of the many bottom feeders in the biz. See my comment below/about about how checking for conflicts of interest.

<comment><USER4> Like they'd ever tell you.

One VC, after investing in a company I was at, deliberately fed us the pitches of competing companies that were pitching them. Thanks, VC!

Another VC, in a second partner meeting, stocked the room with the m-team of a direct competitor. After the meeting, the competitor talked about "buying" us. Thanks, VC!

Note: in neither case were this minor VCs. You would recognize them.

<comment><USER2> So, by your logic, because you might be lied to, you should not even ask. Smart.

Regardless of the truth of an answer received, when we ask questions, we gain information. If you ask a question and are lied to, you have gained valuable information about the person, among other things.

It's all about information and you get that information by interacting with your counterparty. Even if they sit there and don't make a peep while you talk, you should be gaining valuable information (unless you're a unobservant). If they open their mouths, you gain even more. If they put something in writing, you have it in writing.

The most valuable information often comes from what people DON'T say or when they lie. Don't have time to discuss further today, but people figure that out on their own over time. Maybe.

In our "Do you have any conflicts of interests example?" If you ask and you are lied to, you have what you need. They are locked in. They have made a representation, in writing. You have relied upon it, and you have told them that you are relying upon it (before you peel back more layers of the onion). It has legal and ethical consequences for them.

Regarding your examples, sounds like you might have had unethical people inside your company and got what you deserved. Birds of a feather flock together. Also sounds like you guys were as trusting as schoolchildren and got fleeced. You did not ask the right questions, such as about conflicts. You did not require the right, or any, conditions precedent. Smart.

</comment></comment></comment></comment><comment><USER5> Excellent points. I have very little to add but a few minor bits:

\- Don't worry about NDAs with VCs. At least on this side of the pond, no VC is going to sign them. Don't leave your full deck behind in digital form. Leave them a summary deck on paper if you absolutely must. (just assume the deck will get passed outside the firm).

\- Do make sure the VC doesn't have a conflicting investment - if so, assume everything you talk about will be going into the ears of your competitors.

\- Avoid spotters/associates. Get referred in to a partner by another entrepreneur they've worked with before (work your linkedin or xing). Don't take a 1st meeting with an associate (feel free to chat with them on the phone briefly). If a firm wants to see you, then they can find a partner to talk to you. Associates can only say 'no' and generally have limited deal experience and just may not understand your market (of course there are exceptional individuals and firms where this doesn't apply).

\- Timing is everything. When you're ready to go out - have a list of VCs you want to speak with and try to get all your meetings lined up for the same two to three weeks. VCs all talk to each other. Once they hear another firm passed on your deal, it's harder to get the next one to bite. Make it a parallel competition. Don't overexpose your company.

\- Do research on the firm and the partner that you're pitching. <http://www.thefunded.com> is free for founders. Get an account and use it for research. (I'm not affiliated with thefunded, just a fan).

<comment><AUTHOR> > Associates can only say 'no' and generally have limited deal experience and > just may not understand your market

Interesting!

That's in direct conflict with my (limited, European) experience. Usually you don't get to speak to a partner until you've passed muster with one of the associates, they act as gatekeepers to make sure the partners spend their time on those things that they feel are worth it.

I agree with all your other points, the NDAs are not a common thing in start- ups, but at a later stage they are definitely important.

<comment><USER4> When we did the tour in '05, we were in the door with partners at every firm we pitched, and we're not especially connected. The way to get VC meetings is to have friends who have been funded; you call them up, and they call up their VCs, and it goes from there.

If your friends like/respect you, this isn't a big favor.

<comment><USER4> Hey, by the way, the fact that this industry is so clubby, and that having the right friends rockets you to the front of the line? Something else I don't like about VC-funded startups.

Yes, I know that if you're rocking it, you don't need the friends. But then, if you're rocking it, you don't need a lot of advice on how to engage VC's --- in fact, you don't need the VC's.

</comment></comment></comment></comment><comment><USER4> This is missing an extremely important piece of VC advice, which is that VC's very rarely say "no". They say "not now", and they use different words to say it: "let's take another meeting a couple weeks from now", "we're really interested", "we'd be interested in syndicating with someone else", "yes", etc.

You will lose a lot of time from important things at your startup if you can't either have the cajones to pin them down (of course, you're probably going to get a "no") or run your business in a way that works with or without funding.

From cofounding a company that got an A round, having a decent role at a very successful VC-funded company, and going out again for funding in '05, my gut is that by the time they've sent someone out to talk to you about database architecture, you're getting buying signals.

<comment><AUTHOR> That must be a cultural thing then. In europe the 'no' is loud and clear, when it's no.

What does happen is that VCs are careful not to burn their bridges, they'll not feel comfortable enough to invest but they can't rule out that you'll pull some rabbit from an otherwise empty hat in the future and then they don't want to have the door completely closed.

This is indeed quite common. But when it's 'no', it really is 'no'.

Another typical VC disease is to want to be the _second_ investor in your company, but never the first.

<comment><USER4> "No" probably does mean "no", but you're lucky if you hear "no", because VCs have so many ways to avoid using the word "no".

"Maybe" is so much more expensive than "no".

I'm pretty sure Paul Graham wrote about this in "How To Fund A Startup", but I don't have time to read and he doesn't like being misquoted.

</comment></comment></comment><comment><USER6> This is a great post, but why not stick it on a blog (posterous?) or something less ephemeral than what's essentially the comments section of a news aggregator?

<comment><AUTHOR> I see HN a bit different than you do I think. To me HN is already a pretty good resource for information like this, I think I have more threads here bookmarked than from any other site I frequent.

It's a veritable gold mine for information.

Another thing you get when you post stuff on some blog somewhere that is really written exclusively for HN is that the comments will split between the two pages.

Like this it's all in one place. It's not like I need the pageviews.

<comment><USER7> The low-contrast faint text on tan makes it annoying to read. Would be nice to see higher contrast, and perhaps narrower column, for long posts like this.

<comment><USER8> It is a bit straining. If you're on mac cmd+opt+ctrl+8 helps a little.

<comment><USER9> good tip! I wonder why cmd-opt-ctrl doesn't have any other numerical bindings... it seems like there's an opportunity to create a usability convention, but instead, this function is sitting by itself on an island named "8".

</comment></comment></comment></comment></comment><comment><USER10> What a great informative post! Thanks and thanks to Mahmud as well.

 _\- There are 'middle-men' in the VC world that sell their services to unsuspecting young companies in order to get them capital - so they say. The trick is that once they have your signature on a piece of paper that gives them exclusivity they no longer have to do anything. If you find your own capital they will claim their pound of flesh._

I recently came across someone with biz plan (essentially one-person with a vague plan in his head and some details on a PPT) who has come here in Dubai in search of funding and exploring clients. I tagged along with this founder to a meeting with one such person - (I've never been involved even remotely with any VC/angels/startups - so I'm not really sure if I'm reading your description of middleman correctly) - and I was quite frankly there only to learn how these kind of deals/discussions take place. I was essentially a passive listener while the two of them discussed over coffee.

I was surprised by how it went. He asked for a 7% stake via some kind of a nominee account in exchange of getting a funding of around $1M + some upfront commission % off the actual funds he could get, and 25% stake for the investors. More importantly he said something about this nominee account means he is not listed as a stakeholder in any of company's legalities (I got the impression that he'd not be held for any future liabilities, lawsuits etc) yet he'd share in the profits....that part was confusing to me.

By all background checks, this guy seems like a well-connected investment consultant who has worked on bigger deals and he indicated this nominee stake thing in a off-hand way and said it was an industry norm. And all he would be doing was take this business plan and pitch it to investors in his network.

And get this: there is no real way to even evaluate or even remotely guesstimate the worth of this business, because as I said right now it's just a plan in someone's head, a shoddy website and cheapjack PPT with nothing really fleshed out.

What's the deal with this nominee stake thing? Certainly he needs to be compensated for his efforts but 7% sounded a bit too much. But what do I know.

Can someone tell me, if this is how just deals take place? If so would you call this angel investment or VC? And apart from the funding size, is there any real legal difference between angel investors and VCs?

</comment><comment><USER11> Great stuff jacque, I'm really digging your posts here. May I inquire when you went through this process and for what company?

+1

Cheers, Steve

<comment><AUTHOR> The most recent stuff is related to 'infocaster', before that 'camarades', but that's already quite a while ago.

My NDA with the VCs I've worked for is such that I can not give you the names of the companies that I did tdd for without asking them and I don't see how it really would matter which companies they are, but the deals were on the order of tens of millions of euros, so a little larger than your average seed investment.

The principles are much the same at that level but the procedures are far more formal and in depth than at the lower levels of investment. Due diligence for a larger company can take several weeks, at the start-up level there is usually not a whole lot in terms of financial and legal, later those are actually the bigger portion of the time.

There usually is quite a bit of time pressure.

When taken as a percentage of the value of the deal due diligence can cost quite a bit in early stage investments, so it can be a partner or the CFO/CTO of a company 'friendly' to the VC (or one they've already invested in) that will have a thorough look.

Later, as the amounts go up and there is a lot more money available to have this work done by outsiders, also because it usually is too much work to do as a favour.

The VC world is a very tightly interwoven one, lots of partners have a stake in more than one company, some may even have an angel fund of their own. So when you pitch to a VC and you don't get a deal there is still a small chance that one of the VCs partners will do an investment out of their own pocket, outside of the main fund.

And sometimes that's the way to get an investment for a 'stage mismatch', where a VC is interested in you but your current situation does not match their preferred profile. They can then do a smaller investment through one of the partners, it gives them the inside view for relatively little money and it is a way to hedge their bets. By the time you're ready for a larger round they'll have their foot in the door and will be preferred candidate.

<comment><USER12> > deals were on the order of tens of millions of euros

Early stage folks tend to be more lightweight than the processes you mentioned. Less technical due diligence (because there's less to investigate, obviously, etc)

> some may even have an angel fund of their own

Increasingly, this is not allowed.

<comment><AUTHOR> > Early stage folks tend to be more lightweight than the processes you > mentioned.

It depends on how far you got under your own power and how big the deal is. Anything that comes from a fund will have the whole show regardless, they have to because otherwise if a company imploded after the deal was done they could be held liable.

And some small time investors are quite savvy, and have their own small army of people to call on. "Angel" deals are different, there it is all much more personal.

But even an Angel deal > 250K will have quite a bit of dd, unless there is a longstanding relationship between all parties.

</comment></comment></comment></comment><comment><USER13> As a young guy who tries to learn everything he can on the business of VCs and that whole world this post was awesome!

-know the terminology. If you don't know an NDA from a MOU then you will have to spend some time on that.

Does anyone have any tips on where I can spend some time studying up on that? NDA is pretty much the only term I know.

<comment><USER4> MOU/LOI - memo of understanding / letter of intent. More concrete and binding than a conversation. Less so than a contract.

The only words you need to know are "term sheet". You will get a term sheet before you get any other form of commitment. You don't care about the other details, because when you get a term sheet, you can tell other VCs that you got it, and now you have competition.

I don't think you need to know the jargon to do the VC thing, other than you should know the lifecycle of a deal, which is something that's kind of missing from this post.

You need to know what should be happening before the term sheet and after the term sheet --- pitching, market due diligence, the partner meeting, term sheet, all the rest of the due diligence, 9 months of waiting with 86.7% chance of flaking, the room at the law office with the papers you have to sign, steak dinner.

The VCs know you're not an MBA, even if you try to sound like one.

</comment></comment><comment><USER14> Middle-men are a personal pet-hate of mine - I wonder if we should publicly name and shame on HN.

Difficult line to tread, but is it worth it?

<comment><AUTHOR> Better not because you might open up YC to liability, it is their site after all.

</comment></comment><comment><USER15> Awesome post, Thanks lot..

+1

pk</comment>


Sorting 2 Metric Tons of Lego - <AUTHOR> https://jacquesmattheij.com/sorting-two-metric-tons-of-lego/ <comment><AUTHOR> He said the data and code will be made public about a year back. Anybody knows if it is available now ?</comment>


Airpush are quite happy to support developers who want to deceive their users. - <AUTHOR>

(Airpush are a controversial company that creates ad software that pushes ads to the Android notification bar usually used for new email and message notifications. Often users don't know which app they have to uninstall to get rid of them)
Live Chat Transcript:
Me: What are your guidelines for notifying end-users about notification area ads?
You are now speaking with Lisa of Sales.
Lisa: Hello
Me: Hi
Lisa: Welcome to Airpush Lisa: Are you a developer or advertiser?
Me: developer
Lisa: Great Lisa: Regarding your question, you can which users will receive your ad and that too how often Lisa: adjust*
Me: How does a user know which app is sending the ads?
Lisa: It will be reflecting your developer's dashboard once you start listing your apps
Me: i.e. User X updates a dozen apps and suddenly starts getting notification ads. How do they know which app is creating them? Me: I'm talking about end users here Me: not developers or advertisers
Lisa: ok Lisa: There is an API key through which you can control the user engagements Lisa: by a push notofication ad
Me: I don't understand how that sentence relates to my question.
Lisa: in this case, the users will receive the ad any time an ad is pushed to a device, whether or not the user actually views the ad or not.
Me: I asked how a user knows which app triggered an ad.
Me: are ads labelled with the originating app name?
Lisa: He will be receiving it in a push notification tray
Me: are ads labelled with the originating app name?
Lisa: Just give me a moment. let me check
Me: To repeat an earlier example - User X updates a dozen apps and suddenly starts getting notification ads. How do they know which app is creating them?
Lisa: for each app they need to setup airpush sdk so they will get the report data in their airpush controlpanel
Me: That doesn't answer my question. Do you understand what I'm asking you? Me: Imagine I am a user. Me: I install several apps and one of them contains Airpush. Me: I suddenly get notification ads and want to know which app is creating them. How can I tell? Me: Are you still there?
Lisa: It depends on the app setting and cannot control that Lisa: And the ads are not labelled with the originating app name?
Me: If a user dislikes the ads - is there any way for him to know which app caused it? I'm worried I'll get bad ratings.
Lisa: No
Lisa: The user will not know
Me: Hopefully users won't know it's my app that's doing it so they won't uninstall my app.
Lisa: No don't worry about that.
Lisa: Here you can also benefit through inactive users as you can configure your settings to deliver ads to users who haven't used an app for X days
Me: And they won't know it's me?
Lisa: No not at all.
Me: Cool. Me: OK. You seem quite happy to support developers who knowingly spam their users. Do you mind if I publish a transcript of this conversation so other people can see how little regard you have for end-users? Me: Hopefully it will hasten the speed at which your nasty company goes out of business
Lisa: Surely it will not.
Me: It's a very revealing conversation.
Me: Thank-you for being so candid.
Lisa: But I believe we maintain our privacy
Me: Who's privacy?
Lisa: And as long as we receive good responses, we will definitely look up to everyone's reputation
Me: Do you receive good responses from end-users?
Lisa: Yes definitely.
Me: Like all the users of APN Droid who have been leaving 1 star reviews and complaints on the Market?
Lisa: Anyways you can download our SDK and start listing your apps if you are happy with it.
<comment></comment><comment></comment><comment>---- Your party has left this session. </comment><comment></comment><comment></comment><comment>---- </comment><comment><USER2> Google needs to seriously start cleaning house in the Market. Given that most Android phones out there can sideload, there won't even be that much of a backlash. I suspect the only reason they aren't already doing this is because they have an organisational distaste for manual screening. The sooner they fix the market, the healthier the Android ecosystem.

</comment><comment><USER3> This blows my mind, but I guess I'm naive when it comes to how sleazy people can be.

I love Android, and I don't want it to be known to the general public as the virus and spyware ridden OS on smartphones.

<comment><USER4> Looks like Android needs a curated distribution, the Ubuntu of smartphones.

Wait, why isn't Canonical already on this?

<comment><USER5> Wasn't that the idea behind the Amazon appstore? Bringing an Apple-esque restricted store to Android to compete with Google's free for all market?

</comment></comment></comment><comment><USER6> It's Windows all over again, with apps sticking themselves in the tray unnecessarily, coming bundled with popups, and wanting updates every 3 days. Google and Apple need to draw hard and fast limits on every one of these common resources and also consider banning apps that abuse notifications to deliver ads.

Because this isn't innovation, it is exploitation.

<comment><USER7> I think the comparison to Windows is a stretch because Windows does not push ads in the system tray and because anything in the system tray is generally identifiable to the user and frequently configured with modest effort by the user as well (though a developer can certainly take steps to make it a royal pain in the ass - printer manufacturers come to mind).

<comment><USER6> The examples used are, but these sorts of user exploitation in the name of 'innovation' and 'branding' smell exactly the same as in years past. They illustrate a complete lack of empathy (and subsequently, taste) on the part of the developers, piss off users, and generally drive the perception of the platform down over the long run.

Printer drivers seem to be nothing more than a sick in-joke as to who can make the biggest, most useless pieces of software.

</comment></comment></comment><comment><USER8> All -- we respect your feedback and are responding. We are releasing an emergency update which will make Airpush ads OPT-IN by the users. Users will be prompted upon install if they want to support the developer by allowing 1 ad/day in their tray.

With this change, as a user would you find Airpush as an acceptable monetization option for the developer? This makes it purely a user's choice.

Please note we have already offered a "Permissions API" which many developers are using to create their own opt-in and opt-out procedures, but we are now taking the additional step of FORCING it in our SDK.

Comments are much appreciated.

<comment><USER9> No. Ads in the notification area are unacceptable noise -- an abuse of the system. I would uninstall any app that did it, tell anyone who would listen to install it and probably scream at my phone for a while if an app started doing it.

<comment><USER8> So because you wouldn't OPT-IN to receive the ads, you think it's fair not to allow others to opt-in?

We believe that with a solid opt-in in place, users should be able to support the developer by receiving Airpush ads.

Our mistake was we gave full control to the developers to build custom opt-in and opt-out using our Permissions API, whereas going forward we will FORCE a standardized opt-in dialog box.

<comment><USER9> If I never saw a notification-bar ad, I would not have a problem. The first time though -- the app gets uninstalled and gets a bad review.

</comment></comment></comment></comment><comment><USER10> I'm sorry, but airpush is ridiculous, and any developer that chooses to use it is asking the community to give it's app a bad name.

I also had a conversation with "matt" from airpush when this story broke on reddit.

<http://pastebin.com/c8cpd5H8>

Needless to say, they've done nothing to refresh their image in the Android community's eyes.

</comment><comment><USER11> I was thinking a few weeks ago about how new advertising models on mobile would look like. The first thing that came to mind was exactly this: ads in the notification bar for Android.

Plenty of business models require that the user trade a negative benefit for a positive benefit. To succeed, you just have to ensure the net value to the user is positive. Yes, new ways of advertising are jarring at first, but some people will buy into it and adoption and acceptance start from there.

The company singled out here is clearly implementing this concept very poorly and possibly causing irreparable damage to this new advertising method, but it's the company's approach that is problematic, not the method itself.

</comment><comment><USER8> The support rep has given you wrong informaton. We ask all of our developers to put a notice in the Details page of their app, which APNDroid clearly had posted for all users to see. We also provide an API for developers to build custom opt-in and opt-out for the push notification ads.

Some users give bad ratings to many types of ad units, including rich media ads and full page interstitials. That doesn't mean a developer should avoid them.

<comment><USER12> Not sufficient. Does the notification showing the ad show which application it's coming from?

As long as you don't implement this, you are being disingenuous.

Not that I really care that much, to be honest: I bet that AirPush will shut down and be completely forgotten in a matter of months.

</comment></comment><comment><USER13> Hey Guys,

At Airpush developers are required to put a notice on their Details page in the Android Market. Also, when an Airpush ad is sent to the device, the icon used in the notification bar is your App's icon.

Link - [http://www.airpush.com/faq/#can-users-determine-which-app- is...](http://www.airpush.com/faq/#can-users-determine-which-app-is-sending- the-airpush-ads)

</comment><comment><USER14> Why is this showing up in "Ask"?

<comment><AUTHOR> Ack - sorry. I think it's because I didn't include a URL. I should have posted the content elsewhere and a link in HN. I forgot HN doesn't really support longer form posts like this. In my defence, I'm currently blog-less.

<comment><USER7> You could edit the title to "Tell HN:"

</comment></comment></comment><comment><USER15> Wow thick-headed much? Thanks for sharing, made me laugh.</comment>


Top Best Websites When You Are Bored at Work - <AUTHOR> http://www.designsave.net/2016/02/top-10-best-websites-when-you-are-bored-at-work.html <comment><USER2> Zoomquilt.org is amazing. How is that even possible? Really just a movie I guess?</comment>


Backpropagation explicitly showing all the calculations for a full sized network [pdf] - <AUTHOR> https://web.archive.org/web/20150317210621/https://www4.rgu.ac.uk/files/chapter3%20-%20bp.pdf <comment><USER2> Backpropatation can also be likened to creating feature attributes in a vector which are scored and ranked making for rich continuously valued vectors which can then be compared (or treed) for similarity using experimental methods.</comment>


Superspeed your AngularJS apps - <AUTHOR> http://orangevolt.blogspot.com/2013/08/superspeed-your-angularjs-apps.html

<comment><USER2> Angular's data binding is nice and has sold me on using that framework. As fairly point out in the blog post it can slow down the browser with to many DOM updates. This looks like a decent solution to have the DOM update when you want them to happen as opposed constantly with Angular. Generally this only problematic when you have a large amount of data being rendered on the page.</comment>


A Letter to Millennials: Don't Sleep Through the Revolution - <AUTHOR> http://time.com/3949933/millennial-letter-revolution/

<comment><USER2> I feel like I've read a pamphlet.

With enough enthusiasm most structural changes can be interpreted as politically driven to spin opposition.

Look at the stretch he made just to suggest Thiel might be sexist. Or that he somehow connects general libertarianism with the ignorance of copyright restrictions. (Which is just polemic and wrong. It's controversial and even Rand was a big fan.)

He believes it becomes harder to differentiate between Kim Dotcom and warlords? How out of touch is that?

</comment><comment><AUTHOR> To be clear, I'm not endorsing anything the author says. I just figured this might spark some interesting discussion on the moral implications of running a tech company, and might also give those in the Silicon Valley bubble a sense of how some outsiders perceive the dogged libertarianism of the Valley's most prominent leaders.</comment>


Exceptions are Bad - <AUTHOR> http://blogs.atlassian.com/developer/2011/05/exceptions_are_bad.html <comment><USER3> Exceptions have a major advantage not mentioned by the OP.

In code, errors usually happen several stack frames away from the code that knows how to recover. The network can't transmit data because a remote computer doesn't respond[0], so it passes an error to the network library, which passes an error to an RPC dispatcher, which passes an error to the high- level RPC interface, which finally produces an error at the site of your RPC call, where you can decide what to do.

If you don't have exceptions, you must write all of this error handling code yourself. Plus, if you need to pass the error higher than the call site to make a good decision, you must write that too. However, if you have exceptions, you can avoid writing most of the error passing code, and you can group error handling logic in the same place. You get more flexibility in structuring and refactoring your code, in exchange for encountering problems when things unexpectedly go out of scope.

[0] This certainly passes my 'exceptional circumstance' threshold, since success is no longer possible.

</comment><comment><USER4> Let me get this straight: he's doing a a full circle -- _without_ examining how the current situation came to be.

At some point we went for exception, because (warning: big simplification ahead!) library authors figured they can't trust client code to always check return value for reported error condition. We got automatic, forced checking injected by compiler -- `exceptions'. With all the pains of _fugly_ syntax in certain languages, because in many projects the trade-off makes sense. With the reasonable default for unexpected and unhandled condition: error is logged and process is stopped.

Now the proposal -- `Let's have [[EDIT]]a tagged union: Either<error_code, return_value> ' takes us back to where we started -- client code is free to not check for errors. The process will not stop nor even print backtrace if the programmer forgets to check; the process will happily go on with invalid / unsupported / mangled / whatever data. No automatic propagation of error down the stack to outer handler in our function's caller. No stack unwind nor automatic object destruction. No hierarchy of error types (no specific errors derived from general ones). No nothing. And _no discussion_ of those matters.

Oh, my. Reliability in software has just gotten a new name.

EDIT: fix'd mistake pointed out by tianyicui & thesz. Thanks!

<comment><USER5> > [...] client code is free to not check for errors. The process will not stop > nor even print backtrace if the programmer forgets to check; the process > will happily go on with invalid / unsupported / mangled / whatever data. > [...]

This statement is simply not true, at least in languages that actually have Either data types (read: Haskell). But I'm not sure how to implement the generic class Either in Java.

<comment><USER4> Please elaborate on how it works? Perhaps I got this very wrong; never used an Either<> class.

Would an attempt to access the value (if an error was indicated instead) cause error condition? Would it be similar in nature to an exception?

<comment><USER6> > Would an attempt to access the value (if an error was indicated instead) > cause error condition? Would it be similar in nature to an exception?

Either is a tagged union (actually a sum type), you have a value OR an error, which are typed (haskell uses Left and Right as the constructors for Either, by convention Left holds an error and Right holds a value, because right is correct).

You can not just "cast" your Either, you have to type-check it with a case (or use monadic operators) to unwrap it, and with the right flag the compiler will ensure you're not missing cases. At compile time.

Either is basically Schrödinger's box (the computation resulted in both a value and an error), and the compiler checks that you're set for handling both a dead and a live cat, or it will not let you open the box.

<comment><USER4> Thanks for explanations; now it makes sense to me.

Another question: is there built-in support, or an idiom or standard practice for unwinding multiple levels of stack? Is it possible to have handler code is not directly in the function that called, but somewhere lower on the call stack -- and have it reached automatically like an exception does?

Btw., it seems the bolder statement I post to HN, the wronger it turns out to be... oh, boy XD

<comment><USER6> > Another question: is there built-in support, or an idiom or standard > practice for unwinding multiple levels of stack? Is it possible to have > handler code is not directly in the function that called, but somewhere > lower on the call stack -- and have it reached automatically like an > exception does?

Not that I know, but I am very much a haskell novice. You may want to ask for further information in /r/haskell, on reddit.

</comment></comment></comment></comment></comment></comment><comment><USER7> _Now we have a more honest result type. It tells you that it will definitely for each and every String return you something, either the Integer value or a NumberFormatValidation (or an ErrorMessage, or an error String or whatever). There is no null to deal with anywhere and no ugly catch blocks._

Is there really a significant difference between:

      Either<Bad, Good> result = callMyFunction(foo, bar);
      if (result.getBad() != null) {
          //Handle error
      }
      //Do something with result.getGood();

...and the regular:

      try {
          Good result = callMyFunction(foo, bar);
          //do something with result;
      } catch (Exception e) {
          //Handle error
      }

The first example is one line shorter, yay, but if you want to "throw" your error upwards, you have to convert that Bad object into whatever is the error class for your current scope and return that. Did you really gain anything here? Or does the Either class have some extra magic on it that makes this unnecessary?

<comment><USER8> Your example is too simple. Yes, if what you want is the exact same semantics that you get with exceptions, Either is little better than exceptions.

I believe the trick with Either is that it assists one in designing completely different strategies. For example, you can design plugins that accept ambiguous arguments. Sometimes -- often, actually -- you really want to write this:

        user_photo = load_user_photo(username)
        ui.display_user_page(username, user_photo)

but instead you are compelled to write something like this:

        try {
          user_photo = load_user_photo(username)
        } catch (PhotoFormatException e) {
          ui.tell_the_user_the_format_is_bad
          user_photo = NULL
        } catch (Exception e) {
          if (ui.interactive?) {
            ui.tell_the_user_a_terrible_error_occurred(e)
          }
          unless (ui.app_in_production?) {
            throw new MyScopeException(e, "bug")
          }
        }
        if (is_null(user_photo)) {
          ui.display_user_page_without_photo(username)
        }
        else {
          ui.display_user_page_with_photo(username, user_photo)
        }

(Now, I wrote that in an extra-clumsy way, but only so that we might fully appreciate the clumsiness of the logic. In the real world, I'd probably try to do this more elegantly. The result would probably (a) look cleaner; (b) be far more abstract, confusing, and overdesigned than it needed to be; and (c) contain a half-implemented broken implementation of the Either pattern. ;)

What we have here is an application that might need to behave differently if there is a photo or not, and differently if the user is a production customer, a script running in production, or a developer running on a local machine. And because exceptions behave like exceptions whether I like it or not -- they always travel up the stack, they're always in a panic -- that try/catch logic has to be here, at this level.

But if load_user_photo() could return an Either I could just pass that Either to ui.display_user_page(). And then I could plug in a "ui" class that does something like this [1]:

        class Ui {
          function display_user_page(username, user_photo) {
             # The customer is blind; user_photo is irrelevant.
             say("The username is " + username)
          }
        }

Or this:

        class Ui {
          function display_user_page(username, user_photo) {
             print("The username is " + username)
             if user_photo.is_good?() {
               display_photo(user_photo)
             }
          }
        }

Or this:

        class Ui {
          function display_user_page(username, user_photo) {
             if user_photo.is_bad?() {
               throw new HorrorException("I am shocked")
             }
          }
        }

or whatever you like. This logic doesn't necessarily belong in your main logic, it belongs in a plugin, and the Either pattern helps you send it there.

\---

[1] These are oversimplified examples too, of course. In the real world my class would probably do a little more exception handling. There is a certain amount of irreducible pain in dealing with the infinite number of things that might go wrong; all the language can do is give us the flexibility to organize the resulting pile of code as best we can.

<comment><USER9> So basically an Either is for returning a different (ostensibly error) type in a language that normally cares about the declared return type in a method signature?

How would that work for passing the result to another method for analysis? Relax the rules there too? Wouldn't that require doing away with compiler/interpretor type enforcement altogether? (not that I have a problem with that)

<comment><USER10> The type checker will confirm that other function accepts a (Either Bad Good) as its argument. If you want to use a function that only takes a Good and returns a SomethingElse, call it in a "do" block and the call will be skipped if you got a Bad (because in the Either monad, the Left value is used for short-circuit failure) or use liftM to convert it to a function that takes a (Either Bad Good) and returns a (Either Bad SomethingElse).

A lot of other languages had to bake in exception type checking as a weird special case, because even though the type of a function (because that's really about when you can and cannot use it) should depend on which exceptions it handles, they made that way too much hassle to actually enforce.

However, Haskell is still evolving, and people have also added a couple versions of the typical bypass-the-type-system exception trainwreck, for reasons that escape me.

[http://www.randomhacks.net/articles/2007/03/10/haskell-8-way...](http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways- to-report-errors)

</comment></comment></comment></comment><comment><USER11> I don't agree that returning an Either is better than returning/throwing. It depends on what you do in the error case. If you try to recover, then Either is better. If you fail fast, then throwing is better.

The main problem with checked exceptions, at least in Java, is the clumsiness of doing things right. Ideally every function would expose exceptions corresponding to useful error cases. Instead, because there's so much boilerplate involved in creating new exception types and wrapping exceptions as the proper type, programmers are more likely to swallow or blindly propagate.

I believe making checked exceptions signifcantly better is as easy as adding two features to Java:

\- Easy wrapping. 'wraps Type1 as Type2' for try blocks and function signatures. \- Easy inline defining of new exceptions. 'throws forge ParityMismatch extends IllegalArgumentException'

<comment><USER12> If you read the comments, the author wrote a comment that basically says this. Exceptions should be used for fatal errors, not for recoverable errors.

</comment></comment><comment><USER13> I think checked exception are indeed annoying, specifying what exception types can be thrown in the method documentation it's pretty much enough. However I don't think ugliness is the main reason why exception should be avoided as much as possible, I think is _performance_ : You get a performance penalty when you throw exceptions.

About the return values, since .NET 2.0 the TryParse calls were introduced and it works pretty well in the case you don't need to know the details of a failed parsing operation which I think is the 95% of the cases:

public static bool TryParse( string s, out int result )

I'm not saying we should stop using exceptions, but we should have more High poerfomance alternatives like this in Java.

More info here: <http://msdn.microsoft.com/en-us/library/f02979c7.aspx>

<comment><USER14> This is a common dogma in .net land. If we're being fair a more accurate statement would be "you _currently_ get a performance penalty when you throw exceptions in _Microsoft's implementation_ of _.net_ ".

Exceptions are much faster in mono than Microsoft's .net[0], are much faster still in Java[0] and can be made as fast as goto in Java in some circumstances[1], particularly if you control the Exception class being thrown.

Claiming Exceptions are slow is like saying "Java is slow". Languages and language features aren't slow, implementations are.

[0] [http://weblog.ikvm.net/PermaLink.aspx?guid=388b2a6d-e7b2-4ff...](http://weblog.ikvm.net/PermaLink.aspx?guid=388b2a6d-e7b2-4ffa-86e7-450c87e6178f) [1] [http://blogs.oracle.com/jrose/entry/longjumps_considered_ine...](http://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive)

<comment><USER13> These are very interesting articles benjiweber and you are right, it depends of the implementation. My point is that there are some cases in which you can gain some speed by no throwing exceptions at all and TryParse is a perfect example of this(at least in .NET). Also exception-handling blocks might prevent the Virtual Machine from inlining the method(again, at least in .NET), is this true for the JVM too?

</comment></comment></comment><comment><USER15> That was boring. I like Damien Katz' [epic piece about errors and exceptions](<http://damienkatz.net/2006/04/error_code_vs_e.html>) much better.

</comment><comment><USER16> Errors are bad. Errors don't respect encapsulation. No amount of design work will anticipate a SomebodyPouredACokeOnARouterInDetroit exception. If a system is composable, there's alway the chance that some subsystem is going to throw an error that wasn't anticipated.

Things like Either[A,B] make me cringe because they're just like what we used to do back in the 1980's in C. You know, it used to be that you wanted to write

int doAandB(x,y) { return A(x)+B(y); }

but then you had to deal with error values, and it turns out that A and B never returned a negative integer so you'd write

int doAandB(x,y) { int a,b; a=A(x); if (a==-1) return -1;

        b=B(x);
        if (b==-1)
            return -1;

        return a+b;

}

3 lines of code balloons to 9 lines of code. Read carefully: adding error handling has tripled the size of this code sample!

That's what exceptions win for you... Effectively you get the extra 6 lines of code written for you. You might argue that the default behavior of exceptions might not be exactly what you want, but it's much better than the first example I wrote... Aborting is a better default behavior than barreling past an error.

Now, Either[A,B] is better than returning an in-band signal like -1, but still requires you to write the bulky error handling code.

A real advantage of having something like Either[A,B] is when you're using asynchronous communications. Just the other day, I was dealing with something that used Scala actors and it turned out that sometimes the "business end" of the actor would fail with an Exception. If you catch the Exception in the actor and send it in a message to the next actor, it lets the next actor see the Exception and decide what it wants to do about the failure.

As for variance of Exceptions, that's a pipe dream. Imagine a system that has a subsystem that looks something up in a 'database'. That 'database' could be an in-RAM lookup table (never throws exceptions), it could be an on-disk lookup table (can throw IOException), it could be a web service (can throw networking-related exceptions), or it could be using something like JDBC (which could throw it's own exceptions).

If you constrain the kind of exceptions that can be thrown by the subsystem, you either destroy the composability of the system or you 'dump-down' the error information that's available to the executive level of the software.

Now, if you REALLY want to move forward but not back with composability of error handling, what's needed is some mechanism that the executive level gets 'hints' that would help it deal with the error. That is, lets it answer questions like:

(i) if I try this again immediately, is it likely that this will succeed? (ii) if I try this again in five minutes, is it likely that this will succeed? (iii) was this error caused by specific bad data I sent, or is this subsystem in a completely failed state... etc.

<comment><USER17> "Things like Either[A,B] make me cringe because they're just like what we used to do back in the 1980's in C."

In C(++/#), yes.

In Haskell, there's two absolutely critical differences, which are worth pointing out, because while it's fun to raid Haskell for ideas it's important to understand the context from which they come or you'll end up thinking good ideas are just crazy. (I _want_ to see other languages raid Haskell, but it ends up being very easy to copy the form and entirely, utterly miss the substance. I see the same problem with Erlang copiers.)

First, the compiler forces you to unpack the error. Now, you can still write code that discards the error or fails to handle it, but you can't simply _forget_.

Second, you _can_ compose these together:

        bigOperation = do
            a <- eitherOperation
            b <- eitherOperation
            c <- someOtherEitherOperation
            return $ a + b + c

With the do notation in the Either monad, you'll get the first error in the sequence, or the final result; you do not need to handle each error individually. This is a choice you make on purpose; if you want to, you can, if you want to handle errors in some other manner, you can, etc, this is not "the" error handling technique in the language, it's just one that ships in the base library. Personally I don't much like it because people tend to use Either with a string in the error position, and I really hate it when strings are the base error type.

(Also, there is a bit of a problem composing together different bits of code that handle errors differently, which is a disadvantage of giving the programmer so much flexibility. The exceptions mechanisms may not be perfect but they are consistent.)

And, indeed, just copying the Either type into C(++/#) is copying the form and missing the substance. I don't know what the solution for C(++/#) is, none of those languages have rich enough abstraction to copy Haskell here.

<comment><USER18> IIRC in c# you can abuse selectmany and it's inline linq syntax to achieve more or less the same effect. (google "monad selectmany" for examples)

</comment></comment></comment><comment><USER19> I am rather fond of the jQuery style of chaining method calls, which doesnt work if methods return status codes. OTOH I dont like checked exceptions at all. Mainly because development teams go overboard with an exception for every type of problem. I make a call to a subsystem and I immediately have to deal with half a dozen exception types so that I dont have to clutter up the signature of my method. Especially in other peoples code where the exceptions are just swallowed leaving behind "//TODO add logging".

The Either class looks like a reasonable alternative, although I would do it slightly differently. Either<String> result = myMethod(). probably with a different.

       result.getError();

would return some kind of error object

       result.getValue();

would throw an exception if there were an error.

It looks promising. I think I will play with it in Java.

<comment><USER6> The problem here is that you can't really statically check your stuff.

With either and match completeness turned on, the compiler will _force_ you to handle the error case, you have to "ignore" it very explicitly by doing nothing in its handling.

</comment></comment><comment> brown9-2 What's the problem with returning _null_ from the Integer parse method, provided that you _document_ when this method will return null? The author dismisses this option without much of an explanation.

The aversion to using null for a return type here seems to be a symptom of the same problem as throwing an unchecked exception - when the behavior isn't probably documented, the developer isn't given a chance to know that the return from the method needs to be handled.

But, if you can't trust developers to write or read documentation, then is it really worth it to go out of you way to invent new ways of returning a non- success response from this method? The underlying problem still exists - <USER2> of communication.

<comment><USER12> The problem with returning null is that you end up with an error in one part of the code causing an exception in a later part of the code.

Integer i = foo(); //Do a bunch of stuff doSomething(i);

is _much_ harder to debug, especially if doSomething() is documented that it is forbidden to call with a null. You now need to find where i came from, which can be non-trivial.

If instead you return Either<SomeError,Integer> you now can't call a function that hasn't contracted to either not unbox the value, or deal with the error. It's making the type signature match the documentation, which means that the compiler will help catch programmer error. I don't see how this can be anything but a good thing.

</comment></comment><comment><USER20> The main problem is to decide what really an exception is. One can make the point that, in 99% of the cases, exceptions in a function should be handled as predictable actions. If a correct client needs to deal with it, it is better to use if/else than a try/catch clause. The later almost always makes to code more obscure and difficult to understand. There is a reason why in professional C programs most of the code goes to error handling: it is necessary. The equivalent Java code will just have one try/catch per line of code, or just let exceptions crash the app.

</comment><comment><USER21> Gaaahh.... Just because C++ and Java do something incredibly stupid when it comes to exceptions, doesn't mean exceptions are bad. Just that C++ and Java suck.

(hint: exceptions without restarts are retarded)

</comment><comment><USER22> Look at Node.js, where exceptions don't necessarily travel up written code, begetting the convention of passing an error object, similar to what the OP proposes.

I don't like it, I don't think anyone particularly likes it. It makes you miss exceptions.</comment>


IPhone 5 with a Power Grab? - <AUTHOR> http://techtodayshow.com/iphone-5-with-a-power-grab/

<comment><USER2> Frankly it's about time. They need to do something to come into compliance with parts of the world that have standardized on USB connector/power brick requirements. Right now they are the only cell phone that doesn't except a standard USB charging cable.</comment>


Custom-Made Spotify Box - <AUTHOR> http://vimeo.com/21387481

<comment><USER2> What a cool concept. I love it. Make one for rdio and I'm sold.</comment>


James Hong: Reinventing HOTorNOT, Part III - <AUTHOR> http://james.hotornot.com/2007/07/reinventing-hotornot-part-iii.html <comment><AUTHOR> _"In other languages, the equivalent word for hot is often used in the same way."_

Certainly not in Japanese as far as I know. It may not be quite as universal as he thinks.</comment>


Generate mp3 files from Wikipedia - <AUTHOR> http://pediaphon.fernuni-hagen.de/~bischoff/radiopedia/index_en.html <comment><USER2> In terms of speech quality, especially how natural and human it sounds, I sure hope this is not state of the art! Sounds like my Amiga 500 in the 90s.

But I have to agree, a cool service nonetheless.

</comment><comment><AUTHOR> Cool service. Horrible name.</comment>


Uber and Lyft End Rides in Austin to Protest Fingerprint Background Checks - <AUTHOR> http://www.nytimes.com/2016/05/10/technology/uber-and-lyft-stop-rides-in-austin-to-protest-fingerprint-background-checks.html?module=WatchingPortal&region=c-column-middle-span-region&pgType=Homepage&action=click&mediaId=thumb_square&state=standard&contentPlacement=1&version=internal&contentCollection=www.nytimes.com&contentId=http%3A%2F%2Fwww.nytimes.com%2F2016%2F05%2F10%2Ftechnology%2Fuber-and-lyft-stop-rides-in-austin-to-protest-fingerprint-background-checks.html&eventName=Watching-article-click&_r=1 <comment><USER2> I think that Uber and Lyft are doing this as it would present a burden and a cost on them.

However, were setting up a world where if you have a record your never going to get a job. People make mistakes, they CAN change... having a job that pays well is one of the steps to NOT being a repeat offender.</comment>


UX Designer Salaries Around the World - <AUTHOR> http://uxdesignersalaries.com/ <comment><USER2> Pretty much useless. Pay varies so widely depending on state/city for example avg developer pay in San Francisco compared to Sacramento (100 miles away) fluctuates 10-15k (if not more). It also begs to question how honest people are when answering? Is this base salary or salary after benefits/bonus? As others mentioned, cost of living? San Francisco's avg 1 bedroom price is around $3120 while Sacramento is around $1000, that's $25,000/yr more in housing costs.

<comment><USER3> That would be a nice 1 bedroom in Sacramento (pool, sauna, tennis courts) vs a run-down place in SF.

</comment></comment><comment><USER4> I'd be interested to see these numbers compared to the benefits offered by companies in each country. I know that in a lot of European countries it is normal to get more time off, the government offers more benefits, etc.

I say this because every time there is a thread saying, "X company just got this awesome benefit" someone always says, in Europe this is the norm.

Edit:

I also bring this up because I've seen companies in the US offer more money but 0 benefits in order to get you to pick them over another company where you'd actually be making more if you factor in the benefits. How much does that affect US vs Europe?

<comment><USER5> I don't have a statistical run-down by country (which would be the way to do this) but if you compare the US with, say, France, where salaries tend to be 40% of what they are in the US, here's what you have:

\- Free health care (for Engineering positions, usually with a company- provided complement meaning you never have to pay for anything)

\- 5 weeks paid vacation/year + 5-10 paid off-days/year (may be more at large companies, up to 9 weeks vacation + 10 days off)

\- A nominal pension (unlike the health care part, this is not something you should be counting on, you need to save by yourself)

\- Unemployment insurance (typically 2 years with 60-80% of your former salary, which is ideal to start a company)

\- Free schooling for your kids up to & including High School (there are private institutions but they're typically worse than good public schools)

\- Generally cheap higher-ed. The top Eng., law, medicine schools & colleges are publicly-run & free, while the top business schools will typically relieve you of 10K/year

On the flipside, you pay significant taxes on the announced salary. For a 45K€ position (developer with 1year/exp typically) you'll effectively receive ~34K€ from your employer, while the rest goes to the state, and you'll have to pay ~3K€ income tax on that. (Of note is that to get you to that 45K number, your employer already pays ~25K to the state on their side of things).

It varies between countries (I believe folks in the UK are less taxed but have more costly education for their kids for example).

I think in general, you're better off in the US or UK as long as you're single, or if you have a really senior position, and are better off in France/Germany with a family & an entry-level/mid-level position.

I hope this gives you a better idea

<comment><USER6> Is the unemployment insurance only if you're let go / fired? I believe in the US you don't get it if you voluntarily quit your job.

<comment><USER5> You don't get it if you just quit. However, there's a middle ground between quitting & being fired, "contractual separation", which is when you & your employer agree to end your employment. In that case, you get the unemployment insurance, and many people use it as a substitute for quitting, because of that fact.

</comment></comment></comment></comment><comment><USER7> This reminds me of the salary spreadsheet that was secretly passed around at google.

[https://www.washingtonpost.com/news/on- leadership/wp/2015/07...](https://www.washingtonpost.com/news/on- leadership/wp/2015/07/21/breaking-the-taboo-of-sharing-salary-info-in-silicon- valley/)

<comment><USER8> There wasn't anything secret about it.

<comment><USER7> I believe it was secret from people that do not work at Google? But I may be mistaken.

<comment><USER8> Well yes, that would have been quite distasteful if said spreadsheet had made its way out of Google.

But it was definitely not a secret internally.

<comment><USER7> I suppose I should have said the spreadsheet was passed around internally at Google, although never released to the public. This was a great example of ambiguity in language. Imagine being a computer trying to parse my original sentence.

</comment></comment></comment></comment></comment><comment><USER9> The UXPA conducts a robust study of this every three years. Here's the report from 2014: [https://uxpa.org/system/files/public/UXPASalarySurvey2014_Fi...](https://uxpa.org/system/files/public/UXPASalarySurvey2014_Final.pdf)

</comment><comment><USER10> I think there is a huge opportunity to move more software development to developing countries. It could become the next version of sweatshops, which have done an immense amount to improve the wellbeing of people in the third world. The winners of using cheap labor from overseas are the companies that hire them and the people they hire. The losers are the workers in the first world who are outsourced. But it's crucial to understand that both nations as a whole benefit, and the first world nations are more than capable of redistributing wealth.

When you cut through all the self-interest and xenophobia surrounding outsourcing, there still remain many quality and communications issues. But I believe these will be reduced as more people learn English and recognize the value of English as a market skill.

<comment><USER11> Very true. Many people insult Apple over their factories, but the fact remains, those jobs some of the best in the area and are subsequently heavily contested.

</comment></comment><comment><USER12> Why can't we see median? That's also a really good metric to have... in fact it arguably makes even more sense because salaries have a long tail on the higher end which inflates the average by a large amount while moving the median in an easy to understand way.

</comment><comment><USER13> Not very useful without data about cost of living in those places (that's why you want to know about it in other places, right?).

For example, Brazil is in a deep depression right now and BRL is devaluing fast, inflation is increasing, etc. What to make of the USD 18,966 figure?

Nice presentation but I don't see the real point. Are you going set your US- located job's salary based on a global average? Choose the highest place as a reference? Move there maybe? Would that salary maybe just be average in Switzerland? Below average maybe?

<comment><USER14> > Not very useful without data about cost of living in those places

That data is freely available elsewhere. Salaries are harder to get.

</comment></comment><comment><USER15> what's interesting to see in the US data is that Ageism seems to exist. the most experienced person gets paid less.

Also it's interesting to note that every UX requirement these days asks for substantial coding experience (on top of everything else non-code related) yet the salaries are at par with a junior coder.

<comment><USER16> $90,000 is "at par with a junior coder"??? Maybe today, in San Francisco.

At my first dev job in LA, in the mid-2000s, I was making $57,000.

</comment></comment><comment><USER17> Very interesting, but I'd like to see more data for each country. (For instance, an average salary of around $21,000 was posted for Nepal, but this might be unduly influenced by one or two data points in the $70,000 range.) Displaying a median, not just an average salary, would be helpful.

</comment><comment><USER18> A lot of these numbers need to be weighted by the number of submissions; e.g. fewer samples implies higher variance.

The fact that the 3 people who reported from Arizona have high salaries, for example, doesn't mean that one should go to Arizona to find UX design work.

<comment><USER19> If you ask me, it does not make justice to compare salaries across countries. May be comparing salary within the industry, within a specific market might make sense.

Just with the data / samples gleaned from this website, I _will not_ be able to make any proper assumptions / statistic.

</comment></comment><comment><USER20> I'd be really interested in data from China and Japan.

China has one of the fastest growing tech industry in the world. As for Japan, I really want to live there because of the high quality of life, but am hesitant since the tech industry doesn't look promising.

</comment><comment><USER21> Florida seems very high but only has 21 responses- are outliers filtered out?

 _edit_ The 8 - 12 yrs exp range in FL has an average of 237,900 - this can't be right.

<comment><USER22> Indeed.com says most Angular jobs in Florida advertise $60,000 to $80,000 and a lot of those are actually back end jobs because the person who wrote the ad doesn't know what they're talking about

</comment></comment><comment><USER23> Interesting site. Would be fun to see one like this for other categories of jobs in the industry - front end, back end, full stack, web designer, etc.

</comment><comment><USER24> Not enough submissions (data) for this to be accurate. CA for example only has 91 submissions. Are most of these from the Bay Area?

</comment><comment><USER25> The most experienced guy in Denmark is also the least payed. Hope this encourages some people to start job hunting!

</comment><comment><USER26> > _" The average salary ... being $125,667 in Arizona."_

This immediately struck me as preposterous, as I'm familiar with the local Arizona economy.

Then I saw that number is based on a sample size of _3 survey respondents_. When your sample size is so small that the results are statistically meaningless, why even bother making such a claim?

</comment><comment><USER16> Why does the US pay so much more than the UK? Are UK salaries just lower across the board?

<comment><USER27> I've been in UX for over 15 years, mostly in the U.S. and Germany, and I think looking at salary on the country level is the wrong level of granularity.

For example, it's completely possible that salaries in London are higher than in New York or San Francisco, given the high cost of living in London.

It could also be that there are more US-based UX people working in major US cities so that the average US salary looks higher.

Or maybe the sample size wasn't high enough to control for these kinds of regional differences.

So, while this data is directionally interesting I wouldn't apply it too much to your particular situation.

<comment><USER28> > For example, it's completely possible that salaries in London are higher > than in New York or San Francisco

I believe this is the case in tech

</comment></comment></comment><comment><USER29> I find most shocking the difference between say 5 years and 15 years is quite small.

</comment><comment><USER30> Are those numbers net or gross?</comment>


The Evolution of the Pitch: From Napkin to Traction Data - <AUTHOR> https://medium.com/@kachchani/the-evolution-of-the-pitch-from-napkin-to-traction-data-bcb8189ad50 <comment><USER2> Now in 2015, its clear either you have traction, and ears might start listening to you. If not you are dead.</comment>