skysight-inc/HackerNews huggingface dataset:
But you still try. =)

The title contains that "bold statement" to incite a response.

There are numerous fallacies in your article. I believe it's a misunderstanding of certain aspects.

> writing code in a test-driven way bypasses your brain and makes you not think properly about what you are doing.

You should not just start writing code blindly. You should have a clear understanding of the problem up front. When you start coding, it should be done after you have a plan.

> Furthermore, true 100% code coverage by tests is a myth: no matter how many good tests you write, not all cases will be covered.

Code coverage measures the code you've written tests for. It in no way promises to cover all cases. This is not a deficiency in code coverage, merely it's understanding.

> Therefore, mindlessly modifying code until all tests pass is likely to introduce new bugs for which no tests exist.

Ignoring the other parts of this that make no sense, I propose that mindlessly modifying code without tests will introduce bugs.

> Algorithms must be understood before being modified, and modifications must be done as if no tests exist at all.

I don't understand this. Of course they must be understood. TDD does not remove this requirement. I'm also not sure how modifications must be done as if no tests exist? Maybe you mean to suggest that optimizations in algorithms must be applied all at once, and cannot be made in small, incremental changes?

> You apply the optimisation, and some tests start failing.

Whereas if you did not have tests, you might not know this.

> But how can you be sure that the algorithm still works? How can you be sure that the mindless modifications did not introduce edge cases that were not tested before?

How can you be sure that your algorithm worked before in all cases? How can you be sure, without testing, that your changes still work?

You really are making a straw-man. You are effectively arguing that TDD doesn't prove something that TDD doesn't promise. In fact, your premise - "no matter which software development methods you use, do not forget to use your brain." - and your title imply clearly that TDD doesn't encourage using your brain.

That's most assuredly not true.

P.S. I hope I don't sound harsh. I'm not trying to belittle or insult you. =)
Al Jazeera report on Irish plan to sell off its forests
How did that happen? (similar situation, earlier in the game)
I think Europeans are just not as open (read: non-racist) as they claim to be, while Americans are the opposite: they are not as closed as they appear to be, they just let all their anxiety out first and then just assimilate as normal.

Or let's put it this way: the French go out of their way to push a "French" culture on their immigrants; whereas "American" culture isn't really defined and is very organic, meaning, like gravity, we all tend to just converge.
This is how you end up on the path of calling your work force human capital. Don't go down that path.

Your definition would also include entrepreneurs. There might be a good one here and there, but I could just walk into any coffee shop and pick up another one.
this reminds me of a joke I've heard (poorly translated):

"How do you win a 100m swimming race? You start at your absolute top speed, and slowly slowly increase the pace"
Interesting, but I am not sure that script dependency needs to be in a cron-like tool.

I've always thought that once you start needing such functionality then it's better that you move your logic to your scripts or timed-tasks system. Because soon, setting variables won't be enough and you're implementing hacks on top of hacks.
People don't even understand the implications after the tech arrives.

I have a fond memory of walking around San Francisco at a conference with a bunch of friends, perhaps a year after the original iPhone was released, and most of them had one. We all decided to go to a particular restaurant or bar, and there was a long discussion about where it was. Finally I pointed out that at least half the people trying to figure out where it was had a device in their pocket that could simply tell them in a few seconds. They just hadn't thought of it.

I still see people today, techies too, doing the same basic thing. It's getting less common, but it's still pretty common.
Sure you will still have bugs. The question is whether the reduction in bugs due to TDD outweighs the increased investment in developer and tester time.

Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it. Not to mention the detrimental impact on build times.

All of that aside. Have you noticed how there are no decent metrics available for TDD's effectiveness ?
100mg in the morning although some of my friends take 200mg. 100mg is enough for me to keep me awake/motivated/focused to about 4-5pm; rest of the day is ok as well and I usually sleep very well after that (interestingly I need less hours of sleep having taken modafinil in the morning).
Depending on country you can get it from various sources in some (UK for example) you can just order it from India 100% legally. In US it's more of a problem but people still get it. Try reddit/r/nootropics for a start (and recommended places to get it). I also like /r/ADHD for community/support.
Please consider what I wrote as personal very subjective testimonal and in no way an advice, let alone medical. If you decide to take any drugs please at least read about possible negative effects/precautions you should take.
The other day, my daughter brought me a CD off the shelf and asked me to play it. Well, the CD player was all the way over there, terribly inconvenient, while my phone with Spotify was in my pocket. CD went back on the shelf, music played from the cloud.

The future is weird.
I think long-term productivity seems to come mostly from consistent, intense effort. I've read that a lot of writers only write for about three hours a day. The key is that they do this every day and it adds up. If you just put in a few hours a day of intense work, over time, you will accomplish a lot and be ahead of most people. For example, John Grisham started writing books by writing just one page every day. The best producers, however, seem to combine intense work with lots of time. Isaac Asimov worked many hours a day and published 1700 words per day on average. (http://www.jamesaltucher.com/2011/11/5-unusual-things-i-lear...)

