Facebook Advertising Strategies for Early-Stage Startups - <AUTHOR> http://blog.interstateanalytics.com/2016/02/29/paid-user-acquisition-for-early-stage-startups-part-3-facebook-advertising-basics/ <comment><USER2> I also have similar experiences running ad budgets ($5M / month at highest). I built tools to do ad optimization on FB using attribution as a backbone and optimizing for ROI. I learned the hard truth with FB advertising when I built my own iPhone app last summer and thought all this experience would help me. Turns out when you're spending $2500 per day per campaign its easier to sit back and optimize, but when you're spending $100 in a month its completely different.

Turns out that the first thing you need to do is figure out if FB is the right channel for you. I found out that on FB, anyone will download anything that looks interesting and you can optimize your CPI fairly easily. But if you count on people spending money via in app purchases, the typical rules (1%-5% of active users) don't always apply for apps of different genres.

<comment><USER3> Would you mind sharing some technical detail on how you used attribution as a backbone? What sort of modeling did you do around it? Just static attribution models? Or did you get into the dynamic algorithmic side of things like the big dedicated attribution platforms are doing?

<comment><USER2> Attribution on mobile is a commodity now. 5 years ago before AndroidID and Apple IDFA, all you could use was IP, OS, Device Type, and random other bits of info the network would send you. So you'd need some machine learning inference to connect installed users to where they came from. Now, you just literally match the device-ids with what you get in the click from network partners (off-Facebook). Adjust, Appsflyer both do this.

On FB, just use FBSDK and it comes with its own attribution. They are starting to shift to a "multi-touch" model where you don't really know how they attribute -- its a black box that FB controls via their statistics. FB will report what the CPI is to you. It sucks, but thats market dominance for you.

What I'm also saying is, make sure you're also sending revenue, logins, and any other significant events to FB as well. Then you can figure out ROI and do more performance marketing. This works at any scale.

<comment><USER3> Thanks. I should have clarified--attributing an app install on Android to the source is definitely a solved problem. I was referring more to cross-channel attribution and determining dynamic weighting across multiple touch points.

Sounds like FB is working towards obfuscating that and not giving granular control which is disappointing to hear, but have you done any work around custom weighting like that?

</comment></comment></comment></comment><comment><USER3> The bit about attribution is critical, but misses a more important basic piece which is "make sure you setup and properly QA your conversion tracking."

So many companies launch FB ads without proper tracking and then are surprised when they have no idea what it did for them. FB tends to group everything under the sun as "engagement" and "conversions", so really digging in and understanding those settings is key.

For example, 1-day view-through credit by default is probably a bad idea for many advertisers, particularly when you have no clue what the quality of a view-through is, and what they are worth to you. They are VERY different in terms of value, but FB wants to give them 100% credit with their rules within 1-day. That's simply not how most savvy people approach attribution.

Google Analytics offers some great basic attribution tools out of the box that let you experiment and compare different static models, or create your own static model. Ultimately static models themselves have inherent limitations because attribution is a much more dynamic thing that exists at the individual user path level, but it is a great start.

<comment><USER4> What are the best attribution tools for mobile (specifically iOS) campaigns?

