The Overprotected American Child - <AUTHOR> https://www.wsj.com/articles/the-overprotected-american-child-1527865038 <comment><USER2> [http://archive.is/kWzYa](http://archive.is/kWzYa)

</comment><comment><USER3> _A wallet-sized Let Grow "Kid Card" is meant to be carried by children when they are out on their own, to calm the fears of overly concerned adults._

[https://si.wsj.net/public/resources/images/B3-AQ358_INDEPE_M...](https://si.wsj.net/public/resources/images/B3-AQ358_INDEPE_M_20180531175517.jpg)

^This here.

Except the Concerned Adults will never get a chance to read it because they'll call the police to rescue the 12-year-old dropped off at the mall by her mom.

[https://www.brainchildmag.com/2014/01/guilty-as- charged/](https://www.brainchildmag.com/2014/01/guilty-as-charged/)

<comment><USER4> she left a 12 year old in charge of a three year old at the mall which is a much different situation.

<comment><USER5> 11-13 year old me was regularly walking with my 1-3 year old brother alone. It was in Russia, in the 90s.

<comment><USER6> Same here in Canada, though I wonder if part of the reason older siblings are trusted with younger ones is that parents are less worried the second or third time around—if they're more trusting that "the kids will be alright," by then.

</comment></comment></comment></comment><comment><USER7> You can always tell when someone grew up like this. They are always afraid of doing anything that might even remotely be considered outside the box. They lack that ability and drive to find things out for themselves, and instead rely on others for help and guidance to a fault. Professional occupations are full of these people who were coddled from birth, through college, and straight into a high paying job with zero understanding of how life actually works. It makes relating to someone like that almost impossible.

<comment><USER8> If they ended in high paying profession and are reasonably happy then maybe their decision to follow advice given to them was right.

<comment><USER9> So you are okay with people with no spine basically running this country? Because that's what high paying professionals typically do. It may not be politics, but they typically have a lot of power and their spinelessness impacts a lot more people than just themselves.

I don't think this is at all a good thing.

<comment><USER10> Luckily, these people rarely have enough confidence to stay in positions of real responsibility.

<comment><USER9> #silverlining

But I don't know how much that mitigates the damage. If good leaders spend all their time cleaning up the mess left behind, it goes pretty far in preventing anything really good from happening.

<comment><USER10> Part of being a good leader (IMHO) is realizing you're going to be spending time mitigating the actions of others who derail progress, for whatever reason (intentional & unintentional). You are the tip of the spear, blocking the impediment of progress for those who report to you.

<comment><USER9> I do a whole lot of that. I have aspirations of someday getting paid for (some of) it.

<comment><USER10> Based on my limited knowledge of you from your HN posts and your history in corporate america, you'd be a great fit for a Chief Of Staff role, or any other executive role where you're unblocking progress through mediating relationships (internally) and partnerships (externally).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> As a counterpoint, Canada (and presumably the US too) has seen a dramatic decrease in unintentional injury mortality among children over the last 70 years.

[https://www.ncbi.nlm.nih.gov/pubmed/28026710](https://www.ncbi.nlm.nih.gov/pubmed/28026710)

<comment><USER12> Yes, although that study suggests the big declines have been with things like choking and burns among very young children. I don't think anyone is arguing for more dangerous products or getting rid of safety precautions for toddlers.

That study also suggests more vehicle-related accidents but it's hard to know what to make of that without knowing more about the type of accidents, population patterns, etc.

<comment><USER13> >I don't think anyone is arguing for more dangerous products or safety precautions for toddlers.

Maybe some people think that way. Colloquially, I've heard about a million times Europeans laugh at how ridiculous they think some laws are in that regard, such as Kinder eggs being banned in America.

<comment><USER14> Are kinder eggs actually a dangerous product, or are they just getting swept up by broader American legislation? It's my understanding the American law preventing the importation of kinder eggs is a law against inedible objects from being embedded inside edible objects, which seems generally reasonable. _Generally._ But are Kinder eggs _actually_ dangerous? Are many European children dying because of Kinder eggs specifically?

<comment><USER12> Very unusual but apparently it can happen: [https://www.independent.co.uk/news/world/europe/kinder- egg-t...](https://www.independent.co.uk/news/world/europe/kinder-egg-toy- death-france-three-year-old-french-girl-chokes-a6822626.html)

<comment><USER15> Note she choked on the toy, not on the egg. That could have happened with a US-friendly 'chocolate egg with toy not inside it' packaging as well.

The egg has been redesigned some years ago. The two parts now stay attached together.

</comment></comment></comment></comment></comment></comment><comment><USER16> When I first moved my family (from Denmark originally) to New York we had to put our oldest son in a daycare.

We have always been fairly "free range" i.e. our kids have had their share of bruises from climbing and in general being allowed to do challenging things.

After a week at the daycare my wife went to pick my son up, one of the teachers pulled her aside and told her that they, unfortunately, had to report some of the bruises on his arm or shoulder (can't remember) and that they hadn't said anything about the bruises on his legs.

My wife and I freaked out worried that the social services would come and take him away.

Of course, we soon learned that it wasn't actually the bruises on our son they were worried about but whether we would report them for mistreating our son.

The primary problem in the US is the liability issue which certainly doesn't help.

People in general though are really weirdly paranoid about their kids. I always thought it would be counterproductive for them later in life. Better to fall when you are a little boy than when you are older.

Anyway who knows.

<comment><USER17> This kinda story is my biggest fear - the state interfering with my family.

</comment></comment><comment><USER18> I wonder how much the built environment impacts the independence we can give our children. For instance, regarding the milestone of safely crossing the road that this article mentions, does the common milestone age decrease in more pedestrian-friendly places? It's one thing to cross a one-lane, slow- traffic narrow street in Europe versus a wide, high-speed one characteristic of most American suburbs.

</comment><comment><USER19> The proliferation of these overprotective practices reminds me of the proliferation of simpler practices we impose on kids like showering regularly and wearing clean clothes that we just take for granted now. The link in my mind is how you can pick most any practice that is common amongst a majority of the population today and look back 50, 200, sometimes 2000 years and you can trace it back to a minority aristocratic or ruling class. You know, like medieval kings taking regular private hot baths but this not becoming feasible for the rest of Europe until the last century.

Another commenter made an observation along the lines of you see overprotected children nevertheless succeeding (or failing up, depending on your perspective) professionally as adults. That would make sense if what we are doing is slowly handing down practices from the higher classes to lower. The failing up phenomenon is clearly highly correlated with the privilege you were born into. As everyone becomes relatively more privileged, then practices would radiate out and be institutionalized amongst more of the population, i.e., everyone would start overprotecting because as long as your kid makes it, worse case, they will be able to succeed via the fail up method.

<comment><USER20> It used to be said that certain kings or personages were made of glass and that if you touched them, they would shatter and the kingdom would fall. Much like a regular private hot bath, I fail to see the value of a Glass King.

Once I visited the UK and some kids threw lit firecrackers into my scarf. Then all the adults kept drinking. I assume America is currently behind the times, Europe having since updated the myth to Atomic Motorcycle Danger King.

This failure has something to do with Americans having enjoyed Downton Abbey more than Mad Max: Fury Road. My investigation continues.

<comment><USER21> Don't forget to come back here when you ultimately publish your findings. I know I'll be keeping an eye open.

</comment></comment></comment><comment><USER22> You do wonder how a contemporary American would read Herman Hesse's _Demian_. Emil Sinclair, the protagonist, he had a _protected childhood_!

</comment><comment><USER23> Abraham Lincoln was left in a cabin for 6 months, responsible for his sister, when he was 9 and she was 11. There were some dried berries to eat, and Abraham Lincoln could go hunt with a rifle. The house didn't have power or water.

He turned out OK. Modern social workers would have taken him. Heck, they'd literally swipe baby Jesus.

</comment><comment><USER20> I grew up in the Danger Zone and it was dull.

</comment><comment><USER24> Paywall removed [https://outline.com/E8VPNv](https://outline.com/E8VPNv)

</comment><comment><USER25> Child poverty is the real problem.

[https://peoplespolicyproject.org/2018/02/16/americas- bizarre...](https://peoplespolicyproject.org/2018/02/16/americas-bizarre- income-distribution-for-children/)

<comment><USER26> > "20 percent of US children live in families with incomes below 50 percent of > the national median income"

This is a bizarre metric. If richer families started having children at a higher rate, or poorer families slowed down, the problem would be fixed?

What if we simply cut the pay of the upper 50%, not even redistributing the income? That would lower median income, and therefore shrink the "less than 50% of median income" demographic, "solving" child poverty.

<comment><USER27> Well, yes, if richer families started having children at a higher rate, this would almost fix itself.

Two major problems, though. a) By and large, rich people don't have more children and b) having a child is a good way to destroy your wealth. That is, many that are just barely in the "rich" category won't be once they have children. More, most wealth in the US does not survive generations. (And this is generally agreed to be a good thing, I believe.)

For the second, ok. Cut the pay. How? That sort of suggestion is literally "wishful thinking." If everyone could get by with less money, everyone would. Folks do grab for the advantages they can get, though, and most rise in costs and pay are ascribable to scarcity. Only wishful thinking will make housing and energy costs flat across the board. Same for social mobility. Or physical mobility.

<comment><USER26> Neither of the things I mentioned are a genuine improvement to anyone's situation, yet they would fix this metric.

It's _great_ that the lowest end of the income distribution still has enough resources to have children. It would help no one to reduce productivity.

The metric is probably not the right way of thinking about this problem.

<comment><USER27> They wouldn't, was my point. One actively works against it through feedback systems. Having kids typically lowers your income. The other isn't actually doable.

Is the metric perfect? No. But neither is attacking it in ways that it can't be attacked.

Do you have alternatives? What are they?

<comment><USER26> Food security, nutrition, housing stability, rent burden, medical and dental care, K12 institutions that meet standards, college affordability, etc. Essentially anything focused on objective conditions instead of relative positioning.

The upper half of a country's income distribution can absolutely be more or less productive compared to another time or another place. How would you go about it? Defunding education and research and starting a trade war would be great first steps.

<comment><USER27> I would wager that all of those correlate so heavily to wealth bracket that it would be a wash. And a surprise for you.

That is, wealth is a proxy for all of those measures. And every attempt at fixing those measures has ended poorly. At best.

<comment><USER26> It looks like 8% of children are food insecure, for example. That's awful but we're also a lot further along than the 20% figure in TFA.

<comment><USER27> Is this just a contest to look good? Yes, we have made great progress. I actually think we should celebrate more of it. Some metrics do give pause for concern, though. Long before they give pause for alarm.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


The Uber lesson: behave like an asshole and people never forget - <AUTHOR> https://withoutbullshit.com/blog/uber-lesson-behave-like-asshole-people-never-forget <comment><USER2> Way too early for this. Uber is still a massive success story.

</comment><comment><USER3> No, mostly Uber has fallen victim to a smear campaign.

<comment><AUTHOR> Doesn't the term "smear campaign" imply an unjustified amount of criticism in relation to minor (or even non-existing) missteps? From my point of view, the list of actual missteps and issues is way to long to call it a smear campaign, even though admittedly the sheer amount of sudden attacks can, at first, appear to be out of proportions. At first.

Basically, the impression of a smear campaign doesn't actually make it a smear campaign.</comment></comment>


Cram your test driven development up your ass - <AUTHOR> http://ww2.samhart.com/node/125 <comment><USER2> Have you ever stopped to think that one of the reasons that people evangelize TDD is because it has worked for them and they want to share that with you?

Here are things TDD gets me in my everyday work:

* I don't have to refresh the web page and re-fill in my forms to see if the record saves correctly this time.

* I don't have to log out and log in as a different user to see how things work

* I can plan an API much easier with tests that I write first.

* I know that my features are done when my tests pass

* I can write new tests to prove that bugs my users encounter are really bugs. (You can't get _everything_ tested the first time, but fixing bugs is much easier with tests)

* I can upgrade to a new version of a framework or library because when stuff breaks, I have a roadmap of what I need to change. I can then give a customer an accurate estimate of what it will take to do the work cos I KNOW what I have to fix.

You're doing it wrong if you write ALL your tests first. You write one, and you only write enough test to cover the feature you're implementing. then you implement the code to make it pass. This iteration takes no significant time at all to an experienced programmer, and automated tools can run in the background, monitoring your code for changes and only running the tests your code impacts. Because we're programmers, and we know how to write code that does that.

You think this is a joke? Something to be ignored? Go ask a CPA (accountant) how they do the books.

They sure don't just do the math once and say "trust me I'm really just that good." They balance the books. Dual-entry accounting. They do this because they are disciplined professionals. And people pay big money to accountants to get that right. Your tests shouldn't exist to exist, they should prove your code does what you want. Checks and balances.

Of course the path to this is the same path one takes to learn a new language. It will be slow to start. It was for me, but really, it's such a huge win for my long-term productivity. I am happier, my clients are happier.

Really, what's not to like?

<comment><USER3> Thanks for this. There's only one thing worse than people being religious about TDD, and that's people being religious about TDD being a religion.

Can't we just for once and for all realize that some techniques work well in some situations, and for some people, but that there is no golden bullet?

</comment></comment><comment><USER4> Google got it: [http://126.96.36.199/search?q=cache:http://ww2.samhart.com/n...](http://126.96.36.199/search?q=cache:http://ww2.samhart.com/node/125&hl=en&client=firefox-a&rls=org.mozilla:en- US:official&hs=gwb&strip=1)

Anecdotally, all the guys I know that drone on about BDD/Rspec/Cucumber/TDD Dejour... never actually use it.

<comment><USER5> I like spec based testing because I think the tests you end up producing with it are seriously useful and can actually help guide your programming if you think of the test names (not the actual test code) before you start coding, but I've _never_ been able to actually write tests in full before coding.

I try to think about how I'll test something when I'm coding it (so that it's easy to test), I try to consider what I'd actually be testing in a given piece of code (so the concerns are separated), and I try to stick pieces near each other that are coherent (so they can use similar setup/teardown for a testing context as needed). But I don't have the actual test code down.

I'll fight anyone that says automated tests aren't wortwhile though.

</comment></comment><comment><USER6> I prefer development driven testing or DDT. Don't write tests until the refactoring churn has settled down a bit. Then write unit tests to to document expected behavior and prevent anyone from breaking that code in the future.

<comment><USER7> I like to treat tests as extended compiler warnings. E.g. in Haskell the type system is so strong, that once the compiler stops yelling at you, your code is more often than not correct. To catch the latter case, I like to write properties in QuickCheck.

QuickCheck is a Haskell framework. It allows you to formulate properties about your functions. Like --- given any list of comparable items, `sort' should conserve its length, produce an ordered list, and conserve the occurrence (and non-occurence) of each item. It should also be idempotent.

QuickCheck then generates a lot of random inputs and tests whether your properties hold. You (almost) never have to write test cases by hand. And since Haskell is pure, you never have to care about setting up the right state before invoking your tests.

This approach allows me to code with success, even when I am not intensively focused. (Of course Haskell helps with this even without QuickCheck. Not having to worry about state, assignment, order of execution, loop indices or recursion keeps the number of items I need to hold in my working memory low.)

<comment><USER8> Right. With Haskell and OCaml, a lot of testing can be pushed onto the type system. The language is better about letting you express semantic constraints via types, without making you declare _every single instance of everything_ the way C and its descendants do.

I wrote a QuickCheck-eqsue library for Lua, FWIW: <http://silentbicycle.com/projects/lunatest/> (It's the first released version, and the documentation still needs work...) For table "objects" and userdata, it checks the metatable for how to generate an arbitary instance.

<comment><USER7> > With Haskell and OCaml, a lot of testing can be pushed onto the type system.

Yes. There's even a paper about how to guarantee the balance invariants in a red-black tree with the type system. (Can't find it now, it's probably written by Ralf Hinze.) You can see an implementation at <http://www.cs.kent.ac.uk/people/staff/smk/redblack/rb.html>

</comment></comment></comment></comment><comment><USER9> seriously getting tired of all the people using such inane ways to grab attention so they can rant about something. It's like these people didn't learn how to be polite and kind in kindergarten. Ohhh look at me I'll use as many superlatives and curse words as I can fit in a page and jump up and down and maybe you'll flock to my site. Sam Hart, Zed Shaw, and anyone else who feels like acting out like a 5 year old kid, it's time to go to time out. When you feel like talking like a grown up and a professional, please send HN a link and most of us will be happy to have a friendly discussion and constructive argument with you.

<comment><USER10> Why would you say this article is merely an attention-getting ploy? Seemed pretty sincere to me. And if you can't take "curse words", I can recommend some filtering software.

<comment><USER11> It certainly reads like a deliberately over-the-top rant, mixing in a little comic exaggeration as a spoonful of sugar to help the "TDD won't solve all your problems" medicine go down.

Alas, it's difficult to tell if the strawmen being setting up (e.g., tests preclude estimation) are part of a serious argument or just more dramatic effect to help underscore the general point.

I wish this post were separated into two articles, one of which discussed the genuine tradeoffs of TDD (such as the possibility of painting yourself into a corner), and the other of which contained all the spurious, unsupported assertions (tests cause scope creep, tests are blinders, etc.) One would make excellent discussion fodder, and the other, well, the Delete key is right over there.

</comment></comment></comment><comment><USER12> This guy's rant includes a bunch of things that aren't true. Just to pick the first two I noticed: initial proof-of-concept code doesn't usually get thrown away, and TDD doesn't say you shouldn't change tests when you find out they were wrong. In other words he's guilty of the same overzealous generalization that makes TDD cultism annoying in the first place. I get the feeling he had a bad experience on a project or two and turned that into adamant universal opposition.

Edit: I think the people who oversold TDD in the first place ought to have known better, though. Either they believed their own silver-bulletism or they cynically computed that it was the only way to push something in the corporate software world. I'm not sure which is worse.

</comment><comment><USER13> Sam Hart, whoever you are, you rock. Like any number of other software development techniques, this one has some applicability in some situations, but the superlatives and the dogma with which it is foisted upon the world is unwarranted and insane. TDD (Test Driven Douchebags), you are emperors without clothes.

<comment><USER14> Hey Sutro, the first part of that is a fair enough comment. Testing's great for the problems it solves, and we should simply be aware of when it's applied in inappropriate ways.

But I did want to bring up an issue with the second part of your comment, _TDD (Test Driven Douchebags), you are emperors without clothes._ That added very little positive contribution to the conversation, and dragged your comment's overall value much lower than it should have been.

Just to point out a line from the guidelines... _When disagreeing, please reply to the argument instead of calling names. E.g. "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."_

<comment><USER13> Hey Sgrove, did you read the guideline that recommends flagging items you find inappropriate rather than complaining about them in the comments? Because your patronizing quotation of selectively applied guidelines added very little positive contribution to the conversation, and dragged your comment's overall value much lower than it should have been.

</comment></comment></comment><comment><USER15> I've given up on trying to convince others of the usefulness of automated unit testing. It works wonders for me in my own projects, but the hassle of trying to police my co-workers just isn't worth it at work.

Love it? Hate it? I don't care anymore. I know what works for me and that's enough.

<comment> brown9-2 The problem with this though is when you end up assigned to "their" project, and you curse how un-unit-testable "their" code is. At which point it's "your" code too.

<comment><USER16> or when they are assigned to your project, change something, and break your test suite

<comment><USER15> and don't care, forcing you to either become the unit test cop or just chuck the whole suite and give up

</comment></comment></comment></comment><comment><USER17> I consider myself an X-File TDD'er: I want to believe.

Having said that, articles that are titled "Cram your X up your ass" don't pass the conversational sniff test with me. That's not the way you talk to strangers. So either you have some kind of emotional problems, nobody taught you how to express yourself in writing without sounding like you're seven, or you're trying to manipulate me through hyperbole.

Shame. Bet there was some good material in there somewhere

</comment><comment><USER18> In my opinion, TDD is a double edged sword. Not only does it depend on the persons preference but also experience. [1]

For the experienced or good programmers TDD is a hassle and often results in less efficient code and often in less code. (read: less done in the same time). Later tests are written to cover the code which is of course arguable. [1]

For the beginning or (below) average programmers TDD is great as it often results in much better code quality and helps produce more robust code. [2][3]

Here is an excellent article about TDD and its aspects. <http://use.perl.org/~Ovid/journal/38616>

[1] TDD Effective or is it ? [http://www.theruntime.com/blogs/jacob/archive/2008/01/22/tdd...](http://www.theruntime.com/blogs/jacob/archive/2008/01/22/tdd- proven-effective-or-is-it.aspx)

[2] In favor of TDD, [http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.p...](http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf)

[3] Indications that TDD increases productivity <http://portal.acm.org/citation.cfm?id=1070618.1070834>

<comment><USER19> And bulletproof vests are good for beginning or (below) average Marines, but really good/experienced Marines find them to be a hassle.

</comment></comment><comment><USER20> Why are so many anti-agile/TDD blog posts just silly ranting? I guess we all like to make a little spectacle.

Please, present a more thoughtful argument without the wild-eyed zealotry.

<comment><USER8> Some people think the way to respond to fanatical zealotry and dogma is with fanatical zealotry and dogma _they like_.

The problem is usually with zealotry and dogma _itself_ , though. If you approach the problem from the angle of, "Ok, let's try to figure out where TechniqueX is a good fit and where it's a poor fit," it gets rid of most of the arguing. It also tends to highlight the people who persist in arguing that TechniqueX will solve all problems for all people, all the time.

It doesn't drive blog traffic as well, though. (The middle path usually avoids all that drama...)

</comment></comment><comment><USER21> Ok... At first, a disclaimer: Yes, I program Test first about all of the time (Acceptance tests first, unit tests later), and yes, I do consider this approach better than not writing the tests earlier. (About every nontrivial test tends to fail around 0-3 times during development. Every failing would be a headache later on). So, what are his points?

\- Extra, often useless up-front development This paragraph just makes less and less sense the more I read it. I think he is ranting against testing spikes, because spikes will get thrown away. Well, know what? Spikes are not tested. Spikes are written to see what is possible and thrown away after this.

\- Development with blinders on Well, his point is: you might develop the wrong thing with TDD. Well, duh. I write my tests in the wrong direction, and thus, my code is written in the wrong direction. Good. Throw the tests away. What remains is: my code is written in the wrong direction. Where are tests evil there?

\- Tests are weighted more than the code Here he shows that he has pretty much no clue about the second meaning tests have (besides checking the code a bit): Interface design. By using your unit in a unit test, you can design your interface, and usually, it is easier to get the interface in a nice, usable way, because you are using it already. Thus, if you write the test first, you first think about the interface of a unit (or, at least a small part of it) and later on, you implement this. So, is it bad to think about nice, clean interfaces first?

\- Coding yourself into a corner This is another of those points of the kind 'Your development practice is bad, because you might end up in a dead end'. I hate those points, because they are so general that they can be made about ALL development practices, unless you are god.

\- Narrowly applicable uses I can 'just' test drive my libraries, datastructures and such? Well. That is a very, very bad 'just'. I watched my brother went nuts when he was working on a compiler with several optimizations heavily based on binary decision diagrams. Eventually, I was able to convince him to just write a bunch of automated tests for this datastructure. He wrote them, found several bugs and everything was done in a few days. So, reiterate: testing the foundation of your application can be of gigantic value, far, far more than his 'just' allows, because, if the foundation is broken or shaking, things break down in unexpected and hard to debug ways.

\- Tests solve problems that don't exist His point: Tests don't prevent all bugs in a software. Again, a point I can just answer with 'well, duh.'. The only thing which could prevent all software would be a correct formal verification of the program (which is surprisingly hard). So, this point simply holds for ALL real-life programming practices again.

\- Scope creep Point: Separation of concerns is bad? Management of Requirements is not well done in TDD? Well, if his point is the first one, he would just disqualify himself completely. If his point is the second one, his point is that some code creation strategy has no clue about managing requirements. Well, duh? Managing requirements is in the management area, TDD is in the area of coding things, so they are entirely orthogonal.

\- Inefficiency Yes, I have to give him this point. If you have tests, reworking things can take longer, if the product radically changes. It has to be noted that this radical changes are reached on the assumption of fauly requirement engineering, which will cause major problems with all other development methods either.

\- Impossible to develop realistic estimates of work His point: TDD has no clue about estimations. Well, duh. Estimation is, in the world of Kent and Extreme*, a management and planning problem, and a development strategy has no clue about planning and managing.

Don't get me wrong, I don't want to be one of those "Do TDD or I whack you with a flyswatter"-guys. I am just a humble, fellow programmer who has learned that writing the right tests for the right components early can be a blessing. Certainly, writing the wrong tests or writing too many senseless tests can be bad, I give you that. Tests cannot make all bugs disappead, I give you that (I already had to track down some really nasty bugs which occured due to subtle assumptions which were not obvious from the tets). I also give you that you might write more code, and I give you that some things cannot be tested. But please, give me that my tests catch a lot of stupid errors, like off by one errors, or mistypes. That my tests help me to define the interface I want to used, that my tests tend to encourage modularity, because modularity increases testability. That userstories, and the acceptance tests for them help me to guide myself where to develop to (and yes, once you have the userstory and the acceptance test, it is race-horse style ;) )

<comment><USER22> I don't think you can really give him a point for the inefficiency remark; If something radically changes, and you haven't any automated tests, then you're going to have to manually test the changed code and anything related that it will impact. If the change is something core to the app, then this will mean manually testing the _whole thing_.

If you had a bunch of tests you could just re-run, then re-testing the entire system becomes trivial (it's a given that you'd need to rewrite the tests for the changed parts, but if your tests are written well, then you won't need to rewrite them all).

</comment></comment><comment><USER20> His loony slogans is like the Fox news of the anti-agile movement.

</comment><comment><USER23> Pretty random rant, if you ask me.

<comment><USER23> (which of course you didn't)

</comment></comment><comment><USER19> Translation: _"I don't understand TDD."_

I like how he links to the Wikipedia article on Horse Tack, but doesn't bother to back up any of his claims.

<comment><USER10> Isn't that a "no real scotsman" argument? Anyway, what's there to understand? TDD plainly means writing tests before writing the implementation, and he's railing against the whole concept.

One also wonders how, or by whom, you might wish his argument to be "backed up". A compelling argument should stand or fall on its own merits.

<comment><USER19> How about his mentions of evidence to the contrary being backed up by actual _evidence_ to the contrary. Or the speculative weaker points like, "TDD wrecks time estimates", "inefficiency", and "scope creep".

Heck, in "Tests solve problems that don't exist" he sidesteps right past the _real_ problem that TDD solves: refactoring code without inadvertently breaking something else.

So yeah, "No true Scotsman" would ever rail against TDD without proper evidence.

<comment><USER24> TDD doesn't help prevent breaking things when refactoring, _automated testing does_

In that section he's complaining specifically about the type of tests that TDD results in -- that they strongly tend to test for totally unrealistic bugs, structural crap that would only possibly come up when writing the code from scratch.

He's not anti-test, he's anti-test-first.

<comment><USER8> I think a lot of people do what zach did, though - because of hype, perhaps, they're loose with terminology and conflate TDD with automated testing in general. Then, people argue until they're blue in the face, because they're talking about completely different things. (This happens with OO all the time.)

<comment><USER10> Yeah, very true, especially with things like Rails where the community is somewhat .. faddish. Someone whose first real exposure to programming was Rails - and there are a lot of such people, coming from other web development areas - might well confuse TDD with automated testing itself. The two are taught/preached as one and the same.

<comment><USER2> The Rails community does tend to be a bit more interested in the "new shiny", but the heavy weight placed on testing has done wonders for improving the quality of the work I do. As for automated testing and TDD being considered one in the same, I believe there's a strong argument to suggest that they are. Allow me to explain.

When I am coaching, mentoring, or training people, I have no problem with bringing up both TDD and automated testing at the same time.

* We write a failing test

* We then fire up the automated test runner

* We make changes to our code until the test passes

* We repeat, adding new tests.

I can show that our automated test runner catches anything we do wrong _immediately_.

I don't believe you get the full benefits of TDD if you don't automate the process, and you can't have automated testing without good tests. I used to write lots of code without tests and I paid the price - lots of wasted time tracking down bugs, delayed releases because I could't figure out why my new feature broke old stuff, the usual stuff.

Investing time and energy learning how it's supposed to work has been the most valuable thing I've ever done for myself, my clients, and my company. The process I teach others is the process that I learned, and I feel that we're all much happier developers for it.

I just want to come back to the point I made earlier... a lot of the people who evangelize this stuff believe in it not because it's "cool", but because it has actually saved us and our projects. If you want to separate the hype machines from the true believers, ask one to show you. The ones who believe in it will almost certainly devote their time to show you how they do it. I know I would.

<comment><USER8> I agree with you that it can be an excellent way to develop, but in some languages the same testing-as-you-go is typically handled by the type system or other tools instead* . While I'm quite convinced of the value of automated testing, TDD is _just one method_ , and one better suited to e.g. Ruby than languages like OCaml. (This is sometimes lost on its most vocal proponents.)

In all fairness, the language about type systems is often impenetrably mathematical, so I'm not surprised that the parallel isn't clear. (I _really_ like OCaml, so I tried reading _The Definition of Standard ML_ to get a better understanding of the language family. _Wham, brick wall._ Then again, I'm not a mathematics grad student...I studied history.)

* Which is just a different way of communicating semantic constraints ("this is never null", "this list always has at least two unique UTF-8 string values", "this can only be used on writable files", etc.) to the language and having them automatically checked.

<comment><USER2> Your point about typing is well put. However Ruby has strong typing, but has no compiler to check. So you're gonna have tests for that, but the existence of a compiler and strong typing enforced by said compiler is not an excuse to avoid testing. My tests check logic. If I decide that User.to_string() needs to return "User: Brian Hogan <email@example.com>" then I write a test for that first. Then I go make to_string() do what that test says. Seems trivial, but no compiler's going to catch if I implement that wrong.

That example seems trivial.. but here's a real example: I had a very complex health insurance system I helped write. A mistake in the formula could have cost someone thousands of dollars in premiums. We asked the end users to give us names of people and their health scores. "Jon, with this height, weight, bmi, and all this other criteria should get a score of x"

Writing the test cases first helped out a ton. Even with a compiled strong typed language, I still would have needed tests to make that work.

And it's been six months since then and I've heard of no issues with the calculation routine. From that, I'm reasonably happy with test-driven development and that's why, regardless of compilers or type systems, I still find it vital to my success as a developer.

<comment><USER8> Oh, I'm definitely not saying that it _replaces_ automated testing. A mixed approach is almost certainly best. I like randomized testing, too. Just, (conservatively) half of the things people write as unit tests could be expressed in the type system in OCaml* . If not correct for all possible input, they prevent the program from compiling, and lead you to everywhere the property doesn't hold. That's arguably a stronger guarantee than passing tests for known input->output at runtime. (In all fairness, much of it can also be done with Java or C++'s type systems, but without type inference it becomes incredibly tedious, and ML type constructors are far more direct than wrapping things in classes all over the place.)

Type systems are _also_ "just another tool", though, and more useful in some cases than others. I wonder how many other properties about a program could be declared, inferred, and verified for the complete domain of input at compile time -- this is safe to use concurrently, that is fully isolated from non- deterministic input, this can have its results memoized, those can fully evaluated once at compile time and don't even need to run in final executable, etc. (Haskell can do some of this, but I don't like lazy evaluation as a default, among other things.) Playing with Prolog and logic programming has gotten me curious about how far that sort of analysis could be pushed.

About the insurance example -- I know exactly where you're coming from. I've done something similar for the architectural industry, and a huge suite of example results helped tremendously.

* And very likely Haskell, SML, Clean, and others, but my "advanced type system" experience is mostly with OCaml.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


F.lux major update - <AUTHOR> https://justgetflux.com/news/pages/v4/bigupdate/?v=4.43 <comment><USER2> Windows 10 and OS X now offer "flux" natively, as does iOS (after the whole debacle of forcing fl.ux out of the app store and then implementing the feature into the OS for themselves).

I was a loyal f.lux user for a long time, but now there's really no point.

Additionally, f.lux doesn't (perhaps didn't, I should check the changelog on this new version) take into account OS-native color shifting and (at least on Windows) caused "night mode" to be enacted on top of the OS' own "night mode" leaving me with a... let's just say very drab screen as a result.

<comment><USER3> I thought the same thing, so I disabled f.lux and turned on Nightshift on Mac OS. To my surprise, nothing happened. It turns out that it doesn't work with my monitors for some reason. They are non-Apple and thus not supported. Back to f.lux which works perfectly. Additionally, f.lux has more con-figurability, it's easy to disable quickly if I need to for a short period, etc.

I personally prefer the OS doing less, but more stability and better, and allowing me to customize through apps. I feel that over the last few years, Mac OS has gone "wide" with features and has gotten less stable.

<comment><USER4> > doesn't work with my monitors for some reason. They are non-Apple and thus > not supported.

I've got a 2012 Mac Mini with Dell display connected over DP, and night shift just works. So at least some non-Apple displays are supported. Not sure what's the difference here.

</comment></comment></comment><comment><USER5> The best tip I ever got (other than to use f.lux at all) was to set it to 5800K during the day. It's an almost unnoticeable difference, but makes a huge improvement in reducing my eyestrain.

<comment><USER6> I've found the lower the value the better for reducing eyestrain. Slowly lowering it down in about 100K chunks it doesn't take long to get used to each step. I currently have mine at 4900/4200 (day/night).

<comment><USER7> Why so high at night? I do fine with candle setting at 1900K (though I turn my brightness up a notch from lowest).

<comment><USER6> The night value hasn't bothered me so I haven't given it much thought. I set it to that value when I first started using it as lower just looked weird at that time. I should probably try lower values at night and see if it effects my sleep.

</comment></comment></comment></comment><comment><USER8> Something I've been pondering recently: If there is broad acceptance of the research, and sufficient industry agreement to justify programs like f.lux and other night lights, should web developers like myself be more considerate as to what colours we splash over our websites?

I ask this as someone whose most recent project is bathed in a deep blue background, while posting on a site that is comfortably orange.

<comment><USER9> > should web developers like myself be more considerate as to what colours we > splash over our websites?

Please please don't write grey on white. It's illegible. I have to ctrl+a all the time. Black on white, like most books. Also take into account that the user may disable websites picking their own fonts. I do this because I don't want to download them fonts for no apparent reason and because it's usually illegibly thin type. Thin type + #ddd color only helps in the process of becoming blind.

Off topic: while at it, I wish pages used the first screenful for more meaningful information.

<comment><USER10> I don't know why this was downvoted. For people that have astigmatism grey on white is not very pleasant for reading.

</comment></comment></comment><comment><USER11> Windows 10 has this built-in now, and I use redshift on linux. I don't see how f.lux is going to compete against Windows 10's built-in feature tbh.

<comment><USER12> With W10 you must enable location service to enable "sunset to sunrise". If you keep LS disabled you can only mechanically set up & down times, which slowly drifts by seasons.

With f.lux you can insert your location manually.

<comment><USER13> What is the difference? You're still revealing where you are--although of course if you enter it manually you can enter random coordinates in the same timezone.

<comment><USER14> The difference is giving it to the F.lux team specifically vs giving it to MS and other supported programs on your PC.

I'd rather just give it to F.lux. MS will use it to sell me Bing search results.

<comment><USER13> Ah, ok, it's a global setting.

I thought it was something like when websites ask for your location temporarely.

</comment></comment></comment></comment></comment><comment><USER15> Excellent! Great update. I run F.lux all the time, day or night. I recently attempted to switch to Night Shift but it's much less effective.

May they manage to find a rewarding and stable business, they've done my eyes and I an important service. Before F.lux, I had strained "computer eyes". It was a drain on my energy and made me grumpy. It is no more.

</comment><comment><USER16> I switched to ligthbulb in the meantime ([https://github.com/Tyrrrz/LightBulb](https://github.com/Tyrrrz/LightBulb)) Haven't really looked back, and I actually prefer it.

<comment><USER17> Thank goodness, I've been looking for a f.lux improvement that would actually let me control exactly when and across what duration the shifts happen. The f.lux developer is very stubborn about wanting it synchronized to sunrise and sunset, regardless of any user preference or reason (third-shift work, daylight saving time, working the same hours on June 20 and December 20, etc) for any other use case.

<comment><USER18> > The f.lux developer is very stubborn about wanting it synchronized to > sunrise and sunset, regardless of any user preference or reason (third-shift > work, daylight saving time, working the same hours on June 20 and December > 20, etc) for any other use case

Ohhh, this explains so much. I uninstalled for the same reason as you and figured it was surprising the program shipped with such a locked-in scheduler as the only option, when there would invariably be a fair bit of overlap between people who'd like to manage their lighting and people who want more custom setups than the incredibly constrained one offered.

I'll look into Lightbulb, I have a piecemeal self-rolled fix - which is usually my favorite solution :P but still worth replacing with a maintained app if one exists.

</comment></comment></comment><comment><USER19> You can donate via PayPal off their install page.

[https://justgetflux.com/news/pages/welcome/](https://justgetflux.com/news/pages/welcome/)

</comment><comment><USER20> I have to assume that this burst of activity came because Apple and Microsoft are both now just do what f.lux does in the OS (Apple fans will be familiar with the term "getting Sherlocked"). Can't see how f.lux is going to survive long-term, to be honest.

<comment><USER5> I still use f.lux because it has way more options and control than the built in Apple product. I wish I had it on my phone too, but I just suffer with Night Shift instead.

<comment><USER21> Sorry, what exactly is causing you to "suffer"? It's an option to warm up the color temperature on your screen.

<comment><USER5> The lack of programmability, like I have with f.lux.

I can only make it come on and off at a certain time, and the color temp is just a slider with no numbers.

With f.lux, I can have day, evening, and night, and it adjusts automatically to my location. When I travel, I have to adjust the time on my phone.

All little things, but it shows how f.lux is polished and Night Shift is not.

<comment><USER21> Um, your time updates as you cross time zones on a cellular phone. Why would you have to change Nightshift? 20:00 is 20:00 no matter where you are.

<comment><USER5> Because time zones span ~15 degrees of longitude, and the sunset can be up to one hour difference between each side of the time zone. Also, I move north and south during my travels, which also changes sunset, and is not reflected in the time zone.

<comment><USER21> Those are some very specific requirements then, you are indeed suffering, I hope you find peace.

<comment><USER5> My main gripe is that it only has a single color temp setting. I use three with f.lux and it makes a huge difference. 5800K during the day, 3400K in the evening (between sunset and 11pm) and 1900K after 11pm, until an hour after sunrise.

My phone is jarring in the evening because it's way cooler than my display.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> The fact that our eyes adapt so well to the light temperature change by flux makes me wonder if there are other tricks we could be burning into operating systems to reduce eye strain or other benefits for health just by applying filters or alter treatments to the display. It seems like "health-oriented graphics methods" is pretty uncharted territory.

<comment><USER23> I'm pretty sure there are a whole host of color schemes that apps/sites/terminals are supposed to use because they decrease eye stress.

</comment></comment><comment><USER24> Does the Linux version work with Wayland already?

Edit: Apparently this is now built-in to Gnome 3.24+, using the name Night Light. I am happy camper again!

</comment><comment><USER25> Do I still need to set a location or can I just use timed based? Most annoying part of flux...

<comment><USER26> Using location is more accurate as depending on how far away from the equator you are light levels can change drastically.

This covers some of the details around it: [http://www.ccfg.org.uk/conferences/downloads/P_Burgess.pdf](http://www.ccfg.org.uk/conferences/downloads/P_Burgess.pdf)

<comment><USER25> I know the reasoning, I guess I'd just prefer to set it manually based on when I'm actually using my machine. As in, near the end of my usage at night I want it to be very orange no matter what the time is.

<comment><USER27> I agree. I live in Iceland and during the summer months it does nothing.

</comment></comment></comment></comment><comment><USER28> Very happy to see this, as I use f.lux less often than I'd like because of some shortcomings (slowdown when transitioning, and lack of customization). What I'd really like to see is direct and unbounded control over brightness and red-shift separately. At night flux just doesn't go dim enough for me, and the 1200k loses more contrast than I think it ought to.

<comment><USER28> I had a chance to try out the update at home and I'm happy with it. There's an 800K color temperature now that's accessible using the Alt+Shift+PgDown shortcut, and many more dimming increments (Alt+PgDown). I'm at 800K and the most dim it will go without entering "darkroom mode". I still wish I could make it more dim, but this is a good improvement.

</comment></comment><comment><USER29> This new interface is the most confusing UI yet.. Also, the update managed to "forget" all my existing settings..

</comment><comment><USER30> Is F.lux open source software? I don't see a link to source code on their site and a quick web search didn't turn anything up. I wonder why they would lock down development when they could get a lot of great community support (not much to lose; it's free and they just ask for a $5 donation).

<comment><USER31> Unfortunately not. However, there is an open-source project Redshift[1] that I'm sure would be greatly welcoming of community support :). It also has a GTK client, etc.

[1] [https://github.com/jonls/redshift](https://github.com/jonls/redshift)

</comment></comment><comment><USER32> I prefer OS X's nighttime mode. Except that it always forgets to turn off when on Sunset to Sunrise mode.

</comment><comment><USER33> I'm constantly surprised at how many designers use flux and its alternatives. I can't stand the color shift and I'm not even a designer. How do you put up with it?

<comment><USER34> I use the 'turn flux off for an hour' feature when I'm actually thinking about colors in the evening. There's a lot of parts of the process where color accuracy isn't important.

The fact that the color change makes drawing a little bit harder may also serve as a gentle reminder to get the fuck off the computer and go to bed instead of staying up until the wee hours of the morning.

</comment></comment><comment><USER35> I love f.lux, but it disappeared from my work computer recently, and the f.lux site is blocked on our network now. I'm not sure why we would have flagged the program and/or site as bad. It seems like a pretty harmless utility to me, and I don't recall there ever being any issues with it. Oh well. At least I can still use it on my home PCs.

</comment><comment><USER36> I've been using this version on macOS for probably over a year now, I'm not sure exactly how long.

I don't believe I opted into any betas, and I couldn't find a similar featureset for Windows/Linux.

Still, good news for anyone running Windows/Linux, I'm actually going to go update ASAP.

<comment><USER37> Yeah, I've had this version for a while on Linux. I believe it was just the Windows build that was behind a few months.

<comment><USER36> Weird, I didn't have it available on Ubuntu whatever I use at work either...

</comment></comment></comment><comment><USER38> Looks like their appcast hasn't been updated for 4.0 yet. I'll wait for that so I can install it with Homebrew.

[https://justgetflux.com/mac/macflux.xml](https://justgetflux.com/mac/macflux.xml)

</comment><comment><USER39> Hue integration is one of the most interesting applications of IoT that I've read about in a while. An entirely obvious application once I think about it, but something I never thought about until now. Looking forward to trying that out!

<comment><USER40> Looks like for now, Hue integration is only available in the Windows build: [https://forum.justgetflux.com/topic/1912/f-lux-and- philips-h...](https://forum.justgetflux.com/topic/1912/f-lux-and-philips-hue)

</comment></comment><comment><USER41> Installing the last update was an awful experience for me. I was prompted to update at night and during the upgrade f.lux turned off without warning and I got blasted with brightness. I hope they handle this better in the future.

</comment><comment><USER42> The supposed performance improvement is really the only thing I care about as I am happy with the amount of red shift I currently have. It's nice they are bothering to integrate more pro-sleep functionality for those who care though.

</comment><comment><USER43> When I originally set up flux, it had the default night time colors _way_ too orange, somewhere like 1900K. This made my eyes strain quite heavily and I had to turn it up to a usable level. Has this been changed/fixed?

</comment><comment><USER44> >Better performance with games (no stutter)

Hopefully this fixes my main issue with f.lux. It seems to cause severe input lag during transitions, making my Windows machine nearly unusable.

</comment><comment><USER45> Have they added custom times yet? Last time somebody requested that feature the dev basically told them to f themselves.

</comment><comment><USER46> When does the new version become available?

<comment><USER47> Now. Go to the homepage to download.

<comment><USER48> The mac version is still the old one look like.

</comment></comment></comment><comment><USER49> Awesome!!! It works with my display adapter finally!

</comment><comment><USER50> Was expecting them to announce a $5 monthly subscription to use the new version too. Lol. "SOFTWARE SHOULD BE SUBSCRIPTION"</comment>


Ask HN: If you could work for any company who would it be any why? - <AUTHOR> <comment><USER2> deepmind, openai, or robotic companies like Boston dynamics,

or my own if I have a good idea.

I'm tired of solving engineering problems, I don't seem to learn too much, because the difficulty of engineering problems come from unfamiliarity or complexity of a system. for most of the time, solving engineering problems doesn't really mean making any break through.

I hope to work for a job that requires some domain knowledge. deep learning is what I'm very interested in.

</comment><comment><USER3> my own :)

<comment><USER4> Get on it. ;)</comment></comment>


Kubernetes 101 - <AUTHOR> https://luminousmen.com/post/kubernetes-101 <comment><USER2> I loved your pedagogy and graphical assets. Can you share what's your charting / illustration tool? I'd not found something like that to train my staff. Thanks in advance, I'm a follower! ;).

</comment><comment><USER3> What does the "dead" label signify ob the sibling comment?</comment>


Git workflow for mobile development - <AUTHOR> So, we started using gitflow workflow with our server side as well as mobile development. It works out really well with server side code, since there is test coverage and with build automation, feature branches get merged into development branch as soon as they are tested ok. Unlike mobile development, since the changes are live as soon as you wish to (no time to deploy apart from build and testing), you can quickly test if there are any bugs in code you pushed and quickly make changes. So this workflow works out really great for server side development. However we are facing issues with mobile development with this workflow.
Now there are two major issues that we are facing with this workflow. One is that suppose we merged some feature into development and later figured out that there are lot of bugs in it. Now it can't be pushed further, whole development cycle is stuck because that code is already merged with development. This is the reason we started forking feature branches from master rather than development as at least individual feature branches will have fully working code. One way is that each feature can be separately distributed to team members to test and only then will be merged to development but it's very cumbersome
Another problem is since base code with every feature branch is from master branch and it has to be merged with development, there are lot of conflicts. Earlier when we used to fork from development, we used to regularly merge development branch with feature branches so there were no conflicts but can't do that anymore. So now to fix conflicts, we create another temporary branch from feature branch with which we merge dev code, fix conflicts and put that as pull request which is again little cumbersome.
Is there a better workflow for mobile development that people have adopted or even some practices that can be followed to solve these problems? <comment><USER2> I work with feature branches for iOS development as follows:

Whenever I want to create a new feature or fix a bug, I create a new branch. I am responsible to rebase and keep the branch up-to-date until it is reviewed and merged. When the branch is merged into master, using @KrausFX's fastlane tools we automatically build, test, submit a build to testflight and create a pre-release with the build number on GitHub. The appropriate people then review the App and submit a release for review by Apple whenever they're ready. Once the App is approved and released we create the corresponding official release on GitHub.

Works well and keeps us productive.

As I may have overlooked something, could you pinpoint where in this workflow you would have issues?

<comment><AUTHOR> Since we are in early stage of our app, we release android app once every two days. Most of the problems are because since features need to built faster, we are lacking in sufficient tests. Also multiple people end up working on same file. Major problem is that if some spurious code goes into development branch and other people create feature branches from it, it becomes a problem. I think using --no-ff flag to merge and the using revert to remove such code should work well. Will try that out.

</comment></comment><comment><USER3> I don't understand the issue, in mobile development you can also test changes as soon as the build is done and see if there are bugs. You can also publish (at least for Android) directly from CI to play store Alpha/Beta/Release and have that go straight to QA. You can build a branch on PR and have a link sent to your QA team via slack.

> One is that suppose we merged some feature into development and later > figured out that there are lot of bugs in it. Now it can't be pushed > further, whole development cycle is stuck because that code is already > merged with development

Why is buggy code being merged in? Why isn't it reviewed,covered with tests and tested manually?

Also, you can checkout commit before merge, create a new branch and continue development without any issues.

<comment><AUTHOR> Yeah I agree we are lacking in sufficient testing right now because since we are in early stage of app development, we are building features at fast pace. One solution is to merge changes using --no-ff flag and using revert to remove changes if there is major bug in that merge.

</comment></comment><comment><AUTHOR> Don't know if it fits well but its a nice article talking about why github doesn't use gitflow workflow

[http://scottchacon.com/2011/08/31/github- flow.html](http://scottchacon.com/2011/08/31/github-flow.html)

I am not denying that automated tests are not necessary but I believe that continuously deploying code and then fixing bugs that occur in the code is atleast faster way to code.

Github flow certainly doesn't work very well with mobile development main reason being you cant deply code to production continuously but I was wondering if there is some middle way

</comment><comment><AUTHOR> I found a new workflow called skullcandy workflow which has separate QA branch. So trying out that for a while. Only downside is you have to do accounting of which branches were merged to QA and were successful and then again merge them to dev, instead of reverting from dev.

[http://blog.endpoint.com/2014/05/git-workflows-that- work.htm...](http://blog.endpoint.com/2014/05/git-workflows-that-work.html)

</comment><comment><USER4> This isn't a git flow issue, unless I'm missing something. If anything, you can more easily revert a bad set of changes by simply reverting the merge commit.

Front-end testing is hard, but you need to figure that out. Ruby Motion can come in quite handy for that.

<comment><AUTHOR> Yeah mostly issue is with front end testing. Also we were not keen on using revert so never really tried it. Is this correct way to revert a merge commit? Because it looks pretty complicated to revert merge commit on development and when need to push those changes back, you need to first revert the revert commit and then merge the branch back.

[https://github.com/git/git/blob/master/Documentation/howto/r...](https://github.com/git/git/blob/master/Documentation/howto/revert- a-faulty-merge.txt)

<comment><USER4> If you're using github, you can also go into the merged PR and hit revert, assuming conflicting changes haven't been made.

Otherwise you can do `git revert SHA -m 1` and fix conflicts / commit.

</comment></comment></comment><comment><AUTHOR> [https://www.reddit.com/r/AskProgramming/comments/45qftw/git_...](https://www.reddit.com/r/AskProgramming/comments/45qftw/git_workflow_for_mobile_development_xpost_rgit/?ref=share&ref_source=link)</comment>


Auto-Compile Sass Files with Sass 2.4 - <AUTHOR> http://nex-3.com/posts/90-auto-compile-sass-files-with-sass-2-4

<comment><USER2> A much needed feature (especially as I don't really want to use Compass). I already coded my way around it though with my "watch and do" script: <http://gist.github.com/286060>

Auto-building will be cool and I initially thought I'd use it.. but I realized having Safari automatically reload the page I'm working on whenever I save my Sass or HTML file is too convenient to give up my script (for now).

</comment><comment><USER3> HAML and SASS have made web design enjoyable again. The time dealing with the learning curve is quickly paid back in increased productivity.

Using Rails and Sinatra for web app development or StaticMatic for static page development handles all of this for me, but the auto compiling will make it easier for prototyping.</comment>


Ask HN: What would be the ideal company to work for? - <AUTHOR> <comment><USER2> A consultancy organized along the lines of the Plausible Labs Cooperative. [https://plausible.coop/about](https://plausible.coop/about)</comment>


Internet Explorer 10 For Windows 7 : I Uninstalled It  - <AUTHOR> http://www.toptrix.net/2012/11/Internet-explorer-10-windows-7.html

<comment><USER2> So, this guy was lazy and refused to fix a bug, and get some hits on his blog in the meantime. Mission accomplished, I suppose.

</comment><comment><USER3> The OP's blog renders wrong because it's forced into IE7 emulation mode by _his own HTML_ : "<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>"

Who intentionally breaks his own website and then complains about it?

<comment><USER4> Somebody who wants to manufacture a bogus reason to criticize Microsoft, which is apparently a common thing to want to do on HackerNews.

<comment><AUTHOR> Not at all. I am the real fan boy of Microsoft. Really.

</comment></comment></comment><comment><USER5> You didn't really give a good reason as to why you uninstalled it.

Did you switch to 9 or 8, and why are either of them better in your opinion?</comment>


How To Explain Your Web 2.0 Job At The Pub - <AUTHOR> http://www.techvibes.com/blog/how-to-explain-your-web2.0-job-at-the-pub

<comment><USER2> I use a 3 tiered system of responses. I gauge my response against the person I'm talking to and am pleasantly surprised when someone actually wants more detail.

My responses to "What do you do for a living":

"Computers" I use this response when talking to someone at a party who is obviously uninterested, or someone that I think has no idea that this could mean a lot of things. Also, to extended family though it may require an explanation as to why I can't fix their computer.

"Software Engineer" This is the answer I most expect to not get more questions on, unless speaking to another software engineer. This answer almost immediately causes the conversation to shift in another direction. I can see the mild panic behind their eyes that I might, in fact, elaborate.

"UI Developer" When talking to someone in design or the rare individual who asks for more details then "Software Engineer" It is usually accompanied by a more detailed description of my job.

</comment><comment><USER3> I had this problem for a long time too, and part of it was that as an entrepreneur it might come up that you run your own company, but saying "I'm a CTO" translates from geek to human as "I'm a self-important and probably delusional douchebag."

So my solution is saying "I work with technology startups." I let them tailor the interaction by leaving it open. They are free to say "Oh... cool," or to ask variously detailed questions, which I'm happy to answer. Takes the guess work out of the whole interaction.

</comment><comment><USER4> Being a poor student who scrapes a living through Rentacoder, Its difficult to explain further without getting lost when someone raises an eyebrow at _freelance web design_.

<comment><USER5> Do you mind if I ask how much $$ you make for that and how many projects you can handle at a time?

<comment><USER4> Given the diverse range of economical backgrounds coders come from for Rentacoder projects, Making being undercut quite a common occurrence, your looking at $15-20USD per hour on a run of the mill job, Providing you have decent enough ratings and offer a decent comment to show your competence and experience.

Personally I prefer to have no more than 3 projects happening at any one time, But its a risky job to have as your primary income, So you take what you get, when you get.

Its definately a great place for making some quick cash on the side. And I've always enjoyed being able to have a bash at new challenges I might not find elsewhere.

</comment></comment></comment><comment><USER6> This isn't just constrained to programmers. I have a friend I met while she was a physics post-doc at MIT and who now is a professor at Cornell and runs a large research group. When asked what work she does at parties she answers "teacher".

</comment><comment><USER7> Too complicated. When someone asks me what I do, I've found that 'I program computers' works for virtually any development job. If you give anything more specific, they probably don't care and wouldn't know what the difference is anyway. If they want to know more specifics, then they'll ask and you can nerd it up.

<comment><USER8> I prefer "design" or "build" or "make" software. Saying "write code" or "program" makes me feel dirty because I'm terribly insecure and don't want people thinking I'm a typist.

But, I make two exceptions:

1\. When I'm speaking to engineers I prefer to say I "engineer software" just to get a rise out of them.

2\. When I'm speaking to the elderly, I've learned "I tell computers what to do" is all they care to hear.

<comment><AUTHOR> As far as my grandparents know, I run the internet.

</comment></comment></comment><comment><USER9> If you need 5 steps to explain you job at the pub, then your audience will be having another beer before you reach Step 3.

A pub isn't much different from an elevator, which isn't much different from anyplace else.

The Universal Answer...

People have Problem <X>. My company provides them with Solution <Y>. I do <Z> to help my company do that.

</comment><comment><USER10> "I'm a programmer"

Then I answer questions if they have them. Which they usually don't.

</comment><comment><AUTHOR> I found this post funny because I was in this situation yesterday. I'm trying to explain that I'm an SEO, and then I have to tell them what SEOs do, then they ask for tips, etc.

Next time I'm playing unemployed.

<comment><USER5> So what does an SEO do other than what should be the normal/standard practice of a website designer? :P

<comment><USER11> I met a very cute SEO consultant at a bar who explained that all she did were the basics: position keywords prominently, use meta description and keywords, move your site name to the end of the page title because you're going to win search results for that anyway, etc.

<comment><AUTHOR> Yes, and she can charge a fortune for it. Most people don't understand these concepts (people who hired her, for one).

</comment></comment></comment></comment><comment><USER12> As a SEM professional I usually defer to the catch all "online marketing" response. If the conversation goes much further than that, I usually follow it up with "you know those little ads on Google?", which usually opens up the floodgates for a discussion of how I am ruining the internet for everyone.</comment>


Nvidia  Officially Releases CUDA 6 – Powerful New Features - <AUTHOR> http://devblogs.nvidia.com/parallelforall/powerful-new-features-cuda-6/

<comment><USER2> I have been wanting multi-device CUBLAS for a long time. Along with shared memory, this is going to make a lot of applications much more powerful, quickly. A major hindrance to getting started with CUDA can be dealing with memory allocation in the device. That is also made more complicated when dealing with threads and multiple devices, especially when workloads have to be somewhat tweaked depending on the number of devices available in a given box. Nvidia did good things here.</comment>


Showscan - <AUTHOR> https://en.wikipedia.org/wiki/Showscan <comment><USER2> One of the Showscan demonstration theaters was in a Chucky-Cheese Pizza restaurant in Northern Virginia, in the 80s. I went to see the demo film and was amazed. I've been a fan of high frame rate ever since. Sadly, Hollywood seems uninterested. I saw the first two Hobbit films in HFR and liked it. I believe James Cameron wants to use it for the next Avatar film. I hope they release an HFR version that is NOT in 3D. That wasn't done for the Hobbit and I think that was a mistake.</comment>


Is `let foo = () = foo;` good or bad? - s-p-n I'm playing around making a language.
I'm a firm believer that recursion is good, but there's a lot going in in `let foo = () => foo;`.
First, I think `let foo` is interpreted, and `foo` is immediately hoisted, as it will be defined.
Second, the value of foo is known to be a function.
That function code isn't evaluated at all, and here's where I have several thoughts going through my head.
I was wondering, at compile-time, should a language bother checking identifiers? I don't particularly like hoisting and think values should be evaluated before declaration begins to take place. I've always liked recursion, but at the moment I thought: "if I want to do recursion, I shouldn't implement any id-validity checking in functions."
Let's say, let bar = () => foo(); (function() {
  window.foo = () => console.log("hi"); }()); bar(); // console logs "hi"
So, at compile-time it seems complicated to check for the existence of "foo" in the function "bar". I mean- sure, it's possible- but it seems like a losing battle for a compiler to chase identifiers all around the program, simply to check if they will exist when they are needed.
So I suppose one solution is to just let undefined identifiers slide unchecked until runtime.
Another solution is to check as much as possible, unless or until the existence of an identifier could potentially come to being during input.
For example, the compiler could see that an array of links in a search-robot might be built after visiting a url that has n links. Perhaps a function is generated for each link, so the compiler might see `links[i].visit()` and think, "Well, that function 'visit' isn't ever created, but links is an object populated by a resource, and maybe that resource provides the necessary API at runtime to make ..visit() defined." Designing a compiler like that seems.. not simple.
So ya, idk. Thoughts? <comment><AUTHOR> For identifier validity checking and recursion, you should look into let-rec and its differences from ordinary let. As for API checking, you would probably be using typeclasses or interfaces to specify an API. Even if the individual URL _objects_ do not exist yet, a URL _type_ should exist (at compile-time) that defines what operations are valid. I don't think that a separate function would need to be generated for each link, but you can build arbitrary operations at runtime with first-class functions.

<comment> s-p-n Thanks! I'll look into let-rec, I've never heard of it before :)

Everything in my language is an expression, so I guess you could say every literal in the language is first-class.

I was thinking for i/o, I could use promises. The promise would resolve to whatever type makes sense for that resource- defined either by a library or by the program.

Of course, that brings up "arbitrary operations at runtime". My target after transpiling is JavaScript, which has a wonderful JIT compiler already. I need to learn source mapping and stuff so I can make error-tracing work nicely, as it's simply not possible to catch any possible error at compile-time.</comment></comment>


Cisco declines disclosure grace period, bug gets released - <AUTHOR> https://code.google.com/p/google-security-research/issues/detail?id=460 <comment><USER2> This is not a particularly interesting bug. The editorialized headline suggests that the interesting part about this story is that Cisco elected not to ask for a disclosure grace period. So? That's how it's supposed to work: get the risk information out in public as quickly a possible. Cisco did the right thing here.

</comment><comment><USER3> If I read the comments I see: "Cisco originally aimed to get the release of the patch for the 22nd September, however due to testing issues this has been postponed until the 29th which would fall outside of the 90 day disclosure window. Cisco were informed that a grace period exists for this exact situation and they could use it if they requested. However in this case Cisco has declined to use the grace period."

So it sounds like they were aware of the issue, communicated out a fix would be in place but 7 days later than the expiration. Someone didn't want to budge those 7 days and released it anyway.

Not that its a big flaw but it seems a bit inflexible. Companies as large and as old as Cisco don't move very fast..

<comment><USER4> Previously, Google has been getting negative feedback for not giving a grace period in the event of an imminent update being released to patch a vulnerability. As a result, they added a grace period to prevent such situations from happening. In this instance, Cisco, the vendor, communicated that they would not want to use the grace period and published the vulnerability on their own website despite Google communicating that they could have waited.

</comment></comment><comment><USER5> Heh, I use this software.

is it only Windows 8 that is affected? we don't have that deployed anywhere at my company. :)

<comment><USER6> [http://tools.cisco.com/security/center/viewAlert.x?alertId=4...](http://tools.cisco.com/security/center/viewAlert.x?alertId=41136)

"At the time this alert was first published, all versions of Cisco AnyConnect Secure Mobility Client for Windows were vulnerable." and no mention of Windows 8 specifically in Cisco's page suggests that this works on any version of Windows where the application runs.

</comment></comment><comment><USER7> Why would Cisco not automatically opt-in for the grace period? Defies me. May be I am missing something.

<comment><USER8> An impulsive company would automatically opt-in for the grace period, using the rationale that the less people who know about the bug, the less damage can be done to Cisco and their customers.

A wise company would consider disclosing the bug even without a patch, using the rationale that their customers deserve to know that the bug exists and make decisions and implement workarounds to mitigate it.

In other words, public disclosure may be in the best interests of Cisco's customers.</comment></comment>


Going to Silicon Valley? Plan carefully - <AUTHOR> http://www.louisdorard.com/blog/silicon-valley <comment><USER2> If you're pushing a real-estate tool, why on earth would you go to Silicon Valley looking for customers (as opposed to investors)? It's got one of the most dysfunctional, abnormal housing markets in the US, so any success you have in working with realtors there is unlikely to translate to broader market success. I'd have thought you'd have learned more by rolling up at realty industry conferences, working with professional bodies, etc...

<comment><AUTHOR> Hey James, thanks for your feedback. Which part of the US do you think we should have gone to instead? Are there any conferences and professional bodies you could recommend us to check out?

<comment><USER2> Unfortunately I don't have any deep insight into the US realty industry, beyond having interacted with it as a customer recently. As a Brit who relatively recently came over to the US though I can tell you that from a European perspective there are probably a lot of things about the US realty business that might surprise you and affect how and to whom you might need to market the product. The seller's agent/buyer's agent split; realtor licensing and the consequent franchise and network-marketing business models, the web of different state regulations, the MLS system, "open houses", the role of online listing sites in real estate sales, and some rental markets; the dominance of craigslist in other rental markets...

</comment></comment></comment><comment><USER3> Having visited the bay area from NYC, the point about travel time (1 hr on average) is useful. Before visiting the area, I had heard that things were more stretched out than on the east coast, but I still underestimated how much time we'd spend in transit.

In NYC, I take a lot of meetings (more than 5 a week on average), but rarely need to spend more than 30 minutes in transit. I'd guess the average is closer to 15.

<comment><USER4> Down in the Metro DC area it's not uncommon to spend 30 minutes to an hour travelling between meetings. In that way Southern Maryland and Northern Virginia are very similar to SV.

</comment></comment><comment><USER5> The title confused me a bit there - I thought the author was recommending against going to SV

<comment><AUTHOR> I have to admit that the title is provocative. I do think that going to SV can be a waste of time/money in certain situations, but hopefully those tips can help :)

<comment><USER5> Oh yeah, these are definitely a great bunch of tips :)

<comment><AUTHOR> Thanks sn0v!

</comment></comment></comment></comment><comment><USER6> Also, if you're into the nerdly arts I recommend as part of "sightseeing" (all clustered pretty nearby):

Digital Guru Bookstore (and Madhuban has a great Indian buffet almost next door); Weird Stuff Warehouse (be sure to go in the back room); and there's a Fry's is close to those 2

Then slightly distant from those:

Unix Surplus (tell them Hacker News sent you and you might get a used hard disk or GBIC as a door prize, or ping me and I'll organize a time for a geek tour)

<comment><USER7> I live in the midwest and have been to SV many times but never heard of any of these places. I'll definitely check them out the next time I'm out there -- especially Unix Surplus which looks like it's just a few miles up the 101 from where I usually stay. Very cool, thanks!

</comment></comment><comment><USER8> _Another thing that surprised me was how people made themselves available to talk to us. We got quite a few meetings on relatively short notice, and it made it possible to learn a lot in a short amount of time. ... It may also be that they 're investing some of their time to discover, before every one else, new stuff that may be useful to them. Or it may be that they're just happy to help out!_

No doubt a little of all of these things. But Americans in general try to be helpful. If anything, people in the Bay area are a little more stand-offish, although this is not taken to an extreme. The helpfulness only extends so far for strangers (and even close friends) -- there often comes a point where people start to get a little impatient. This helpfulness is to be contrasted with the superb hospitality shown in some parts of the world. Americans are helpful but not very hospitable. Be prepared to fend for yourself here for anything beyond the basics.

</comment><comment><USER9> _" As I said in the beginning, we were surprised that in our industry people weren't as tech savvy or tech-minded as we thought they would be. ... Another thing that surprised me was how people made themselves available to talk to us. We got quite a few meetings on relatively short notice"_

Could be that you were meeting with the wrong people - those with the time on their hands to meet over what is frankly a very unlikely opportunity for them (if you're based in France, and they do Realty in SF/SV etc) or are having to be so opportunistic are probably not the people who are going to be the best placed to help you. Those that can make that golden connection, have they key knowledge or can make something happen may be simply too busy to meet someone without a strong endorsement within their network.

I wouldn't tarnish all of SV as being "not tech savvy" simply from the bench of folks who would take a meeting like this.

<comment><AUTHOR> I want to stress that I am only talking about my own experience and this isn't a study on SV. The comparisons I make are also based on the various tech meetups and events I have been to (unrelated to VA-Live).

</comment></comment><comment><USER10> No knowing how Hacker News is moderated, it'd be great, though, if someone would change the title to "Going To Silicon Valley? Suggestions on Preparation."

Then I wouldn't get cheesed off when I clicked on it, because I wouldn't click on it.

(Oh look, it happened while I was posting! Thank you Intarweb Gods).

<comment><AUTHOR> Just changed the title based on everyone's feedback. Thanks for reading anyways!

</comment></comment><comment><USER11> "Going to Silicon Valley? How to maximize the time you have."

<comment><AUTHOR> My intention was to have people really question whether it is the right time for them to go. Anyone else think I should change that title? If so, I'm happy to experiment...

Is it ok to change a title after the link has been posted?

<comment><USER12> I think your connitation might be getting lost in translation

not sure if "don't waste your time" is an american idiom or not

it comes off as "don't bother" which I don't think is what you're trying to convey

<comment><USER13> It's a UK idiom too, I also misread the title & quite a bit of the article to mean 'Don't bother going to SV'. I thought it was a bit odd he gave a bunch of tips after saying don't go.

</comment></comment></comment></comment><comment><USER14> > They are developing a click-to-chat solution for the Real Estate sector that > offers 360° virtual tours of properties, guided in real time. It's a B2B > technology product in an industry that's not particularly tech-savvy.

I guess it's somewhat fashionable to suggest that the industry you're targeting isn't tech-savvy, but I don't see how anyone with knowledge of the market can credibly suggest that this is the case with real estate.

<comment><USER15> My company does websites for real estate agents. I'll verify that in BC at least, realtors are not tech savvy. They'll ask for a wordpress site because someone told them that wordpress is easy, but it's still not easy enough, so they'll call us to make changes like uploading a photo or a blog post.

Many of them still write property descriptions as if they're paying by the letter in a dead tree publication - "2bdrms, 3bthrooms&snny blcny", randomly interspersed with lines like "this exciting property features exciting features like a sunny sunroof and utilities are included." Some of them are not just un-techsavvy, they're nearly illiterate.

<comment><USER14> This is an example of another fashionable exercise: assuming your customer/client base is representative of an entire market. The National Association of Realtors has over a million members. Some are obviously going to be savvier and more successful than others, but on the whole, real estate is an industry that has embraced technology and realtors use technology in a variety of ways to market listings, service their clients and complete transactions more efficiently.

You should consider that "knows how to use WordPress" is _not_ the litmus test of tech savvy. There are a good number of folks out there who have made millions online who probably don't have any experience with a CMS.

</comment></comment></comment><comment><USER16> Also, if you're going to be taking 2-3 meetings/day in the Peninsula or South Bay, rent a car. Public transit is ok in some cases for a routine daily commute, but it's a huge pain for going from one office to another mid-day. In SF itself it's different, since ~everyone is in SOMA, which is all walking distance.

</comment><comment><USER17> In a similar vein, here's some travel tips I put together for people planning a trip to SV: [http://www.ldn2sfo.com/travel- tips.html](http://www.ldn2sfo.com/travel-tips.html)

</comment><comment><USER18> Good general advice about doing business and meeting contacts in the US.

Bad link baiting title.

<comment><AUTHOR> Thanks Iwan. Do you think I should change that title after the link has been posted?

</comment></comment><comment><USER19> Oh man, good blog post, but I opened VA-Live's website in a new tab and it scared the living daylights out of me with that awful music. I thought we weren't supposed to do things like that anymore...

</comment><comment><AUTHOR> Just updated the title based on everyone's feedback — thanks for your suggestions. Will update the blog itself soon!

</comment><comment><USER20> Nice check list. Thansks

<comment><AUTHOR> You're welcome qwerta!

</comment></comment><comment><USER21> Misleading, link-baiting, title.

<comment><USER22> Maybe. He's foreign, remember, so "don't waste your time" isn't the same familiar euphemism it is here.

<comment><AUTHOR> Thanks for backing me up bennyg :)</comment></comment></comment>


Ask HN: Why don't we use ICBMs for transportation? - <AUTHOR> Seeing the progress of spacex's VTOL rockets has made me wonder what's stopping us from using rockets to move things and people (if they don't mind the g-forces) around the planet.
I believe I read somewhere recently that you can move an ICBM between any two points on the planet in less than an hour.  Seems like there are things - and people - we'd pay a big premium to move around the planet that quickly.
Is there some fundamental reason that makes this not work? <comment><USER2> > Seeing the progress of spacex's VTOL rockets has made me wonder what's > stopping us from using rockets to move things and people (if they don't mind > the g-forces) around the planet.

People, and very many things, definitely "mind the g-forces".

> I believe I read somewhere recently that you can move an ICBM between any > two points on the planet in less than an hour.

You cannot.

You can use an ICBM to deliver a payload between any two points on the planet in that time, which is considerably different than moving the ICBM.

> Seems like there are things - and people - we'd pay a big premium to move > around the planet that quickly.

Part of the "that quickly" is that, well, impacting at multiple km/s. There's not a lot of things or people that would survive being delivered in that manner.

> Is there some fundamental reason that makes this not work?

As covered elsewhere in the thread: cost (ICBMs aren't cheap), fragility of most of the things you'd want to deliver (and most of the places to which you might want to deliver them), and the fact launching ICBMs is a good way to start a war?

</comment><comment><USER3> At $7 million per message (Minuteman per-unit cost) I doubt that there is a large demand - a slower but cheaper option is better for most deliveries, unless you want to deliver a nuke to someplace that doesn't want it.

</comment><comment><USER4> I think the Russians get a bit twitchy when we start firing off ICBMs.

Also, they cost about seven million dollars each and one use only.

</comment><comment><USER5> Assuming you could find a practical use for spending that much money, the United States and Russia are watching to shoot down or retaliate against exactly this kind of vehicle, 24/7.

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

[https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...](https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alarm_incident)

</comment><comment><USER6> The rocket equation. Your missile would have to be able to slow down when it arrived, which means carrying a lot of fuel. That makes it very heavy, which means you need more fuel for the launch, and you end up with a monster rocket that's far more expensive than an ICBM.

</comment><comment><USER7> Not sure I am ready for the first FedEx branded rocket heading into Memphis.

</comment><comment><USER8> Something like that was tried before, with limited success. [http://en.wikipedia.org/wiki/Rocket_mail](http://en.wikipedia.org/wiki/Rocket_mail)

</comment><comment><USER9> Besides the expense, I can think of two reasons:

\- It has to be able to slow down before impact.

\- To other countries it would look a lot like a nuclear missile.

</comment><comment><USER10> [http://en.wikipedia.org/wiki/Spaceplane](http://en.wikipedia.org/wiki/Spaceplane)

</comment><comment><USER11> Cost.

</comment><comment><USER12> Similar to why we don't move people with the teleporter in star trek. It kills you ripping apart the atoms in your body then reassembles your now dead body at the destination.

</comment><comment><USER13> For one, an ICMB gets there in an hour by hitting the ground at a couple thousand miles per hour. Sub-optimal for cargo. :-)</comment>


Is Editing Humanity the Solution to Society's Problems? - <AUTHOR> https://medium.com/@CM30/is-editing-humanity-the-solution-to-societys-problems-3413391487cb <comment><USER2> Human gene editing is the future. Currently, we are scared that we don't know enough so everyone is against it. I hate the idea but at some point, we'll feel like we know enough and someone will feel like there's a "good" reason to do it. Once it starts it will be hard to stop since we'll try to fix unintended consequences in the same manner. And yes, there are always unintended consequences.

Also, given the human characteristic to separate into groups. I see a future where there will be human and transhuman communities. It's not out of the realm of possibilities that there will be human vs transhuman wars.

</comment><comment><AUTHOR> Part of me regrets this article because of how insane it is with the futurism and what not, but part of me also thinks it raises interesting possibilities about how tech could fix social problems in a few decades/centuries time.

And come on, real life macros/automation would be such a neat concept.</comment>


PHP Sucks - <AUTHOR> https://evertpot.com/PHP-Sucks/ <comment><USER2> I run a shop that sometimes works on PHP projects. It's true that the reputation of the language causes issues.

It's hard to hire, people who are competent software engineers don't want to work for a PHP shop - because of the reputation - and people who are willing to work with PHP are often people who can't write good quality software.

It's not that good/great software can't be written in PHP it's that over the years it has gotten a reputation as a terrible language due to the propagation of bad coding practices and some quirks of the languages that haven't been true for 8+ years but people associate with PHP still.

</comment><comment><USER3> Would maybe consider "The effects of PHP's bad reputation" as a better title.

</comment><comment><USER4> [http://phpthegoodparts.tumblr.com](http://phpthegoodparts.tumblr.com)</comment>