To acheive consistency, you can't sabotage tomorrow's work by working late today. So 100% completion of today's work should be a goal in the context of the understanding that today's work has a definite ending time that is necessary to enable a successful tomorrow.

Here's an article on deliberate practice: http://graphics8.nytimes.com/images/blogs/freakonomics/pdf/D...

Here are two articles that give some insight into how writers work:
http://io9.com/5106135/science-fiction-novelists-reveal-thei..., http://www.onlinecollege.org/2010/01/11/25-famous-thinkers-a...
Reading through the sci-fi tropes of this article, they could have just gone with "2013 is the same as 1988 but with networked computers", and saved a great deal of paper.

25 years is not remotely long enough for a city in the developed world to have more than a smattering of new buildings, and yet the future LA they came up with is utterly transfigured into a Syd Mead utopia. I love a bit of Mead, but Blade Runner was set in 2019, and I'm not sure that our attack ships have even reached the Shoulder of Orion yet, much less caught fire!

So what will 2038 look like? Pretty much like 2013, but most of the cars will be electric. But they'll still look like cars, not space-cruisers, and they won't fly (often).
The problem isn't the advice, it's the misunderstanding of that advice. Thinking about a problem should happen, and when you sit down to code, you should already know what needs to happen. TDD doesn't propose to replace planning and thought.
I have no recollection of ever even hearing of approximately 3/4 of those.
Exactly right. A moral high ground built on an axiom of 'our citizens are now deserving of human rights than anyone else's' is more of a moral tar pit than a high ground.
Keep in mind that it's actually your desire to meet their expectations that's at play here.

You can also go back and tell them that your previous speed is probably an outlier, but you don't/didn't do that because you want to maintain this high level of expectations.

I'm not sure I'd even advice against it, since that mechanism is what kept me improving until 30, but at one point it'll also pull you beyond what your physical limits ... and that, my kids, is how I me^H^Hgot a burnout ;)
Dijkstra's quote reminds me of Knuth's "Beware of bugs in the above code; I have only proved it correct, not tried it."
He also completely overlooked the refactoring part of the equation, too: write test(s), write code that passes all the tests, then refactor the code until it's shiny enough and still passes the tests.
X Who Programs vs Just A Programmer
This sounds a bit like "we don't need no stinking testing", but I know the author is trying to hit at a deeper point. I only wish he had done better.

One of the problems here is language: TDD as a general concept can cover everything from high-level behavioral testing to a method-by-method way to design your program. There's a big difference between those two!

In general, of course, programming is balancing what the program is supposed to do with how the program is constructed. That's true whether you have TDD in the mix or not.
I have gone through my life with one rule, anyone who is providing me a service I address by Sir or Ma'am. I do not care if its the order taker at McDonalds, the register operator at Wal-Mart, or my Doctor. They are people performing jobs whose service I need or may need, I respect anyone out there earning a living for themselves and their families. For myself it puts everything in perspective, we are all trying to make it in this world and there is nothing to gain by disparaging the position of others.

There are times where I really like the people at McDonalds than those I work for, the pretentiousness at times is discouraging.
We are giving away PrePayMe.  Looking for someone to take it over.
Yeah, I'm amazed that people consistently run around reinventing the wheel, when there are 18-wheeled chariots out there free for the grabbing.
Its working just fine here...
If I only were in the past. I've seen this behavior with coworkers, changing random bits of the code, without any coherent system to speak, rerunning the application from scratch and manually testing if it works now.

I can't describe how shocked I was.
It's not an @gmail.com address.

And why do people keep making excuses for Google?

Google simply isn't very good at filtering spam, something most regular ISP's can handle perfectly well, and the lack of options in Gmail and Groups clearly show that they don't care very much about it either.
You're supposed to refactor your code. Layering tests on top of tests means that you end up spending more time maintaining tests than writing code.

Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.
> Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it.

I do not know your environment, but TDD does not add 2-3x longer for most everyone I know that practice it. This is especially true when you factor in total development time. Most estimates I see place TDD making the project take 15-30% longer.

> All of that aside. Have you noticed how there are no decent metrics available for TDD's effectiveness ?

Not sure what you mean by that. There are metrics you can use (how else could they do studies on this?). It's been proven time and time again in studies (some are linked in these threads here).
Shannon Larratt has passed away
http://news.bme.com/2013/03/15/rip-shannon-larratt-1973-2013
(link may be considered NSFW by some)

https://en.wikipedia.org/wiki/Shannon_Larratt

http://www.zentasttic.com - personal blog

