Ask HN: How to get traction for programmers' community? Or stop doing it? - <AUTHOR>

I made the site for programmers for exchanging information, with a very flexible posts-filter.
I submitted a link to the site on HN and people said that it is interesting and useful.
Later I emailed a message with a link to Guido van Rossum to share with him what I've made in Python. He tweeted about the site: http://twitter.com/gvanrossum/status/24148697432457216 and after that there was a little buzz in Twitter, after which approximately 500 users registered on the site.
I received emails and comments that it is very good idea, that they see big potential in it. I saw that people like it, they said that I should continue working on it. But now all is silent.
Please, help me to make a decision: should I continue or stop doing it? <comment><USER2> 1\. What do you want to get out of it? 2\. Do you see this happening? If not, stop. 3\. If you're not sure, what do you need to make it happen? 4\. Does that seem viable? 5\. If not stop. 6\. Otherwise continue.

<comment><AUTHOR> My main goal is to make it useful for people, and I know that it can be useful and convenient. But it is hard to explain to people that it can be useful.</comment></comment>


Did Boeing Secretly "Bet the Company" yet Again on an Airline Project? - chupa-chups https://blog.thetravelinsider.info/2019/07/did-boeing-secretly-bet-the-company-yet-again-on-an-airline-project.html <comment><AUTHOR> I think Boeing stock has held up because Airbus has limited production capacity for the A320. The 737 and A320 split the market almost 50-50% and it isn't like Airbus can double their production capacity overnight to replace the 737.

Marginally the 737 MAX problems will push some business to the A320 and will also help the rise of the A220/E190 class aircraft. It will take a long time though.

In my mind it is a clear case of secular stagnation, under-competition and under-investment. One of the reasons why flying has gotten worse over the last 20 years is that the 737-A320 class has entirely pushed out widebodies in the U.S. domestic market.

People make all kinds of excuses for the 737 but you shouldn't buy them.

For instance, the 737 is a horribly loud aircraft. People will say "buy some noise canceling headphones" but what about the poor people on the ground?

People will point to seat pitch as a factor and blame airlines, but seat pitch is one of three dimensions. The 737 feels cramped because of the low ceiling and it is stuck in a local minimum of comfort with 3-3 seating in coach.

The A220/E190 class ditches the circular cross-section for something more appropriate for the human body. The planes are smaller but have a little more width with 3-2 seating. With geared turbofans, the noise level in both the cabin and on the ground are greatly reduced. These smaller planes feel like riding in a 767 or other widebody compared to the 737 -- it sounds like a boast, but flying is believing. It's like the Japanese cars in the 1970s that were big on the inside and small on the outside when American cars were the opposite.

</comment><comment><USER2> It's worth noting the massive incentive for a company to push the narrative that "One more big financial hit and we'll be gone! All those jobs destroyed!" \- in the build up to what is obviously going to be a massive fine by a regulator that can be politically influenced. Boeing _will_ be using every avenue it can to spread fear about what would happen if they get hit too hard by regulators.

</comment><comment><USER3> _Amazingly, most of the certification process for this new and very different plane was based on grandfathered approvals for the original 737, almost exactly 50 years earlier._

That is an interesting claim about certification I haven't previously read.

<comment><USER4> The whole point of the 737-MAX was that it was a modified 737, and that's why what would now be considered unsafe design features were allowed (reducing development costs and time to fly), and why MCAS existed: to hide that it was a new aircraft.

Every design decision in the 737-max is geared towards a plane that appeared to be no different from a 737 to pilots or regulators.

</comment></comment><comment><USER5> So, if Boeing kills of the 737, and Airbus can't ramp up production of its plane in that class, who's going to build them? Seems like a perfect opportunity for a Chinese manufacturer.

<comment><AUTHOR> see

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

I can't say I am exicted to fly on one but it's a competent 737 replacement.</comment></comment>


What is a normal CPM? - <AUTHOR>

According to YOU,<p>what is a normal CPM for an adSense campaign ? <comment><USER2> Range does widely vary. However, typically adSense (net effective) CPM will be moderately low, e.g. $.10-.90 for most sites. Sites with a high concentration of audience for higher demand verticals can see higher CPMs, particularly if you've got decent volume of preferred placement sizes and get Google Display rather than AdWords. Higher paying verticals include: automotive: $1-7 possible (I used to manage ad sales & ops at a larger automotive site; for some time we served 50-80M impressions a month to Google) travel: $2-6 (I've spoken with several sites in this vertical that rely on G)

Other major consideration in managing your ad network revenue is to equate everything out to your net effective CPM, since many entry-level networks will pay you on a rev-share or CPC/CPA basis. Taking the total revenue you receive and dividing by (total impressions / 1000) can help you compare many diff sources on an equal basis.

Hope that helps. \--Coondog.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER3> I posted this a while back: <http://news.ycombinator.com/item?id=1136710>

We were doing £0.20 ($0.31 US), more recently it's been closer to £0.30.

We did have a period over summer of £0.50+, but this was after a phone call from Google..... I think we jumped "on their radar" at this point and they had some campaigns specific campaigns.

We only run adsense on our backfill, after premium and Adjug.

</comment><comment><USER4> It varies from 10c to $20+ depending on the category

ie. is your site about politics, or is it about how to find an asbestos lawyer in new york?

If you have enough traffic, the ad networks will fill and sell better than adsense almost everywhere.</comment>


Is Money Always the best Way to Reward Employees? - <AUTHOR> http://www.mikemichalowicz.com/convert-recurring-model-increase-revenue/

<comment><USER2> A thoughtful gift (emphasis on thoughtful) is nice. Nice is good. Frankly, just getting any sort of verbal, sincere "atta boy" is a great motivator.

Rewards are not a replacement for proper compensation.

That said, I think it is also fair to ask: "Is money the best way to reward companies?" ;-)</comment>


Speed matters: Why working quickly is more important than it seems - <AUTHOR> http://jsomers.net/blog/speed-matters <comment><USER2> From the comments, I think readers are generally failing to take an opportunistic attitude toward this article. Dig out useful ideas and ignore what doesn't help.

Yes, there are situations where working too quickly will bite you, so you can't always do it. But the key idea here is that by working quickly you reduce your expectations of how costly a new effort is. Then you'll actually start it. Inertia is a powerful adversary. Any weapon you can put on your belt to fight it is worthwhile. I'm keeping this idea.

<comment><USER3> "Opportunistic attitude" looks too much like "confirmation bias" to me to be comfortable with it.

<comment><USER4> The phrase may put you off but I think the sentiment is sound. Too many dismiss something/somebody in entirety because of one flaw. I think it's better to try to find value in everything; even if it's 99% shit, you can still learn from that 1%.

<comment><USER5> Or you could find something that's 95% shit and learn from its 5%. You can't learn everything, so why would you spend your time learning the 1% good things and dealing with 99% shit? There are too many easy ways to find value out there to be spending your time panning for scraps in sludge.

<comment><USER6> What's your search cost? If you have to hit "back" on 5 articles that were 99% shit to find the one that's 95% shit, you were better off just taking your 1% tidbits.

