An open letter to Paul Graham - <AUTHOR> https://medium.com/@RickWebb/an-open-letter-to-paul-graham-3d4f3369fe76#.69wt9xmbz <comment><USER2> Between this essay and the one I saw on HN over the weekend [1], I feel PG really got this essay wrong.

Both response essays have really compelling points, and even as I read PG's original, I felt like he was catastrophizing.

Something that none of the above mention is that, as "job eliminators," we need to start considering how to keep the people who have no chance at a job can continue to live reasonable lives.

California, despite being the home of Silicon Valley, still has "truck driver" as the most common occupation as of 2014. [2] In ten years we'll probably be seeing the first self-driving trucks; in 25 the occupation will likely be gone for any runs that don't require humans to unload the truck at the other end (home or small commercial delivery drivers, movers, etc.; a lot of trucks just move goods from one manned loading dock to another).

Before you say they'll work at some new job, what other jobs at that skill level won't also be automated by that time?

We need a serious movement toward guaranteed income. Capitalism needs consumers; if most of the population can't get jobs, who will be the consumers? And what will happen to those people? Without guaranteed income, they'll be desperate; I don't exaggerate in suggesting that the poor will eventually get to the point of trying to overthrow or attack the rich. A brief look at the fall of various past civilizations will reveal many parallels, and even if the rich _could_ sufficiently arm themselves to resist, living in cyberpunk-style walled enclaves, that's not a future I would want to live in.

Making sure everyone has enough to live a decent life is the only path I can see to a humane future.