His final post - which was posted to and then removed from his site is here: http://pastebin.com/uGQKSVUP
They're relatively safe for any given individual, but overall they're still a huge factor in sudden cardiac arrest at this age.
People always ignore the refactoring. They also look at the time TDD adds merely in terms of individual sessions. They don't look at the project as a whole.

> Also, don't test stuff that isn't going to break

Hah! =) But how will I prove that i++; is actually incrementing i!
Yes, it's all a big conspiracy. Maybe there are some aliens involved too.

Why do some people always assume bait/trolling when no such thing appears even remotely possible (as is this case, which is a well reasoned and argued post), is beyond be.

You might disagree with the author, but we tries and provides arguments for what he writes.
The "bold statement" is a little too bold. It goes from:

| writing code in a test-driven way bypasses
| your brain and makes you not think properly
| about what you are doing.

(Test Driven Development makes you not think properly and bypasses your brain) to:

| no matter which software development methods
| you use, do not forget to use your brain

"Just don't mindlessly program."
I don't think this article gets it quite right.

I think non-technical people that do best stumble into the tech scene - rather than want to get in. By this I mean if you want to make it anywhere - especially in a world where you have none of the technical skills needed to actually build anything - you have to LOVE it. And that love comes from a deep and not-too-well-understood place within us. The kind of place which is not very easy to access with the cognitive part of your brain that lets you create the sentence 'I want to get into the tech scene now - but I know nothing - what steps can I take?'.

I am (sadly) non-technical (for now (but learning!)) - an Economics graduate who was on the path to investment-bankdem - but I couldn't help myself but be part of the tech scene. Some old colleagues from a hedge fund I interned at wanted to start a community for motorcyclists and, as I was young and more tech savie than them, they asked if I wanted to help out. It was (and still is) SO much fun thinking about how someone could use things - have an enjoyable experience, gain value, and try to find a way for us to extract a little value too. That is such a beautifully complex challenge to think through.

Our budget for the build was £25,000 - which is how much I thought it cost to build a website - so my plans for my own ideas had to go on hold - as I didn't have that kind of cash. Then a friend told me he got a website built in Romania for £2,000 - I can afford that!!! I designed my first website in microsoft word - from top to bottom - and sent my files over to Romania, greatly confusing the web agency who had never received 30 microsoft word files as the basis to build off. I was learning Spanish in Spain at the time and happened to meet an awesome German graphic designer. He took me through my designs and showed me why they sucked, and he told me about a program called InDesign. I came back to England and learnt that.

Since then I've won prizes for tech entrepreneurship, worked in a company that existed to build other tech companies, built a team of 6 around one of my core ideas, and learnt a little front end code myself. I would love to say - the rest is history - but now I am learning how to execute on ideas. Something which I have not yet done well enough.

But the point is I couldn't help any of this. And I think if you have to force yourself to read PG, or it is a 'I want a job', not a 'I want to build what's in my head!' mentality that makes you write your first piece of code - then maybe the tech world is not the place you really want to be.
Lifecycle emails with KissMetrics
Rcarmo/rss2email
I admit I did fall into that trap once, long ago. I’m very aware of the consequences now.

The reason for writing the article, however, is because I have seen the same mindless behaviour with other people as well.
Hi nirmel

Sorry to tack this on here, but any chance I can give you a call or an email? Wanted to ask you a couple questions as I'm developing a product in this field as well (don't think it competes with lawdingo).