(In practice, I've found that anything that's >50% shit or so isn't worth wasting time on. Stuff that's >50% good, informative stuff is usually qualitatively different from stuff that's 5% good informative stuff; go where the former is.)

<comment><USER5> I think that's really a matter of what level of mastery you are looking to achieve, and how broadly you intend to achieve it. If you're looking to be the best of the best in one single, narrow subject, you might quickly run out of <50% shit resources and need to dig into some really bad stuff to find little, rare bits of good knowledge.

<comment><USER6> If you want to be the best of the best in one single, narrow subject, then listening to what other people think is useless. Rely on direct experience instead; perform your own experiments, test out your own ideas. That's what it means to be the "best of the best": you're the one injecting new data into the ecosystem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection.

But one good counter example does come to mind - designing a database schema.

I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes where the future state depends on a prior state, are relevant.

Maybe we could say tasks are either "strongly Markvoian", that is, how well we do them now will influence our future work and hence we should really think them through, e.g. designing a schema. Weakly Markovian, in which case there may be some future impact but not much, and so we exercise caution but "done is better than perfect". And finally non-Markovian - e.g. throwing out the garbage, cooking dinner, most emails - getting the thing done is simply a pass/fail and so we just have to do it, quality is relatively unimportant.

I think what I'm saying is, most tasks will be weakly or non-markovian, so we should "move fast and break things", but every now and then there'll be something we need to do that is strongly markovian. For such things we should be prepared to take a step back and give ourselves a little extra time, so things don't blow up further down the track.

<comment><USER8> I can think of lots of more things, where doing them fast initially makes sure you'll never learn them:

* Typing on a keyboard

* Sharpening a knife

* Driving a car.

It seems more like a question of doing things a lot and very focused, than focusing on speed initially.

<comment><USER9> Tried to teach myself to touch type. I can kind of do it, but its just so slow compared to my normal typing.

<comment><USER10> Measure your writing speed. Aim for 70-80 WPM. If you get that speed then it's a) enough and b) it doesn't matter at all if you "touch type" properly or have invented your own typing system.

<comment><USER11> The advantage of touch typing is on a good keyboard/desk/etc you can do it 10 hours a day for 30 years without wrecking your hands. That said, most programmers don't actually type that much so it's not nearly as important.

<comment><USER12> I bemoan the death (or near-extinction) of text-input games. I learned entirely on my own how to touch type by playing classic Sierra adventure games and spending a ton of time in DOS. I never would have done that if I had gotten into computing a few years later with the transition to mouse-based UIs.

<comment><USER13> Definitely same here. I feel I was fortunate that my parents were poor graduate students. As a result, I learned my formative computing skills on DOS 6.2/Windows 3.1 at a time when respectable citizens were packing 486DX4s - Pentium 90s.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Yes and no.

Do things fast when the cost of doing them wrong is low. If you're learning something, or doing something with low risk, then doing it as fast as possible is a really good idea (for all the reasons set out in the article).

But...

Do things slowly if the cost of getting it wrong is so high that you'll have no opportunity to try again. For example, don't pack a parachute quickly.

The key is recognising that there's more than one way to approach soemthing; _selecting the right method for the problem at hand is the winning strategy._

<comment><USER15> The parachute analogy is worth exploring.

Let's say in a life time, the accident rates due to packing a parachute quickly is 1/10000, and the fatal rate of the slow packing group is 1/1000000\. Even though the fast group faces bigger danger than the people in the slow group (or people sitting at home), but other than the few who have the bad luck, the rest of them will practice way more than the other group, jump more times, go to more places, have bigger opportunities to become a world champion of parachute packing or whatever parachuting sports.

Sure, a few will be forgotten by the world.

The victors we see in the world are probably the people who are still alive in the fast group, and have produced lots of results because of their speed and being still alive. Someone in that group will pay a huge price, but it's not necessary you or any particular one.

<comment><USER16> You're attacking this analogy with made-up numbers and wild logical leaps. What is the real risk increment to packing a chute hastily, and does the real number help or hurt your position? Now make the stakes really high. Also consider the possibility that your choices have externalities, and others around you may not want to share their jumps with someone they perceive to be that reckless idiot who's going to get himself killed.

You didn't give specific numbers on how often someone can jump, but consider the realistic bounds on how much more often a person who packs hastily can skydive. How often is this person jumping? Are we in a scenario where the amount of time it takes to pack a parachute is really the limiting factor, to the point where the hasty packers can jump "way more?" Seems like what that would mean in concrete terms is that as soon as you hit the ground you're going to hit the john, re-pack your chute, and immediately be back in the plane. Is that a realistic scenario?

<comment><USER17> I found your response to the guy a bit hostile, he's still using a hypothetical analogy too.

<comment><USER16> Hostile to the idea, not the person. With some reason - there are a lot of pernicious myths that survive purely on the false mimesis you can generate by using made-up numbers. See: Politics.

<comment><USER17> I'm specifically saying that "You're attacking this analogy with made-up numbers and wild logical leaps" is too harsh a way to begin a comment here - it's not civil. The dude just said some hypothetical thoughts, you could have responded "Unfortunately I feel your numbers are not drawn from the real- world, and I think some of your conclusions take real leaps of logic. Specifically..."

but hey it's just me. this place is usually pretty civil - it's in the rules.

<comment><USER15> Yeah I thought we were talking hypothetically and in a very general sense (hence the obviously made up numbers to merely indicate some scales) about an inherently very general issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Speaking as one who is laid back in a personality sense, I could imagine nothing worse than a life lived non-stop frenetically under the imagined need to speed up all activity in the name of productivity.

Take time to pause, reflect, _think_ , and enjoy your life experiences.

Even when it comes to work-related activity, there are times and places to do things quickly and there are times and places to do them deliberately. If nothing else, just for sanity's sake, it is important to pace yourself through a day, through a week, through a month, through a year, through a career. Even if speed were exactly correlated with maximum productivity and effectiveness, it is vital that you have times when you simply feel you can enjoy being at work, being with people, doing your activities, _without_ everything feeling you have to work like a machine that will be evaluated by engineering standards only.

Even more, we all have different personalities and some people do not work well if they feel they are forced to work at some arbitrarily quick pace as opposed to one that suits their style.

Finally, even speed as a factor can vary with your activities as you develop skills in those activities. When I began years ago to try to write things, I was agonizingly slow about the process. I felt I had a quick mind but the process of getting what was in my mind down on paper made me feel plain stupid. Whatever I did, it would never come out right. Through a very tedious process of writing and re-writing, it would eventually become passable and that was it. It might take me a week in such cases to write something expository of modest length. Yet, realizing this was a weakness, I worked damned hard to fix it and, through a process of many years and countless hours of effort, I reached a breakthrough point where I could do "walls of text" (in the phrasing of some) in 10-15 minutes and produce quality stuff. I now write very quickly and effectively. But had I tried to do so years ago with my limited abilities at that time, all I would have produced was hash.

So, lighten up and do it in your own style. Yes, speed does matter. But it is only one of many factors that will determine how you do at work or, even more important, at life itself. By all means, apply yourself well - be diligent, hard-working, etc. but do it fast or slow as suits your needs and your own style. At least that is how I view it.

<comment><USER19> One of the tenets of Extreme Programming is, "Quit when you're tired." Why? _Because it 's faster._

It's not faster today - if you kept working, you'd presumably get more than zero done. But you'd also create more bugs, and you'd come back more tired tomorrow. Coding is not an assembly line; your brain needs to be fresh.

Taking time to pause, reflect,and think is the same. It's slower in the next minute, maybe in the next hour. But stopping to think and realizing what is the right thing to do can save you days of waste.

My first boss said, "You need to learn when the most productive thing you can do is go look out the window for 15 minutes." After 30 years, it's still good advice.

I'm ignoring your point about work-life balance here. All I'm saying is, too much emphasis on speed slows you down, even only considering work.

<comment><USER20> As someone who's just finishing nearly four weeks of non-stop work including weekends, I approve of this message.

</comment></comment></comment><comment><USER21> Perhaps this applies more to shooting than software development, but...

Slow is smooth. Smooth is fast.

If I take 20 minutes more to code a module because I'm thinking about it, but spend 30 minutes less debugging problems with the module, that's fast.

If I take a day to respond to an email, but the person I'm conversing with gets the info they need, avoiding three more days of back and forth, that's fast.

If I take a week longer to iterate through a project idea, but nail the implementation, then I can know that I'm pivoting because the idea was wrong, not the implementation.

</comment><comment><USER22> How do mere mortals become wizards to their peers? They take the time to read documentation and code and really understand the tools that they are working on. What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly. Of course there's a balance, and our current system of financing software projects rewards fast and loose, and there will always be a place for fast prototyping to help understand the problem, but to create something truly amazing takes a lot of time.

<comment><USER23> "What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly."

I kinda think that the opposite is true, or at least as true as your statement (meaning that at least as much half-baked stuff rushed out the door 'stood the test of time' as did stuff that took a lot of time to ship.) Unix, C, Windows, PHP, JavaScript...

<comment><USER24> To offer an example of a project that has stood the test of time far longer than the ones you mentioned, consider Fortran. The first compiler was released in 1957, several years after it was first proposed. The specification took a couple of years to complete. This was over 60 years ago, and even now they are releasing an update to Fortran (Fortran 2015).

Even in the examples you mentioned, Unix, C, and Javascript are all run through standards bodies now. It took years for C11 to be finalized. It's been years since ES6 has started development. PHP7 has taken a few years (and a version update before even being released).

Windows, depending on who you're talking to, can be a good example of half- baked, or an example of why half-baked is terrible, with regards to Windows 8 and Windows 10 releases.

<comment><USER25> May be you and your parent comment are both right? Release the first few versions very fast (even if it is not good) and if it is successful, then slow down, redesign etc? Examples include PHP and JS

<comment><USER26> You can totally screw the pooch with this approach and squander all your momentum, as well. See Perl 6, OpenGL Longs Peak

</comment></comment></comment></comment></comment><comment><USER27> There are actually three lessons here:

* Momentum - To stick with something and finish it, you need to use momentum. Lacking momentum, projects languish. Quoting author Steven Pressfield: "Second only to habit, momentum is a writer's (or artist's or entrepreneur's) mightiest ally in the struggle against Resistance."

* Waiting is painful. That's the point behind the examples in the middle section (waiting for an email reply, waiting for Google, waiting for an employee to finish a task). One thing this article makes me more aware of is the concept of getting impatient with yourself. Part of you is the boss or client that wants things accomplished, and it is sizing up the worker part of you, wondering if it assigns a task whether that task will get done quickly or require a lot of waiting, and there's a relationship to manage there. (Perhaps this dynamic underpins the phenomenon of momentum?)

* Quantity Always Trumps Quality - There's a blog post by Jeff Atwood with this title. The point is, if you want to get better at something, do a lot, and don't worry about quality while you're practicing.

Focusing on "speed" is probably a good mental trick for a couple reasons. First, it validates and acknowledges that we hate to wait. Second, it helps overcome perfectionism and the tendency to think and judge instead of doing and creating, by giving us something to measure that is not about quality but is instead correlated with action and progress.

<comment><USER28> > Quantity Always Trumps Quality - There's a blog post by Jeff Atwood with > this title. The point is, if you want to get better at something, do a lot, > and don't worry about quality while you're practicing.

I wholeheartedly disagree. My martial arts instructor had a saying: "Practice doesn't make perfect. Perfect practice makes perfect." I've found that to be true. After all, if you practice bad technique, how do think you're going to perform in real situations?

Not to mention, you usually practice things in a controlled environment where you are evaluating your own technique. That's often not true in real situations, where your focus needs to be split on many different things. If you want to execute well in a real environment, good technique needs to be second nature so you don't have to think about it. You just do it. Being able to do that requires a large amount of good practice.

<comment><USER27> "Quality" here means the quality of your result. If you are learning to paint/sing/code, it means how good the painting/singing/code is. The advice is to not "worry" about the quality, in the sense that if you are not producing good quality output, that does not mean you are doing anything wrong. When you are just learning something, the output will not be good quality! You need to produce a lot of crap results, and that makes most people uncomfortable.

I can relate what you're saying to my experience taking singing lessons, though even there, I find that making progress is all about turning off the inner judge while you practice. All you need to practice something is a bit of intent and a bit of awareness; it's not important that you "worry" about the quality of what you are doing, per se.

</comment></comment></comment><comment><USER29> Speed matters and there are more ways to make things faster other than doing them often.

1\. If you are coding ensure that your debugging environment is good (simplest example would be if you write HTML how long does it take to see the output or is it auto-refresh itself int the second monitor when you change the file?).

2\. If you are building a project how long does it take to deploy? Do you have CI with a one button push to production environment? If you have then you'll deploy faster and more often there is no overhead. If not you won't want to deploy often due to the overhead of the deploy.

etc.

The most important lesson I've learned about speed is that "design your environment and build for speed and remove the repetitiveness" then you can be fast. You can apply this rule to many things. Blogging, ensure that your blog tool makes it easier (how easy to link stuff, find images, does it really necessary to add an image to all posts, do you FTP upload, or do you just copy&paste and image to the editor, what happens if it crashes, do you lose data or does it just recover?)/

<comment><USER30> Reminds me of Mjoolnar's (author of vim) talk on 7 habits of effective editing 2.0; the core idea is essentially (my current interpretation): awareness: look for repetition - they are candidates for automation and/or being more effective. Rule of three: If you do something (anything) 3 times - figure out if it can be done more efficiently. In vim (or any other editor) an example might be shifting the indendation of code: maybe you only remember how to do it a line at a time; figure out how to work on blocks of code; figure out how to do it on a file - a whole project.

[https://m.youtube.com/watch?v=p6K4iIMlouI](https://m.youtube.com/watch?v=p6K4iIMlouI)

</comment></comment><comment><USER31> > I've noticed that if I respond to people's emails quickly, they send me more > emails.

An alternative explanation would be that if you don't take your time to understand people's mail and just rush to answer them as quickly as possible, things that would take two mails to communicate now end up being a thread of ten mails, two phone calls and an in-person meeting.

Nothing is more infuriating than a person that replies 30 seconds later with a message that suggests they didn't read past the first sentence.

I don't know the author or his ways of responding to emails, but in my experience the above often applies to people that value speed above all else.

<comment><USER32> Agreed.

I also don't respect people that always respond to email immediately because it makes me think they don't have anything important enough to work on that requires unbroken concentration.

</comment></comment><comment><USER33> I see a lot of responses that seem to reflect what I consider a misunderstanding of the real advantage of speed.

It's not to get the same amount of work done in a shorter time (the management fallacy referenced in some of the comments).

The point of speed is to increase the number of feedback opportunities. Each feedback datum allows for slight course corrections / confirmation of original hypothesis.

By analogy, think of it like sample size. If you accept time as a primary constraint, then faster iterations (even if you accomplish less!) tend to give you more samples. More samples mean less variance.

Making decisions on a better model (less variance) is very appealing to me.

<comment><USER34> This article reminds me of one of my all-time favorite articles. Quantity Always Trumps Quality by Jeff Atwood [1]. There is a bunch of commentary on it on Less Wrong [2], some of which is interesting. Also an interesting parallel to a Paul Graham post [3]:

> I was taught in college that one ought to figure out a program completely on > paper before even going near a computer. I found that I did not program this > way. I found that I liked to program sitting in front of a computer, not a > piece of paper. Worse still, instead of patiently writing out a complete > program and assuring myself it was correct, I tended to just spew out code > that was hopelessly broken, and gradually beat it into shape. Debugging, I > was taught, was a kind of final pass where you caught typos and oversights. > The way I worked, it seemed like programming consisted of debugging.

> For a long time I felt bad about this, just as I once felt bad that I didn't > hold my pencil the way they taught me to in elementary school. If I had only > looked over at the other makers, the painters or the architects, I would > have realized that there was a name for what I was doing: sketching. As far > as I can tell, the way they taught me to program in college was all wrong. > You should figure out programs as you're writing them, just as writers and > painters and architects do.

1: [http://blog.codinghorror.com/quantity-always-trumps- quality/](http://blog.codinghorror.com/quantity-always-trumps-quality/)

2: [http://lesswrong.com/lw/53e/just_try_it_quantity_trumps_qual...](http://lesswrong.com/lw/53e/just_try_it_quantity_trumps_quality/)

3: [http://www.paulgraham.com/hp.html](http://www.paulgraham.com/hp.html)

</comment></comment><comment><USER35> Before anything, the obsession with speed seems like a management fantasy that tries to squeeze more out of workers in less time. We shouldn't forget that we're all human, and there are myths and facts related to working fast.

Working "fast" is tricky. The ironic conclusion part of the article is an example to that. People will miss the point and screw up more while trying to be "faster". However if a task becomes more automatic, it will become faster, which means that actually doing something "fast" would consume less energy, since it is more or less automated and unconscious, while "trying" to be fast would consume more energy.

The key here seems to be that just do something "a lot", and it will become faster by itself through time by being more and more "automated". But _take your time_ , and stop worrying about speed. Speed is just pressure which will bring more pressure as you do stuff faster. Don't create unrealistic pressure.

Another key is garbage collection. Just get stuff "done", and get rid of the old tasks, or treat your long to-do items as "later" lists. If something really matters, you will do it anyway. You won't even need a to-do list to keep track of your "important tasks".

<comment><USER36> Ok, i will hold up my hand, im a software manager, and nothing fustrates me more than developers trying to do everything at break neck speed and just plain geting it wrong. They either fail to read or understand the requirements in the rush to get started, or they will rapidly push out a pile of shit, and fein suprise when it repeatably gets rejected by QA. My best guys are the ones who take the time to read tbe specs and talk to the stakeholders about what they want, and who spend time making sure that what they produce will pass muster. Those guys are golden, they are worth 10 of the immature speed freaks.

</comment></comment><comment><USER37> I believe the author has mistaken speed with efficiency. What's the benefit of being fast if you're sloppy and have to redo things often?

<comment><USER38> The implied benefit is that repetition improves quality, so more repetitions, more quickly, means your quality will improve more quickly.

You need to self-reflect after each iteration, mind you, to make sure that you learn each time you do the thing. But, this is necessary for skill progress whether you're going fast or slow.

(And, having to make the corrections can be as informative or more so, depending on how you're able to reflect on the "why" you're refining or fixing the thing).

<comment><USER39> "The implied benefit is that repetition improves quality, so more repetitions, more quickly, means your quality will improve more quickly."

Yes, but that's frequently not the case. Developers at "sweat shops" tend to write far more code, and work many more hours, than the average dev at a top tier software house and yet they are usually much worse devs.

<comment><USER40> That's largely (IMO) because those sweat-shop developers started out as much, much worse devs, whose only viable option was a sweat-shop.

The claim is that repetition and a short feedback/learning cycle will improve a developer more quickly than a long cycle. It doesn't say that a poor developer with a fast cycle will out-learn a different, stronger developer with a slow cycle.

</comment></comment></comment></comment><comment><USER41> Entrepreneurs would say that speed is the signal of mature markets: more and more effort for less and less return. Mobile games were very profitable in 2009-10 (low effort, high return), balanced in 2012 (speed was important at that stage), unbeatable and unbearable as a business in 2015 (however fast you are, you're just playing a lottery).

</comment><comment><USER42> not so long ago... [https://news.ycombinator.com/item?id=9952875](https://news.ycombinator.com/item?id=9952875)

<comment><USER43> Thinking slowly doesn't imply working slowly. Thinking slowly means making a plan, doing some research, before working. Each one of these can be done fast.

</comment></comment><comment><USER44> Some other reasons why speed can be good:

\- You can only hold so many details in your head at once, and you can only sustain that collection for a limited duration. Holding those details there can be crucial for doing good work and the faster you work the more you make use of them.

\- Doing good work often requires a lot of experimentation and iteration. In a number of circumstances this may only be practical if you can do them fast enough

</comment><comment><USER45> I am reminded of the story of how Leonardo da Vinci took three years to paint The Last Supper and produced only a small number of paintings, generally considered masterpieces, during his life.

</comment><comment><USER15> Working quickly is important because it's the better method to survive and thrive. Quickly producing 100 deliverables with qualities ranging from shit to pretty good, will probably on average always defeat carefully crafting one deliverable in the same time frame.

Speed lets you try many alternatives, experiment with many different even opposite options, and draw out creativeness.

Another possible reason is that speed is the strength of the younger generations. In human history, if new comers want to beat the current authority (in business or politics) who have already mastered the intricacies of the current game, one have to propose and experiment large quantity of new alternatives, new rules of new games, even though most of experiments might have low quality results judging by the established rules. But it's the better way to compete and survive.

</comment><comment><USER46> The author rests his entire argument on illusions to "the mind" that are untested and impossible to test. For example, "If you work quickly, the cost of doing something new will seem lower in your mind." Not sure how we get into someone's mind to measure the "cost of doing something."

We could not confirm or disconfirm this as truth, say in the context of an experiment. This phenomenon is better described by the concept of immediacy of reinforcement. As one decreases the delay to reinforcement, the strength of behavior maintained by that reinforcer increases [0].

0: [http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1332712/](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1332712/)

<comment><USER47> Sounds like you're advocating a return to strict behaviorism.

<comment><USER46> Strict behaviorism? I'm advocating for the experimental analysis of behavior (sometimes referred to as radical behaviorism). When applied to practical human problems, it is referred to as applied behavior analysis.

The study I cited provides support for the authors conclusion. However, his description is flawed because it doesn't provide means for prediction and control of behavior.

<comment><USER47> It's a blog post - an opinion piece - not a scientific paper.

Do you go around criticizing all opinions that refer to people's thought processes as 'flawed because it doesn't provide means for prediction and control of behavior'?

<comment><USER46> I understand that this is just a blog post. This post provided me an opportunity to spread the word about behavior analysis. If the author is advocating for behavior change (i.e., "doing things faster"), then we should speak in terms that have grounding in a science of behavior. That doesn't mean you have to conduct an experiment, but base your argument in science. If I were to make claims about how a particular piece of software worked or some law of physics that were untestable, I think people would have something critical to say (especially in HN comments). Why should we treat human behavior differently?

<comment><USER47> Are you saying that talking about what goes on in the mind is unscientific and should not be done?

<comment><USER46> "What goes on in the mind" is behavior. It can be studied scientifically but one can run into the "private event" problem. That is, what goes on in the mind is a private event only observable to the subject. In many psychological experiments, what goes on in the mind is inferred from observable behavior. This is problematic.

In behavior analysis all behavior is considered the subject matter, including private events. So the answer to your question is: No, I'm not saying that.

<comment><USER47> It seems you think that people should only use behavior analysis when talking about the mind.

I wish you luck in persuading people to accept this philosophy. You may have an uphill struggle convincing people that it is comprehensive enough to replace all the other ways humans have thought about their experiences to date.

<comment><USER46> >"It seems you think that people should only use behavior analysis when talking about the mind."

That's not what I think. See the difficulty in inferring someone else's thoughts? ;)

If we are just theorizing or talking about what the mind is and so on, then this belongs in the realm of philosophy.

Behavior analysis is alive and well on the psychological scene. APA's lifetime achievement award this year went to an applied behavior analyst. If behaving is doing and behavior is the subject matter of behavior analysis, that's pretty comprehensive.

<comment><USER47> It may not be what you think, but you continue to argue (condescendingly) that behavior analysis is the only valid approach to any topic concerning human behavior. Now you do so by an appeal to authority.

Have you considered the possibility that some philosophy might actually be useful in this domain?

[incidentally: I have nothing against behavioral analysis in itself - just the claim that thinking about what goes on in the mind should be excluded in its favor]

<comment><USER46> My bad for coming off as condescending. That wasn't my intention. Philosophy is useful when talking about or discussing things. The problem with philosophy though is it doesn't allow one to predict and control behavior. Thus, if practical behavior change is your goal then behavior analysis is appropriate.

<comment><USER47> Prediction and control is not the only paradigm for causing behavior change, indeed it may frequently be the least appropriate one.

<comment><USER46> Prediction and control is what science rests on whether we're talking about behavior or physics. You can't prove that an independent variable (IV) caused a change in a dependent variable (e.g., behavior) unless you can predict and control it by systematically manipulating the IV while observing changes in the DV.

However, this is way beyond the scope of the original blog post or my original comment. In my first comment, I offered an alternative description of a phenomenon that the author described. You suggested that I was advocating for "strict behaviorism." That wasn't the case, so I clarified. At this point, I'm not sure what the purpose of this discussion is.

<comment><USER47> The purpose is to point out that people sharing information about how they think about things is a valid a way of influencing behavior. You are simply wrong to dismiss that.

I agree that humans influencing each other through talking about how they think about things is a hard phenomenon to reduce to the kind of science that you are advocating, but that is a limitation of your preferred methods, and it's inappropriate to dismiss phenomena just because you don't have a good way to understand them.

<comment><USER46> > "The purpose is to point out that people sharing information about how they > think about things is a valid a way of influencing behavior. You are simply > wrong to dismiss that."

I agree that people sharing information about how they think about things may INFLUENCE behavior. In your previous comment you used the term "cause." These are very different words, especially when we are talking about science. It's not clear what you think I dismissed.

> "inappropriate to dismiss phenomena just because you don't have a good way > to understand them."

I never suggested that we dismiss phenomena. If you read my original comment, I agreed with the authors general premise but I offered an alternative explanation: "This phenomenon is better described by the concept of immediacy of reinforcement. As one decreases the delay to reinforcement, the strength of behavior maintained by that reinforcer increases."

Thus, I'm not sure what your point is.

<comment><USER47> In that same paragraph you quote from, you dismissed the author's reasoning about thinking processes. You didn't simply 'offer an alternative'.

<comment><USER46> You are incorrect. I did not dismiss the author's reasoning. I said: "We could not confirm or disconfirm this as truth, say in the context of an experiment." The author isn't running an experiment, he's just talking about how he feels when he does things quickly. So what's your point?

My point in the original comment about the concept of immediacy of reinforcement is that it is a broader, evidence-based concept that encompasses what the author described. I thought HN users might get value from such an explanation as they could apply it to more aspects of their lives than just "doing things quickly." It seems as though your purpose is to argue with me over things I didn't say or ideas I don't hold, which isn't productive or meaningful to the HN community.

<comment><USER47> [https://news.ycombinator.com/item?id=10024791](https://news.ycombinator.com/item?id=10024791)

In this reply, you are wholly dismissive of discussions about behavior that do not solely use behavior analysis.

<comment><USER46> First, that's not the reply you were talking about when you stated that I was being dismissive above. Yet, your interpretation is still wrong. Second, except for the first sentence I didn't even use the term "behavior analysis" and instead used the term "science." Nowhere in that reply did I suggest that "discussions about behavior that do not solely use behavior analysis" should be dismissed. Throughout this discussion, you have attempted to mischaracterize my statements and your most recent reply is another example. Thus, I'm not sure what your point is other than attempting to build a strawman and blow it down.

<comment><USER47> Now you are being intellectually dishonest. You didn't use the term behavioral analysis in that specific reply. True, you used he word science, but this is irrelevant to the fact that you were dismissive.

Attempting to evade this through being pedantic rather supports my point.

<comment><USER46> I'm not being intellectually dishonest nor am I being pedantic. That's kind of offensive. Nowhere in my post did I suggest that behavior analysis was THE ONLY way to conceptualize "the mind" or whatever we are talking about at this point. Yet, that's what you're accusing me of saying. It's ridiculous because all of our words are above. I don't want to argue with you, but you're wrong.

Nonetheless, you are arguing with me. You responded to my comment. I would rather you not tell me what I think or what what I said, when the facts don't show it.

<comment><USER47> I'm not wrong about you being dismissive of anything except what you deem to be 'scientific'.

<comment><USER46> You are wrong. I'm not sure what your claim is now, but you were accusing me of suggesting "that behavior analysis is the only valid approach to any topic concerning human behavior." Nowhere in any of my posts did I make that claim. This makes your quote factually incorrect.

This discussion (which has now devolved into an argument) began when you stated that I was "advocating a return to strict behaviorism." This was also incorrect, so I clarified.

I honestly don't have a problem with you, but you have been kind of attacking me in this thread. When you told me that my tone was condescending, I apologized because I know that my words can have an affect on people that I didn't intend. At this point you are offending me by claiming I said things I didn't say and attempting to characterize me as someone who ignores all viewpoints except for BA. Yet, our entire conversation is recorded above and does not support your claims.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER48> As a developer, what this means to me is:

For every piece of code you write, there should be a unit test covering it that you can run fairly instantly with 1 keypress which catches _at least_ internal-consistency errors. (Integration tests would cover external- consistency errors, but when you're refactoring/adding/deleting code, internal-consistency is violated far more often than external consistency, in my experience.)

Once you experience this for yourself, you will NOT want to go without it. It allows you to IMMEDIATELY get back to coding without waiting for test runs to finish and without creating bugs unknowingly that you only catch much later.

<comment><USER49> This is why I love Haskell---the check, though approximate, is built in to the language as the type checker. Pair it up with the speed Haskell coder's best friend, "undefined", and you can be just 40 characters into writing part of a method and check it right there on the spot, getting into a good flow.

<comment><USER48> I see that appeal of Haskell, and I think the strict focus on typing does catch many possible bugs... but I don't think it catches _all_ the types of bugs that an actual unit test would, so I'm almost afraid that it's leaned on a bit too much.

<comment><USER50> > but I don't think it catches all the types of bugs that an actual unit test > would

You are correct. Likewise types can catch some bugs that unit tests cannot.

<comment><USER51> There is always a unit test which could catch any type mismatch. The problem is that every type declaration implies a set of unit tests (probably an unbounded set!) and in practice it's not likely you'll actually write enough of them.

</comment></comment></comment></comment></comment><comment><USER52> One apparent counter-example is that when practicing the piano, some common advice is to play pieces much slower than you think is necessary, but play them correctly. Then speed up once you have the right habits.

But the overall goal is to learn new pieces as efficiently as possible. Someone who is efficient at practicing will make much more progress (and have more fun doing it) than someone who isn't.

</comment><comment><USER53> High speed alone is not so good if it comes without quality.

<comment><USER54> That's the catch, isn't it? You probably want to get high quality fast, but you can't get fast without losing quality, at least in the beginning. But I'm pretty sure speed trumps quality in most cases - having a good enough product out is eons better than having a perfect product years away...

<comment><USER55> See: Worse is Better vs Worse is Worse.

</comment></comment></comment><comment><USER56> I feel like there's a bunch of data over-fitting going on here. The examples here are merely the ones that fit with the author's model, are they not? I'm sure I could have had a theorem that points to the idea that "fast work is catastrophic", gone back in time, and shown how the slow individuals / components of a system were significantly more effective than the fast ones.

</comment><comment><USER43> It's funny that they include google as a fast example. On my Nexus4 and Nexus7 Google search is the slowest thing you can do on the internet. Youtube HD videos are way faster than a google search and fail less often when on the train/bus. I always wonder how sending a String and getting back a list of Strings can be so much more expensive than a HD video but who am I to judge, right?

<comment><USER57> I think he's having in mind the time when you had to enter altavista- digital.com to enter a search site. There were worlds between that and google.com (both entering the URL and getting the results).

</comment></comment><comment><USER58> Not using flyspeck grey fonts on light gray background in a tiny column on a vast screen is more important for readability than it seems.

</comment><comment><USER59> I am not sure if the writer has thought out the drawbacks to working quickly but there is probably some benefit to deciding quickly.

The writer mentions that faster employees have more work assigned to them. Woo hoo, but what happens when the work queue fills up faster than it can be emptied? Then the once-fast employee now seems slow.

</comment><comment><USER60> I find myself really, tangentially curious now: what editor is he using that has a slow undo feature?

</comment><comment><USER61> There is a big unasked question here - is your final work product the same or better quality when working fast?

If you can honestly answer "Yes" to that question, by all means, speed it up.

</comment><comment><USER62> Move as quickly as possible while maintaining a high level of accuracy/quality. Some people underestimate themselves, moving too slowly!

</comment><comment><USER63> I can see the benefit of making progress quickly. Haven't seen frenetic/"quick" working lead to that result.

</comment><comment><USER64> Never mind the quality, feel the width :)

</comment><comment><USER65> The article reminds myself when I was younger when I was 27. Now I am 28, and I have grown wise and old in this year to know that working quickly does exactly that, produce quick results without much quality. It works well in cases where you need a result or just something to build momentum, but it's not at all sustainable. Just like coding, if you speed without thinking through the steps you end up with a mountain of technical debt, instead, it's actually faster to think slowly and careful and doing the right things instead of your ego which gets a huge kick out of doing more in higher quantity than quality in short period of time. Again, it works well in some scenarios which I can't think of right now but not at as important as this young buck has written.

</comment><comment><USER66> so inspiring. this person is generous, admitting to being the slowest.

-=in defence of taking your sweet time=-

the arguments for speed and the arguments for quality are not either or. they both contribute to a product that works.

to introduce the case for slowness a natural precedent is appropriate. the development phase for human beings was on the order of 2 billion years.

and in that time a whole lot of nothing happened. all those evolutionary competitors at every level of the tree of life were more rapidly produced than humans. and now humans rule the world and in 200000 years have used that comprehensive development period to move rapidly and adapt so effectively to the world that we have changed it to support 7 billion of us and tripled our life spans. the hockey stick curve of our technology speaks to the benefits of long development, and the long tail of non-adaptive more-rapidly developed ideas that come to nought.

those practising rapid development and launch save costs during the development stage and increase costs during the much longer operating stage by code that has more bugs, takes more to maintain, is more brittle, and these things constribute to being slower to adapt to customers and competitors when it counts, that is, when you have customers, are burning operating costs, and competing.

it works better to develop comprehensively when it is cheap to and build the most efficient product to be really useful when you run with it. longer development, then move faster in operations.

otherwise you end up solving your terrible code base by hiring more brains, and those brains could be better put to use creating improvements for your customers and not fixing the consequences you shipped in a sprint.

pre launch development is cheap, so it works to take your time and not optimize that __process__ prematurely. everything is more expensive after launch when the stakes are real and where an advantage can be moving fast -- if the code you crafted creates that you can adapt quickly, then you've minimized costs over the operating period, and your brains can work on growing and retaining, rather than building an ozymandius of monkey patches.

the time when speed is important is after launch not before it. if you rush your pre launch development, you will be a slow operator, and this will cost you exponentially more than the linear increase in cost from a longer development time.

also the more robust the system you build is, the slower ( as in slow thinking ) you can create your decisions in the operating period to really consider strategy.

let your competitors ship first and watch the things they miss. let them pay for the experiments you now decline to run. if someone seems to be capturing the market through their business model then you are too slow anyway and the high order bit for you isn't code anymore. if that is not your market, then it is filled with competitors who are mimicing each others sub-monopoly strategies. so you can step in, be the last mover, and take the market. invest time during development to make code and tools that work, grasp your business plan, and have the possibility of thinking strategically about the business, in the operation phase, once you have launched.</comment>


Why the calorie is broken - <AUTHOR> http://mosaicscience.com/story/why-calorie-broken <comment><USER2> A better title might be "our understanding and contextualisation of the calorie was broken but is getting better."</comment>


Job Losses Likely to Accelerate - <AUTHOR> http://www.forbes.com/markets/2008/08/01/unemployment-july-update-markets-economy-cx_mp_0801markets10.html

<comment><USER2> I thought this was going to be about Steve Jobs. Thank god its only about 51,000 people getting fired.

<comment><USER3> I changed the title. (It was "Future Looks Bleak for Jobs.")

</comment></comment><comment><USER4> WTF? This article has nothing to do with Apple at all!

Linkbait!</comment>


Polyscope: a C++ viewer and UI for the rapid prototyping of geometric algorithms - <AUTHOR> http://polyscope.run/ <comment><USER2> > Rather than forcing the user to manually convert their data types to some > Polyscope types, we implement a series of templated adaptor functions, which > attempt to read from the user types via a common set of strategies. These > adaptors are applied to the inputs to nearly all Polyscope functions, > allowing them to automatically accept user-defined types as inputs.

It's interesting how object oriented programming seems entirely orthogonal to code reuse. Polyscope seems to have solved that problem with templates, but I wonder what the compilation errors will look like if your type does not support one of the required operations. Would Concepts finally solve this problem in C++20?

<comment><USER3> Anecdotally, message-passing OO style is great for code reuse where there's a lot of state to manage - you tie together the state and the functions that operate only on that state, and you get a nice clean reusable module. Inheritance-style, however, I've never found especially useful - it seems like the layers just end up depending on each other in an opaque fashion.

Polyscope, however, seems sufficiently ambitiously abstract that "code reuse" might be too narrow of a concept. It's a great example of the fuzzy distinction between "writing a library" and "inventing a DSL".

</comment></comment><comment><USER4> While the project sounds interesting, there are no screenshots at all, either as a gallery or topically when describing various functionality.</comment>


Show HN: Haystack – Visibility into How Software Teams Works - <AUTHOR> https://usehaystack.io?bypass=hn&utm_source=hackernews&utm_medium=show%20hn&utm_campaign=hn <comment><USER2> It would be useful if the web-site had a _real_ case-study where they show all the features in action. Right now it looks like vaporware -- like one of those sites people put up to see if there is interest in an idea.

And perhaps stuff like this should have on-site capability for enterprises that don't use github, gitlab and such?

<comment><AUTHOR> > It would be useful if the web-site had a real case-study where they show all > the features in action. Right now it looks like vaporware -- like one of > those sites people put up to see if there is interest in an idea.

True. We'll add better images and case-study to avoid the confusion.

> And perhaps stuff like this should have on-site capability for enterprises > that don't use github, gitlab and such?

I'm assuming you are talking about GitHub Enterprise, Gitlab Self-Managed and Bitbucket Server. We currently have support for Bitbucket Server and working on the rest.

<comment><USER3> There's lots more issue tracking and code hosting systems (often run as independent parts, not all-in-ones) than those 3.

</comment></comment></comment><comment><USER4> To avoid trademark fun, you may want to rebrand at some point.

A tech selection from Googling 'haystack'

[https://www.haystack.tv/](https://www.haystack.tv/)

[https://project-haystack.org/](https://project-haystack.org/)

[https://thehaystackapp.com/](https://thehaystackapp.com/)

[http://haystackdata.com/](http://haystackdata.com/)

<comment><USER5> There is also [https://expediadotcom.github.io/haystack/](https://expediadotcom.github.io/haystack/), an Open Tracing-compliant distributed tracing system.

</comment></comment><comment><USER6> I find this website to be a fairly amusing example of how marketing co-opts real, generally easily expressible ideas to be an amalgamation of highly targeted jargon and pointed funnels for personal information collection.

Generally any well intentioned person who worked on an idea like this would be delighted to share what their product does specifically and clearly - unashamed screenshots of interesting visualizations (maybe half cooked), telling descriptions of specific numbers being crunched and their utility as predictive indicators of project success, verified with statistical certainty.

Sadly this kind of naive, honest approach is very regularly usurped by the machiavellian machinery of the professional art of convincing others to buy things, which is narrative focused and story driven with very little concrete substance.

Not blaming the author here, I understand the motivations at work and sympathize with them, but still sometimes find myself dumbfounded by the results.

</comment><comment><USER7> Seems this is actually vaporware. No screenshots, no actual demo/application and signing up with emails leaves a "you'll receive an email soon" but no email arrives. Ebook requires email to download, and ebook ends up saying same stuff as on website already.

<comment><AUTHOR> Sorry that you felt that way. We had a few issues with our sign up flow, but that should be fixed now.

The ebook has additional content such as

\- Mitigate Bus Factor

\- Protecting Deep Work

\- Avoiding Engineer Burnout

and explains each problem in detail.

<comment><USER7> Thanks for "fixing" the issue. Now instead of saying "you'll receive an email soon", it now says "Due to increased demand, we've had to place you on a short waitlist. We'll be reaching out shortly with a link to get started."

Please tell people upfront what happens when they "sign up", as right now you're employing dark UX patterns just to collect emails.

</comment></comment></comment><comment><AUTHOR> Haystack aggregates activity in git to give engineering managers more visibility into how their team's work. We came up with the idea when we realized how difficult it is to answer a simple question: 'Is the team doing better than we were 6 months ago?'. We realized how hard it is to not only visualize trends on their team but get actionable insights into the biggest areas to improve. Whether it's spending too much time in code review, taking on too much concurrent work, or even getting bogged down with technical debt; we wanted a tool that can not only help to spot issues but also alert us so we can take action. Introducing Haystack.

<comment><USER8> Very curious now: how do you know what is "too much" time in code review?

Could you provide an example of actionable insight you provide when you have detected that a team is taking on too much concurrent work?

<comment><AUTHOR> In the book you can check the sections _Avoid Burnout: Work Overload_ and _Overload Risk: Too Much Concurrent Work_.

We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".

Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It's good to keep an eye out of the number of Open Pull Requests since it's a great indicator of the team's current workload.

<comment><USER8> Absolutely agreed. None of that is particularly actionable, though. "Don't do the bad thing" is not actionable advice!

</comment></comment></comment></comment><comment><USER9> This isn't so much "show Hacker News" as "tease Hacker News".

Your web site shows me diddly squat. Do you actually _have_ a product? Where's the video walkthrough, or at the very least, some screen shots?

If your product were genuinely useful / insightful (which is very hard to do in this space) then we might buy it. For 400 seats. But it looks like vapourware to me right now. Come back when you actually have something to show the community.

</comment><comment><USER10> Would love if the homepage showed actual screenshots of this product. It sounds interesting, but i'd like a sample of what is to come before signing up.

<comment><AUTHOR> Great feedback. We'll be adding screenshots from the product rather than the book.

</comment></comment><comment><USER11> The pricing page is pretty confusing. Is the price per engineer per month? Whats the difference in engineers vs accounts?

<comment><USER12> I would assume the "engineers vs accounts" is due to the output not being intended for the coders, but the managers. I.e. you only have accounts for the managers, but you price based on how large a team they are monitoring.

(This is just a guess, I have no connection to haystack)

<comment><AUTHOR> You are correct. Accounts are basically number of managers that can access to the dashboard. Engineers tracked is the main business model.

</comment></comment></comment><comment><USER13> Does the development team get the stats from this? I could see it empowering self organising teams.

If not it seems like a horrible product for engineers.

<comment><AUTHOR> The product focuses on giving visibility by visualizing trends, identifing blockers and optimizing code reviews.

As long as the team has a visibility problem Haystack should be beneficial.

We have organizations prefering to use the stats more privately and only mention the necessary stats to engineers. We also have organization using our product in their daily standups. It depends on how the team choses to use it. We have seen both styles work well.

</comment></comment><comment><USER14> What's the minimum size team this tool would be useful for?

<comment><AUTHOR> The problem starts to be big enough when the team has 8 software developers. Usually, the bigger the team, the bigger the problem.</comment></comment>


My name is adam from indonesia,please help me go to CA. - <AUTHOR>

hello my name is adam,i really love learning new things, i can do some code in php,willing to learn other language and i really want to get some startups experience, especially at startup companies at CA especially San Francisco.unfortunately im far away from CA, and in not a good situation that i just can buy plane tickets to go there, i am willing to code or anything at CA for just a living + some learning. im doing things like www.github.com/adamramadhan ( mainly private ), pm me for example, or you can see my online work at www.networks.co.id or talk to me at rama(at)networks.co.id.i know this sounds crazy, but yes im doing everything i could to take a chance. please take this seriously, thanks!. Adam Ramadhan
if there is any question, or suggestion please comment
sorry this is my first post if there is something that i missed at http://ycombinator.com/newsguidelines.html please comment.
*edit thanks for the vote!. it helps me to get more comments. <comment><USER2> I would suggest improving the visibility of your networks.co.id website a bit more. It's should also be in English if you are focusing on an American employer. Also maybe a landing page so we know what it's about and what makes it special without needing to login first. (Maybe also make the load time faster. Took 30 seconds.)

Unfortunately SF/CA is quiet popular and startups are hard. I would assume they're looking for very dedicated people who are masters of their domain. Be prepared to show them that you have both qualities.

<comment><AUTHOR> thanks jim for the comment, 1\. English : yes it should be on English, but yes i know, and im very sorry about it, but i can tell im working on it.

2\. i dont know about it and what makes it special: yes that's why, here its extremely difficult to find people like me to share ideas, and im hopeing working there will make me have some expirence about things like this.

3\. loading: yup its on iix ( indonesian datacenter ) so i am expecting it.

4\. well yeah. im expecting that too. i really want to meet some people to talk to, skype ? ( adamramadhan ) or anything so i know, what do really they need, and how we do things later on. about dedicated, yeah im a bit desperate that is im writing this now at YC. ( ive been here quite long but just for the great news, friends told me to take a leap or whatever they call it :) ).

* and what im thinking is, indonesia is a social addict if you have twitter or anything else, but its epic hard here, we have no trust on the internet ( cause of scammers etc. ) and second i believe no VC will invest on any product, that they dont know or have meet the founder facetoface, not just that, they just dont believe it, especially if we have no experience on startups ( again that's why ).

if there is information about VC or angels that is on indonesia, or currently have done a research about indonesia. please pm.

Thanks again.

</comment></comment><comment><USER3> Dude, i feel you. I'm from Malaysia myself. How is the startup scene in Indonesia. For 250 million population, you could do your own startup there. Hit me up on fretwiz at gmail dot com. Maybe we could do talk or come up with something.

<comment><AUTHOR> emailed bro.

</comment></comment><comment><USER4> How about Singapore?

<comment><AUTHOR> i don't get it, you mean why CA?

<comment><USER4> I mean how about considering other places like Singapore

<comment><AUTHOR> well i do consider singapore, but really, its not as fast as CA. i will post again maybe with my CV :) thanks btw.

<comment><USER4> the startup scene in singapore is beginning to heat up. check out founders institute singapore and jfdi.asia or hackerspace.sg to get a feel for the scene. hope that helps.</comment></comment></comment></comment></comment>


Challenging web application to improve web development skill set - <AUTHOR>

I want to build a web application that will improve my overall web development skill set and that may possibly be put up on github and used in my portfolio. I have some experience in web development using Python(Django) and PHP. Apart from building a CMS, what kind of web application is technically challenging as well as suitably impressive? <comment><USER2> One good step forward would be building a web application that crunches a lot of data from different sources and presents it in an original and practical way. For example, something related to flights and hotels and airbnb.</comment>


Product Image Search - <AUTHOR> http://www.rapfox.com/ <comment><AUTHOR> We develop a product image search website. You can search the similar products in Amazon or Walmart with uploading an image or submitting an image URL. Would you please try this service?</comment>


Pound-250 on your phone replaces phone numbers? - <AUTHOR> http://pound250.com/

<comment><USER2> Betteridge's law of headlines says what?

<comment><AUTHOR> Are there ways to get our own #-something numbers?</comment></comment>


Researchers Discover the Tallest Known Tree in the Amazon - <AUTHOR> https://www.smithsonianmag.com/science-nature/researchers-discover-tallest-known-tree-amazon-180973227/ <comment><USER2> Because a lot of HN readers are located near San Francisco, I thought it would be worth mentioning that this tree is not as tall as the tallest tree in the bay area! There is a 328-foot redwood tree in Big Basin.

[https://blog.sfgate.com/stienstra/2013/09/18/328-foot- redwoo...](https://blog.sfgate.com/stienstra/2013/09/18/328-foot-redwood-is- bay-areas-tallest-tree-11-pic-gallery/)

There are hundreds of amazing, huge trees in Big Basin and I would recommend it to anyone. It is humbling to think that these organisms may outlive you by a thousand years. Even if you aren't into hiking for long distances, or if you are bringing along small children, the one-mile loop trail near the entrance is very nice. So many people come to SF for the tech industry and don't take advantage of the world-class parks that are also in the area.

<comment><USER3> Not to mention, the tallest tree in the world is only a few hours drive away in Sequoia National Park.

<comment><USER4> That'd would be the largest tree by volume, the General Sherman tree is 52,500 cubic feet.

The tallest tree would be Hyperion, a coastal redwood, which is in an undisclosed location in one of the Redwood National or State parks.

Coincidentally the oldest tree in the world is also in California, Methuselah in Eastern California is 4,851 years old.

<comment><USER2> Arguably, a spruce in Sweden is 9550 years old.

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

Depends how you count regrowing from the roots though. Trees can't be too much older because that's around the end of the Ice Age. ;-)

My personal preference is not for a single tall or big tree as much as a sprawling area full of many huge trees. If you're ever in the far-Northern- California area, this hike is amazing:

[https://www.alltrails.com/trail/us/california/cathedral- tree...](https://www.alltrails.com/trail/us/california/cathedral-trees-trail-- 2)

</comment></comment></comment></comment><comment><USER5> It's "88.5 meters, or over 290 feet", for those just looking for the number.

</comment><comment><USER6> There was always a "Tallest Known" tree, a better headline would mention that the new tree was about a third bigger than the previous tallest known, at 88.5m.

</comment><comment><USER7> And... it's now a soy field /s

</comment><comment><USER8> They had better un-discover it before some idiot chops it down just because

<comment> munk-a Or, alternatively, drives into it with their truck while drunk[1].

1\. [https://en.wikipedia.org/wiki/Tree_of_T%C3%A9n%C3%A9r%C3%A9](https://en.wikipedia.org/wiki/Tree_of_T%C3%A9n%C3%A9r%C3%A9)

<comment><USER9> Ugh. Was camping at a small oasis in the desert in Jordan earlier this year. Someone had chopped down all 6 palm trees recently. Somehow it seems so much more tragic when there isn't another tree in 10s of miles.

<comment> seph-reed Few things get my goat like this, but I'd drop all forms of civility in a heart beat just to see the kind of person who'd do that suffer.</comment></comment></comment></comment>


Is-Vegan – Helps you to find out which food ingredients are vegan - <AUTHOR> https://github.com/hmontazeri/is-vegan <comment><USER3> The comments here are depressing. Reminds me of the comments on anything related to bicycling on reddit- extrapolations from generalized and uninformed opinions about choices people make about their own lives. Veganism(I am not vegan) is a personal choice and yet the dissenters here choose to let stereotypes color their opinions on entire groups?

<comment><USER4> I'm an atheist who eats a plant based diet but I didn't start out that way. I noticed that those who choose to eat meat are a lot like Christians in that they become unhinged when an atheist is in their midst. There's this reputation of the preachy hippy vegan, but in my experience it is the other way around.

<comment><USER5> Do you not see the irony in your comment?

</comment></comment></comment><comment><USER6> Doesn't this fall prey to the fact that there isn't a black and what distinction for exactly what's vegan?

There are people that will argue that honey is suitable for vegans: [http://veganbros.com/1-reason-honey-vegan/](http://veganbros.com/1-reason- honey-vegan/)

There are even people that will argue that shellfish are suitable for vegans to eat: [http://www.slate.com/articles/life/food/2010/04/consider_the...](http://www.slate.com/articles/life/food/2010/04/consider_the_oyster.html)

<comment><USER7> There has to be a word for this kind of... comprehensive incompleteness. Being so particular about a vegan diet (for ethical reasons) strikes me as very odd when animal products are in use every day around us by vegans. Do people know we use every part of the proverbial buffalo? Or do vegans often ponder the "ingredients" in everyday objects?

Is vaccinating your kids vegan? Are all vegans anti-vax?

Are soaps, cosmetics, detergents, plastics, tires, and lubricants made with stearic acid and other beef products vegan?

Vegans for ethical reasons seem to only not want to consume a single part of the animal, but consume the rest, which is a pretty large portion, by weight.

And if you're eating organic food, isn't it more likely that your spinach was grown in a bath of bone meal, blood meal, fish meal? Do vegans know how we produce organic fertilizers?

<comment><USER8> > Or do vegans often ponder the "ingredients" in everyday objects?

Yes.

> Is vaccinating your kids vegan? Are all vegans anti-vax?

There is certainly a lunatic anti-vax fringe. But no, not all vegans are like that, even though many vaccines contain animal derived products. I find this interesting: [http://rvgn.org/2015/05/09/anti-vax-and- veganism/](http://rvgn.org/2015/05/09/anti-vax-and-veganism/)

> Are soaps, cosmetics, detergents, plastics, tires, and lubricants made with > stearic acid and other beef products vegan?

No.

> Vegans for ethical reasons seem to only not want to consume a single part of > the animal, but consume the rest, which is a pretty large portion, by > weight.

No vegan I ever interacted with fit this description.

> And if you're eating organic food, isn't it more likely that your spinach > was grown in a bath of bone meal, blood meal, fish meal?

Possible, but if everyone stopped eating those animals, the prices of these products would presumably make their use uneconomical, so promoting veganism would change this.

Though I admit I haven't heard vegans I know ever discuss this particular point. They are probably not aware of how the plants they eat are fertilized.

<comment><USER9> >> tires... vegan?

> No.

Tires are rather hard to eat in general, so I guess that alone makes them unsuitable for a vegan diet. But I suspect that's not the real reason. What is the actual rationale then?

<comment><USER10> "Veganism is a way of living that seeks to exclude, as far as possible and practicable, all forms of exploitation of, and cruelty to, animals for food, clothing and any other purpose." \- The Vegan Society

Veganism for most is more than just food, it's includes seeking to reduce animal exploitation and suffering in any aspect of your life.

People who eat a vegan diet but ignore animal product consumption in leather, wool, cosmetics are not considered vegan by most vegans, it's usually referred to as "plant-based diet".

<comment><USER11> > People who eat a vegan diet but ignore animal product consumption in > leather, wool, cosmetics are not considered vegan by most vegans, it's > usually referred to as "plant-based diet".

Variations of vegetarian? Vegetarianism seems to be solely about diet, whereas veganism is abstaining from animal products in general.

<comment><USER12> Honest question: What are a vegan's views on pets and work animals, such as a horse who pulls a cart to the vegetable market.

<comment><USER13> From what I've seen, pets are not ideal, but also a low priority.

Work animals are usually limited to less industrialized situations, so they're not usually a concern for the same people. I've never known anybody who used a work animal, with the exception of riding horses if you count that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> This is kind of cool. The really good thing is the idea of a blacklist though, but perhaps having a system to tag ingredients would be better - it could potentially help food allergics and stuff as well if we could tag "gluten" or "lacto-ovo" or whatever. Vegans are a small group compared to vegans and people who restrict their diet due to illness.

<comment><USER11> > The really good thing is the idea of a blacklist though

It's not though, because untagged items are assumed to be suitable. This becomes an issue for people with health-related diets e.g. if you have serious food allergies you want to be very very sure your foodstuff does not contain the allergen. So a tag/categories system should have "suitability tags" (whitelist) in much the same way restaurants will have marks for vegan or jain/ahimsa or halal items, not for the opposite.

<comment><USER15> It's is it vegan, not is it allergen okay. I think blacklist is a good tool for that job.

<comment><USER11> I'm replying to a comment which specifically mentions gluten. Gluten is an allergen, and hype aside there are people for whom gluten is an actual health risk.

</comment></comment></comment></comment><comment><USER16> General question: Wouldn't it make more sense to have a whitelist instead of (or at least in addition to) a blacklist?

Moreover, I'd love to see this information maintained somewhere in Wikipedia/Wikidata.

<comment><USER17> It would have the unintended effect of showing people just how restrictive and bland a vegan lifestyle is, turning them off from it.

<comment><USER18> Restrictive? It has to be, by definition.

Bland? Only if you define your meals primarily by the meat they contain, which is still very ingrained in the western approach to food.

So a lot of people think of vegetarian food as "leaving something out" or "taking something away", and imagine a steak dinner where you've simply removed the steak. That is obviously a bad approach.

Focus on what you can make instead.

Disclaimer: I like cooking and eating all kinds of tasty food, and I don't mind at all if it's vegetarian or vegan.

</comment></comment></comment><comment><USER19> Are carnivorous plants vegan?

<comment><USER20> No. For example, figs aren't vegan because the fig tree is fertilized by a wasp, which dies as part of the process.

<comment><USER21> But does not eating figs, mean that that would stop the wasp from fertilizing it?

<comment><USER19> Yes, but eating the butcher would also stop butchering, so I'm not sure I want to plant that idea in the head of vegans...

</comment></comment></comment></comment><comment><USER22> I'll have to give this a package try.

My wife can't eat dairy so we often have to find an item on the menu marked as Vegan to guarantee it doesn't contain any dairy.

Otherwise, it's nearly impossible to get a server to answer the question, "Does this item contain dairy or is it cooked in dairy? Butter, cream, milk, etc."

A common answer we get is, "I don't know if its dairy-free but it's gluten- free."

</comment><comment><USER23> It says "true" for any ingredient it doesn't have in its list (I tried lamb, goats milk, and sausage – all are reported to be vegan).

It would make more sense to just release the JSON list of known non-vegan ingredients. People can use Array#filter and Array#some themselves.

EDIT: it says these are all vegan too: steak, bacon, ham, pheasant, venison, cheddar, mozzarella, ghee, lactic acid, sour cream.

<comment><USER11> > t says "true" for any ingredient it doesn't have in its list (I tried lamb, > goats milk, and sausage – all are reported to be vegan).

Hence the title specifically noting it uses a _black_ list.

<comment><USER23> The HN post says uses the word blacklist, but the library itself works like this:

        isVegan.isVeganIngredient('ham'); // true

<comment><AUTHOR> ham is a product. pork would be the ingredient which is on the list...

<comment><USER24> According to the website they're linking to, ham can also be an ingredient.

Although technically I couldn't find a reference to 'HAM', but rather 'HAM (CURED WITH HONEY, SALT, SUGAR, WATER, DEXTROSE, LACTIC ACID STARTER CULTURE, SODIUM ASCORBATE, SODIUM NITRITE)' [0]

[0]:[https://ndb.nal.usda.gov/ndb/foods/show/82389](https://ndb.nal.usda.gov/ndb/foods/show/82389)

</comment></comment></comment></comment></comment><comment><USER20> Much like anti-malware, you'd be better served by using a whitelist.

</comment><comment><USER25> In their last example, I'd argue "MECHANICALLY SEPARATED CHICKEN" should be in the list with BEEF and WHEY. :)

<comment><USER26> I saw that too, ended up making an issue for it because it spoke to the underlying problem of using exact matching. [https://github.com/hmontazeri/is- vegan/issues/9](https://github.com/hmontazeri/is-vegan/issues/9)

</comment></comment><comment><USER27> I am sorry, but most vegans I know always want to talk about ... being vegan. Kind of like socializing with a vocal religious convert.

</comment><comment><USER28> Serious question: are scallops/oysters vegan ? They have no central nervous system, but are living beings.

<comment><USER29> A lettuce is a living being

<comment><USER11> Indeed, and carrot juice is murder.

</comment></comment></comment><comment><USER30> I find this list very helpful for non-vegans with food allergies. Thank you

</comment><comment><USER31> Wondering how hard it would be to build something that takes a picture of ingredients on a food label for text recognition, which feeds into this... or something like this

<comment><USER32> You don't do that, just use barcode [https://world.openfoodfacts.org/](https://world.openfoodfacts.org/) they also have app in play store with scanner function. It is no brainer to build with existing barcode libraries.

<comment><USER31> oh sweet

</comment></comment></comment><comment><USER33> I'd like and AI that can recognise fruit and veg as you prepare them and weight them and calculates total calories.

a raw fruit and veg white list would be better.

<comment><USER34> There are quite a few scales out here that can measure this exact thing. I know a big point is the AI recognizing it, but as people tend to cook with similar ingredients anyway, it shouldn't be too hard to adapt it as part of a process

Here's just a few examples that I've done no research on and am receiving no compensation from:

[https://www.amazon.com/Greater-Goods-Nourish-Portions- Nutrit...](https://www.amazon.com/Greater-Goods-Nourish-Portions- Nutritional/dp/B00O5U4NDQ/)

[https://www.amazon.com/gp/product/B00Q3IBXUO/](https://www.amazon.com/gp/product/B00Q3IBXUO/)

[https://www.amazon.com/gp/product/B0013IDHTO/](https://www.amazon.com/gp/product/B0013IDHTO/)

</comment></comment><comment><USER21> We built this same function for the paleo world - [http://paleo.io](http://paleo.io)

</comment><comment><USER35> 20 loc, great job man. Keep on sharing, impressive (for vegans)

</comment><comment><USER36> The comments in this thread show:

Trollin' ain't easy

</comment><comment><USER37> Is mutton vegan? Apparently the answer is yes.

<comment><USER38> Is a sheep anything more then a biologically processed heap of vegies?

<comment><USER19> So like chicken, it is merely a higher-order vegetable?

<comment><USER11> So that makes carnivores third—order vegetables?

<comment><USER38> If you get a gnu-hoof onto your head, while hunting, you can actually fall down the veggie ladder- so from third order vegetable, you can return to beeing a vegetable alltogether.

</comment></comment></comment></comment></comment><comment><USER39> Would it be acceptable for vegans to eat animals that died accidentally or without human intervention? There's some valuable proteins in that squashed skunk ma'am

<comment><USER40> Speaking personally (vegan here), that's a good question. Well, vegans tend to be people who think for themselves; there's not one thing vegans think on that or any subject.

I was once in the position of having a couple of sausages on my plate at a wedding, that I knew would be thrown out if I didn't eat them, and I was hungry, so I ate them. The person I was with couldn't believe it, as it seemed to go against my professed veganism. But as eating them didn't add to animal suffering, and they'd otherwise be wasted, it wasn't a conflict for me. I don't think I'd eat them now, as I haven't eaten meat for uh 25+ years. (And never once missed it, surprisingly)

So, sure, I think for vegans generally, animal suffering is the issue, and if somehow that wasn't a factor, the issue is then something like yours would be if you were hungry and came across a person that died accidentally. (See the movie _Alive_ 1993 or read the book)

disclosure: Both my gf and I have shirts saying _EATING PEOPLE IS WRONG_ , featuring the Goya painting of Cronus eating one of his sons.

<comment><USER41> > disclosure: Both my gf and I have shirts saying EATING PEOPLE IS WRONG, > featuring the Goya painting of Cronus eating one of his sons.

Hmm, what if the human being died from roadkill? _Runs_

<comment><USER40> Hehehe well.. I guess that's the point of _Alive_. It's sometimes the thing to do. Depends how hungry you are. If the alternative's dying, most people would.

For some societies, e.g. Eskimo, being vegetarian would be impossible, while in ours, eating meat or animal products is totally unnecessary for almost everyone. And does a lot of harm to the environment.

<comment><USER41> > Depends how hungry you are. If the alternative's dying, most people would.

Yeah, survival movies like Cast Away, Into The Wild, and 127 Hours (I just saw the latter) underline that people do weird things to survive including diet- wise. But I also saw the voluntary coin of the story in the beautiful documentary Happy People: A Year in the Taiga. An animal lives in freedom and relative peace, until it gets hunted and killed. That's different from ~45 days of prison life a chicken here gets. Can't compare that 1:1 and judge the former as non-vegan. Its as close to vegan as it gets due to being natural.

<comment><USER40> Sure. <Intrepidly goes off-topic> .. _Into The Wild_ was just the guy being a spoiled ignorant delusional dick, I thought, really not impressive. _Jungle_ was far better. You almost persuaded me the guy in _127 Hours_ ate his arm off the first time I read that haha. (Um he didn't, did he?!) Am writing this in case you didn't see _Dersu Uzala_ (the Kurosawa version), one of my very favourite movies. The world before cities was a different world, like you say. <Totally off topic> Incidentally, it's my theory that Yoda is taken from Dersu. (As _Star Wars_ is a remake of _Hidden Fortress_ )

</comment></comment></comment></comment></comment></comment><comment><USER42> I'm always interested to see that almonds are acceptable to vegans. Perhaps people should look into commercial beekeeping and how most farmed almonds are pollinated. I'd say that a colony of bees is much more intelligent than a typical cow or chicken.

I'm not vegan btw, so perhaps I'm not entitled to an opinion on this - <USER2> said, I do keep bees.

<comment><USER43> Vegan here.

While I'd argue that stopping to consume meat/dairy/eggs has more impact on animal lives and the planet than stopping almonds because bee are used in pollination, I'm still interested in how these bees a exploited/harmed.

You seem to know more than me on this topic, could you please elaborate?

<comment><USER44> Unless you grow your own vegetables and produce your own fertilizer you are eating plants that grow on bone and blood.

This holds true especially if you are buying organic produce which does not use non-organic fertilizers.

<comment><USER43> I was talking about bees harm.

<comment><USER45> I think bee keepers amputate the wings of queen bees, for example.

<comment><USER43> Please read the thread. Bee harm in producing almond, we're talking about. Yes, it's a bit of a fringe discussion. :) But that's quite common in veganism.</comment></comment></comment></comment></comment></comment>


How Many Nukes Would It Take? - <AUTHOR> http://www.informationisbeautiful.net/2009/how-i-learnt-to-stop-worrying-and-love-the-bomb/

<comment><USER3> Content on the site looks largely copied from other sources. I believe this is the original

[http://www.informationisbeautiful.net/2009/how-i-learnt- to-s...](http://www.informationisbeautiful.net/2009/how-i-learnt-to-stop- worrying-and-love-the-bomb/)

<comment><USER4> I think plagiarism is worth flagging for.

EDIT: And unflagging when someone re-points it to the original link.

</comment></comment><comment><USER5> That's a bit disingenuous - the explosive damage is a tiny fraction of the net destruction a nuke can cause, especially if it's a windy day.

<comment><USER6> Good cite that the nuclear fallout is a big deal?

<comment><USER7> [http://www.amazon.com/Effects-Nuclear-Weapons-Samuel- Glassto...](http://www.amazon.com/Effects-Nuclear-Weapons-Samuel- Glasstone/dp/0160020360)

</comment></comment></comment><comment><USER8> To completely wipe out mankind?

I guess a couple hundred would be enough to nudge a passing rock into an Earth-crossing trajectory. Better yet would be to use the fuel to power a mighty big NTR attached to a comet and use its own water as propellant. This would be a lot more discrete than a big blast, may provide for a quicker intersection and also add a nice oomph to the comet for when it hits the ground. I would also suggest hitting the Atlantic or Yellowstone as nice strategies for maximizing destruction. Hitting Europe could yield the maximum number of deaths in the first hours, but the other two may provide a larger overall devastation.

And nothing would prevent you from using more than one comet. A string of fragments, like SL9, could rain death from the sky very evenly across all inhabited places.

In the end, it all depends on how long after launch you want to wait until the last human is dead. If you require them to be all vaporized a couple minutes by the end of the afternoon, then, perhaps, we don't have enough nukes. If you are a villain with a little more patience, you could use them far more efficiently to first render useless all emergency services (EMPs or stratospheric detonations), then ruining food supplies (even small nukes could start fires) and only then using the remaining firepower to wipe out whoever is left.

It's doable. In fact, we may even be able to wipe out humanity without using any nukes. Some politicians are much, much more destructive.

</comment><comment><USER9> I suppose fallout is not factored into his equation.

<comment><USER10> Nor is population density factored in. Urbanization ought to make it easier to kill the first 60% of the world's population. You probably don't need very many bombs to achieve that. Trying to track down and kill every last human being with nuclear weapons is impractical and beside the point.

If you kill 60% of the industrial, technologically advanced urban centers of humanity, you have essentially destroyed civilization. Who cares if 40% are still scampering around if they have no energy, no infrastructure, no libraries, no communications, no industry, and agriculture spoilt by nuclear fallout and potentially nuclear winter?

</comment></comment><comment><USER11> Looks like we don't have near enough nukes... need to get building!

<comment><USER12> If it makes you feel any better the subsequent Nuclear Winter from the roughly 25,000 warheads in existence would be more than enough to finish off the rest of us. Even if it didn't the 2.5 billion metric tons of soot thrown into the atmosphere would destroy the ozone layer along with any hope of survival.

</comment></comment><comment><USER13> Otavio Good created a computer simulation on what it would take to blow us up. <http://otaviogood.com/RandomStuff>

</comment><comment><USER7> Why not got for the ultra messy fully loaded configuration of the "Tsar bomb" design? 100Mt and a god awful amount of fallout.

I seem to remember that device could take out Belgium with blast but would have killed people way back into Eastern Europe/Russia with its fallout.

<comment><USER8> Tsar bomba was a very clean (as far as nukes go) bomb. Its yield was halved for the test to reduce it even more.

There is little limit to how big you make a fusion bomb. If you have enough Deuterium, you can make is as big as you like.

Or, at least, as big as you can carry.

<comment><USER7> Yes, the bomb tested was very clean because it was only two stage. Fission primary and fusion secondary.

The full 100Mt design would have had the usual 3rd fission stage that would have been _incredibly_ messy. Khrushchev announced they had a full 100Mt bomb even though they could only really test a limited version of the design - <USER2> really a weapon as it wasn't practical for a number of reasons.

<comment><USER8> Keep in mind it's an unusually clean 50Mt device.

Who needs a 100Mt device anyway?

<comment><USER7> Politicians - so they can brag about their H-bomb being bigger than yours.

</comment></comment></comment></comment></comment><comment><USER14> A lot of nukes going off at once would cause a bunch of dust to go up into the atmosphere and block out the sun for a long time. That would kill plants and we would all starve or get sick and die. This is at least according to the history channel.

</comment><comment><USER15> People interested in this will also like _The Road_ by Cormac McCarthy:

<http://www.amazon.com/Road-Cormac-McCarthy/dp/B001OV2GRE/>

</comment><comment><USER16> but I live in Manhattan

</comment><comment><USER17> hit a couple capitol cities and civilization as we know it is gone. thats, like, 20 nukes.

<comment><USER18> I don't think destroying the 20 largest cities would end civilization per se.

</comment></comment><comment><USER19> The damage radius from nuclear weapons can also be greatly reduced by hills and such, so we are even better off than that.

</comment><comment><USER20> ... to get to the Tootsie Roll center of a Tootsie Pop? The world may never know.</comment>


Ask HN: Should I use ReactJS or ReactNative for my Startup - <AUTHOR> I'm building a FinTech platform, utilising a core banking API, but the people I have spoken to have not shown a clear preference for either ReactJS or Native. Neither side ever fully explains why one over the other though. Any recommendation for either would be hugely useful at this juncture <comment><USER2> Without knowing your use case it is hard to say

1) do you want to do more native stuff, do you need the additional performance. 2) or are you just building any web capable user interface 3) do you need to simultaneously push to web and native 4) do you need to push to both ios and Android 5) Finally layer in the talent of your team, what are their strengths, you pick the lowest common denominator.

As you start talking in terms of functionality, platform and team strength you will start to answer that question yourself

<comment><USER2> FWIW, we stuck to web because of all those reasons, maintaining multiple code bases for different devices is not something key to our business at our current team size and strength.

<comment><AUTHOR> Interesting - we would absolutely benefit from the multifunctionality of use on IOS/Android

</comment></comment></comment><comment><USER3> Right now your focus should be get a MVP out. Don't worry about the technology. You can change the underlying tech later once you have a viable business. Pick something which you are comfortable and get the product out

<comment><AUTHOR> The problem I have is that I am comfortable using either, but can't really understand the long-term implication of my choice. Obviously I can change the tech later, but with it being money I see the switching cost being much larger than normal. It's about wanting to minimize risk now as much as possible with view to future development on the platform.</comment></comment>