[1] [http://cryoshon.co/2016/01/02/a-response-to-paul-grahams- art...](http://cryoshon.co/2016/01/02/a-response-to-paul-grahams-article-on- income-inequality/)

[2] [http://www.npr.org/sections/money/2015/02/05/382664837/map-t...](http://www.npr.org/sections/money/2015/02/05/382664837/map- the-most-common-job-in-every-state)

<comment><USER3> On the surface I want to support BI, I really do. But how does it work other than as a _replacement_ (not supplement) to existing social welfare programs? Give someone enough money that they can rent a room, buy food, and cover their healthcare (whatever cost that may incur). The numbers required to do this in the US when you eliminate all social programs seem doable. Most people pay less in taxes, money gets distributed directly to the people, and it seems fine.

So what happens when someone uses their entire BI allowance on Fireball and lottery tickets? The two choices seem to be "they die" or "we don't actually eliminate social service in exchange for a guarantee BI."

<comment><USER4> The BI proponents typically forget that there's some average amount of money that would work for everyone, but there is clearly a power-law at the expensive end of social services.

As an example, I have an extended family member who was born happy and healthy but contracted meningitis at 5 years old and was severely mentally handicapped afterwards. For the past 20 years, his parents have provided his extensive care buoyed by social security disability, but they won't be around forever, so then what? Giving him or some agent on his behalf $12k/year isn't going to come close to paying for the level of support that he needs.

There are millions of people in similar situations that could not survive without significant amounts of money which is almost entirely funded by the government. Just assuming that this will be covered by any basic income is silly.

<comment><USER3> So at that point it basically becomes a "you only get BI unless you need more," which is really just what we have now but everyone gets a $12k/yr kicker on top, right (to use your figure).

<comment><USER2> Throw in single-payer to cover health issues ( _and_ include mental health issues) and you'll cover 98% of the problem.

People play PowerBall to extremes and similar because they're desperate.

I doubt $12k/year would be sufficient, BTW. You want people to be able to live a decent, if spartan, life on BI, and at $12k I think they'd be forced to decide between starving or extremely poor living conditions.

Probably $18k/year would be an absolute minimum, plus allowances for kids (how to handle kids is a HUGE question, well outside the scope of this post).

The amount you earn could vary by chosen living area, in proportion to living expenses. Maybe not 100% proportionally; if an area has 150% of the cost of living, but only pays you 125% more than the nominal amount, there would still be a pressure to move to less expensive areas, but more expensive areas wouldn't de facto exclude people on BI.

There needs to be extended discussion on the details. I don't know nearly enough to be able to have all of the answers. But it seems like the answer is out there, if enough people get together to work on it.

</comment></comment></comment></comment></comment><comment><USER5> > The crux of your argument — that "Ending economic inequality would mean > ending startups" — is both a straw man (no one's advocating eliminating > income inequality completely) and untrue (people can still pursue whatever > they want — they just have to pay more taxes on it.)

Will you get a 80% tax rebate on your opportunity cost if your startup, as most do, fails? Of course not, which means you've dramatically shifted the EV of the proposition.

</comment><comment><USER6> >In the real world you can create wealth as well as taking it from others. A woodworker creates wealth. He makes a chair, and you willingly give him money in return for it. A high-frequency trader does not. He makes a dollar only when someone on the other end of a trade loses a dollar.

But wait a second, the woodworker doesn't get the wood from something? Which happens to be a natural resource? So he's just siphoning wealth from the earth to his own pockets (by adding some more value).

<comment><USER7> You could argue that the _woodcutter_ is "siphoning wealth from the earth to his own pockets". Or, you could say that the woodcutter is getting paid for his labor.

But the woodworker buys the wood from the woodcutter, rather than cutting it himself. He creates wealth by making a chair that is more valuable than a block of wood.

And I would say that "siphoning wealth from the earth to his own pockets" is antithetical to "adding some more value".

</comment></comment><comment><USER8> > Literally no one in America, save for a very few on the fringe, is talking > about "eliminating income inequality." People are seeking to and talking > about reducing income inequality.

This is disingenuous. On social and mainstream media the issue has been framed as "income inequality is a problem" not "excessive income inequality is a problem."

<comment><USER9> Unless you are trying to be obtuse, or hate brevity, the statement "eliminate income inequality" and "eliminate excessive income inequality" read exactly the same. No one is arguing for a move to a fully socialist state, so "eliminate income inequality" in the US means "tax the highest bracket more" and/or "add a higher tax bracket and tax it more" and/or "add a wealth tax". If you honestly look at the arguments rather than just arguing petty semantics you'll be better off in the long run.

</comment></comment><comment><USER10> Paul Graham is absolutely right, and those who argue against him are doing so from a position of close-mindedness.

First of all: it's irrelevant to the principle whether the goal is to "eliminate" income inequality, or "reduce" it. This being HN, I won't elaborate on why. This place should be above pedantry and people coming from all viewpoints should be able to see why it's the case that if one is bad, so is the other.

Second, Graham is not arguing that the pie is getting larger. He is saying that the type of capitalistic market-based activity that increase income inequality also increase the size of the pie. Sure a new regulation that increases legal fees for the average person but increases the wages of highly educated legal professionals will be a zero sum reallocation of the shares of each slice, but that is not what PG is talking about when he says he's in the business of creating income inequality.

<comment><USER9> It's not clear that reducing income inequality is bad, please explain. The arguments against eliminating income inequality rest on the idea that people won't do a hard or bad job if it didn't pay more than other easier or nicer jobs. While there are very likely jobs that people wouldn't do for a small multiplier on some ideal base pay for some ideal good job. Increasing marginal tax rates, which is the actual way that actual people suggest we handle income inequality, doesn't actually put a cap on pay.

<comment><USER10> I'm not going to rehash PG's entire article. Feel free to address all of the arguments in it so we can avoid an endless, unconstructive merry-go-round.

<comment><USER9> And I'm not going to point-by-point refute arguments that aren't particularly convincing, but here's some thoughts.

> Closely related to poverty is lack of social mobility.

It's not just closely related, when considering income inequality the two converge. It's simple arithmetic really. When poverty wages are a lesser multiplier (i.e. income inequality were less) of wealth wages (let's say 2), then it's obvious how to lift oneself out of poverty, split a home with another person earning an income.

> you don't have to grow up rich or even upper middle class to get rich as a > startup founder, but few successful founders grew up desperately poor

Sure, but a rich founder has a clear advantage, in the same way that a founder at Harvard has a clear advantage. It's a lot easier to ask a friend/colleague/parent for money than a stranger.

> For example, let's attack poverty, and if necessary damage wealth in the > process.

Yes. The way we attack poverty is to spend money to improve schools, spend money to improve transit, spend money to provide food for low cost. Where does that money come from, taxes. If we just talk about fixing poverty, we run the risk of not actually spending money and fixing the problem. Ignoring the greater context of politics, and the almost 100% sign on of republicans to the Grover no new taxes pledge, in order to actually get a mandate to fix anything, the alternative has to be upfront and direct about taxes.

If you'd like me to address arguments directly feel free to respond with something less dickish than telling me to read an article that I've already read.

<comment><USER10> >Sure, but a rich founder has a clear advantage, in the same way that a founder at Harvard has a clear advantage.

PG didn't suggest otherwise. He didn't say that wealth doesn't beget wealth. He said the absence of it does not prevent one from generating wealth.

He's not arguing against the idea that entrepreneurship contributes to income inequality. He is saying that the manner in which it produce income inequality is not harmful to society, because incomes are becoming more unequal by individuals generating wealth, and not by siphoning existing wealth that others have.

This is just example of how you misinterpret his arguments in a mad rush to defend economic orthodoxy.

<comment><USER9> Could you please respond to my whole comment rather than cherry picking one thing I said.

> wealth doesn't beget wealth

The return on an investment in the S&P 500 over the past 50 years undermines this.

> absence of it does not prevent one from generating wealth.

Prevent is such a strong word. I'm not technically _prevented_ from breaking the longest free-fall record. However, I do not have 1000s of skydives under my belt or connections in the community of record breaking skydiving. While I'm not technically prevented from getting those things, I'm behind the curve compared to someone that has those things.

> the manner in which it produce income inequality is not harmful

But he doesn't really present any real evidence that this is the case. Now, I agree, that some startups produce new wealth as some percentage of the wealth that their founders, investors, and employees reap. But it's obviously always more complicated than that. Take, for example, the Microsoft office suite, which by almost any measure created an immense amount of wealth. However, it also made a large number of jobs obsolete, and thus "redistributed" the wealth from people working typist style jobs. Take for example, smartphones, which again, have created an immense amount of wealth. However, they also allow smaller independent contractors who would otherwise have rented an office space, and hired a secretary, to simply use their smartphone to manage their day, thus "redistributing" some amount of wealth from a lower-middle class job to an upper-middle class job. Now, obviously, I've ignored that maybe, the loss of these jobs created new jobs that the workers who were displaced could do, but given that PGs argument was basically just "We make the pie bigger" with almost no evidence, my argument of "It's really not that simple" with some examples should be at least equally convincing to you.</comment></comment></comment></comment></comment></comment>


Test-driven development: A great idea hiding behind a terrible implementation? - <AUTHOR> https://itnext.io/test-driven-development-is-dumb-fight-me-a38b3033280c <comment><USER2> He's right, but also wrong. It really depends on what you are developing.

TDD is awesome when fixing bugs (as opposed to writing features), when writing straight up business logic (especially when there are a lot of edge cases) and when you know exactly how something is going to work.

It's really bad when doing anything that requires exploration and research (which is the example in the article).

<comment><USER3> I work for a Danish municipality and we buy quite a lot of development from various software houses. Being the public sector we track and benchmark almost everything, and we actually have a dataset on automated testing that's been running for two decades.

It's hard to use the data, because we're comparing different projects, teams and suppliers but our data shows no advantage in choosing the companies that are very test-focused.

They are often slower, more expensive but have the same amount of incident reports as the companies which tests less or doesn't do automated test at all.

<comment><USER4> One question: are they somehow more efficient in answering to an incident report?

My conjecture: I am not so surprised at these having the same % of failures - after all the TDD will not magically lead everyone to think of all the possible ramifications; you write tests for the case that you can "imagine" just like a non-TDD developer will implement logic to cover cases they can "imagine". But on the other hand, if after fixing the bug you need to prove that you haven't caused some other side effect, then having a full test suite in place should be more efficient than retest everything again (or less risky than "ok, fixing module W _should_ not impact X, Y and Z, so we test X only and ship...").

<comment><USER5> Why is this downvoted, it seems like a good point.

Also @moksly's point seems at odds with an apparently highly regarded piece of software, SQLite.

<comment><USER6> most projects can't move as slow as sqlites development does.

A software such as sqlite is in the rare situation that stable releases are more important than anything else.

Everyone I've worked with got payed for features though, not stability

<comment><USER5> I guess these are good points. The last line especially.

Yet it's obvious to me that correctness and stability should be features, and more fundamental than all others. It's not as if a non-extreme amounts of testing is all that expensive.

</comment></comment></comment></comment></comment></comment><comment><USER7> Great to see the author tackle such a broad topic after 3 months of bootcamp and 1? year of professional development.

Regurgitating others' opinions and making multiple unfounded assertive statements is key to demonstrating he has already mastered the software domain.

<comment><USER8> The experiences of beginners are as valid as anybody else's.

It creates an unfriendly culture if people are told they can't talk about their frustrations and challenges without having x years of experience first.

<comment><USER9> The experience of a beginner with a certain tool is quite important. E.g, if Linux is not user friendly to newbies something could be done about that.

But some tools require expertise and a beginner might not get the entire picture yet. E.g, if someone with 1 year of physics experience claims Quantum Mechanics to be dumb, is that a valid opinion?

<comment><USER10> It might be. Your point is that it's not worth your time to consider that someone's opinion.

<comment><USER11> I'm not going to take any opinion seriously with a headline like that.

</comment></comment></comment></comment></comment><comment><USER12> There clearly are problems that are suited very well for TDD and others that aren't.

I guess the suitability of TDD depends on how much a feature involves "how" rather than "what": Whenever it is clear what the feature should do (and what the feature's interface looks like) and the implementation is only about the "how", TDD seems to a very good idea. Almost every compiler-related task falls into this category. I just wrote a blog article on how to implement Typescript refactorings using TDD ([1]) and I don't think anyone could argue against using TDD there.

If the feature is more about "what" (like UI/UX), TDD seems to be more of a burden than an useful asset.

[1] [https://blog.hediet.de/post/implementing_typescript_refactor...](https://blog.hediet.de/post/implementing_typescript_refactorings_with_hot_reloading)

</comment><comment><USER13> One important aspect of tests is to derive them from requirements. Not from the implementation. This is also true if your requirements are only implicit in your head.

TDD ensures this as there is no implementation yet when you write the tests.

It also implies the changing requirements comes with the overhead of changing the corresponding tests. This is what happened in the incident described in the article. In many cases development speed might be more important than test coverage.

Still worse are tests derived from the implementation (usually to boost done coverage metric) because they often break although the code fulfills the requirements.

Rule of thumb: Test only the requirements which are stable.

</comment><comment><USER14> Regardless of my opinion on the topic, which I don't have:

why must software engineering be mainly opinion-based? Why can't we have objective facts, or at least only talk about objective facts without going out asserting one's opinions as truth?

AFAIK other engineering disciplines do not suffer from this problem as much as software engineering. This really bugs me.

<comment><USER15> Well call me crazy, but imho the reason for that is that for the most part, software engineering is not engineering. We're not fighting laws of nature, we're fighting other people's style and decisions. That's why our work is opinion based: we're basically computer lawyers.

<comment><USER16> Software engineering may not be an engineering discipline but in theory you could set up empirically studies/experiments to test certain hypotheses of software development practices. In theory you could also review or evaluate design against certain criteria and derive what's better to fulfill certain goals.

<comment><USER15> Absolutely. And I think there were actually studies on the effectiveness of TDD, and I seem to recall them confirming it.

</comment></comment></comment></comment><comment><USER17> Not much to add except that when j tried TDD, I had to have this mentality of typing out code as fast as I could, going back to the test, fixing stuff, back to code, learn the mistakes, etc.

While my dev approach is more about think, think, think harder, code, compiler barely complains, fix small issues, write test, done.

TDD felt very uncomfortable because the thinking part didn't seem to be emphasized much. It's like keep going, you iterate again real soon in this code, now again, and again.

Maybe I got it wrong, I don't know. But I share the author's frustration.

<comment><USER18> I'm with you and the author on this.

</comment></comment><comment><USER19> "...I never understood why it was better to do things backwards...The idea behind TDD is that you're able to write a test because you sit down and think about things first...."

Yeah no. You have been instructed poorly. It's not your fault.

Yes, you have to think about things, but that's not the real purpose of TDD. Just like making a good design, it's a side effect.

Straight coding is doing it backwards, as odd as that sounds. The reason is that the computer never lies, but it's really, really easy to lie to yourself, forget things, misunderstand your own variable names, and so on. When you're coding, you'll make all kinds of errors. The computer will not. So wouldn't it be better to have the computer constantly checking on you to see if you're making any new errors? Better still, not only will it check on you, it'll check on everybody else who touches the code too.

There are domains in which TDD does not make sense. Exploratory coding, like you'd do in startups, for instance. Small pure functional code. Academic learning. _In each of these cases you are still doing TDD, it 's just you're not coding the tests_. You never get away from TDD, you just sometimes hide it or pretend it isn't happening. There's a test, it fails, you write code to make it pass.

In other cases, such as any non-trivial mutable OO commercial code that is going to be around for a while, not using TDD is malpractice. Whatever small hit you may take on initial productivity is insignificant compared to the endless amount of money you may spend later on maintenance.

Plus, I'm not so sure it's inefficient to begin with. Instead, I think a lot of coders code in an inefficient way writing code that is difficult or impossible to test. Once you start using TDD, you're going to have to come to terms with that and un-fuck your code. That's probably going to suck. Best to do it earlier rather than later. (Long discussion here about what to do with legacy codebases)

</comment><comment><USER20> I'm generally inclined to agree, test coverage is good, but test driven development is awkward. I think there's a tinkerer's mindset which is very much stifled by TDD.

I think TDD does shine for some things, it especially shines for refactors (where the tests ideally shouldn't change anyway) or bug-fixing where you can write in a test to catch the bug that has been found as a regression test before starting to fix the bug.

For brand new features it is a signifincant discomfort. I concede that that discomfort can result in more thought-through code but it can also just put off the implementer into not working as efficiently as they would be able to in a 'code first, then refactor' mindset.

<comment><USER21> On the flip side, "code first, then refactor" is only safe if you have tests to confirm the validity of the refactor, and in my experience, a TDD mindset is the only thing that ensures I have thorough tests by the time I need to refactor.

That said, it sounds like my version of TDD may be different than a lot of others. The tests I write before coding tend to test real-world logic and requirements, in terms of the domain language, rather than testing implementation. This means I can refactor everything behind that DSL-like facade and my tests give me assurance that I haven't changed the logic.

If your tests are at the implementation level, I can see how a TDD approach would impede refactoring and eliminate tinkering. If refactoring the code means rewriting the tests, then your tests aren't protecting you, they're just getting in the way.

</comment></comment><comment><USER22> I concur! Additionally to the article I believe the overall problem with software development is that it cannot be done by everyone. Developing great software requires the mentality of a passionate artist and a lifetime dedication. Unfortunately most companies I've worked with (with very few exceptions) are only after immediate profit and thus creating toy programs mainly by means of integration of ready-made third party libraries. The example they set for new developers is catastrophic. Fewer and fewer people dwelve into the depths of knowledge. Shallow integration, adoption of over- hyped immature components and the new trend of containerization is a two-fold failure: a) Failure of educating minds to think and b) low quality end products for the users with all the consequences this brings (aka performance, security, UX, etc). It really feels as if software development has entered a dark era where instead of educating people we create mechanics that take 'experinments' to market asap and disguising them to look like they operate error-free. Of course such tactics cannot keep problems hidden forever. If only I could share with you the stories of large heap fragmentation I've heard over the years on production server code...

</comment><comment><USER23> This is skipping the purpose of TDD actually, TDD is basically binding your every code change to a test (basically it is a spec) You are supposed to write the minimum required code to satisfy a failing test. Basically it is kind of commenting every bit of your code with a test.

So every line of code you are writing has to have a purpose, and later on when you are fixing a bug or adding something new, you are making sure, you didn't break any previous functionality.

<comment><USER24> And yet when an oracle dev comments on HN about the test suite we all gasp in horror...

</comment></comment><comment><USER25> This comment in the original article is really to the point:

I think one of the biggest values of TDD is it teaches developers how to write unit testable code, which, if you are new to unit testing, can be quite hard to get your head around.

As for its usefulness in 'real-life', I'm going to answer with a solid 'it depends'.

Anyone who dismisses it is missing out on some potential big advantages, anyone who is a 100% TDD zealot is probably either wasting time or lacks extensive real world experiance.

</comment><comment><USER26> I tend to think that the biggest flaw with TDD is that it assumes you have requirements, from which to derive test cases.

And In 7+ years of engineering at FAANG companies, I've never once had clear requirements before the software was complete (let alone started).

</comment><comment><USER27> One claim TDD makes is that a reasonable architecture arises from from its basic approach. To me this is an extraordinary statement of which I have seen no proof.

<comment><USER28> TDD doesn't make that claim, because TDD is not a thing which can make claims. _Some people_ make that claim about TDD. Those people are indeed mistaken.

As someone who thinks TDD is useful, i find those people particularly infuritating, because such an obviously silly and easily disproven claim turns the programming public off TDD for no good reason.

<comment><USER27> It is implied by the minimalism of the red-green-refactor mantra.

</comment></comment></comment><comment><USER29> A couple of things to mind when talking about TDD.

1\. Tests can be unit-test, integration-test, e2e tests. Don't limit yourself.

2\. TDD is a technique. Depending on the problem and your experience it might not be the right one to efficiently get you a working program and a good test suite.

Remember there is no free lunch.

3\. Also, if you have never successfully applied TDD: Please stand stil for a moment. Some techniques require practice and TDD is one of those.

You need to invest time in order to use it efficiently. Once you do it, you will be faster and deliver higher quality code for a large set of programming tasks.

4\. There are tasks where i don't use TDD. However, I usually go back to it as soon as I can. You can switch between the two techniques. There is not one way that is most correct.

5\. Also, note: if you don't write tests first. Writing tests after the code is complete is more difficult. You might need to adapt your code to make it testable.

6\. If you write tests afterwards, usually you will accidentally omit tests for crucial cases if you are not careful. I use line coverage and branch coverage tools to help me when I don't develop test driven.

</comment><comment><USER30> Testability, Performance, Readability, Maintainability are all vectors we can judge software by, and while they are not orthogonal, they are also rarely colinear. TDD optimizes on Testability to the expense of the others. This is rarely a good idea.

</comment><comment><USER31> Development is the ability to deliver/ship the things that increase your business metrics, consistently.

Sometimes the right thing to do is TDD, sometimes the right thing to do is to ssh into a production server and modify a Perl script.

</comment><comment><USER32> It's painful when I come to a project and the process for developing a feature is...

      (1) install database (or point to dev,) configure app, run seed data.
      (2) creating the state in the database manually.
      (3) change lines of code for feature
      (4) reloading app, navigating through to the feature state, manually verifying.
      (5) fix runtime errors or bugs
      (6) Repeat as needed. Commit.

We don't need to swing around the entire stack to craft some pixels or make sure some message is displayed under specific circumstances. How do we get developers to think beyond this workflow?

I think TDD at the very least is a education/comprehension exercise in abstract thinking which will discourage scenarios like the one described above. Once someone is able to TDD and 'gets it' then sometimes the way they approach arranging code even without TDD is better. I think this is why we may have mixed messages like "TDD is great!.. but we don't practice it at work."

Using a test harness any sorts to test something in isolation will speed things up. We can better understand where a module begins and ends (i/o, side- effects.) Develop it rapidly in the harness and then a few (automated) integration tests at the end. It doesn't have to be a TDD-specific testing harness.

React Storybook is an example of a UI test harness. It's still manual testing, but we get that great separation-of-concerns goodness that makes for better designed (and easier to maintain) systems.

</comment><comment><USER33> TDD is so tragically misunderstood. I don't think this dude knows what he is talking about.

Case in point: you don't have to write your tests first. You can write a quick spike first to feel out you API, then rewrite that code with TDD.

Why is this dude so desperate to have this function written quickly? This whole episode could not have taken more than 20 minutes. Sloppiness is the enemy with software development.

"But in real life, features are way more complex than Function X should take a name and output a greeting with that name. Often times the product request will change mid-work, or you'll realize that the feature can't work as requested. Maybe your original understanding was flawed and you have to start over."

Smoking gun right here. This is just wrong and stinks of amateur. Features are almost always made of many small functions that do little bits of easily tested work. And if you factor you code well, which is a large benefit of TDD: having well factored code, changes should not collapse you whole sand castle. If that is happening, maybe go back to school. Oh wait, you never went to school, just a 4 week course so you can have low level programming job to toil at...

What he is missing here is the alternative: a big ball of mud with giant functions and poor tests to validate behavior.

</comment><comment><USER34> TDD is one tool in your toolbox. You can easily solve problems like this one: [https://itnext.io/you-dont-know-tdd-691efe670094](https://itnext.io/you-dont- know-tdd-691efe670094).

However, there's a myriad of other problems TDD doesn't help you, like when you need to design a system beforehand or you want to make an educated jump to a solution that's good enough and you already know it.

</comment><comment><USER35> I have learned and used TDD before, but I don't _do_ TDD. I am, however glad I learned it, as it influences the way I write code now to the better. (Think more before I start writing, for instance, and writing smaller testable units of code up front). Much in the same way learning a new programming language/paradigm also can change how you write code in the old language.

</comment><comment><USER36> I don't think I have a good enough to brain write all but the simplest code without TDD. I specify what I want, write the tests, then figure out how to make it pass those tests. Thanks to libraries like @testing-library/react this approach applies as equally as well to when I'm writing babel AST parsers and custom languages as it does to developing a user interface.

</comment><comment><USER37> My experience is that tdd only works when the requirements are super clear

</comment><comment><USER38> _What's far easier is writing your code, manually doing some QA tests, and then writing automated tests that mimic those situations, specifically for the code you wrote._

This is the most popular method of doing things in my experience and the reason for that seems to be it makes chronological sense to a human brain. It's very unnatural for people (including clever devs) to consider a project like manufacturing a car and starting with 'the tire pressure should be correct'. Also too often (wrongly or rightly) prototypes often don't have tests and that sets the tone quite early. Automated tests should be written ASAP no matter which methodology is used.

<comment><USER39> This type of order will most probably get the developer into confirmation bias: writing the tests that show the code works.

The best for me is to thing about how would I test if the solution will work, then implement the solution and then run the tests. This why I try to compensate a little for comfirmation bias.

<comment><USER38> That's no so bad since automation is highly useful for regression testing.

</comment></comment></comment><comment><USER40> As stated tests are important, what varies is the style and ordering of writing them.

I don't like brittle tests that are specific to the implementation, such as assert that such-and-such isn't invoked--an equivalent function can be invoked and pass.

The order I do things:

      - think about the problem space, come up with some shape(s)
      - list the test cases, but don't write the bodies
      - code the happy path and runtime errors for others
      - write the test bodies, make them pass
      - clean-up any remaining placeholders

Sometimes (2) and (3) are flipped, more often interleaved

</comment><comment><USER41> As with most software engineering tools and practices, the context matters.

I'd imagine that TDD is good when you know exactly what the requirement that the project has. i.e. TDD is good in the implementation phase but not the design phase. In the design phase, you often don't know exactly what the problem really is, so you need to keep things as loose as possible because you're going to experiment. I imagine that in many small business scenarios these two phases are often fused together, so TDD wouldn't appeal that much for them.

</comment><comment><USER42> TDD is an interesting concept.

Anything you write as an engineer has to be tested. Manual testing is way slower than automated testing.

I find that when I have a few good automated tests in place, especially in browser selenium tests, I save literally days of work of manual testing. Thats time that I can use to build more features, get more feedback on my product or do other more productive things than manual testing.

10 minutes of time writing a good test saves me days of work in the future testing new changes. Writing good tests is a high impact, time saving investment.

<comment><USER43> _Manual testing is way slower than automated testing._

It's entirely a matter of perspective. I consider writing a unit test to do something the compiler could check for you if you were using a statically- typed language to be "manual testing".

<comment><USER44> Manual testing is where you click buttons on a device and observe results. Even that can be automated most of the time.

Pointless unit testing is a separate thing.

</comment></comment></comment><comment><USER45> > If a coding style turns out to be great in theory but not practice, let's > keep the parts that work and toss the rest. My convoluted point is: There > are lots of ways to code, we need to stop holding any one of them up as the > "best" way.

I think this is the crux of what the authour is trying to say. Not necessarily a criticism of TDD, but rather a criticism of holding to a particular belief no matter the circumstances. Of being inflexible.

<comment><USER46> I don't disagree with being flexible when needed but the counterargument is that flexibility can sometimes be used as an argument for corner cutting. For example when you start to make a few exceptions for TDD it then becomes easier to make more exceptions; if you're not careful you can quickly end up in a situation where your rational is "we don't have time to write tests" or worse yet "can't be bothered to". The point of methodologies like TDD is they force people to follow the best practices even when it's easier not to simply by mandating a standard process.

<comment><USER45> > The point of methodologies like TDD is they force people to follow the best > practices even when it's easier not to simply by mandating a standard > process.

I don't disagree with that, and I don't think the authour disagrees with that.

It's when the mandated process interferes with working in the actual world.

A better test-pipeline in the article's example might be, "We don't merge without full test coverage of changes" rather than "We must have a test before we've explored how a spec should look".

If the standard makes the real world overly difficult, then it will cause people to try and cut corners. It makes the developer seek to do the wrong thing.

There's nothing inherently wrong with TDD or a bunch of other processes. There is a problem if you're pushing yourself into a corner where you find yourself fighting the process rather than solving the task that needs solving.

<comment><USER46> > A better test-pipeline in the article's example might be, "We don't merge > without full test coverage of changes" rather than "We must have a test > before we've explored how a spec should look".

This is very much the rule I prefer to enforce as well. Though I do really like the TDD approach when there are defined specifications or refactoring happens. In those situations it can sometimes even speed up development because once the tests are in place you then have a tighter "write, test, repeat" cycle.

However I do still agree with all the points you've raised.

</comment></comment></comment></comment><comment><USER11> TDD is just another tool. I don't use it all that often but there are some situations where I know it works. I have for example found it very helpful in verifying and later addressing issues in larger codebases. There are other approaches but they often make the root cause or causes of an issue harder to locate. I really hope the author reevaluates TDD as I think they're doing themselves a massive disservice.

</comment><comment><USER47> About the only time I consistently code the test first is to reproduce defects. It's really useful in that case. Sometimes that also works for features.

When designing an interface I like to write usage examples. They're more nimble to work with than tests who require scaffolding. The usage examples do tend to become tests during implementation.

</comment><comment><USER48> I think the driven part is bad. Using tests are fine, it should just not drive your development efforts.

<comment><USER17> Sometimes you do have to make your code more "testable" on purpose though. But yeah, writing the tests first doesn't always work. YMMV.

<comment><USER48> True. I just run into these situation too much because I functional style code where there is very little internal state and try to use pure functions as much as possible. This narrows down the code that has to be written on a more testable way.

</comment></comment></comment><comment><USER49> I find myself TDDing code when the problem space is well-defined, i.e. I know exactly what output I'm looking for. Last time I remember using it was, oddly, in making a game. I wanted to build a CLI 2048 clone. Specifying that was easy and fun.

</comment><comment><USER50> Everything has a cost. TDD (and Refactoring) increases the cost of implementation (linearly), but they greatly reduce the cost of change. Without TDD (and refactoring) the cost of change might become exponential and impossible to catch up to.

<comment><USER10> Assuming that the amount of test code is 2-4x the amount of production code, TDD increases the cost of change by 2-4x when change is most likely to occur: at the beginning of development.

<comment><USER50> Agreed, it increases linearly. But now think about the cost of change without tests. The longer you wait to introduce the change the more you will have to change (increases exponentially). If this code was fully tested and maybe refactored (isolated) when the need arises, the cost of change would almost go to 0 because you would only have to implement a new feature without touching the old code.

<comment><USER10> You assume that changing a software that has tests is free, which is wrong.

Your previous-to-last sentence applies equally to a software project with or without tests.

</comment></comment></comment></comment><comment><USER51> Is there a way to read this without creating an account in Medium?

<comment><USER52> [https://outline.com/2cNZTz](https://outline.com/2cNZTz)

Alternatively incognito or no js should do the job also.

</comment></comment><comment><USER53> Write the least amount of code that will solve the problem, then write the least amount of code that will make the feature as efficient as possible to your ability.

</comment><comment><USER54> Reading this article got me thinking that the problem isn't TDD it self but the interpretation of it from a specific programmers perspective. One other poster noted that TDD is great when you know what your inputs and outputs are, ergo a toy function/project but I disagree as a programmer you should know that for every function you are writing before you start writing the function since you need to settle on return type(it's true for loosely typed languages too) so I'd conclude that maybe the OP is misussing the TDD paradigm

</comment><comment><USER55> It seems to me that software tests is like checking if an architectural design is structurally stable.

It's dumb to do that when you still don't have the characteristics of the space where you are building or the materials available, but it's dumb not to do it when you know exactly what and how you are building it.

In the same way, it's dumb not to do it when you have already a building and you are going to start to change things.

I think the problem is that, being all information, in programing those phases look the same but they are actually very different.

</comment><comment><USER56> The point is to have tests.

What came first the chicken or the egg?

Either the test came first and the code after or the code came first and test after.

An issue can arise in fast agile test driven development environments if you develop the code first and then do not get time to do the tests. If you start with the test you will be ensured to have time to write code otherwise the software will not work.

"The muscle doesn't see what you're holding in your hands." Arnold Schwarzenegge \- The tests doesnt care how you got them in place

<comment><USER57> Requirements come before implementation.

In many organisations it often happens that the test team implements tests and is ready to test a feature before the dev team has actually implemented it.

IMO, that's the basis for TDD, really. When you start coding you should know what the result should be and thus you should write tests first to capture this and guide implementation.

</comment></comment><comment><USER58> I agree that writing tests before code is unrealistic, but love tdd. We have nice weekends because of tdd.

</comment><comment><USER59> TDD of course forces you to build modular mockable code. For me it encourages a short term thinking, hacking approach. I think it elevates unit testing a bit too far conceptually, but it does encourage better construction. Like the author implies, it's a useful way to think, even if you dont do it.

</comment><comment><USER60> In my experience, if you find that you're unable to do TDD with a problem you're trying to solve, then you've probably not decomposed the problem enough. In your mind. Step back. Think.

The rush to produce code, now, is making working in this industry suck.

<comment><USER61> I find that writing _something_ can help me to get a feel for a problem. Start, then sitting back and thinking about it, helps me to move towards a better solution faster.

Of course, I don't always do the stopping and thinking part...

<comment><USER62> > I find that writing _something_ can help me to get a feel for a problem. > Start, then sitting back and thinking about it, helps me to move towards a > better solution faster.

That summarizes the struggle that I have with TDD. I guess you could argue that I'm doing TDD wrong, but most of the time I feel like I don't know what I'm going to be writing until I write it.

Basically most of my coding I feel like I'm prototyping until I iterate a few times and arrive at a solution I'm happy with and understand where the boundaries between various functions need to be. Until then, how am I supposed to pre-empt my solution with tests?

</comment></comment></comment><comment><USER63> I am more a fan of behaviour driven where the behaviours are written using specflow or cucumber almost like acceptance tests. Then the developer writes code but the behaviours are validated by the business analyst or product owner

</comment><comment><USER64> TDD is less about writing tests and more about the approach.

Just having an understanding of TDD and holding it as an aim will ultimately result in a better, more maintainable codebase.

So what's the downside?

</comment><comment><USER65> I don't think saying anything negative about test driven development is a positive contribution. Our industry should practice it more instead of less. I do it almost all the time. Sure, there are a few exceptions. It is quite unneeded for at throw-away script, obviously. If something is in a user interface and it is purely visual it may be better to write the code first because the browser in your head might not be good enough to write a correct test beforehand. Those are the exceptions, though. For any program containing somewhat complex logic TDD is king. There is nothing that beats it in terms of reliability and after some time also regarding speed because in the end nothing costs more time than something that keeps breaking in production. Thorough manual testing is also quite expensive in terms of time.

I note some people here are talking about things that require exploration and research as a counter-inducation. Well, maybe in some cases but certainly not in all. One could also start with a test at a relatively high level and then do the exploration while writing code to make it pass. In that case one would write more code to make it pass than would be normal but it still benefits from being in the TDD cycle. After having it basically working one does additional TDD cycles to iron out the cases where it would go wrong.

The main benefits of starting out with a test is that: 1) tests do cost time so you need to recoup that by going faster in other parts of development. If you start out with the test it immediately starts paying back when it flags your first attempt at an implementation as either passing or failing. 2) The fact that the test first should fail and fail in a particular way tells you whether your thinking about how the system works is actually correct. It is like bringing the scientific method to programming. People in practice very often have just the wrong idea of how something works in the first place.

People are also talking about TDD being a strange order to think about programming. This is also my experience. It requires some getting used to. It is quite good though. The point being that it enables one to not need to think about everything at the same time. When writing a test you think about the functionality you need. When writing an implementation you think about algorithms and when refactoring you think about code quality. In traditional development this gets rolled up in one big ball of mud which makes the thinking about either of these three aspects of lower quality.

One thing that people get into trouble with is trying to write test for functionality that is too low level and therefore very much implementation defined and therefore subject to change. I think one should generally work at a level where one tests the behavior of a cluster of a few classes. This problem also leads to tests that are too trivial. If one has a method that adds n to m and one writes a test for that one is testing that the processor really can add numbers and that is not very interesting.

</comment><comment><USER66> TDD is not dumb, just there are use cases where it fits better, specifically, when you know the exact inputs and outputs beforehand and how it will fit in your system. When designing an API, it's not a good use-case for TDD at all. The author obviously doesn't understand that. If you don't even know what functions will you need, you obviously can't write a test for it!

Kent Beck, DHH and Martin Fowler explain it very nicely in the "Is TDD Dead?" dicussion: [https://martinfowler.com/articles/is-tdd- dead/](https://martinfowler.com/articles/is-tdd-dead/)

I highly recommend it to everyone even if you think you understand what is TDD all about! It's a very deep, interesting discussion about TDD between truly great minds.

</comment><comment><USER67> The authors of this might not realize it, but a good chunk of their audience can't read their post at all, due to Medium's paywall.

</comment><comment><USER68> What works perfectly for some devs doesn't for others. That why there are choices.

IMHO only thing dumb is developing without testing

</comment><comment><USER69> I somewhat dislike the TDD cargo-cult myself; but this is such a shallow opinion piece, how is it on top of HN?

25 minutes, 16 points - all that it takes?

<comment><USER28> HN _loves_ shallow opinion pieces, especially when they're contrarian. They give us a chance to wade into the comments and demonstrate how smart we are, either by agreeing or disagreeing!

</comment></comment><comment><USER70> After 15 years in technology/software development my impression is that your favorite methodology says more about you than anything else.

The sharpest engineers I know distinguish themselves mostly by how rarely they resort to running code at all. Instead they seem to have a mental model of the code base they are working on, similar to that of a mathematician. They can write code for days, weeks (or even months) and just know it will mostly work once they run it.

<comment><USER71> Did anyone, ever, in the history of world coded for months without running the code?

</comment></comment><comment> yoz-y First thing: they do not define which kind of TDD they are talking about. Second thing: without really good test coverage any kind of larger refactoring is gambling with reliability and will bite you at some point.

<comment><USER17> What kind of TDDs are out there?

Don't seem fair to call out author on not writing tests because they never said that.

<comment> yoz-y > What kind of TDDs are out there?

I have never actually seen somebody writing all of the tests before implementing the code even if they claimed doing TDD. Parts of tests maybe but I think that things rarely go the way the definition is spelled out.

> Don't seem fair to call out author on not writing tests because they never > said that.

Fair point. I have written my comment halfway into the article, the author makes a point about tests at the end.

<comment><USER72> > I have never actually seen somebody writing all of the tests before > implementing the code even if they claimed doing TDD.

I had an architect who did exactly this. It was awesome, one could just look at his code and see where it would fail because it didn't occur to him to either test for that case or actually think what the code does. His only explanation would be "but it passes the tests". Later he was made into CTO.

In a way, not testing for edge cases that are found during development is quite similar to commenting on article one hasn't fully read.

</comment></comment></comment></comment><comment><USER57> > _A great idea hiding behind a terrible implementation_

TDD is a method.

TDD forces you be clear about what the result of your code should be before you start coding. It also ensures that there is a test to check your code. This is certainly not dumb.

You will write tests anyway (right?) so it does seem smarter and more effective to write them first in the same way as you write requirements first before writing code. Nothing prevents you from iterating as progress and discover corner cases, for example.

People who say that TDD moves slower are simply admitting that they don't test. Automated tests are also crucial because 99% of testing is regression testing and that obviously cannot be done manually every time the code changes.

I found it rather ironic that the article ends by praising behaviour-driven development, which is an extension of TDD...

<comment><USER73> > TDD forces you be clear about what the result of your code should be before > you start coding

... which is often difficult and inefficient. A large part of the point of the article is that when making changes to an existing system, you often DON'T know until doing some experimentation what the result of your particular new bit of code should be. You know what change you want to happen to the behaviour of the system as a whole, but don't yet understand how the pieces that make up the system slot together. That permits you to dive in and try making changes and see what their effect is, but doesn't permit you to write a unit test right away.

> it is smarter and more effective to write them first.

But... why? You're asserting this without any justification.

> People who say that TDD moves slower are simply admitting that they don't > test.

This accusation is pretty tedious. The article was _explicitly_ comparing the test-first-code-second approach against the code-first-test-second approach and giving a reasoned argument (which you've not acknowledged or engaged with) for why the second was usually superior. The author isn't saying they don't test or arguing for not testing.

> I found it rather ironic that the article ends by praising behaviour-driven > development

That was sarcasm.

<comment><USER57> If you start coding before knowing what you are implementing then you have a bigger problem than TDD.

Experimentation is not the same as implementation, by the way.

Obviously nothing is adhered to 100% of the time in real life, this is not a dogma, but the point that you should know what the result of your code should be before you write it and should thus write tests first (which can also help you clarify your understanding) is eminently reasonable and valid.

> _That was sarcasm._

Article is poor overall. Sarcasm does not help.

</comment></comment></comment><comment><USER74> In college we were always taught to do TDD on large projects, and everybody I know does TDD(at least here in France). I can even think of working on a project that's not TDD. You need to look up Agile, Clean code and Xtreme Programming ;-)

<comment><USER75> Other than being taught it, and people you know doing it, do you have an argument for it to share?</comment></comment>


My First Job: Fired and Rehired on Day 1 - <AUTHOR> http://www.linkedin.com/today/post/article/20131029100222-95015-my-first-job-fired-and-rehired-on-day-1?trk=tod-home-art-list-small_1 <comment><USER2> I feel like I'm a different species when I hear someone excited about working 80+ hours a week. Having so little free time and so little time to spend with friends and family seems like a sad life regardless of the paycheck.

I agree with this: "Have a passion for Doing something rather than Being a title on a business card." I also agree that "Showing up a lot increases your odds" (in this case meaning working a lot of hours), but I just don't think it's worth the trade-off.

Life outside of work is, for many of us, far more meaningful than work. I thought this feeling was extremely common, but judging by what gets to the front of HN I'm in the minority here.

<comment><USER3> If I have to work 80+ hours a week to have the absolute financial freedom to live the rest of my estimated 40-50 years on this planet in any way I chose, nevermind ensuring similar benefits accrue to my family, then I think that's a pretty good deal. I still have down time and plenty of fond memories -- you just have to plan how you spend that time a bit better.

I live in a part of the world where a lack of financial resources is death. Every single day I pass by people begging for money and for work, and I live 5min away from my office. My crappy little second hand Fiat is worth more than combined net worth of every person I pass on the street. I remember seeing a documentary once where a labourer said something to the effect of: "I work like a horse so that my children can work like dogs, so that their children can live like people, and their children can be free."

And before any says your children should take care of themselves: try telling that to a child born with severe autism or down's syndrome, or some other disabling birth defect. If you're not planning for your family so that you can enjoy your younger years a bit more fully, you're taking a huge, selfish risk.

I'm much more fortunate than that guy was - my parents worked like dogs.

<comment><USER4> There's a nice parable about working hard to have free time later: [http://www.protolink.com/MexicanFisherman.html](http://www.protolink.com/MexicanFisherman.html)

<comment><USER3> The problem with this parable is that it equates two different scenarios. A fisherman without extensive financial resources is not the same as a person with extensive financial resources choosing to fish. Here's some alternative endings, in a country without social and medical support in place, for you to consider:

1\. The fisherman develops a serious illness and finds he can no longer support his family. His wife, who was barely getting by on a fisherman's income as a housewife, finds herself working at a local bar, serving drunk, lecherous men every day and night. His son and daughter find themselves unable to afford an education and really don't want daddy to die. With mounting medical bills, the son finds himself involved in crime to support his family and is eventually sent to prison for life for a crime he didn't commit. The daughter meets a wealthy man and everything is great until he starts hitting her. But at least she can support her father, lying on his deathbed in hospital. Daddy eventually dies but by that point she's stuck with 2 kids married to a man she hates.

2\. Oh but medical welfare would solve the problem in #2? Setting aside that this is contrary to my stated scenario (a country without medical welfare), consider this scenario: the fisherman loses his fingers and toes in a freak fishing accident.

3\. Oh but somehow he managed to afford an insurance policy that paid out on disability? Setting aside how unlikely this is to be for people barely making a living wage, consider this scenario instead: the nearby waters are polluted by an American oil extraction firm, and the fisherman finds himself scrubbing toilets at McDonald's to support his family. The American happens to come by one day and leaves him a nice tip.

<comment><USER5> On the other hand you can get bankrupt due to:

1\. Share market crash. 2\. Change in government regulations. 3\. Getting sued. 4\. Or simply bad luck. 90% of all business fail anyway.

<comment><USER6> None of these should cause a wealthy man to go bankrupt.

It can cause a business to go bankrupt, and a wealthy man to become much less wealthy, but otherwise either you are stupid or you are diversified; and it's easier to 'stay there' than to 'get there'. If a stock market crash or, say, Madoff hurts you then it's bad luck; but if it destroys you then it's stupidity.

For example, Bill Gates should still be wealthy even if Microsoft went completely bankrupt at any point since mid-1980ies. Sure, he probably wouldn't be on his malaria campaign in that case, but it wouldn't hurt his life that much.

</comment></comment></comment></comment></comment></comment><comment><USER7> > Two weeks before the class was over, the head of the deployment team asked, > "Steve, are you single?" Yes. "Do you like to travel?" Sure. "Why don't you > come to Korea with us when we ship the system overseas."

The first of those questions was completely unnecessary, and invited a potential employment discrimination lawsuit; it fairly directly implies they might not have made the offer if he wasn't. It would have sufficed to find out if he was willing to travel.

<comment><USER8> There is no federal law about Marital status discrimination, only state law, and not all states.

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

Note that California does prohibit it, but it seems to be a recent law.

This [http://www.unmarriedamerica.org/column- one/01-08-07-californ...](http://www.unmarriedamerica.org/column- one/01-08-07-california-sweeping-bill.htm) implies it was around 2007/2008.

<comment><USER9> Its a dangerous question to ask anyway, not because its against the law, but because it is somewhat ethically grey - the candidate would feel they've been discriminated if they had answered that question "poorly".

</comment></comment></comment><comment><USER10>
      > Trust your instincts
      > Showing up a lot increases your odds
      > Trust that the dots in your career will connect
      > Have a passion for Doing something rather than Being a title on a business card.

So basically, his advice is to just hope everything works out okay. What he doesn't explicitly point out is that all of the success in his story is based on being a really good bullshitter. If you can bullshit well, you can get promotions, you can get jobs, you can get a lot of things. If you can't bullshit well, you're out of a job with barely any cash in a place you're not familiar with, and probably soon calling your parents to wire you gas money to get back home.

I've also been fired the first day on a job. But I had savings to fall back on, and then got a much better job a few months after. Trust your back-up plan, not connecting the dots.

<comment><USER11> > all of the success in his story is based on being a really good bullshitter.

And then delivering on what he said. You forgot that part.

</comment></comment><comment><USER12> "You're not so smart, you just show up a lot in a lot of places."

Quite astute. As they say, showing up is half the battle.

<comment><USER13> Maybe, but being the kind of person to hustle your way into a job in a situation he described is pretty impressive in itself, and he showed a lot of savvy in a short space of time in gathering the intelligence to work out the pitch that meant they _had_ to hire him.

So yes, 'showing up' a lot is very important, but it's not the only lesson I take from his story by a long shot.

</comment></comment><comment><USER14> As a mid-40s year old male, I can assure you that working 70+ hours a week will eventually kill you. Your body will respond in ways you never expected in your youth. And it's insidious. It will sneak up on you and catch up to you when you least expect it. If you're lucky, there will be time to take corrective action.

<comment><USER15> Could you elaborate on the tolls it takes?

<comment><USER14> Sure.

For me, the stress has manifested itself in the following ways, I have high- blood pressure, I have fatty liver, I have high cholesterol, I'm overweight, my eyesight is horrid, I grind my teeth while I sleep which has resulted in broken teeth, I have one gold crown and another chipped tooth and have a really messed up "sleep" schedule.

I have chronic back problems, allergies and get frequent colds.

All of this due to the stress of working long, hard hours. Keep in mind that I have a diet which is _better_ than the typical American's. I've cut a lot of sugar out of my lifestyle.

<comment><USER16> How do you know you wouldn't have all these problems if you worked less?

</comment></comment></comment></comment><comment><USER17> > My First Job:

> [...]

> I had quit my job

The "In Silicon Valley" is missing from title.

</comment><comment><USER18> If I drove all the way across the country and heard that on my first day. My middle finger would be raised very high as I shouted profanities as I walked out the door.

But the author kept his cool and it worked out, maybe a trait I need to develop.

</comment><comment><USER19> Can anyone summarize? I do not read linkedin articles.

<comment><USER20> What's this guy asking? I don't read stupid Hacker News comments.

<comment><USER21> _Agile Opportunism – Entrepreneurial DNA

Posted on June 29, 2009 by steveblank_

Seems like the guy has a point. Title's been changed. And the meta-data of the source publication ([http://steveblank.com](http://steveblank.com)) is lost in the process. About par for the course. Linkedin is a needless re-direct.</comment></comment></comment>


ACLU Report: The Public Internet Option - <AUTHOR> https://www.aclu.org/report/public-internet-option <comment><AUTHOR> The rural township that I live in is considering the possibility of providing municipal broadband; hence my interest in this report.

From a security point of view, I am skeptical about the ACLU's recommendation in this report to provide open WiFi access points. Due to the danger of MITM attacks, I don't think it's a good idea to promote the use of open APs.</comment>


Happy Anniversary WWW - <AUTHOR> http://www.jacquesmattheij.com/happy-anniversary-www

<comment><USER2> Well said, Jacques.

There are too many angry, ranty, sensationalist accounts of why online surveillance is A Bad Thing, and you put it in a calm & rational way.

I hope more people read this article and better understand the objections if they didn't already.

</comment><comment><USER3> "It's been a bit of a slow realization for me, but I don't actually want to be safe, I'd rather be free and unsafe."

This, I believe, is the key tension in democracies. A majority of the constituents can be scared into compromises for "their security", not fully understanding what they are really giving up. A large number would rather "feel safe" than "feel free".

<comment><USER4> I disagree with that statement. It's possible that he hasn't lost someone close in any kind of traumatic event that makes him so optimistic about it. Human nature compels people to want revenge or hatred towards say the same (religious) groups that the "terrorists" were from. This is very evident post 9/11\. People hated muslims, destroyed their properties and discriminated them.

I think it's not time to be so care free. We don't even understand the universe yet. Of course I don't want survellience, but there has to be a requirement for saftey, and yes if that means putting bad people behind bars and make society advance faster so that we can colonize other planets, and understand how everything works better. There needs to be more scientists and engineers not more thieves.

<comment><USER5> Nobody has problem with putting bad guys into prisons. All civilized societies do this.

What I/we have a problem with is that everybody is treated as guilty, spied on etc.

This becomes even bigger problem when you consider that most governments consider anyone that is not with them to be their enemy. So in essence If you don't 100% agree and support government you are an enemy and then anything goes (spying, dronestrikes, ...).

Additionally I am not American, I don't even get a vote, but i am beeing spied on, and If I make to much fuzz them might decide to drone me. (As far as I know they haven't killed any EU citizens, but I doubt they would think twice). They also keep expanding who they go after, first it was just the Al Kaida and other terrorist, now its pretty much anyone USA doesn't like. So to put it bluntly I as a EU citizen am far more scared of USA than Al Kaida.

<comment><USER4> Are you serious? Despite the 1% spending to aid, US gives more aid to developing countries more than any other nation. You're scared because if you make a fuzz they'll drone you?

People that didn't like obama talked bad(even death) about him when he first became the president, they're still alive.

I don't support what the NSA is doing by spying on everyone but detaining someone of probable cause is necessary for saftey measures.

According to your view, US should've nuked North Korea already by now.

</comment></comment></comment></comment><comment><USER6> Obligatory link to [http://howoldistheinter.net/](http://howoldistheinter.net/)

</comment><comment><USER7> Does the Internet Archive project collect emails or cross any privacy lines? Will future Archive members be as benevolent?

(Should I go read the Archive's website and find out for myself? Probably yes.)

<comment><USER8> They don't collect email because that's behind a password protected access if it is web driven and presumably imap or pop if it isn't. So your emails are not stored by the IA.

I don't speak on behalf of the archive nor am I in any way associated with it but from a technical point of view the archive crawlers simply do not have access to your emails.

See the faq for lots more information:

[http://archive.org/about/faqs.php](http://archive.org/about/faqs.php)</comment></comment>


Can Dogs Detect Seizures? [2007?] - <AUTHOR> http://www.epilepsy.com/information/professionals/hallway-conversations/can-dogs-detect-seizures <comment><AUTHOR> Also see:

[http://news.nationalgeographic.com/news/2003/04/0416_030416_...](http://news.nationalgeographic.com/news/2003/04/0416_030416_seizuredogs.html)

Whence the following quote:

 _When selecting a potential seizure alert dog to work with, she performs a trainability test. Hermansen says she "prays that God will show her the one that best fulfills the needs of the person with epilepsy."_</comment>


iOS 13's Robocall Feature Might Stop Legitimate Calls - <AUTHOR> https://www.twilio.com/blog/new-apple-robocall-feature-cost <comment><USER2> I feel like the feature doesn't go far enough. They should force you to acknowledge that the phone app is not safe for any sensitive information because the phone networks are fundamentally insecure.

If the web didn't have SSL, there would be PSAs about how you should never trust it for anything, ever. However, the current phone network is in this state, and we're all okay with it and we act like this isn't a crisis.

Honestly I think Android and iOS should both blast warnings all over their OS about how dangerous it is to trust the phone, and how you should avoid using it for anything that requires privacy. Never trust a call from anyone, period, until we have some kind of cryptographically secure system that assures us of the identity of the party calling us.

</comment><comment><USER3> It's hard to believe this isn't biased considering it is written by Twilio.</comment>


A black box in your car? Some see a source of tax revenue - <AUTHOR> http://www.latimes.com/nation/la-na-roads-black-boxes-20131027,0,6090226.story <comment><USER2> Why is raising the gas tax not an option? I mean, almost noone wants to pay more taxes, but if the road fund needs to take money then it's far simpler to raise the existing tax rate rather than implement a new process, collection agency, and monitoring tools.

The rate listed in article (18 cents/gallon) is not a big influence to prevent driving - it's ten times less than the gas excise tax I pay in EU, which comes out to a bit less than $2 per US gallon. Business doesn't stop because of it, and there's extra motivation to reduce the polluting transportation.

<comment><USER3> With the new CAFE mileage goals, tax revenue will fall as cars become more fuel efficient. Or as people buy more electric vehicles.

The deal is that cars actually cause very little damage to the roads. Trucks are the real cause of road damage -- up to 80,000 pounds spread over five axles. Compare that to 4,000 pounds over two axles for a car (or 5-6k pounds for a loaded pickup or SUV) -- the per-axle weight is much higher for a truck.

The trucking lobby is very powerful in Washington, and will resist any effort to increase the diesel motor-fuels tax. They have a powerful argument in their favor: The majority of food in America is delivered by truck. Raise the tax, raise the cost of food.

But even outside of that, there's a simple way to get about a 20% increase in funds for repairing the roads & bridges, and that's to stop the diversion of funds out of the highway trust fund into the general fund. The tax money intended to go to build & maintain our crumbling transportation infrastructure, is instead being fed into the sausage factory where it gets turned into pork.

<comment><USER2> The valid argument for not taxing a flat rate ($xxx per car per year) is that it unfairly penalizes those who use it very little. For personal vehicles that makes sense, so their 'costs' are mostly paid by the gas excise; but for commercial trucks you can just tax them directly - for example, here local semi-trailers pay ~$350 annual vehicle tax; does USA have something like this?

The food argument is bullshit, of course, but probably effective because it sounds nice. The truck fuel cost is a very tiny part of the actual food cost - taxes on farming fuel would impact food, but not that. Of course, extra taxes always create inflation; but fuel tax is probably the one most evenly spread across everything, as it affects burger prices just the same as Barbie prices.

<comment><USER3> The federal diesel motor fuels tax is 28¢ per gallon. The states will have their own tax as well. Texas imposes a 20¢ per gallon tax. Connecticut's is 54.9¢.

There's also a tax on the vehicle itself. I want to say that it's in the $500 per year range, depending on it's GVWR and the state.

</comment></comment></comment></comment><comment><USER4> As others have said in this thread, just raise taxation on fuel.

In the UK ($8.50 per US gallon) it has encouraged people towards more efficient vehicles and the government has made electric vehicles free from yearly charges (Vehicle Excise Duty is based on emissions which again punish bigger engined cars).

Of note it is quite unusual to see an 18 year old with a car these days. Cost of fuel and insurance discourages the young from getting a car.

In fact there is a major push towards 'Active travel' (Cycling/walking/public transport).

Where I can see these type of devices finding a home is in reducing your insurance premiums. In fact I can see the Russian situation where something like this box with a dashboard cam will almost become mandatory. Well not so much mandatory, but as the only way to get cheap insurance.

<comment><USER5> > As others have said in this thread, just raise taxation on fuel.

This is one of those "uniquely American" problems.

You simply can't get any meaningfully-large group of US citizens to agree to raise taxes. On anything.

Even if it's in their own interest. Even if there is zero drawbacks of any kind. Americans will fight tooth-and-nail against anything that looks or feels like a "tax" of any kind.

In addition, many Americans already feel like the gasoline prices are "high" here. (Even though, factually, we live with very low subsidized prices: they're around $3.25 per US gallon here today).

Raising tax on fuel is not even fathomable.

<comment><USER6>
      You simply can't get any meaningfully-large group
      of US citizens to agree to raise taxes. On anything.

Really?

[http://www.nytimes.com/2012/11/08/us/politics/in- california-...](http://www.nytimes.com/2012/11/08/us/politics/in-california- voters-approve-ballot-measure-that-raises-taxesin-california-approve-voters- ballot-measure-that-raises-taxes.html)

I was one of the voters that voted for the increase. I don't mind paying taxes most of the time; with them I buy civilization.

<comment><USER5> Your right. I should have started all of the above sentences with "most of the time".

</comment></comment></comment></comment><comment><USER7> Moronic. So to _create_ tax revenue, let's spend tax revenue on a device, data collection, analysis, complex billing, which of course the gov having a great history of being good stewards with our tax dollars, will overpay. All for something that can double as a spying device. yay.

Just raise the gas tax to make up for lost revenue. Sick of hearing "we are addicted to oil" every state of the union and the answer is right there. Solves the road revenue problem as well.

</comment><comment><USER8> People need to get out of the false notion that the government is desperate to increase tax revenue by any means, and will foist us with an extra tax at every opportunity.

There are two main drivers of tax policy. The bad, is that there is political gain to be made by making taxes less salient. If people don't notice they are being taxed, they will complain less. The article claims gasoline taxes are more salient than the proposed new technlology.

The good, is that the government wants to tax negative externalities, and give tax breaks for positive externalities, and possibly tax luxury items to make taxes more progressive (the last one isn't always good policy). The proposed policy may or may not achieve this - as mentioned, it does allow for congestion taxation.

So whether you are saying what the government should do, or what the government does do, the paradigm of a government desperate to obtain more revenue is a poor one.

<comment><USER9> Local governments are notorious for trying to increase revenue. Like changing yellow-light duration to increase red-light traffic violation tickets after cameras were installed.

Governments in general, at a federal level, might not be this way, but local cities and counties certainly often try many tricks. From "taxes" on driving, to abusing seizure laws. Hence the notion people have.

<comment><USER8> Yeah good point. I guess for various reasons higher levels of government tend to reign in the ability of lower levels of government to raise taxes, and it does create precisely the situation you describe.

Still, all the more reason to make fine distinctions - in this case between local state and federal government

</comment></comment></comment><comment><USER10> And we have to use complicated tracking/transmitting devices that force us to trust us that you're not monitoring our movements instead of just having our odometers read annually (perhaps during emissions testing?)...why?

</comment><comment><USER11> At least in the state I live in, the gas tax would more than pay for road upkeep and upgrades, but they keep diverting the money to other uses (usually ending up in the pockets of politically connected cronies). We now have bridges in need of replacement and roads falling apart.

It's no surprise that, having found a great gimmick to divert money, while at the same time making it seem like the money is actually needed, that politicians want to see how far they can push it.

</comment><comment><USER12> Four or five times a year someone floats this eternally stupid idea for the Exciting New Car Tax!!! and the answer to why the hell people would ever accept this, but not a gas tax increase, is always _mumble mumble mumble_ "hey, look over there!"

</comment><comment><USER13> This sentence discredits the writer:

"Libertarians have joined environmental groups in lobbying to allow government to use the little boxes to keep track of the miles you drive, and possibly where you drive them — then use the information to draw up a tax bill."

Libertarians are for use tax and privatization of roads. Unless misled by clever wording, they would never support a state administered use tax that tracked your location.

</comment><comment><USER14> Oregon is doing exactly this, apparently. The Economist had an interesting article on it recently.

[http://www.economist.com/news/united- states/21588097-oregon-...](http://www.economist.com/news/united- states/21588097-oregon-wants-tax-motorists-miles-driven-not-petrol-burned- will-it-work-roads-less)

It does seem like raising the gas tax would be an easier option.

</comment><comment><USER15> I really don't see how this would work. Just because I put a certain number of miles on my vehicle, it doesn't mean they were accumulated in my home state. That would end up being a tax for out of state travel.

</comment><comment><USER16> A tire tax might be simpler to implement, and would capture similar information.

<comment><USER17> A tire tax is a really bad idea from a safety point of view. People will delay tire purchases past the safety line.

<comment><USER18> A flat yearly tax on the vehicle.

<comment><USER19> You could call it a vehicle registration fee.

<comment><USER17> If your vehicle registration fee was in the several thousand dollar range, it would cripple a goodly number of poor and low income folks.

<comment><USER18> They're already paying the taxes; its just streamlining the collection. If they're crippled by current fuel taxes, they'd still be crippled (or rather, unable to afford) taxes under the proposed scheme as well.

See my post where I outline the math: [https://news.ycombinator.com/edit?id=6623693](https://news.ycombinator.com/edit?id=6623693)

<comment><USER17> No, it is easier for people to pay small chunks at different times then to be confronted by one huge bill. Planning is not something innate in people. This is the exact reason withholdings were created.

Number 2, the cost addition to government budget should be unacceptable and the cost of this program will increase the tax beyond what is needed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I haven't read it yet. So they are going to get rid of the fuel tax right?

</comment><comment><USER21> The TRON-ripoff logo isn't helping at all.

</comment><comment><USER22> lol americas stupid-low petrol prices catch up with them faster than expected.

This seems like a crazy attempt to use tech to confuse people and trick them into paying higher tax. Tax which could/should come by the far more simple means of fuel tax. They should just suck it up and give their constituents some tough love.</comment>


Freakonomics: Game Theory and Child-Rearing - <AUTHOR> http://freakonomics.blogs.nytimes.com/2011/01/04/game-theory-and-child-rearing/

<comment><USER2> There is a ton of evidence that people will give up individual gain in order to punish bad behaviour. The classic example is A gets given $100. He can choose to split it with B any way they like. B can accept the offered deal or refuse it, in which case nobody gets anything.

From simplistic game theory B should accept any offer (for example $99 for A, $1 for B) since B would have more money than he had before, which was nothing.

In practice with real people, anything below a 60-40 split gets rejected. People will indeed give up gain in order to punish anti-social behaviour. You don't have to think very long to see why we have evolved that way.

<http://en.wikipedia.org/wiki/Ultimatum_game>

With kids there is an even bigger factor in play - control. Normally, a child is not able to punish its sibling. Under this adult-administered scheme, the child actually has the power to send its sibling to its room! If you know how kids crave to be able to control their situation, you realise this must be like Santa Claus and the Easter Bunny rolled into one.

A long-winded way to say: I am _so_ not surprised, and mildly confused as to why the Freakonomics blog would be.

<comment><USER3> there was an interesting paper last year that said that refusal behavior at the ultimatum game was limited to westerners: [http://www.nationalpost.com/Westerners+World+weird+ones/3427...](http://www.nationalpost.com/Westerners+World+weird+ones/3427126/story.html)

<comment><USER4> That could have something to do with the relative size of the reward offered. If the average daily income in a country is $1, then any split of $100 is going to be significant.

Add a couple of zeroes on to it to see how a 'westerner' might feel about it. Of course, the researchers aren't going to be able to offer too many people a split of 10 or 100 grand in a western city before they are stampeded to death...

I know if I was in this game and they had to split 50 grand and 'only' offered me 10 grand I'd think a lot harder about turning it down than an 80:20 split of $100.

On the other hand, I wonder if there is a link in western society between how good the person is at handling their own finances, and how even the split has to be before it would be accepted. I can think of a few examples of 'angry and poor because of it' people who would demand nothing less than 50:50, and would grumble even at that, they always believe that they _deserve_ more than everyone else. It seems to me the very epitome of the poverty mentality.

</comment></comment></comment><comment><USER5> My favorite comment from the article, and something I'll be trying on my kids:

"Our kids played upstairs in a bonus room. If I heard fighting I'd go upstairs and break it up, then proceed to find all kinds of things that needed to be cleaned. The bonus room was always a mess.

It didn't take many iterations of that process before I started hearing fighting, then "shhh! Do you want dad to come up here and tell us to start cleaning up?!"

<comment><USER6> Yep I've done this myself with the kids. Classic stuff!

</comment></comment><comment><USER7> Good way to teach the kids to team up against the parents.

There isn't some secret to raising kids. Just create good/bad consequences for good/bad behavior. Make sure they understand you love them, and your goal is to teach them to be good. Their behavior is simply choosing the method in which they are taught.

<comment><USER8> But there is a secret: The goal is not to raise good kids. The goal is to raise good adults.

<comment><USER9> >The goal is not to raise good kids. The goal is to raise good adults.

This sounds like an empty aphorism to me. I don't want my kids to be just good adults I want them to be good kids too. I don't mean good in the sense of undemanding behaviourly or conforming or that sort of thing I mean I want them to be fulfilled as much as possible in their childhood too, happy.

Someone just accused me of being unnecessarily argumentative so I'm wary of that. But, really one does have to define what a good adult is and consider what you mean to obviate by "not [raising] good kids".

<comment><USER8> I find it to be far from empty, and it helps me in my decisions. _shrug_

Raising good adults does not preclude raising good kids, so I do find your response to be a bit combative. Just because you have one clear goal in mind does not mean that other goals are not achieved along the way.

I don't really want to get into details of how I apply this concept to my parenting -- my reason for posting was exactly the opposite. I want parents to stop (for a moment) focusing on the details, stop worrying about specific techniques, and look at the bigger picture - what are you really striving for over the next 5, 10, 20 years with your kids? And are your current actions supporting that?

<comment><USER9> >Raising good adults does not preclude raising good kids, so I do find your response to be a bit combative.

It's the "not to raise good kids" part that turns me off. Surely it should be "to raise good kids _and_ good adults"?

</comment></comment></comment></comment></comment><comment><USER10> One comment said their son did well at piano, causing their daughter to give up, causing the son to stop in sympathy.

I don't have kids, but I thought maybe if they tied each child's reward to how well their siblings did. Does anyone have any experience with this sort of incentive structure?

</comment><comment><USER11> Interesting coincidence. My daughter got her first timeout yesterday for hitting her brother.

The "game" she wanted to play with me last night was to give me timeouts.

<comment><USER12> How do you deal with that? I always get mildly annoyed when my 4yo daughter does that, but I feel that is not the right way to go about this.

<comment><USER9> I sit them on "the step" (which is any step in a quiet place where they're supposed to think about their actions). Hence I get told "you've got to sit on the step" when they don't like one of my edicts for some reason.

I simply challenge their dislike, if I am wrong (illogical, false premise, unnecessarily tedious, or whatever) then I apologise and we continue. Generally they do not want to listen to [my] reason as it compels them to accede although I am [shock horror] proven wrong occassionally (at this stage it tends to be on matters of fact). I guess I could get in trouble when they argue for a democratic right or somesuch at which point they learn about parental autocracy ...

</comment></comment></comment><comment><USER13> I'm sorry to see the non-critical acceptance of punishment, even a time-out, as an appropriate or effective parenting option.

The Case Against Time-Out <http://www.naturalchild.org/guest/peter_haiman.html>

22 Alternatives To Punishment <http://www.naturalchild.org/jan_hunt/22_alternatives.html>

</comment><comment><USER14> It is time now to talk about The Wheel: [http://www.metafilter.com/58583/Youre-so-smart-you- probably-...](http://www.metafilter.com/58583/Youre-so-smart-you-probably- think-this-post-is-about-you#1588699)

</comment><comment><USER15> Awesome - someone should expand this idea into a book!</comment>


Ask HN: Resources to learn Metal iOS - <AUTHOR> What useful resources can you recommend to learn Metal for iOS development? <comment><USER2> I picked up this book by Janie Clayton, it's pretty good: [https://www.amazon.co.uk/Metal-Programming-Guide-Tutorial- Re...](https://www.amazon.co.uk/Metal-Programming-Guide-Tutorial- Reference/dp/0134668944/ref=sr_1_1?ie=UTF8&qid=1530452201&sr=8-1&keywords=programming+metal)</comment>


Ask YC: Is google mail down for anyone else?  - hafeez-bana

It seems mail.google.com is timing out and so is the username password dialog box at http://www.google.com/analytics/<p>The search seems to be working! <comment><AUTHOR> It is not down for me. A helpful site - <http://downforeveryoneorjustme.com/> \- although ironically it doesn't seem to be working.

</comment><comment><USER2> Both accounts are working fine for me.</comment>


The Year 2038 Problem - <AUTHOR> https://en.wikipedia.org/wiki/Year_2038_problem <comment><USER2> Relevant?

Trump Orders Government to Stop Work on Y2K Bug, 17 Years Later

[https://www.bloomberg.com/news/articles/2017-06-15/trump- ord...](https://www.bloomberg.com/news/articles/2017-06-15/trump-orders- government-to-stop-work-on-y2k-bug-17-years-later)

<comment><USER3> It's just a stop to the paperwork required for Y2K compliance. It's outdated by today's standards but back in the late 90s, early 2000s is wasn't uncommon to run into old software (DOS, Netware, old school UNIX, mainframes, etc.) in major corporations.

</comment></comment><comment><USER4> We still have plenty of time.</comment>


Open Source Hardware Hackers Start P2P Bank - <AUTHOR> http://blog.wired.com/gadgets/2009/03/open-source-har.html <comment><USER2> Following lines of abiratry regulations and rules is a headache. It might be doable for a large bank but not so much for a small decentralized banking operation.

</comment><comment><USER3> This is a very cool idea. I'd love to see more open source hardware/software combo projects, and this is a great way to kickstart that.</comment>