<comment><AUTHOR> Mobile install attribution is an entirely separate thing from marketing attribution. As far as I am aware all the mobile attribution providers are just attributing the last click that led to the install rather than giving partial credit to each ad interaction prior to conversion. The list of common providers there is generally: AppsFlyer, Kochava, Apsalar, Adjust, and Tune (doesn't work with Facebook).

<comment><USER5> Hi Jamie, I work at AppsFlyer. Indeed the attribution standard is by giving credit to the last click. However, our dashboard provides more insights by providing multi-touch attribution data, meaning assisted installs.

</comment></comment></comment></comment><comment><USER6> Surprised that the article doesn't mention Website Custom Audiences (WCA in short), which for many startups might be much easier to collect compared to email addresses.

With WCAs you can build audiences based on people who visited your site (or say, a specific URL like a blog post or a thank-you page). You can then use these both for retargeting (e.g. someone visited your site but didn't sign up yet), or build lookalike audiences out of website visitors and/or signups. Imagine that someone read an amazing blog post describing some key features or use cases of your product? Why not create a WCA and then craft a creative addressing that specific audience segment.

Another benefit of WCAs and lookalikes based on those is, that they're updated automatically, whereas for email-based custom audiences you'll either have to manually upload new signups to FB, or set up some custom automation to do that for you.

</comment><comment><USER7> Facebook is an effective acquisition channel for many verticals especially for Gaming and E-commerce companies. For Mobile gaming, activation campaigns benefit from Facebook's mobile reach, targeting and analytics. For e-commerce, Dynamic Product Ads will generate the highest ROI among most paid marketing activities (albeit at limited volume).

There is one huge catch, though: measurement and attribution.

Yes, setting view and click attribution windows on the platform is a given and necessary, but this is only partly effective, unless Facebook is the only paid marketing channel you're using.

If you're any running media on other networks or channels, then you need to measure the their interactions and influence on the customer journey in order to arrive at the incremental value of each channel and an attributed CAC (customer acquisition cost).

Most attribution partners will allow you to do this and play nicely with all of the networks/partners/channels, with one exception: Facebook.

Facebook is a 'walled garden' in that it does not allow third-party impression tracking, unless you're using its attribution product, Atlas.

This means you are unable to effectively value and weigh the effect of Facebook impressions, measure frequency and overlap across channels, conduct accurate path analyses, and understand the incremental value of Facebook.

That said their ad products are sophisticated, best in social IMO, and their roadmap is very promising.

<comment><USER8> Facebook allows a few other third party tools for measurement/attribution analysis. Ref [https://facebookmarketingpartners.com/marketing- partners/#ad...](https://facebookmarketingpartners.com/marketing- partners/#ad=&co%5B%5D=United+States+Of+America&in=&la=&qss=&sp%5B%5D=Measurement).

<comment><USER7> No, they cannot provide measurement and attribution for campaigns that use Website Custom Audiences or Lookalike audiences, which are often the two largest, most valuable segments of any campaign. Atlas is the only provider that can.

Also, this list points to mobile measurement companies.

</comment></comment></comment><comment><USER9> I've been advised that advertising enterprise products (for US market) on Facebook are a bad use of resources. Then we looked at Linked In, but their pricing and targeting was disappointing.

What's the best platform to advertise enterprise software on? I think IP level targeting is a good strategy, but curious to hear about other ideas.

<comment><USER4> Don't advertise, do lead-generation & sales.

Read this: [http://www.amazon.com/Predictable-Revenue-Business- Practices...](http://www.amazon.com/Predictable-Revenue-Business-Practices- Salesforce-com/dp/0984380213/)

<comment><AUTHOR> Advertising is a part of lead generation. Content marketing with paid distribution is a valid strategy that is in use by a ton of SaaS companies today operating on the Predictable Revenue model.

</comment></comment></comment><comment><USER10> One thing I would add is that you don't need a large list to make good lookalikes off of - some of the best lookalikes were generated from only 5,000 emails.

Lookalikes almost always outperform interest targeting.

<comment><AUTHOR> Past some point yes. I've seen a list of 5k work. I've also seen a list of 5k fail miserably and get outperformed by interest audiences. I don't think its accurate to say that interest audiences _never_ outperform lookalikes. At some small scales they do.

Also there is a huge difference between a list of 5k emails that signed up and 5k emails that purchased in terms of performance.

<comment><USER11> You can also combine lookalikes with interest targeting -- once some audience gets saturated, mix a bunch of your past performing segments like a lookalike + interests.

</comment></comment></comment><comment><USER12> Wow. I didn't know you could upload a list of your customer's email addresses to Facebook and have it build an audience of similar users. This seems highly unethical -- who knows what FB will do with your customer's email addresses.

Edit: I also wonder what would happen if I uploaded just my own email address? Would it find people very similar to me?

<comment><AUTHOR> The data is hashed locally to get around personally identifiable information (PII) issues: [https://www.facebook.com/business/help/112061095610075](https://www.facebook.com/business/help/112061095610075)

</comment></comment><comment><USER13> Great article</comment>


Why is YAGNI a good rule? - <AUTHOR> http://lionelbarrow.com/2013/08/24/why-is-yangi-a-good-rule/ <comment><USER2> YAGNI is well and good for certain types of problems, especially prototypes and proofs-of-concept--essential to succeeding, even.

However, the very second you know for sure that you'll need to expand the system, you need to stop and pull on your big-kid pants and do some design. Any fool can keep throwing code at slight variations of a problem until they're buried in spaghetti (and many do!), but people that actually know what the hell they're doing will bust out the abstraction hammer when it becomes clear that it's prudent (and not a moment before).

Generally, once I've had to solve a similar problem three times it's time to refactor. Once is providence, twice is coincidence, but three times suggests that things need to be designed.

EDIT:

The author's example is particularly poor. A dog, chicken, and cat all need to move, follow a player, interact with the game world, update, spawn, and die. It makes perfect sense to have a Pet class handle this glue entity lifecycle code, and then to specialize a subclass to override the rendering or update code.

There are cases where YAGNI is alive and well, but this example simply isn't it.

<comment><AUTHOR> I chose that example precisely because it makes sense to have a Pet class that holds common code between Dogs, Cats and Chickens. When the code only contains Dogs, though, the Pet class is unnecessary, even if you plan to introduce Cats at a later date.

<comment><USER2> But you knew right then that you were going to implement the other two classes, and that you would need the code. It's not like you aimlessly added abstraction to cover your lack of design and grasp of the problem space--you had done some back of the envelope design and _knew_ you needed it.

That's not premature at all.

<comment><AUTHOR> Your code shouldn't be designed to reflect what you believe is going to happen to the program eventually; it should be designed to fit the requirements as they are right now. If a Pet class makes sense later on, add it later on.

<comment><USER2> The example stated "when we add chickens and cats", not "if we decide to add chickens and cats". It was clear that the requirements at the time included 3 types of animals--if it wasn't clear, you should've written the spec better.

Look, I'm on your side about YAGNI and shipping products not code and whatever other stuff we probably both genuflect at. I'm actually dealing right now with a lot of fallout involving overengineering a project when it should just be kicked out the door and set to work.

That all said, too much shoddy engineering and cowboy-coding is done with YAGNI given as a hollow excuse. There is a lot of pushback on doing upfront design work, but even a cursory consideration of the problem domain and code structure will oftentimes yield better code that otherwise would've been ignored under the banner of "we aren't gonna need it".

EDIT:

Hell, I'll take it one step further: when developers do decide to be lazy and claim YAGNI, they often aren't lazy _enough_ , and instead write hacks that are too large to just get something done. If you are going to half-ass something, by God, half-ass it all the way.

<comment><USER3> If I had a dollar for every time clients have said "when we X" and then later went on to insist we need to do Y instead, that is completely opposite to X, and counter to everything agreed in specs, I'd be happily retired by now, living off my fortune.

It'd be great if we could all know in advance what the requirements will actually be, but that requires us to be able to visualize exactly how everything will actually work in advance. That is rarely the case.

YAGNI is not about avoiding design (though I agree it might be used as an excuse), but about deferring decisions that does not need to be locked in yet, until they need to be. That does not mean you should not design. Just don't go into unnecessary levels of details, and iterate when more detail is needed.

</comment></comment></comment></comment></comment></comment><comment><USER4> I've worked on some big, mature code bases, and I've always appreciated it when other people believe in YAGNI. It tends to result in relatively simple code with just enough complications to support the features which actually exist.

In theory, it would be nice if the code included appropriate hooks and abstractions. But in practice, it's often quite hard to guess where those hooks should be, and which aspects of the code should be abstracted. And since the abstractions are based on hypothetical designs, they're very often useless.

Basically, I'd rather maintain over-simplistic code that implements a few features well than code that has been prematurely generalized to support half a dozen features which don't exist yet. All too often, the generalizations are wrong, or simply get in the way of other features I'm trying to add.

Unfortunately, YAGNI is one of those rules that requires common sense to apply well. It works best as a sanity check for an already-experienced programmer: "Really? Do I actually need a whole new set of abstract interfaces here? Or can it wait?" If a programmer is totally lacking in taste and judgement, YAGNI won't save them by itself.

<comment><USER5> Maybe YAGNI should be applied to generalizations as well. Don't make one until it becomes hard to add something to your code, but if you do - generalize as little as possible.

</comment></comment><comment><USER6> I'll confess, I don't understand YAGNI.

I think I've been tainted by too many counter-examples: seeing a piece of code that was specially written for a very narrow and specific use case, and needing to extend it to some scenario that the original author did not envision. If the author hadn't been thinking in terms of re-use and extensibility ("because they ain't gonna need it"), it gets frustrating and regression-prone.

In other words, you ain't gonna need it, until you eventually do. Lazy programmers shouldn't be excused for dismissing maintainability with a simple catch phrase.

<comment><USER7> YAGNI is not about being lazy, it's about being smart about the code being written, about the craft.

Over-engineering, architecture astronauts, hurt a system a lot more than someone following YAGNI. Making systems that are a big mess of hard to understand and modify code (even worse). I've seen this happen again and again.

Architects sitting in ivory towers pump out Word documents which result in overly complicated systems. Large, slow, waste people's time and money. The whole idea of "oh, in 10 years we may want to handle this and that" adds unecessary code which then needs to be tested and creates many more points of failure. And did I mention slow? These hairy-balled monstrosities are terribly sow.

If over-engirneers got paid by the line of code, they'd be millionaires. If they got paid for writing elegant, short and easy to maintain code, then they wouldn't have two pennies to rub together -- the YAGNI developer would be sitting in his yacht.

You Ain't Gonna Need It!

<comment><USER8> I'm not so convinced that YAGNI generally leads so directly to "elegant, short, and easy to maintain code" as you say. Certainly, with a very keen sense of when to make the transition from Ain't to Are, it can lead to time- savings and simpler and more focused code, but with less discipline or tight deadlines or (typically) both, it can also lead to repetition and the complexity of maintaining many one-off features, even if each is relatively simple in itself. Something very similar can be said for a more architectural philosophy - with a very keen sense of when a design is liberating and when it is burdensome, it can lead to less repetition and targeted maintenance, but with less discipline it can lead to analysis-paralysis and over-engineering. Like most things, the best answer is somewhere in the middle.

My preference is YAGNI while keeping a sharp eye on things that are relatively hard to make extensible later and relatively easy to make extensible now. To tack on another not-great example to the not-great Dog example - if I find myself writing 'dog' a bunch of times in a bunch of ways, I may well pull that out into some sort of `type` variable even if I-ain't-gonna-need-it.

<comment><USER7> You're correct when you say about YAGNI not necessarily leading to "elegant, short, and easy to maintain code". That is, in the end, up to the developer's skill.

<comment><USER8> Well, I agree with you because you're agreeing with me, but I'm not sure your comment that I replied to agrees with you. From my reading, it definitely implies that YAGNI leads to good code and architecture astronautics doesn't, entirely ignoring developer skill. Perhaps you just oversold your point.

</comment></comment></comment></comment></comment><comment><USER9> I can't really agree, although its hard to argue against a contrived example and a general rule that is almost a tautology (don't write code you don't need).

A lot of times "architecture astronauting" is simply good separation of concerns. To take the Dog example: there is a lot of code necessary to get a Dog into the world of minecraft that isn't specific to the concept of Dog at all, such as drawing itself, keeping track of its state in the world, etc. These are the types of concerns you would want in a base class of Dog and potential Cats and Chickens. This is something that should be factored out, not because you may eventually make a Cat, but because those concerns have no connection to the concept of Dog at all. Keeping such code together will just make comprehending the actual Dog specific code harder.

<comment><AUTHOR> (OP here.) I agree that code examples would be better than intangible statements; I included a few samples in early drafts of this post, but ultimately concluded they made it too long.

I'm not saying we shouldn't try to make components reusable or that we shouldn't use abstractions. Rather, we should introduce reusable components when they're actually _re_ used rather than just used once. Component re-use should be introduced into a program lazily.

In the Minecraft example, once I add the Cat class, I would go back and refactor the Dog and Cat classes to inherit from Pet. The point I'm trying to make in the blog post is that I wouldn't do that until I had _actually written_ at least two classes that I knew would be inheriting from the Pet class.

<comment><USER9> Yes, it was clear what your point was. My point is that there is code in your Dog class that would do well on its own, irrespective of any supposed Cats or Chickens. Separating positioning/movement code and barking code makes real design sense. Separation of Concerns is at times the antithesis of YAGNI.

<comment><USER3> You are assuming that you know upfront which of that code actually will be separate.

Some of it may seem very obviously separate, but that does not mean it is clear what the generic version will look like for all practical use cases.

E.g. a generic "move" method may look substantially different if it is to only deal with pets that walk on the ground vs. handle pets that fly too.

How much do you generalize it in advance before it is too much?

If the code really is becoming so large it is a maintenance issue, then sure, yes, separate it anyway. But do it explicitly for that reason.

</comment></comment></comment></comment><comment><USER10> A thousand times yes. I totally agree but this is one of those practices that's really hard to teach. A big part of the job for a software engineer is balancing abstraction with specificity. The argument from the architecture astronauts is always that once the system gets big, we'll be glad to have the AbstractServiceFactoryFactoryManagerFactory. My argument is that unless we're shipping the "big system" on this release cycle, we should do what's best for the small system. In all likelihood the system will never get big and by the time it does the requirements will change. In all likelihood useful components will get rewritten many times anyway.

I think YAGNI is a really good rule of thumb when you define "need it" as "need it for the current release".

</comment><comment><USER11> There are three reasons why YAGNI works so well.

First, people systematically underestimate uncertainty. The human brain is good at recognizing patterns and making plans but not so good at dealing with randomness and uncertainty. When talking about software development and maintenance we're talking timescales of years. Companies go out of business, projects get cancelled, code gets thrown out and rewritten. It's easy to paint a pretty picture about how the Cat class will get added to the Pet hierarchy but there is tons of uncertainty involved in even the simplest project. Because the scenario is specific the brain overvalues its likelihood compared to the nebulous unknown alternatives.

Second, keeping code as simple as possible is almost always for the best. YAGNI forces smaller simpler code. More complexity and more code means more room for bugs. All the studies I know of consistently show that more code means more bugs.

Finally YAGNI is a principle that forces priorities to be in the right place. The question is never between spending time making something that might be useful in the future or doing nothing, it's between doing one particular useful thing or another. I can't think of a single case where the right priority is to do something that MIGHT help in the future. You start by doing things that DO help now, then things that WILL help in the future.

</comment><comment><USER12> It is even simpler than this.

There is a non-linear relationship between number of requirements and the complexity of the resulting software. The exact relationship is hard to nail down - I've seen some data suggesting that complexity goes as the cube of the number of requirements - but it is clearly non-linear.

This goes whether or not the requirements are handed down by a product manager, or generated by a developer who mistakenly believes that the future types of requirements are predictable. The impact on the complexity of our software of additional requirements is all out of whack with how many requirements you added.

Here is food for thought for those who are not convinced. Suppose that a developer who wants to abstract things doubles the set of requirements and the relationship is the cubic one that I suspect. Then your task is 8 times as hard. And you don't have working software until it is done.

Suppose that 2/3 of those requirements turn out to be needed eventually and, horror, there is no way to do it without a complete rewrite. Then you expect the full energy now, 4x as much work later, and your total effort eventually is 5x what it takes to produce what you really needed right now, AND you get to enjoy a working partial solution before you're done.

Even a worst case scenario for YAGNI (yet) comes out better than trying to aggressively plan for the unknown future.

</comment><comment><USER13> The problem with YAGNI as a development slogan is that it can be too broadly applied.

I think a better wording might be, "don't _increase complexity_ writing code you may not need". The issue is usually not the presence of additional code. Rather, it's making design decisions based on requirements that may never in fact come to bear.

</comment><comment><USER14> I'll join the chorus. If you're not going to need it don't do it but if you will need and you don't do it you're going to pay dearly. "Software Engineering" is about being able to tell the difference vs. just throwing something together.

</comment><comment><USER15> No, i wouldn't think so at all. A little foresight and modular design is not _that_ hard. Sure, after you implement the Dog Class you know better what the Pet Class may need, but you can most likely already have 75% of that Pet Class ready beforehand.

If the OPs software design (for a particular subset!) is so complex he can't imagine it in his head: either the design is too complex or the programmer is not very good, imo.

Any why the hell do we need the next acronym?!

</comment><comment><USER16> I was nodding along, but man was that example painful. I'm sure that it was in good effort...but it really didn't do justice to why YAGNI is bad.

I'll bite: it's really _terrible_ for security purposes. Aside from the typical YAGNI feature examples, there's plenty for application maintenance and back-end development.

Let's say you have a database with several layers of privileges. You frequently have to perform actions that require higher privileges than that user has, and you're a lazy dev. So you try to automate this process by adding further code to your system design, expediating the entire process at the cost of some authentication.

Bam, huge red flag and a half. Yes, you _can_ have this and defend it at the same time, but in most cases, it's silly to try. Adding code just adds another vector and a half.

That said, yes of course adding features you don't need will bloat the system. But that pet example kinda sucked, I'm sorry.

</comment><comment><USER7> Design Patterns are one of the biggest culprits in large, over-engineered patterns. [http://37signals.com/svn/posts/3341-pattern- vision](http://37signals.com/svn/posts/3341-pattern-vision)

</comment><comment><USER17> Perfect post about one of the most important principles in programming. Nine out of ten, concise design with fewer lines of code is better design than over-engineered abstractions over abstractions over abstractions over...

</comment><comment><USER18> If you are going to use a rule like this, you really need agile project management to guide what you are going to need. If you are doing Scrum properly, you plan the features (and internal architecture needed for those features) for up to a month at a time, but you don't architect for purely internal things more than a month in advance (the YAGNI principle) since one of the Scrum principles is to limit work in progress.

If you are doing a waterfall PM process, it doesn't apply so much.

</comment><comment><USER19> I totally agree! The problem is that sometimes you just can't convince your coworkers. They'll say this XYZ feature is coming sooner or later, they'll argue that abstraction means cleanness. And as future is so uncertain, arguing about what might happen in the future always ends up with no conclusion, and they still think their future-proof approach is worth it.

<comment><USER3> But the true future proof approach is to not add the code, but write the code you _do_ write in a way that makes it easy to support the expected changes anyway.

E.g. for the pet example: Avoid hard-coding the class name all over the place, so that if you do end up having to add a Pet superclass and add Cat's in the future, you don't need to make changes more than one or two places.

Writing loosely coupled and reusable code is good practice anyway, and also makes testing easier, but if you practice YAGNI it becomes extra essential: You know your code almost certainly _will_ need to change in the future, so you should structure your code accordingly to make extension and refactoring easy.

</comment></comment><comment><USER20> I'd like to see some analysis on the real "cost" of a line of code.

</comment><comment><USER21> This sort of reminds me of Minimum Viable Product methodology (MVP) but I think YAGNI is at a later stage in the development cycle.</comment>


Microsoft releases revamped Azure ML, new AI tools - <AUTHOR> https://azure.microsoft.com/en-us/blog/tools-for-the-ai-driven-digital-transformation/ <comment><USER2> Miguel Fierro from Microsoft here: Joseph Sirosh session will be broadcasted live at 2.15pm ET in this link: [https://myignite.microsoft.com/sessions/56555?source=session...](https://myignite.microsoft.com/sessions/56555?source=sessions)</comment>


Space junk mission deploys from the International Space Station - happy-go-lucky https://www.gov.uk/government/news/space-junk-mission-deploys-from-the-international-space-station <comment><AUTHOR> If anybody is interested in some fiction around this topic, there's a pretty good Japanese Manga/Anime series called Planetes that revolves around a group of "space janitors" who have to clean up space junk.

[https://en.wikipedia.org/wiki/Planetes](https://en.wikipedia.org/wiki/Planetes)

<comment><USER2> Also Neal Stephenson's Seveneves, for an extreme space junk problem after the moon mysteriously breaks apart.

Both of those and others are mentioned here:

[https://en.wikipedia.org/wiki/Kessler_syndrome](https://en.wikipedia.org/wiki/Kessler_syndrome)

<comment><USER3> That novel is a work of a legend. Especially, the future part. Ecen Christopher nolan won't be able to do justice to this novel.(maybe he could)

<comment><USER4> Has his writing style improved since Snow Crash and prior works? I don't think I can handle slogging through another Stephenson novel.

<comment><USER3> Well, i haven't read Snow Crash. I read about it on wiki and decided to skip it. But i admit, while I was reading i got bored in between because pace had slowed down and then I skipped a few dozen pages , read a few lines and skipped way more and read more because wanted to know about the end as I was becoming really impatient. Anyways after reaching the end, i felt guilty that I skipped through a lot. A few days later I started reading again from the point I began skipping and in the later parts , i got to know that I had misunderstood some parts while skipping, so it turned out to be a blessing in disguise. Also, some space stuff would have been better explained with a rough diagram. I guess, I got bored in between because I was reading a novel after a really long time. also, I got to know about Neal and this novel via Bill Gates' summer reading list a few years ago.

</comment></comment></comment></comment></comment><comment><USER5> Kind of sad ending for that cute, useful, little box to just burn up in the atmosphere.

Makes me wonder if this is actually a viable approach on a larger scale, in terms of resource costs? Or is the "burn it up at the end" just part of this specific experiment and future versions won't have to be disposed of like that?

<comment><USER6> Surely, de-orbiting is how you remove the space junk from orbit.

<comment><USER5> Agreed on the junk, but does the satellite itself really need to be burned too?

With the amount of space-junk floating around it might be kinda wasteful to burn the whole thing with the junk, that's why I was wondering about reusability of the satellite itself.

</comment></comment></comment><comment><USER7> Why are they not experimenting with using photon momentum from a laser to push debris into the atmosphere? It seems ideal for small high-velocity garbage. Perhaps that's too close to weaponizing a spacecraft?

<comment><USER8> This is one of the (many) things Philip Lubin has looked at. The momentum transfer from photons is far too low. However this can be partially fixed. A laser can vaporize part of the trash and then heat up some of the vaporized material, effectively turning the ablated material into a small rocket. I am not entirely sure how much more effective this is, and if it is enough to be a viable technology.

<comment><USER9> alignment of forces would be a real pain. I expect the little rockets would just spin the item around. Also, I would expect much of the existing space junk to already be spinning in random directions for this approach to be really difficult. (didn't read the article - perhaps it's explained there?)

<comment><USER10> You could disperse* the beam over the entire object to even out any added rotational force. *whether by increasing beam diameter or sweeping beam across the object's face.

</comment></comment></comment></comment><comment><USER11> That seems to be a great idea.

Unlike the "humanity star" initiative, a highly reflective object in space designed to cause as much light pollution as possible. Something needs to be done to prevent that from happening again. Our survival as a species depends on reliable astronomy.

<comment><USER12> The Humanity Star was visible only for short periods of time at dusk and dawn (which are not astronomical observing hours) and was, at brightest, approximately magnitude 2. Less bright than many stars and planets, as well as many existing satellites. In addition, it only stayed in orbit for about 6 weeks (although it was intended to last 9 months).

</comment></comment><comment><USER13> Isn't the simulated space debris actual space debris?

<comment><USER14> Yes, but it is already in a decaying orbit and will fall/burn up within a few months. The ISS has to be reboosted routinely in order to keep it in orbit.

<comment><USER15> Yes, though depending on the part we are talking about it can take up to a couple of years. The mission has been designed to avoid creating small untrackable debris and everything is below the ISS.

Fun fact, as all the missions deployed from the ISS, the RemoveDebris satellite is already classified as a debris in the NORAD satellite catalogue.

</comment></comment></comment><comment><USER16> What about simple deflection into the atmosphere - an inverted pyramid?

</comment><comment><USER10> What was the point of harpooning something already attached to an arm? (see video)

<comment><USER15> The goal of the experiment is to test the harpoon itself. You could have a moving target but then it creates a constraint on tracking a non cooperative target and orientating your harpoon accordingly, which is quite a feat in itself. Also, by having it on the spacecraft, it allows observing the impact point later on with the in board cameras.

</comment></comment><comment><USER17> Well, many years later than everyone else, plucky little Britain finally gets into space - to collect the trash. Great!

<comment><USER18> Not actually everyone else: [https://en.wikipedia.org/wiki/Prospero_(satellite)](https://en.wikipedia.org/wiki/Prospero_\(satellite\))</comment></comment>


I know JavaScript, should I learn Ruby or Objective-C next? - <AUTHOR>

I am looking for max career advancement as well as max mental growth. <comment><USER2> You can easily pickup RoR if you get into a situation where you have to use the framework.

However, if you're like me and you know javascript well, Objective-C might be the better choice. I've recently gotten into iOS app development and started off with using Phonegap. However, I quickly ran into the limitations of Phonegap and started having to do minor Obj-C modifications to get one of the apps to do things I needed. This experience has lead me down the path of deciding to tackle Obj-C, which for me is the better move than learning Ruby.

<comment><AUTHOR> Yeah. That's what I think I want to learn but phonegap etc. were making me feel like maybe it was becoming more obsolete. From what you said, and what I have heard others say though I think that isn't true. I just want to learn something that will continue to be relevant for a long time.</comment></comment>


Yale's online class on "The Science of Well-Being" - <AUTHOR> https://www.cnbc.com/2019/05/13/i-took-yales-most-popular-class-ever-and-it-completely-changed-how-i-spend-my-money.html <comment><AUTHOR> I posted it here because the summary on the course seemed likeable.

Eg.

\- Money doesn't create happiness ( and what they don't mention: being short on money makes unhappy, my 2 cents)

\- never ever forget exercise, it makes you feel better and healthier

\- make time for friends and family, not every relationship needs to have a meaning future-wise

And that related to me. Not "mumbo-jumbo" and spirituality like some comments below mention.

Or my TLDR; have enough of money, you don't need plenty.

Have plenty of time, you never have enough.

<comment><USER2> > \- Money doesn't create happiness ( and what they don't mention: being short > on money makes unhappy, my 2 cents)

I had this exact conversation with my uncle and dad the other day. It was basically along the lines of, "Those who say money doesn't make you happy have never been low on money trying to meet bills." Perhaps we're really cynical, but I feel this is a good point that many things don't address (though I am aware of the studies that show money _does_ increase happiness, up to a point, around $75k USD if I remember).

That said, "Money can't buy happiness, but it can buy the things that make me happy."

<comment><USER3> As someone that grew up very poor, worked very hard for a long time and got very lucky, to then make a lot of money:

I like to look at it as the power of money to most people isn't what it adds to your life, it's what it takes away. No more fears about bills, no more worrying about being broke or stressing over the monetary concerns. That/those are the first plateau. Once those things are gone some people are going to be a lot happier, but sometimes money wasn't the actual cause of your unhappiness; just one of many causes amidst the pile. You might be more happy, or less stressed, neither, or both.

These concepts are nebulous at best, but I'm curious how one measures an increase in happiness versus a decrease of stress. Likely a fair amount of comorbidity at play.

<comment><USER4> "No more fears about bills, no more worrying about being broke or stressing over the monetary concerns"

Sounds like heaven!

<comment><USER3> It changes everything. I'll refrain from tying it to happiness and instead just say that it increases the quality of life.

</comment></comment></comment></comment></comment><comment><USER5> The class starts today if anyone is interested in enrolling: [https://www.coursera.org/learn/the-science-of-well- being](https://www.coursera.org/learn/the-science-of-well-being)

</comment><comment><USER6> Just my 2.5 cents for myself.

Happiness is not a good thing. It is the other side of the same coin that brings me sadness and pain. What I'm looking for is peace.

Being in peace is the ultimate form of being -- the only form of being.

If I'm not in peace it means I'm chasing something else. When I stop looking for anything (including peace itself) then I am... I am.

<comment><USER7> People who are in peace generally don't have to think much about happiness, so in that sense peace = happiness.

<comment><USER6> Being in peace brings me joy but no happiness. Happiness takes one's ego up and what goes up will always come down.

But words are words, my joy could be your happiness.

</comment></comment></comment><comment><USER8> Sadly, the article read more like "teenager discovers the things her parents failed to teach her". Sorry I'm too old for this. Maybe the class is great, but the article was uninspiring.

<comment><USER9> > Sadly, the article read more like "teenager discovers the things her parents > failed to teach her". Sorry I'm too old for this.

When you were 18, how concrete was your definition of well-being? Remember, this is a class being taught at Yale, whose incoming students are likely already high achievers. On top of that, a 10% admissions rate tells incoming students that they will simply have to keep climbing the ladder of GPAs, internships, varsity sports etc. for the next 4 years, and after that, for the rest of their lives.

I haven't taken this particular class, but I went through 4 years of college feeling like a failure if any one of the above "todos" didn't pan out, because it made me feel like I was closer to the bottom of the pile than the top. At that age, all you can see are the trees, not the forest

Looking back, it would've been nice to have had some perspective on what it's all for. Before you know it, you've graduated, and you can't go back and try to do things differently.

</comment></comment><comment><USER10> > Spending less money on things that aren't long-lasting, like extravagant > gadgets and more bedsheets that I actually need.

My gadgets seem like they will outlast me at this point...which is exactly what makes it hard to continue spending money on them :D (I don't buy bedsheets, is this some kind of hobby?)

I do personally count ham radio as one of those "experiences plus gadgets" hobbies though; it's been a lot of fun in that way. It gives me more reasons to get out and exercise (radio play), make little trips (club breakfasts and event volunteering), and reach goals (stuff to talk about with friends). I feel like the friendships I make through the hobby are about 10x more resilient than other friendships.

There is a "spin the dial" philosophy in ham radio that I have taken into other friendships. There will always be someone else to talk to, so stop hanging around as if you're stuck with your current conversation partner. If things aren't going well, give the frequency dial a spin and see who else is around.

</comment><comment><USER11> I'm glad to hear of this class. I think I'll take it in order to see if I can learn some things I didn't know.

That said, the article is very poorly written. The author appears to not have a good understanding of what constitutes standards of proof in the social sciences, and in what way studies in social sciences ought to be spoken about.

(For example, they refer to a landmark Princeton study that "proved" money doesn't equal happiness, then states that some later studies with a different demographic "disproved" this.

But the first study did not prove anything by most meanings of the word, nor did the second disprove it. They provided evidence, suggested conclusions, invited interpretation...etc. You can't prove lasting things about changing statistical aggregates, nor prove things about individuals based on group statistics. That is not how statistics works.)

Then there is the cheesy bit where they show themselves "scoring points" on a professor who "concedes" that a car could be an experience, if you can focus on the experience of driving it...but frankly she's gently correcting them, not conceding a point. (Note that these scare quotes are my interpretation; they are not said in the article.)

I do think in general that I don't like this folksy let's-pretend-the-journo- knows-nothing-because-some-readers-won't style. Perhaps it's an imperfection of mine rather than the author's.

I'd rather they just tell me what they know or found out, or quote the authority, because I don't find the fact that they had a conversation with the authority human-interesting. (That is, I think they're angling for a human interest style in this sort of piece, but there is nothing of human interest in showing me you had a conversation with a person.)

</comment><comment><USER12> I was part of a group that took the free on-line class together a while back. It is not well-named, being not about 'well-being', rather entirely focused on 'happiness.' In addition, as the course is given at Yale, a college community enclave, the viewpoints of the participants are somewhat peculiar to young people who are still preparing to live in a society that is not all about them. Those two, three or four times the age of the college kids will find it hard to identify.

<comment><USER13> "Subjective well-being", as far as I can tell, _is_ psychologists' code-word for plain old happiness

</comment></comment><comment><USER14> This is why I'm religious. Christianity, in accordance with scripture and tradition, is a path to mental and spiritual well-being that was tested by my ancestors for millennia.

Sadly, as scripture tells us, many (most) people who claim to be Christians are wolves in sheep's clothing. But there are plenty of wolves hiding in the guise of the other paths too. Caveat emptor.

<comment><USER15> Until very recently, your ancestors didn't have too much of a choice.

<comment><USER14> Every single one of my ancestors, back to the first, had a choice.

<comment><USER16> Also the dark ages, but now N(ietzs +che) predicted the down fall of Christianity a century ago which was tested by all atheist ancestors.

<comment><USER14> Western Atheism is just another gnostic Christian heresy, because it claims direct knowledge (gnosis) of God. It's nothing new and it always fails relatively quickly.

<comment><USER16> So was Plato and Aristotle, most respectable people who walked upon this earth?!

<comment><USER14> You're confusing agnosticism with atheism. Atheism claims direct knowledge of God, namely that He does not exist. Agnosticism on the other hand is the position that the question cannot be answered. Plato and Aristotle's position was one of agnosticism, not gnostic atheism.

By the way I consider the agnostic position to be entirely intellectually honest and defensible. I happen to believe otherwise, but a reasonable person can reach the agnostic position.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Why does the teacher put "Well-Being" in the course title, instead of "Happiness", even when the course is totally about happiness? Does this mean happiness is the same as well-being? I highly doubt it.

<comment><USER18> Happiness might be well associated with a specific mental state or emotion while well-being is really one's overall health.

Someone who is in a very good position, and general state of well being will have bouts of every emotion, and surely won't be 'happy' in every moment.

Though surely one could make the case that 'general happiness' and 'general well being' are the same thing if they wanted to.

</comment></comment><comment><USER19> I thought I'd join, but the more I read the more spiritual and mumbo-jumbo the course appears. From the course overview:

      Week 1. Signature Strengths
      Week 2. Savoring & Gratitude Journal
      Week 3. Kindness & Social Connection
      Week 4. Exercise & Sleep
      Week 5. Meditation & Gratitude Visit
      Week 6. (It's a SURPRISE!)
      Week 7. Rewirement Challenge Part 1
      Week 8. Rewirement Challenge Part 2
      Week 9. Rewirement Challenge Part 3
      Week 10. Rewirement Challenge Part 4

Just for starters, what's the deal with "gratitude"? Isn't that a spiritual concept? Why not go straight to the root and dislodge the root cause of resentment itself? Gratitude treats the symptoms -- it counters resentment -- but does not eliminate it. As an intelligent HNer we should not fall for these superficial traps.

EDIT: So a group of people have taken to downvoting my comments, instead of intelligently addressing them. Apparently I made a blasphemy, attacking a religious concept (gratitude). LOL.

<comment><USER20> I think gratitude is part of mindfulness. It means appreciating the smell of fresh air, the taste of your go to breakfast beverage, the sounds of the birds chirping or the smell of your partner. These are things we can get used to day after day, and so it's useful to take a moment or two to appreciate them. That's at least how I interpret it...

<comment><USER19> Then why call it "gratitude" instead of calling it what it is, to wit: appreciation? Obviously the proponents of gratitude meant something more than appreciation.

<comment><USER21> Have you had a bad experience with spirituality or something? You sound hella mad my friend and it's not a good look.

People invested their time and effort in this course. The least you can do is be grateful that there are such people on the planet who care about the wellbeing of others.

<comment><USER22> Who _hasn 't_ had a bad experience with spirituality?

This is the same kind of thing that's used to promote anti-vax campaigns and scam people out of thousands of dollars for fake medical treatments.

<comment><USER23> I think a lot of people have had both positive and negative experiences with spirituality (which I want to emphasize is not synonymous with "religion", which I think provokes stronger emotions for a lot of people). Similarly, I've had both good and bad experiences with public transportation, which I think is also fairly common. There are plenty of things that I've had bad experiences with that I still find useful due to other experiences that were better.

</comment></comment></comment></comment></comment></comment><comment><USER19> Happiness has become a dirty word.

People fail at happiness; and then start devaluating happiness itself probably to rationalize their unhappiness and also justify the consequent resorting to socially inculcated meanings. Mr. Jordan Peterson even enabled a cult following around this odd psychic adumbration.

And, by the way, it goes without saying that cynicism and weariness precludes happiness.</comment>


Show HN: A decentralized insurance vehicle on an Ethereum blockchain - <AUTHOR> https://provident.one <comment><AUTHOR> Hey there!

We just open sourced a set of Ethereum contracts for anyone to freely provide, consume and invest in transparent and fair insurance vehicles.

Insurance can get really bureaucratic and opaque; using Ethereum, bureaucracy is nonexistent, and everything is transparent. No individual party has control over the funds, or can withdraw all its money at any time.

We want Provident One to be a community driven effort to create and standardize a set of Solidity contracts that anyone in the world can use to create insurance vehicles that are more transparent, fair and free.

Thanks!</comment>


Online Storage Company Box Has Strong Debut in First Day of Trading - <AUTHOR> http://dealbook.nytimes.com/2015/01/23/online-storage-company-box-has-strong-debut-in-first-day-of-trading/?_r=1

<comment><USER2> First of all, congratulations to Aaron Levie and Box. This is a tremendous journey of perspicacity and grit. Here is a write-up about Aaron Levie's journey by his friend Om Malik: [https://gigaom.com/2014/03/24/levietation-a- believers-rise-t...](https://gigaom.com/2014/03/24/levietation-a-believers- rise-to-the-top/)

Also, one thing people absolutely do not understand about Box (or they underestimate this aspect of Box's business): they are an 1) enterprise 2) SaaS company that 3) targets slow-moving, low-churn departments. Look, for example, this analysis by SaaStr: [http://www.saastr.com/2014/12/18/saastr-on- techcrunch-box-wi...](http://www.saastr.com/2014/12/18/saastr-on-techcrunch- box-will-hit-1-billion-in-revenues-before-you-know-it/)

<comment><USER3> That 'analyis', i.e., "Box Will Hit $1 Billion In Revenues Before You Know It", is the type of wild claim that people will look back years from now as a great example of the irrational exuberance of this age.

<comment><USER4> I don't know man. They're in the same industry as other large enterprise vendors. If their product works, and it costs more than $15 a user, and they have many 10k user companies, they could see that sort of revenue with 7k customers. I think thats totally doable. There are 600k enterprises with over 10k users.

[http://www.census.gov/econ/smallbus.html](http://www.census.gov/econ/smallbus.html)

</comment></comment></comment><comment><USER5> If anyone is interested in how much the VC's or the CEO made on their investments in Box check out EquityZen's Infographic here: [https://equityzen.com/path-to- ipo/box/?utm_source=hackernews...](https://equityzen.com/path-to- ipo/box/?utm_source=hackernews&utm_medium=comment&utm_campaign=box)

<comment><USER6> Love the data. Don't like the &utm_source=hackernews&utm_medium=comment&utm_campaign=box part of the URL. Is commenting really a campaign and worth tracking?

<comment><USER5> I like tracking everything. Just curious, why does it bother you?

<comment><USER7> can't this be tracked by referer links?

<comment><USER8> The referrers get stripped when you come from an https site like HN, so you actually can't

</comment></comment></comment></comment></comment><comment><USER9> I'm always confused when stories like these are spun as a "strong debut" rather than saying Box left a lot of value on the table. Why do we care more about the people who've held the stock for < 1 day than the capitalization of the company?

<comment><USER10> It's understood that a tech company releases a small minority of shares at IPO and follows up with a secondary in a year or so. Someone else observed that they raised only a year's worth of money and from what I've read, they don't know when they'll be profitable, so it's quite obvious that they're going to do a secondary and that will be when they really raise some capital.

<comment><USER11> It's still a lot of cash left on the table. Why aren't dutch auctions more common in IPOs?

<comment><USER12> Because the financial companies that control everything on Wall St. hate them. Box isn't a very powerful company - they're no Google - and can't easily go against the grain. Box desperately needed that IPO, they're burning very large sums of red ink.

</comment></comment></comment></comment><comment><USER13> Big and pleasant surprise here as a boxer. I was hoping for $16.50+. Ya, we probably left some $$ on the table but keep in mind, we had a rough patch there this summer and couldn't easily afford more turmoil.

Now time to buckle up and go for it! I'm confident.

</comment><comment><USER14> The dilution image made by EquityZen is interesting: [https://pbs.twimg.com/media/B8DCNDoCcAAU3jM.png:large](https://pbs.twimg.com/media/B8DCNDoCcAAU3jM.png:large)

Those last two major investors _lost_ a lot of money.

Is that usual? Do investors usually come in for the long-term even though they faced an IPO that would lose them a chunk of the value?

<comment><USER15> IIRC, the last two investors had some sort of deal where if the IPO was priced at under $20, Box paid them some sort of penalty. (Maybe someone here remembers the details better than me.) I'm sure they watched their backs on the paperwork and that any gain like the one the stock is currently seeing is a win for them.

</comment></comment><comment><USER16> Who is buying this stock?! A company that burns through a TREMENDOUS amount of cash raises enough for just about a year's worth of operations, meaning that they will almost certainly dilute their stock against next year just to pay for cost of doing business. Their future consists of insisting that they aren't "just online storage", and competing on pricing that is trending towards 0.

I'm not invested in this company one way or another, but it really baffles me that people think the company is worth investing in. I'm sure I'm missing something, since I haven't dug deeply into their financials or anything.

<comment><USER17> >Who is buying this stock?! and

>I haven't dug deeply into their financials or anything.

should be mutually exclusive, don't you think? If you haven't looked at their financials or anything, how do you know whether it is a good investment or not? You can't just look at 'macro-trends' and determine if individual companies are a buy or not.

e.g. since 1970s, cigarette industry has been in a steady volume decline. Guess which stock has been (by far) the best performing stock during since that period? Yep, Philip Morris (which recently split into Altria and Philip Morris)

<comment><USER18> I'm not an expert, but by all accounts the financials for them are somewhat grim: [http://www.forbes.com/sites/benkepes/2014/03/24/boxs-ipo- rev...](http://www.forbes.com/sites/benkepes/2014/03/24/boxs-ipo- revenueexpenditure-mismatches-and-the-cult-of-growth-at-all-costs/) They're spending more in sales than they're making back in revenue (nevermind profit). Building a company around spending $2 to make $1 isn't good for the long term (ask Groupon how that worked out for them).

<comment><USER19> > (ask Groupon how that worked out for them).

They're a $5B company four years after their IPO and are selling ~$2.5B annually.. not the failure that people keep representing.

<comment><USER3> Their revenue is flat and they make no profits. That's pretty terrible in this market. [http://finance.yahoo.com/q/is?s=GRPN](http://finance.yahoo.com/q/is?s=GRPN)</comment></comment></comment></comment></comment>