Bruno
Tools And Frameworks for Unit Testing in .NET for 2013
It, RSS Subscription Extension (by Google) v2.2.0, is still installed and working in my Chrome. It does not seem to use any backend service. It just reads RSS information on a webpage and creates subscription links for you that go to the RSS webreader of your choice (I've been using Google Reader with it).

But, the extension's website has been removed: https://chrome.google.com/webstore/detail/nlbjncdgjeocebhnmk...

I believe that version (the original) was written by a Google employee, Finnur Thorarinsson (finnur at chromium.org): https://plus.google.com/104317586100499660731/posts

Another extension claims to be a fork, but I don't know any specifics: https://chrome.google.com/webstore/detail/rss-subscription-e...
It sounds like you've had some bad experiences. I'm not sure that you could attribute unwieldy spaghetti code to the use of TDD though. Do you believe the projects you've worked on with TDD would have been in better shape without TDD?
The problem is that that right now in the software industry:

TDD, Agile, Scrum, XP etc are a religion.

And a lot of people have managed to make their lives easier by making the teachings of this religion mandatory. So what I've been witnessing the last few years is that saying "no I don't think we need a test for this" is a position that will get you no where. So instead every one just puts up with longer and longer build times and spending more time each day fixing broken tests.
Nice collection of stories.

The photos on the main feed are stretched on my phone, making everyone's head look extra wide.
I also have the same problem the author has sometimes: If I know that there are a lot of tests covering a particular piece of code, I tend to be less diligent making modifications
I don't use Thunderbird, but I do like the idea of getting RSS feeds as email. I'm trying out http://blogtrottr.com
Moral of the story: Coding mindlessly can be almost as bad as blogging mindlessly.
Usually this makes people go for very simple solutions without thinking properly what are the right data structures and algorithms for the problem at hand.

I rather write proper designed code and write the tests afterwards, before delivering the code.
Fair enough, I do admit my experiences with TDD are pretty much limited to writing the game of life several times at a code retreat where thinking too much ahead of time was somewhat verboten and talking with TDD practitioners that suggest the best solution to solving a problem is to write some tests, then take some "baby steps" until the problem is solved. I always get the impression it seems to lead into a somewhat absurd situation, such as the one described in [1].

What do you think would be a good reference with regards to TDD practices, as opposed to "I saw some people do it and it looked seriously wrong?"

[1] http://programmers.stackexchange.com/questions/109990/how-ba...
Come work to the enterprise world where no one cares about whatever the cool kids are proposing.

If the customer does not request for unit tests on the contract, usually no program manager is enforcing people to waste time writing them.
It's pretty ironic that they would pull this right after this BuzzFeed article on developers' problems with the platform: http://www.buzzfeed.com/jwherrman/this-is-facebooks-midlife-....
I find TDD to be useful in two cases:

1. When I already know what I'm doing and it's just a matter of coding what's already in my mind

2. When I'm writing in a dynamically typed language, it forces me to be not lazy and have adequate test coverage since I don't have compile time type safety

I do less of TDD when dealing with a statically typed language and/or when I'm working in an exploratory mode. TDD doesn't help me when I'm just trying out different things to get going.

The thing that pisses me off is when people don't realize that EVERY technique has caveats and try to promote it as a golden rule - a lot of "agile" consultants preach TDD as the golden grail for writing code without any bugs.

EDIT: grammar
It's going to be similar in terms of audience, but less focused on in-depth understanding of each framework and more focused on practical, hands-on learning. I'm a firm believer in experiential learning – I'd rather have someone learn about the NSString class organically through using it than have a chapter devoted to it.
There's Cheatography.com (my site), where you can make your own cheat sheets.
There are also programs and services to send you your RSS feeds by email.

Rss2email is a Python program you run periodically on your own computer. http://www.allthingsrss.com/rss2email/

Blogtrottr is an online service: HTTP://blogtrottr.com
Could we please stop arguing? This back-and-forth with absolutes is akin to useless political campaigning. http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsO...

(More specifically, read everything from the "The Pragmatics: So when do I not practice TDD?")
For the first issue, you might check out newsblur. Basically solves the clicking through to the original issue perfectly.

The second I completely agree with you on. Even these cool readers that prioritize stuff you're most likely to read, by necessity, keep track of what's read and unread, and I get exactly that same itch that I need to stay on top of everything. It's completely artificial and almost ridiculous, but there it is. And I can't imagine how a reader could solve that problem without creating the even worse worry of missing things. (Which ironically evaporates when you don't use a reader and therefore no longer expect not to miss anything.)

Perhaps there is a novel solution there though, waiting to be discovered.
That's an overly cynical take - I've seen both TDD, Agile and Scrum work really well. In any case, refactoring is part of the religion too, so it shouldn't be too hard a sell for you.

And it'll fix build times and broken tests! :)
There's a reason I'm running full nightly mirrors of all of our private and public GitHub repositories...

The same applies to services. They can end tomorrow. Well, maybe not that fast, but how fast can you shift your business to an alternative without paying a terminal penalty?

We can't run without GitHub for more than a week, so we have to be able to get out in less. Same goes for AWS. Besides snapshots we run old-school backups to ensure we can recover on old-fashioned bare-metal if necessary.

Using those services, great. Letting our business depend on them? Never.
If you're coding mindlessly doesn't that by definition mean you've bypassed your brain?
http://www.dalkescientific.com/writings/diary/archive/2009/1... is a much better article about the problems with TDD.
I did Code Year and was pretty critical of it (I've blogged about it but won't spam here!), particularly as it got less and less immediately practical over the course of the year and spent the last 3 months doing Python (which was bad enough for me who has experience with PHP, HTML/CSS, and JS) I hate to think what it'd have been like for people still getting their heads around coding!
Cool - I can have my robo-butler read this article to me while we're jetpacking our way to the spaceport.
I'm pretty sure that all of those things are legal.
Let me settle this for you guys.

"There is an inherent risk associated when developing on top of someone else's platform. It's your job as a business creator to identify that risk very early on and mitigate it as much as possible. It is impossible to eliminate. Blindly assuming it's not a risk, can easily lead to large stakeholder management problems down the line."
Massive adoption and wide use of contraceptives would do the trick.