The Failures of "Intro to TDD" - <AUTHOR> http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-tdd.html <comment><USER2> I think this is a great explanation of a lot of the obvious pitfalls with "basic" TDD, and why so many people end up putting in a lot of effort with TDD without getting much return.

I personally have kind of moved away from TDD over the years, because of some of these reasons: namely, that if the tests match the structure of the code too closely, changes to the organization of that code are incredibly painful because of the work to be done in fixing the tests. I think the author's solution is a good one, though it still doesn't really solve the problem around what you do if you realize you got something wrong and need to refactor things.

Over the years I personally have moved to writing some of the integration tests first, basically defining the API and the contracts that I feel like are the least likely to change, then breaking things down into the pieces that I think are necessary, but only really filling in unit tests once I'm pretty confident that the structure is basically correct and won't require major refactorings in the near future (and often only for those pieces whose behavior is complicated enough that the integration tests are unlikely to catch all the potential bugs).

I think there sometimes needs to be a bit more honest discussion about things like: * When TDD isn't a good idea (say, when prototyping things, or when you don't yet know how you want to structure the system) * Which tests are the most valuable, and how to identify them * The different ways in which tests can provide value (in ensuring the system is designed for testability, in identifying bugs during early implementation, in providing a place to hang future regression tests, in enabling debugging of the system, in preventing regressions, etc.), what kinds of tests provide what value, and how to identify when they're no longer providing enough value to justify their continued maintenance * What to do when you have to do a major refactoring that kills hundreds of tests (i.e. how much is it worth it to rewrite those unit tests?) * That investment in testing is an ROI equation (as with everything), and how to evaluate the true value the tests are giving you against the true costs of writing and maintaining them * All the different failure modes of TDD (e.g. the unit tests work but the system as a whole is broken, mock hell, expensive refactorings, too many tiny pieces that make it hard to follow anything) and how to avoid them or minimize their cost

Sometimes it seems like the high level goals, i.e. shipping high-quality software that solves a user's problems, get lost in the dogma around how to meet those goals.

<comment><USER3> > When TDD isn't a good idea (say, when ... you don't yet know how you want to > structure the system)

(Apologies in advance as I can't figure out how not to sound snarky here.)

Isn't that called "the design? And is there any meaningful way in which, if "test-driven design" fails if you don't already have the design, it's worth anything at all?

<comment><USER2> Sure, you can call that structure the design, or the architecture, or whatever you like. Either way, it's a fair question.

As a point of semantics: TDD generally stands for "test-driven development," not "test-driven design," though the article here does make the claim that TDD helps with design.

To reduce my personal philosophy to a near tautology: if you don't design the system to be testable, it's not going to be testable. TDD, to me, is really about designing for testability. Doing that, however, isn't easy: knowing what's testable and what's not requires a lot of practical experience which tends to be gained by writing a bunch of tests for things. In addition, the longer you wait to validate how testable your design actually is, the more likely it is that you got things wrong and will find it very painful to fix them. So when I talk about TDD myself, I'm really talking about "design for testability and validate testability early and often." If you don't have a clue how you want to build things, TDD isn't going to help.

If you take TDD to mean strictly test-first development . . . well, I only find that useful when I'm fixing bugs, where step 1 is always to write a regression test (if possible). Otherwise it just makes me miserable.

The other thing worth pointing out is that design for testability isn't always 100% aligned with other design concerns like performance, readability, or flexibility: you often have to make a tradeoff, and testability isn't always the right answer. I personally get really irked by the arguments some people make that "TDD always leads to good design; if you did TDD and the result isn't good, you're doing TDD wrong." Sure, plenty of people have no clue what they're doing and make a mess of things in the name of testability. (To be clear, I don't think the author here makes the mistake of begging the question: I liked the article because I think it honestly points out many of the types of mistakes people make and provides a reasonable approach to avoiding them.)

<comment><USER4> I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem.

One point I'd like to draw out. _If you don 't have a clue how you want to build things, TDD isn't going to help._

This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build. I think that's the greatest benefit to TDD: it forces you to stop typing and think.

<comment><USER5> Exactly. This is the whole purpose behind the "spike" \- make a branch, write a crap implementation of some code to help understand the problem, put it aside. Then go write the production version TDD style. Once you understand the problem, you can use TDD to create a good design to solve that problem.

Sounds crazy, but this is how I do everything I don't understand. And my second implementation is usually better than my first.

<comment><USER4> Or, in the words of Fred Brooks, build one to throw away. I'm always amazed at how prescient he was.

Unfortunately I find all too often that spike project finds its way into production for one reason or another. Now I only spike in Befunge.

</comment></comment></comment></comment></comment></comment><comment><USER6> I have tried many times to do TDD. I find it extraordinarily hard to let tests drive the design, because I already see the design in my head before I start coding. All the details might not be filled in, and there are surely things I overlook from the high-up view, but for the most part I already envision the solution.

It's difficult to ignore the solution that is staring my brain in the face and pretend to let it happen organically. I know that I will end up with a worse design too, because I'm a novice at TDD and it doesn't come naturally to me. (I'd argue that I'm a novice at everything and always will be, but I'm even more green when it comes to TDD)

I have no problem writing unit tests, I love mocking dependencies, and I love designing small units of code with little or no internal state. But I cannot figure out how to let go of all that and try to get there via tests instead.

I don't think that I'm a master craftsman, nor do I think my designs are perfect. I get excited at the idea of learning that the way I do everything is garbage and there's a better way. If I ever learn that I'm a master at software development, I'll probably get depressed. But I don't think my inability to get to a better design via TDD is dunning-kruger, either.

I want to see the light.

<comment><USER7> Maybe you're over thinking it? It sounds like you're already doing the right things.

 _All the details might not be filled in, and there are surely things I overlook from the high-up view, but for the most part I already envision the solution._

The design part of TDD is just the expectations. So if you were to test an add function for example, you might write something like

      assertEqual(add(5,2), 7)
      assertEqual(add(-5,2), -3)
      assertEqual(add(5,-2), 3)

before actually implementing the function. So here the design is that the add function takes 2 arguments. That's it.

For other things like classes, your expectations will also drive the design of the class -- what fields and methods are exposed, what the fields might default to, what kinds of things the methods return, etc. Your expectations are the things you saw in your head before you start coding. So it's pretty much the same as what you do already. The benefit of TDD is in knowing that you have a correct implementation and you can move on once things are green.

One thing that's easy to misinterpret is that TDD doesn't mean writing a bunch of tests before writing any code...That's pretty much waterfall development. TDD tends to work best with a real tight test-code loop at the function level.

<comment><USER8> Incidentally for functions like that, if you have an environment that supports a tool like QuickCheck[1], it's a great thing to use. "The programmer provides a specification of the program, in the form of properties which functions should satisfy, and QuickCheck then tests that the properties hold in a large number of randomly generated cases."

1: [http://www.cse.chalmers.se/~rjmh/QuickCheck/](http://www.cse.chalmers.se/~rjmh/QuickCheck/)

</comment></comment></comment><comment><USER9> The comments section today looks like a support group for beginners/intermediates who struggled with TDD and gave up, and so want to explain why it's all bunk. I get this. I am not a great programmer. I'm self taught like a lot of you. I had tremendous difficulty grokking TDD and for the longest time I'd start, give up, build without it.

But, I'm here as a you-can-do-it-to. You might not think you want to but I'm so glad I DID manage to get there.

Feel free to ignore because I respect that everyone's experience differs. But the real problem is that there are few good step by step tutorials that teach you from start to competent with TDD. Couple that with the fact that it takes real time to learn good TDD practices and the vast majority of TDDers in their early stage write too many tests, bad tests, and tightly couple tests.

Just as it's taken you time to learn programming - I don't mean hello world, but getting to the competent level with coding you're at today, it'll take a long time to get good with TDD. My case (ruby ymmv) involved googling every time I struggled; lots of Stack Overflow; plenty of Confreaks talks; Sandi Metz' POODR...

Like the OP says - at different stages in the learning cycles you take different approaches because you're better, it's more instinctive to you. I thought I understood the purpose of mocks/doubles, until I actually understood the purpose of mocks/doubles. When used right they're fantastic.

The key insight that everyone attempting TDD has to grok, before all else, is that it's about design not regression testing. If you're struggling to write tests, and they're hard to write, messy, take a lot of setup, are slow to run, too tightly coupled etc. you have a design problem. It's exposed. Think through your abstractions. Refactor. Always refactor. Don't do RED-GREEN-GOOD ENOUGH ... I did for a long time. It was frustrating.

This is a good post. Don't dismiss TDD because you're struggling. Try to find better learning tools and practice lots and listen to others who are successful with it.

It's true that sometimes fads take hold and we can dismiss them as everyone doing something for no reason. But cynicism can take hold too and we can think that of everything and miss good tools and techniques. TDD will help you be a better coder - at least it has me. If your first response to this post was TDD is bullshit, give it another try.

<comment><USER10> "If you're struggling to write tests, and they're hard to write, messy, take a lot of setup, are slow to run, too tightly coupled etc. you have a design problem."

This is my problem exactly, and I wouldn't say I have a design problem. My application is a Django app that return complex database query results. Creating the fixtures for ALL of the edge cases would take significantly longer than writing the code. At this stage it is far more efficient to take a copy of the production database and check things manually. It helps that my app is in house only, and so users will report straight away when something isn't working.

But to say that I have a design problem because tests are going to be difficult to implement is just plain wrong.

<comment><USER9> sure... it can be more broadly stated "you have a design problem and/or you're testing the wrong things"

</comment></comment></comment><comment><USER11> The approach outlined actually makes much more sense without OO. I guess the WTF comes from forcing yourself into a world of "MoneyFinder", "InvoiceFetcher", etc. Makes it look a lot more complicated and prone to error than it is, because you're now supposed to mock objects that may have internal state. Otherwise it's the usual top-down approach with stubs.

<comment><USER12> Yeah I think it's interesting that the final approach with "logical units" and "collaboration units" mirrors a functional approach with "functions" and "higher-order functions". The advice to write small "logical units" could also just be "write pure functions". The complex class hierarchy in the final example could probably be avoided entirely if you were using a language with first class functions. As a bonus, in a functional language the "collaboration units" have probably already been written and tested for you.

<comment><USER13> I'm not sure if the current draft says so, but I talked about how the logical units ought to be "pure functions" most of the time at some point.

</comment></comment></comment><comment><USER14> I think that Red-Green-Refactor is as much about learning to habitually look for and recognize the refactoring opportunities as it is about being meticulous in reacting to those opportunities.

It's true that nothing forces your to refactor - but I think wanting that is a symptom of treating TDD as a kind of recipe-based prescriptive approach. It is not a reflection of the nature of TDD as a practice or habit.

It's a subtle difference, but important:

A recipe says "do step 3 or your end result will be bad"

A practice says "do step 3 so you get better at doing step 3"

</comment><comment><USER15> The more I try to explain TDD, the more I realize that some of my favorite concepts, like the ability to mock functionality of an external process because the details of that process should be irrelevant...is just beyond the grasp of most beginners. That is, I thought/hoped that TDD would necessarily force them into good orthogonal design, because it does so for me...but it seems like they have to have a good grasp of that _before_ they can truly grok TDD.

Has anyone else solved this chicken and the egg dilemma?

<comment><USER13> This was indeed my motivation for writing the post. I think the _next_ step to take if you agree with my premise is that we need to come together with ideas for how to best _teach_ TDD to beginners/novices. Exercises that promote these concepts, lines of reasoning to take, tools to get people started without any unnecessary cognitive overhead, etc.

I agree that teaching TDD exactly how I do it today can be a bit overwhelming from a tooling perspective currently, but conceptually I think visualizing it as a reductionist exercise with a tree graph of units is pretty simple.

<comment><USER5> One thing I do with my beginning programming students (since their programs are tiny) is make them write out "test plans" on paper before they can write their program code.

They have to write the inputs and then the expected results.

It gets them thinking about the concept of using tests as part of the design practice.

Later, I give them the unit tests and they have to write the code. This is usually a rewritten version of a previous program so they see the text-based test plans in action as unit tests.

Then I might give them the empty test and an empty implementation, asking them to fill in the test first, then the implementation.

Finally I ask for a completely new feature, and they have to figure out how to write the test. And I ask them to go about it with a test plan.

After a few semesters of this, I think I'm ready to say that this is successful for getting the "beginners" there.

It doesn't address everything, but I think it's a good start.

</comment></comment></comment><comment><USER16> I wonder about these workshops (even asked Uncle Bob Martin about them in a recent thread). I can't shake the feeling they are the exact opposite of agility (obviously, he is better qualified than me to judge that). Their limited time schedules, which is essentially a bound over the amount of contact between the client and the supplier, seems analogous to the infamous "requirements document". Also, there doesn't appear to be a "shippable" product at the end - the developers apparently don't end up practicing TDD.

I used to be an instructor for a living, and I kind-of equated lectures to waterfall and exercises to XP. There is even a semantically analogous term in teaching research, problem-based learning (each word corresponds to the respective word in test-driven development - cool, right?). Is there anyone else who sees these analogues, or am I completely crazy here?

<comment><USER17> Uncle Bob responds: [https://news.ycombinator.com/item?id=7139961](https://news.ycombinator.com/item?id=7139961)

</comment></comment><comment><USER18> Might one of the problems be that we place too much importance on the "symmetrical" unit test. In your example the child code is still covered when it is extracted from the parent.

As a developer that often prefers tests at the functional level, the primary benefit of tests for me is to get faster feedback while I am developing.

<comment><USER13> The trouble with abandoning symmetrical unit tests is that:

* The unit is no longer portable and can't be pulled from the context it was first used in (e.g. into a library or another app) without becoming untested. And adding characterization testing later is usually more expensive * A developer who needs to make a change to that unit needs to know where to "test drive" that change from, which requires that they know where to look for the parent's test that uses it. That's hard enough but it completely falls over when the unit is used in two, three, or more places. Now a bunch of tests have to be redesigned and none of them are easy to find. * Integrated unit tests like this lead to superlinear build duration growth b/c they each get slower as the system gets bigger. This really trips teams up in year 2 or 3 of a system.

<comment><USER18> Unless I'm missing something, wouldn't the child dependency be enough to prevent the unit from being dropped into another library or app? That's a good point you bring up about knowing where to "test drive" the changes from, though usually on the apps I've worked on, they've been small enough that the relevant integration test could be found without much detective work.

I guess I haven't been involved in too many 2-3 year monolithic projects. Maybe that's when a stricter symmetrical unit test policy makes the most sense.

What other levels of tests do you end up running besides your unit tests? Do you have any integrated unit tests? Functional tests? End to end tests?

<comment><USER19> The author is stating that the _child_ dependency cannot be extracted to another library or app. If it is extracted, it is untested, because the only tests wrapping the child dependency are actually testing the child's original parent. (Which is likely to not exist in whatever other library/app to which the child component is moved.) And then, to retroactively add tests to the child component in order to facilitate moving it to another library, is painful.

Having symmetrical tests enable components to be easier moved to other libraries/apps because the test can move with the unit under test.

</comment></comment></comment></comment><comment><USER9> Shout out for Sandi Metz book POODR, and her Railsconf talk The Magic Tricks of Testing, if you're a rubyist (though the principles hold true for non-ruby OO programmers too).

[https://www.youtube.com/watch?v=URSWYvyc42M](https://www.youtube.com/watch?v=URSWYvyc42M)

<comment><USER20> +1 for POODR - very ( _very_ ) well written, goes down multiple pathways reasonably (rather than "this is how you solve that" without any clue _why_ you solve it that way), and gives some decent tools for any project. I only wish it were longer.

</comment></comment><comment><USER14> I agree with the general approach suggested in the article (in tests, write/assume the code you wish you had).

But one detail ran counter to my personal practice.

I don't believe that "symmetrical" unit tests are a worthy goal. I believe in testing units of behavior, whether or not they correspond to a method/class. Symmetry leads to brittleness. I refactor as much as possible into private methods, but I leave my tests (mostly) alone. I generally try to have a decent set of acceptance tests, too.

Ideally, you specify a lot of behavior about your public API, but the details are handled in small private methods that are free to change without affecting your tests.

<comment><USER13> I understand the concern, but I value consistency and discoverability, so symmetry of thing-being-tested to test itself is (so far) the best way I've found to make sure it's dreadfully obvious where a given unit's test is.

This approach is not concerned with brittleness or being coupled to the implementation because each unit is so small that it's easier to trash the object and its test when requirements change than it is to try to update both dramatically.

<comment><USER14> I suppose that if you do keep things that small, it could work well to trash and rewrite. Plus it has the benefit of making you consider explicitly what is going/staying.

Personally, I like my tests to be pretty clearly about the behavior of the contract, and not the implementation, which is hard when you require every method have a test.

I'd also be concerned that other team members are reluctant to delete tests - as this is a dysfunction I see often, and try to counteract with varying degrees of success.

</comment></comment></comment><comment><USER21> Yes! I've always hated the common kata, because for every dev writing software for a bowling alley, there are 200,000 devs writing software the sends invoices or stores documents.

When I'm teaching TDD, the kata I have everyone go through is a simple order system.

The requirements are something like:

A user can order a case of soda

The user should have their credit card charged

The user should get an email when the card is charged

The user should get an email when their order ships

If the credit card is denied, they should see an error message

(etc....)

This way they can think about abstracting out dependencies, an IEmailService, a ICreditCardService, etc. There are no dependencies for a Roman Numeral converter.

</comment><comment><USER22> I like the way he broke things up, but something bothers me about his technique.

All his classes ended in "er".

he's not writing object oriented software, he's writing imperative software with objects.

<comment><USER13> Yes I am.

<comment><USER22> fair enough. Do you think TDD and OOP are mutually exclusive practices?

<comment><USER13> TDD as I practice it does, but I think OOP as it's traditionally taught encourages developers to tangle mutable application state and behavior, which leads to all sorts of problems. The more I practice, the more I learn that life is better when I separate whatever holds the state from whatever has the behavior

<comment><USER23> > life is better when I separate whatever holds the state from whatever has > the behavior

If you are not doing what is traditionally taught as OO, and you are doing something better why not say that?

I wonder why you don't say: "OO is an inferior design because it tangles mutable state with behavior"

"Not OO" should not be pejorative. OO is definitely sometimes wrong.

</comment></comment></comment></comment></comment><comment><USER24> This is probably the first reasonably sophisticated attempt to describe a test-driven design/development process I have read.

The observation that "[s]ome teachers deal with this problem by exhorting developers to refactor rigorously with an appeal to virtues like discipline and professionalism" reminds me of E. O. Wilson's remark that "Karl Marx was right, socialism works, it is just that he had the wrong species."

If test-driven design were the programming panacea its proponents sometimes seem to make of it, Knuth would have written about it in TAOCP. Instead Knuth advocates Literate Programming. TDD seems to attract a cult-like following, with a relatively high ratio of opinion to cited peer-reviewed literature among proponents.

TDD as this is commonly understood seems to me like the calculational approach to program design (c.f. Anne Kaldewaij, _Programming: the derivation of algorithms_ ), only without the calculation and without predicate transformers. Still it can be a useful technique.

There is no "right" way to program. This was evident from the beginning, when Turing proved the unsolvability of the halting problem. (Conventions are another matter.)

</comment><comment><USER25> Sure, but if the end result is "lots of little objects/methods/functions" maybe there's a simpler way of getting there, e.g. prescriptive design rules. After all, that's what every design method, including stuff from the waterfall era attempted.

I'd like TDD to be more than just another way to relearn those old rules, especially if we arrive at the same conclusions on a circuitous path. Perhaps the old design rules, object patterns, etc. have to each be integrated with a testing strategy, e.g. if you're using an observer you have to test it like this and if you refactor it like that you change your tests like so.

The general rules are easy to understand and your post makes perfect sense but once you formulate your new design approach you'll have to find a way to teach it precisely enough to avoid whatever antipattern is certain to evolve among the half-educated user community, which usually includes myself and about 95% of everyone else.

</comment><comment><USER13> Hey HN, I just wanted to thank you for the overall very positive, constructive comment thread. Thanks to you this post got roughly/over ~22k page views and I didn't receive a single vitriolic comment or bitter dissent. All I got was thoughtful, earnest, and honest replies. Made my day.

</comment><comment><USER26> OK but after you "Fake It Until You Make It" and you have to add a new feature to that class structure, aren't you just going to start over with all the failures he brings up?

\</comment><comment>---

I haven't designed code the way he's advocating, but I have attempted TDD by starting with the leaves first. Here are the downsides to that:

1) Sometimes you end testing and writing a leaf that you you don't end up using/needing.

2) You realize you need a parameter you didn't anticipate. EG: "Obviously this patient report needs the Patient object. Oh crap I forgot that there's a requirement to print the user's name on the report. Now I've got get that User object and pass it all the way through".

Maybe these experiences aren't relevant. As I said, I haven't tried to "Fake It Until You Make It".

<comment><USER27> "1) Sometimes you end testing and writing a leaf that you you don't end up using/needing."

So what? Just delete it. Your version control system should have a record of what it was if you end up needing to go back to it.

</comment></comment><comment><USER28> Excellent post, I've had exactly the same experience and come to exactly the same conclusion.

I still follow the old Code Complete method: think about the problem, sketch it out, then finally implement with unit tests. The results are the same, and it's a lot less painful than greenhorn-TDD.

<comment><USER13> Time at a white board breaking down a problem is rarely wasted :)

<comment><USER10> I completely agree with this. I fact when I have a bigger architectural problem to think about I like to sit on it for a day or two, thinking about one or two designs that would work. It takes a while to see the strengths / flaws in each design and jumping in to code you won't realize problems until you have something half implemented.

</comment></comment></comment><comment><USER29> I suspect if they had called it _Architecture_ Driven Development (ADD) rather than _Test_ Driven Development (TDD) it might contextualize better. Basically what the author explains is that you can design an architecture top down from simple requirements, deriving more complex requirements, and then providing an implementation strategy that lets you reason about whether or not you are "done."

But that 'test' word really puts people in the wrong frame of mind at the outset.

<comment><USER13> Yeah, the common implications of the word "test" have always been problematic. The BDD movement did a good job bringing that to light, but I didn't want to re-litigate that all in my post just to make a point about semantics. Totally agree, though.

</comment></comment><comment><USER30> TDD and agile have been an effort at breaking an old must have for code which was: ISO9001; the code should behave according to the plan, and if they don't conform, plan must be revised if the tests failed. The Plan Do Check Act Mantra. Now, they find themselves facing the consequences of not respecting the expectation of the customers and they whine because "it was not applied correctly, because no one cared".

So now, they reformalize exactly the so "rigid" ISO9001 they were trying to throw down.

What an irony.

</comment><comment><USER13> Apologies for the downtime folks, this post is proving a little too popular for us. Would love to see some folks reaction to the post in the comments

</comment><comment><USER31> > ...TDD's primary benefit is to improve the design of our code, they were > caught entirely off guard. And when I told them that any regression safety > gained by TDD is at best secondary and at worst illusory...

Thank you! Details of this post aside, this gave me an Aha! moment and I feel like I'm finally leaving the WTF mountain.

</comment><comment><USER32> Ian Cooper has a good talk that's relevant to this blog post. It's called 'TDD, where did it all go wrong?' and a recording from NDC 2013 can be found here: [http://vimeo.com/68375232](http://vimeo.com/68375232)

</comment><comment><USER33> Those guys must really hate their readers. That crappy web site is not zoomable! In the 21st century? In the era of "responsive web design"? Mega fail. Did they use TDD?

<comment><USER19> What's your definition of zoomable? I'm able to adjust text size just fine. More details on your specific issue? If you mean layout, it is responsive. The text column narrows and the images never exceed 100% width.

</comment></comment><comment><USER34> What about tools like Typemock? How does that fit in?

<comment><USER32> Tools like Typemock helps you make bad decisions that you will regret later on...

Isolating things is very important to make it easier to test, and lower the risk for tests to break when you change other parts of the system. Some times isolating one part from another is hard work. Typemock makes it easier, but in the same time it ties you closer to the part that you are trying to isolate from.

e.g. a database. You want to test something that eventually should store something in a database. You can either make a thin layer abstracting away your database so that you can test the functionality without depending on the database, or you can make a tighter coupling to the database, and use tools like typemock to get rid of it in test mode. If you want to change the way you store data, you now have production code tightly coupled to the current storage strategy AND tests tightly coupled to the current storage strategy...

Typemock can be of great help some times, but really you should strive to find better designs instead.

</comment></comment><comment><USER35> Hello there, Heroku error page

<comment><USER13> Apologies for the continued downtime, we're trying to get a CDN in front of the (static apache) heroku app. In the past not having any dynamic language in the background was enough to stay up, but not today apparently.</comment></comment>


Serverless APIs – Passing the Buck (part 1 of 2) - <AUTHOR> https://www.lunchbadger.com/serverless-apis-passing-buck-pt-1/ <comment><USER3> Are you ruining on Lamda? I like serverless, but hate AWS bill sucking up my cash runway. Not economical in Production...maybe at lower scale. I would prefer to deploy LB on a private cloud serverless architecture. Tips ?

<comment><AUTHOR> if you're on a AWS, we utilize Lambda to get cost efficiency and predictable cost of execution, we also have a container based runtime that can run your APIs along with everything else that's part of the LunchBadger infrastructure to be run wholly on-premise in your private cloud. To the developer - <USER2> write a JavaScript/Node function realizing the serverless simplicity in building out their APIs.

</comment></comment><comment><USER4> Is this a lambda play?

<comment><AUTHOR> We run on top of AWS Lambda - if you choose. Lambda is great but there's still a TON of scaffolding and boilerplate to get your APIs up and running including: model mappings, routing, point to point connection to either HTTP based proxies or Lambda functions. We simplify all of that utilizing the Serverless Framework running LoopBackJS models.

If you're not on Lambda or don't want it - the model logic can be run within our optimized container based runtime built on Kubernetes. Everything is transparent either way built on open source. Where you run it is your choice.</comment></comment>


How To Attribute Creative Commons Photos w/ Infographic - <AUTHOR> http://foter.com/blog/how-to-attribute-creative-commons-photos/

<comment><USER2> awesome</comment>


Show HN: Sendfreesms.online (a two hour side project) - <AUTHOR> I set myself a challenge to create a simple web app idea in a couple of hours and so http://sendfreesms.online was born. It allows you to send free SMS messages, it's crude, but works. Not sure if people even text message anymore.<p>All in all this took me a little over 2 hours to get working. It's an Aurelia/Node.js application using Twilio and MySQL for logging. <comment><USER2> I built something very very similar at Whispe.rs except it took me a bit longer than 2 hours :P

I built it first using Twilio but didn't think the ad revenue would pay for the messages so I switched it to using SMS-email gateways.

Great job! What did you use for the captcha?

<comment><AUTHOR> The captcha is just using Google's Recaptcha service. Yeah, I don't think the ad revenue will pay for the cost, but I set myself a challenge and managed to get something working quickly.

It's built using Aurelia for the client-side and Node.js for the backend using Restify to create a quick REST API for handling the requests.

</comment></comment><comment><USER3> I couldn't get it to work (Chrome 55, Germany, using the same numbers for to and from, or leaving the from field blank).

<comment><AUTHOR> Thanks for the heads up, sorry it didn't work. I'll test it out and see if I can see the problem.</comment></comment>


Public key as Identities in real world - <AUTHOR> https://medium.com/@nivesh/public-key-as-identities-d87942f385b9 <comment><USER2> What happens if you need to repudiate a particular public-key? If the Public Key is tied to your identity then you have a real problem.

Your identity is one thing, you ability to authenticate is another, your ability to encrypt is another still. Experience in other fields tells us that conflating different things and purposes into a single thing is generally a very bad move.

<comment><AUTHOR> well, the public is not tied to ones identity. It is just a theoretical concept that public key acts as an actor. Besides, the thing what you are talking about is related to anonymity which is a different concept.

<comment><USER2> > well, the public is not tied to ones identity.

And yet your title is "Public key as Identities"

> It is just a theoretical concept that public key acts as an actor.

And yet you are talking specifically about using a Public Key in practice.

> ... the thing what you are talking about is related to anonymity which is a > different concept.

None of what I've said is related to anonymity.

Your title is "Public key as Identities", which oddly enough leads me to believe that you are talking about using a public key as an identity. But if you do that, then your identity is the public key, because that's what you've just set up.

But keys get compromised, and so it is occasionally critical to be able to repudiate a key. But if it's your identity, you can't do that.

In short, everything in that article seems to be vague speculation without addressing some very real problems with the concept it's espousing.

</comment></comment></comment><comment><AUTHOR> If you know private key that corresponds to a public key. Then you can sign messages using private key and publish it onto the network, but what you are basically doing is making statements on behalf of that public key.</comment>


Remote Team == Distributed System - <AUTHOR> https://twitter.com/tariqrauf/status/1263901288556826627 <comment><USER2> The fallacies resonate. Has anyone done a detailed map of how to address them?

<comment><AUTHOR> There are some ways but most have to do with "over communicate" or "assume nobody knows anything".. etc -

HBR has a good post here: [https://hbr.org/2020/03/a-guide-to-managing-your- newly-remot...](https://hbr.org/2020/03/a-guide-to-managing-your-newly-remote- workers)</comment></comment>


Scaling the Patent System - <AUTHOR> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2016968

<comment><USER2> "This paper posits a simple but novel answer to this long-puzzling question: firms ignore patents because they are unable to discover the patents their activities might infringe."

Novel? Puzzling? Really? If this answer is really considered novel or this question the slightest bit puzzling, then this might be the best unintentional example of the actual problem I've seen.</comment>


Cards Against Humanity Has Made Over $54K Selling Nothing on Black Friday - <AUTHOR> http://techcrunch.com/2015/11/27/cards-against-humanity-has-made-over-54k-selling-nothing-on-black-friday/ <comment><USER2> Cards against Humanity has great marketing team, but I'm still pretty sure people are buying in because they think there's a chance they're getting something still.

There was that time recently that cards against humanity sold a box of literal bull shit, and then people were disappointed when they got just literal bull shit.

<comment><USER3> They don't ask for your address, there's no way they'll get anything.

<comment><USER4> That's even in the FAQ:

 _But really, I'll get something, right?

No, we're not even taking your shipping address. All we have to offer is nothing._

</comment></comment></comment><comment><USER5> They raised $71,145 and announced they're spending money with a list of items they're buying:

[http://cardsagainsthumanity.com/blackfriday/](http://cardsagainsthumanity.com/blackfriday/)

<comment><USER6> And if you missed out on this phenomenal deal, you can experience it retro- vicariously through the magic of The Archive:

[https://web.archive.org/web/20151127130402/https://store.car...](https://web.archive.org/web/20151127130402/https://store.cardsagainsthumanity.com/)

</comment></comment><comment><USER7> > Because the greatest Black Friday gift of all is buying nothing. We're > offering that for the rock-bottom price of $5. How can you afford NOT to > seize this incredible opportunity?

Great salesmanship.

<comment><USER8> It would be even better if they had it as $10 crossed out, 50% sale price: $5

<comment><USER9> Or $0 crossed out? Given that's the recommended retail price of nothing?

<comment><USER10> Given that they raised prices during one black friday, crossing out the $0 and charging $5 would be apropos.

</comment></comment></comment></comment><comment><USER10> Several of the commenters here are missing the point.

Cards Against Humanity has had an anti-black friday "gimmick" for at least one or two years now, and this is keeping with that tradition.

One of their black friday sales was to raise the price of the game. Next year, they'll have a different gimmick.

<comment><USER11> You've explained it completely, yet I still don't see the point from the customer's perspective. _" Haha I just gave a company $5 for nothing!"_.. What?

<comment><USER12> I find pleasure in mocking consumerism.

<comment><USER12> [https://www.facebook.com/MitchellWiggs/videos/10156258219585...](https://www.facebook.com/MitchellWiggs/videos/10156258219585257/)

</comment></comment></comment></comment><comment><USER13> It sounds reminiscent of the "I am rich" app[1], and even more to the apparently apocryphal copycat "I am not stupid" (which was presumably sold for US$1.99)

[1] See: [https://en.wikipedia.org/wiki/I_Am_Rich](https://en.wikipedia.org/wiki/I_Am_Rich)

</comment><comment><USER14> They are selling an experience and a story to tell. $5 and you have a funny story to tell when CaH comes in in conversation. It also makes you part of a group of "ironic" CaH customers. Similar to buying prestige by buying a luxury good when there is a cheaper equivalent.

Marketing today is all about identity, authenticity and defining oneself.

<comment><USER15> Today? It's been that way for the better part of a century.

</comment></comment><comment><USER16> Totally baffled at any/all articles and discussion of this by anyone who's familiar with their modus operandi. It's CaH. Either they're going to donate it, or do something awwbsurdacomical, and all they need is your name and email to keep you in the loop as the black frijinx ensue. Yadda yadda.

</comment><comment><USER17> Isn't this either very border line or even illegal in the US (genuinely asking)? - I thought every contract between 2 parties required an exchange of something, so money can't be traded for nothing, but maybe I'm wrong.

Edit: getting downvoted, not sure why, explanation would be helpful

<comment><USER18> It just means the buyers could easily get a refund. It's not illegal.

Similarly, technically minors can't enter into commercial contracts except for life necessities. So if an <18 buys a car, they could return it whenever they want. Whether they'd have to pay something for its use/damage is debatable.

<comment><USER3> >So if an <18 buys a car, they could return it whenever they want. Whether they'd have to pay something for its use/damage is debatable.

Can you go more into detail on that or tell me what law says that? Does that mean I (17/US) could walk into Walmart, buy a shirt, wear it for 6 months and expect a full refund?

<comment><USER18> [https://en.wikipedia.org/wiki/Capacity_(law)](https://en.wikipedia.org/wiki/Capacity_\(law\)) It's a very general legal principle, so how it applies varies jurisdiction to jurisdiction (and probably case by case since it may not be codified clearly). Look under infancy, and minors and contractual capacity.

Chances are, a dealership won't sell a car to someone <18 for this reason. Used car/private sellers are taking a big chance if they do.

</comment></comment></comment></comment><comment><USER19> "Sometimes buying nothing is better than buying Cards Against Humanity. This is one of those times."

</comment><comment><USER20> I ask for nothing every year and I never get it.

</comment><comment><USER21> is it possible that no one has paid anything and then they're just posting these numbers for attention?

<comment><USER22> Given how well Cards Against Humanity did in their last stupid sales like that (their first Black Friday was Everything Costs 5$ More!, on another occasion they sold shit, literally shit in a box) I think those numbers are 100% real.

</comment></comment><comment><USER23> Cards Against Humanity is always doing something crazy. When they sponsor the Accidental Tech Podcast and instead of a sponsor read, they have John Siracusa review toaster ovens.

</comment><comment><USER24> I love the idea and kudos to CaH for nailing the against-the-wind trend. However one questions came to mind. Is that legal? Can someone actually sell "nothing" without calling it a donation?

</comment><comment><USER25> In Buddhism, nothingness or emptiness is actually a "thing".

<comment><USER26> And a "thing" is nothingness

<comment><USER27> The Nothing was a great enemy to Atreyu.

[http://www.imdb.com/title/tt0088323/](http://www.imdb.com/title/tt0088323/)

</comment></comment></comment><comment><USER28> Nice. If they're smart, they'll donate it all to Oxfam. That, or post InstaPix of spending it on hookers and blow.

<comment><USER29> Readin the headline I kind of expected that it would be going to a worthwhile cause, but no.

Wow some people are stupid.

<comment><USER30> > I kind of expected that it would be going to a worthwhile cause

They do have posted:

> If I give you $5, what are you going to do with the money?

> That's for us to know and you to find out. We'll make the announcement soon.

So it may yet be. And it may not.

</comment></comment></comment><comment><USER31> Played it for the first time at a Thanksgiving dinner yesterday. It's everything I had heard and it is _offensive_. It's also an absolute blast to play with the right people.

</comment><comment><USER32> Oh Karlee (blush)

</comment><comment><USER33> Great marketing!</comment>


Airbnb's Burglary Disaster and How To Fix It - <AUTHOR> http://lifeinasack.net/2011/07/29/airbnbs-burglary-disaster-and-5-ways-to-fix-it/

<comment><USER2> Not sure this adds anything to the discussion.</comment>


Your mouth and gut microbiomes have a signature - <AUTHOR> http://www.ubiomeblog.com/predicting-oral-vs-gut-microbiomes/

<comment><USER2> I poked around the site some, interesting, I thought one of the funniest or stickiest reasons to poke around was to see if they explain how "just swab the area" sample technology works WRT gut biome sample collection (a really long swab? Insert via the, uh, exhaust port? They don't say).

It looks like an interesting bioinformatics type study.

<comment><USER3> IIRC from a podcast interview with one of the founders, you swab a bit of your used toilet paper for the gut sample collection.

The concept sounded pretty interesting, and it's on my list of things to do this year along with 23andme. Gut biome health is getting more awareness these days, and with them comparing large populations of samples it seems like a cool way to contribute to a data set that ought to provide some useful insights.

I was reading a post recently about someone who had surgery to remove part of their intestine due to some sort of GI disorder, and wondered how many of these sorts of major procedures could ultimately be avoided using biome-based treatments like fecal transplants.

<comment><AUTHOR> Yup, just the tiniest swab of poop from toilet paper will do. :)

</comment></comment></comment><comment><USER4> I wonder if they're still there after a lifetime of processed food, antibiotic rounds and GMO shenanigans?

<comment><USER5> Don't express skepticism of the wonderful and plainly obvious merits of GMOs on HN, please. It'll get you tagged as a conspiracy theorist and/or luddite.

<comment><USER4> Too late for that.</comment></comment></comment>


The IT business rebounds: Betting on bytes - <AUTHOR> http://www.economist.com/businessfinance/displaystory.cfm?story_id=14688776

<comment><USER2> "Yet more to the point, encouraging numbers or not, the technology sector is unlikely to lead the economy out of the recession. More likely, it is the economy, supported by cheap money and stimulus programmes, that is pushing IT."

This is not supported at all in the article, imho. Isn't growing technology always driving economic growth from agriculture to plastics to computers?</comment>


UC Davis Wondered If $175,000 Would Make the Internet Go Away. Conclusion: No. - <AUTHOR> https://www.popehat.com/2016/04/14/uc-davis-wondered-if-175000-would-make-the-internet-go-away-conclusion-no/ <comment><USER2> I don't get why those cops are pepper spraying the students. Are the cops, bored of patrolling all day without any of the action they saw in COPS while growing up, decidedly choosing to go pepper spray some kids?

</comment><comment><USER3> I'm very happy that up to now, in the non-eu 'internet must forget me based on court order' world it's not very easy for even rich groups to make things disappear.</comment>


Ask HN: Why Doesn't Google Believe in Customer Support? - <AUTHOR>

Background:
I was setting up a Google+ page for my company two days ago and my email was suspended because I used the company founding date as the birthday which is less than 13 years.
More Issues:
Of course the first thing I did was check the Google Support Forums to see what the solution would be. The solution the forums stated was to verify a credit card or to mail or fax scanned legal documents (Passport, Birth Certificate, etc).
Things were looking good until I realized that when I tried to login, I was not redirected to the verification process, it merely stated "Account has been disabled" which is completely different than what was written in the forums.
Horrible Customer Support:
When I emailed the Google Support Team, they merely redirected me back to the same forum posting without offering additional help. Obviously I know about the process to verify my age, however, it was impossible for me to begin the verification steps as that page did not exist for me.
What this means?
I have lost my email account containing thousands of contacts and clients. All the relationships I have established and all the business plans that I was working on are all lost at this point. And Google has done absolutely nothing to fix this.
So my question is why doesn't Google believe in good customer support? And no, it's not a scaling issue because companies like Zappos and Amazon handle it beautifully.
My suspended email is: firstname.lastname@example.com (email hosted by Google) <comment><USER2> The simple answer is that people don't scale. At least, that's what I've heard them say.

I've seen loops like this before, where the process to report that their process is broken is broken. And you're right, it's hell.

I'd double check just to make sure there's no mistake on your end, but yeah, unless you can find one of the Googlers who reads HN, you're stuck in limbo.</comment>


Linus Says People Must Work More on Technologies and Less on Log-in Screens - <AUTHOR> http://news.softpedia.com/news/Linus-Torvalds-Says-People-Must-Work-More-on-Technologies-and-Less-on-Log-in-Screens-394157.shtml?utm_source=twitterfeed&utm_medium=twitter <comment><USER2> Will Linux ever take off if developers can't pull in a common direction? Is there no space for an authority to say "We're using X, Y and Z"?</comment>


You're Young. I'm 18. So what? - <AUTHOR> http://theindustry.cc/2012/09/14/youre-young-im-18-so-what/ <comment><USER2> > _"Age is just a number."_

Age is a proxy for wisdom. The longer you are on this earth, the more wisdom and experience you will acquire. That has value. But that's not to say that age alone should be a dealbreaker or barrier to success, as the author has proven.

I'm 32; I look back at me at 18, 19, 20, even 25 and laugh at how little I knew. I have learned so much since then, and continue to do so. The main problem with being young is that you don't realize what you've yet to realize.

<comment><USER3> > The longer you are on this earth, the more wisdom and experience you will > acquire.

Well, maybe. You get experience when things happen. The more you play it safe, the less happens. And you only get wisdom when you think about your experiences.

There are plenty of people with wisdom well beyond their years.

> The main problem with being young is that you don't realize what you've yet > to realize.

Bad news! It gets worse. At some point, just when you start to feel like you know what you don't know, you realize that they are making new things up faster than you can keep track. Talking to people a generation younger than me can be a humbling experience. I have to tread carefully, as you do when you're talking with a person from another country.

<comment><USER4> > _There are plenty of people with wisdom well beyond their years._

I still haven't met any. I've met plenty of smart kids, and I'm pretty sure I was one, 15 years ago. However, I had no idea what I was doing, and worse yet, had the hubris to think I did.

I was insufferable, and I'd never hire 15-years-ago me. I also won't hire any other young engineers -- I'll let them find out how little they actually know on someone else's dime.

On the other hand, if I was in the VC game, I'd absolutely leverage young engineers as grist for my mill. They're the most amenable to the risk, and it doesn't really matter if the vast majority of small investments fail (and they will, especially given the inexperienced teams), if you hit just a few home run exits.

> _Bad news! It gets worse. At some point, just when you start to feel like > you know what you don't know, you realize that they are making new things up > faster than you can keep track. Talking to people a generation younger than > me can be a humbling experience. I have to tread carefully, as you do when > you're talking with a person from another country._

That's unnecessarily defeatist. There are steady advances, but there's very little that's genuinely new under the sun, and quite a bit of what the youngsters get excited about is just the cyclic rediscovery of what we already knew.

<comment><USER5> > I also won't hire any other young engineers

Your loss, really. I've interviewed and worked with several young engineers who were really top-notch, who worked out great, and were mature in their approach to work and life in general. They also tend to come with a lower price tag. Some have not worked out so well, but I don't have any reason to believe that the failure rate changes dramatically with age.

As I myself get older, I'm not so sure that the maturity level changes all that much either. People are just better at hiding their flaws as they grow older, then you find out too late when there's an issue.

<comment><USER4> I've never worked with a top-notch young engineer. Brilliant, yes, top notch, no. Every single one has had misguided priorities, significant experience gaps (leading to both bad engineering decisions and misguided priorities), and -- even in the best of them -- hubris.

Despite their intelligence they've always required constant senior level supervision, and have generally been the ones most likely to create maintenance-heavy components due to inexperience.

I'm not sure why our experiences differ so substantially, but I'm happy to hire only senior engineers and let other companies pay to train the young ones. The senior engineers are more than worth the minimal financial premium.

<comment><USER6> "I'm not sure why our experiences differ so substantially"

Sounds like you have bad projects management and let people go cowboy and build bad things because you don't communicate with each other.

<comment><USER4> No, it's simply impossible to babysit junior engineers to a sufficient degree as to prevent bad implementation without effectively doing their job for them. It's not worth the effort.

<comment><USER6> It's called comparative advantage. Have junior engineers work on easy things that are a waste of time for senior engineers to do. Personally, I'd rather not have my $200,000 a year senior engineer working on debugging cross browser javascript or writing documentation.

<comment><USER4> Hopefully he's not wasting a bunch of time debugging cross-browser javascript because A) He already knows how to fix it, or B) It didn't break to begin with. JavaScript is hardly difficult material.

As for documentation, I'm not sure quite what to say. The best person to document code is the person that's writing it. The best person to document things that aren't code is a technical writer, not an engineer.

<comment><USER6> Those were just example of simple tasks that a junior developer can do. And a junior develop in my company is someone of any age who has less experience. What kind of industry would we have if we only hired senior developers? If we said junior developers have no value? I guess we'd be a bit like the fashion industry where anyone new is just supposed to work for free.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Point 1: Age may be a proxy for experience, or wisdom, or whatever -- but anyone who evaluates individuals based on proxies rather than based on their _actual attributes_ is both lazy and (by definition) prejudiced. It's always possible that an individual -- young or old -- will greatly exceed the average capabilities of their age-group. Moreover, those who exceed the average capabilities of their age-group are likely to be extraordinary individuals in more ways than one -- more worth getting to know, in my experience, than individuals who merely live up to the average capabilities of their age-group.

Point 2: I, too, was a wunderkind -- and part of me regrets it. By age 12 I was hacking around the Freenets; by age 14 I'd tested out of high school; by age 16 I'd left home and was working for a well-known architectural institute; by age 18 I was running its computer department and my 3D visualisations and been featured on PBS and NHK, and exhibited around the world. But I was so busy being a wunderkind that I never took the time to be an actual _kid_. I was enormously serious: didn't goof off, didn't party, didn't kiss a girl until I was damn near 20. I wish I'd gotten an earlier start on all that. Honestly, there's plenty of time in life to rack up accomplishments, but youth is something that you only have once, and my advice to other wunderkind is to exploit the hell out of being young while you still can.

(Not that I would've listened to such advice myself...)

<comment><USER8> On the flip side, I was identified as a genius level IQ at an early age, joined Mensa, was utterly bored to tears by it and then proceeded to go be as 'normal' a child as I could be.

I fell in with the cool crowd, cut more school than I attended, graduated with a grade .01 points above failing (I'd become an expert at doing the minimum), learned about recreational drugs and spent years in a drug-induced fog.

Later in life I decided to start applying myself and join the work force in IT and found myself utterly unprepared. Work was never hard, naturally, but it took me a long time to get up to speed on the normal, expected social interactions between co-workers.

In summation, while I like who I am and what I do now, I'm often plagued with pangs of regret at having wasted away all that time to rack up accomplishments and get something done with my life. There's still time, naturally, and I don't have a pressing need in life for anything more than I have, and things just move generally slower with a family involved.

</comment></comment><comment><USER9> That's one hell of a story of hustle. What you've discovered, I think, is (paraphrasing Steve Jobs [1]) that the world around you was built by people just like you. You've seen behind the curtain, and there's no wizard, only some dude who's no smarter than you are figuring it out as he goes along. Kudos to you for discovering this at such a young age, I didn't get it 'till my twenties.

My advice to you: put the last section of your article out of your mind. You've achieved some pretty amazing things, focus on that, and keep shipping. Comparing yourself to others is a path to insanity, there will _always_ be someone who has accomplished more, done it faster, made it look easier, etc. And one more thing-- you're never too young to do anything, but keep in mind that with age comes experience. There are people out there (like the ones you mentioned), who have been where you are before, have faced similar challenges, and overcome them. No matter how early you start, you'll always have more experience the older you get, so continue to seek out the advice and mentorship of those who have walked the path before you.

[1] [http://www.youtube.com/watch?feature=player_embedded&v=U...](http://www.youtube.com/watch?feature=player_embedded&v=UvEiSa6_EPA)

</comment><comment><USER10> This may sound all bitter and such from some 'old guy', but... I wonder how Jared will view things at 50. Will he be saying "age is just a number", or might he find that people start to pass him over for younger blood? I do realize that much of his story hinged on getting connected to people without them knowing his age up front, but at some point, people will know your age (range, or at least guess somewhat accurately).

I'm not saying he's right or wrong, or I'm right or wrong - I'm not sure there is a 'right' or 'wrong' to be found, but I'm very curious about what his perspective will be 30 years from now.

</comment><comment><USER11> Sounds like rather remarkable story, and might have read it all, had the annoyingly small font size, not been _forced_ on Chrome and Safari users.

Grandpa's eyes at age 33, can't read your blog comfortably, as a result. :p

 _-webkit-text-size-adjust_ [1][2], is just NOT cool

[1] [http://stackoverflow.com/questions/1831922/how-to-prevent- us...](http://stackoverflow.com/questions/1831922/how-to-prevent-users-from- resizing-the-font-on-my-web-site/12263866#12263866)

[2] <http://theindustry.cc/css/style.css>

<comment><USER12> That is obnoxious.

Here's a workaround: [http://viewtext.org/article?url=http%3A%2F%2Ftheindustry.cc%...](http://viewtext.org/article?url=http%3A%2F%2Ftheindustry.cc%2F2012%2F09%2F14%2Fyoure- young-im-18-so-what%2F)

<comment><USER11> Thanks :).

PS didn't mean to be harsh, I really appreciate it when others take the time to tell me that sort of thing, as it helps one to improve, but maybe you see it differently.

<comment><USER12> Oops--actually I was agreeing with you :) Restricting font resizing is the obnoxious act!

</comment></comment></comment></comment><comment><USER13> I used to think the same as Jared. I was 14 and writing DirectX 8 mini games for fun in VB6. Thought I could get a job soon, and I'd set myself up nice and early in life.

In high school I had a few "clients" for websites and such as well, as I'd learn PHP by that stage, along with the usual XHTML and CSS - almost just like Jared. It's not the same though.

In the professional space, there is SO many more factors that you're just not ready for until you've worked for a company or two.

That being said, there are exceptional people out there, and they shouldn't be judged by their age. Soon I think there will be more of them. We really just have to remember that no matter how old or "wise" we supposedly get, we're no better than anyone else. We all deserve a chance sometimes.

""" Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You are the same decaying organic matter as everything else. We are the all-singing, all-dancing crap of the world. We are all part of the same compost heap.

<comment><USER14> > [I learned XHTML and CSS in High School]

Wow. A WC3 specification has never made me feel so old.

<comment><USER13> My bad. I'm 25 now, does that help? Haha

</comment></comment></comment><comment><USER15> Something I didn't understand at 18 (that I do at 35) is that your 'enemies' may be dealing with things you simply cannot understand.

If a coworker is belligerent to an 18 year old, they are assholes. To a 35 year old (at least to me), the first thing I think of is that I have no idea what their home life is like.

People endure crazy life experiences. I am working with them on a problem that results in revenue for both of us. Just because we're making money, doesn't mean that they're dealing with problems of personal identity, cancer, financial ruin, etc.

Age matters, kid. It fucking sucks. It's cool that you're punk rock about this. But you will achieve more & achieve faster when you realize that age really does matter.

(p.s.- age is not a way to measure wisdom, but it is a wisdom indicator)

<comment><USER16> > If a coworker is belligerent to an 18 year old, they are assholes. To a 35 > year old (at least to me), the first thing I think of is that I have no idea > what their home life is like.

I'm sorry, but I don't care what your home life is when you're at work. You're there to do your job, and communicating with your coworkers without being an ass is part of that. It sucks that <insert bad thing here>, but your job should not be affected by that.

If we're out at a pub in a non-professional setting, that's different; feel free to pour out your soul. But when we're on the clock, just do your job.

I say this having had a very, very close friend die on the morning of my first real world product launch. I had been up all night hammering out every last detail when I got the call from my mom, around 7am. At that moment I knew that the right thing to do was to finish what I had to do, and go home and mourn on my own time; it was what was fair to my coworkers, working right along with me, and to myself. It wasn't their problem, and if I had lashed out at them it would've done nothing but impede our progress. Sometimes you have to step up and do what needs to be done.

<comment><USER17> I'm from the UK, I know all about stiff-upper-lip but even to me this seems like unnecessary martyrdom.

I would feel that I had failed my staff if any of them thought that our product was so fragile that delaying launch by a week so they could mourn would cause irrevocable damage.

</comment></comment></comment><comment><USER18> Reminds me of when I was 15 (now 24), I started designing & building porn sites for customers that didn't know my age. Made a lot of money that way. Also started my own, but no longer associated with that industry.

To be honest, young people are very talented, they haven't been moulded into a certain shape or way yet, and I tend to get the feeling they think more out of the box.

That being said, with age comes wisdom, you start to learn more and more, what works, and what doesn't work.

You either have talent, or you don't, sure experience is good. But people evolve in different ways, some faster than others. Even though you're younger than your competition, you still might have more experience, or you just might be 10x better. I've only been turned down once for a fulltime job at Philips, when I was 18. They liked my work but wanted someone older. I could fully understand that, and wasn't too bothered by it. Just go on, stay focused and you'll get very far. Your work and socializing skills are key, not your age.

</comment><comment><USER19> Jared, I nearly cried at the end of reading. So many people, even those closest to me, never believed (and still do not) or understood what you have so beautifully and artfully articulated. Reading what you wrote, I could relate to your every sentiment. People think that just because of an age, we lack the ability to create and provide amazing things. It works against us, beyond the 'cute' factor, and it is seemingly a constant pressure and embarrassment that we have no hold over. Then, even in our best moments, people will question what we've done and dismiss it as nothing more than an 'exercise'. It's aggravating, frustrating and depressing. But then we'll have those amazing experiences where we meet 'adults' that understand this and they treat us like equals. Our opinion, expertise, and passion weigh so much more than a number. The level of gratification from meeting these people, to know that there are others that accept the results we produce, is simply awe- inspiring.

Among my circle of friends back in High School, I can think of only a select few who I can confide with these thoughts. It's so difficult trying to find someone that really understands these kinds of struggles- the dismissive remarks, the attitude of negativity and failure, etc that people give when they find out your 'age'.

Thank You for sharing your post with HN. To know that someone else is out there who truly understands these trials and struggles makes me feel just a bit less lonely – to know that I'm not the only one who feels that way about entrepreneurship. Your post was inspiring and for all the articles I've read on HN, yours makes everything worth it.

<comment><USER20> These teenage angst posts are both a little amusing and a little disturbing.

I'll skip the amusement part which you'll realize as you become older and just give you a little warning on this one:

 _But then we'll have those amazing experiences where we meet 'adults' that understand this and they treat us like equals._

Be aware that there's not a small number of people who will not hesitate to take advantage of young eagerness. Especially in the startup scene.

Learn to distinguish between people who treat you well because they respect you, and people who treat you well because you're running half their business for an intern-salary. It's more common than you, at your age, think.

<comment><USER19> Ahh, another one.

I appreciate the lesson and understand that wisdom also comes with age. I don't dismiss that - in fact I realize and acknowledge that. That's why people have mentors, people with decades of life experience to learn from.

"Learn to distinguish between people who treat you well because they respect you, and people who treat you well because you're running half their business for an intern-salary."

Perhaps that is something you did not learn in your youth, but you should know that does not mean that those of similar youth age don't realize that. Personally, this was a point I exploited when I ran my business. Having interns that were years older than me doing work for me. Quite "amusing", as you point out, now that I think back...

Nevertheless, I think your advice is true. Lots of people out to take advantage of young people. This is not new, though and anyone with the level of experience in business having done work previously in youth years would know this.

The pattern that I've noticed is most people will speak similar to you. Those that don't and truly appreciate it were once young entrepreneurs themselves and experienced their levels of 'success' so they understand it. Though perhaps I just choose to surround myself with mentors of that particular quality.

<comment><USER14> I was a young entrepreneur. I started a web hosting company in 1998 when I was 16. A real one, not just a white-label reseller.

Here's something I learned: It takes years--several years--to come close to mastering anything of sufficient complexity to be worth mastering. That is just not possible when you're young. We've all had to deal with that.

"I fear not the man who has practiced 10,000 kicks once. But I fear the man who has practiced one kick 10,000 times."

Be water, my friend.

<comment><USER21> > Here's something I learned: It takes years--several years--to come close to > mastering anything of sufficient complexity to be worth mastering. That is > just not possible when you're young. We've all had to deal with that.

Magnus Carlsen [1] became the highest rated chess player in the world at 19. This means that either it is possible to master very complex subjects while young, or chess is not very complex.

[1] - <http://en.wikipedia.org/wiki/Magnus_Carlsen>

<comment><USER22> Or it could mean Magnus Carlsen was excepcionally endowed with the traits that make great chess players, as Phelps is to swimming. And his 29 year old self, given the same discipline he must have applied pre-19, would be a much better chess player than himself 10 years back.

I don't understand why people, including the author, are completely disregarding experience here. I agree with the author's points that a young person, even a teen, could bring a lot to the table and has his own qualities, one of which is not great experience. But that doesn't disqualify him for any job, given a hunger to learn and a passion for his work. But to suggest that "the only difference is in music taste"--well, if you measure any one young person against any one older one, you could get that result, but I'd be hard pressed to expect the same when comparing you with yourself 10 years down.

</comment></comment></comment></comment></comment></comment><comment><USER23> When the young say,"there are some young people who are wise beyond their years",you should translate it as "I am one of those young people who is wise beyond my years."No wise person ever says that.

<comment><USER24> _When the young say,"there are some young people who are wise beyond their years",you should translate it as "I am one of those young people who is wise beyond my years."No wise person ever says that._

What happens when "old" folk like me and @wpetrie say it? :-)

I am wiser than I was in my 20s, but I know people in their 20s who have become wiser faster than I did. They had more stuff happen to them (through hard work, or good luck, or bad luck) - and learned from it well.

</comment></comment><comment><USER25> "Today I'm 18. I: have worked at two major startups, have written for AppAdvice, Macgasm, Envato, brushed Mashable, encountered numerous entrepreneurs, run The Industry, advise two startups, am a team member of Advise.me..."

I don't know what to think. It's great what he achieved, and I respect that. However, I think he might wake up one day and start asking himself, what did I do? Was my youth fun? Did I go out with people and do what kids usually do or did I just try to accomplish things and get my career somewhere?

When I hear someone being "only 17", or "only 20", or whatever, and wanting to be an entrepreneur, I don't rule them out because they are too young and have too few experience. I worry that they might miss out on living their life.

<comment><USER26> I think it's pretty simplistic, not to mention rather patronizing, to suggest that the only proper way to spend one's youth it to waste time on stuff that other teenagers do, and that people who aspire to something else must be protected from themselves.

</comment></comment><comment><USER27> One important point that hasn't been touched on is the neurological development that comes with age.

It's not until your 20s does one's frontal cortex (or lobes) of the brain fully develop. Until this occurs one physically lacks the ability to control higher-order functioning. This could range from long term planning, motivation, and inhibition towards behavior.

When you're young you're somewhat crazy and brash. This allows one to take chances, push the envelope, and reach breakthroughs.

With that said it works both ways. The youth lack the ability fully reason, plan, and in SOME cases think logically through a problem (in the sense of understanding the repercussions of their actions).

</comment><comment><USER28> Wow, I am amazed and a bit disappointed with a lot of these responses. I've seen plenty of young people who are much more mature, intelligent, and hard- working than most 40 and 50 year olds. Yes, in general there is a correlation with increasing age and other positive traits, but there are plenty of exceptions that cannot be overlooked. To overlook someone simply because of age would be extremely foolish.

<comment><USER29> Intelligence and hard-work are extremely important, but it can't wholly make for experience.

How can you write about start-ups without ever having lived through a downturn? Sure, you can read about it, but the proper level of skepticism bordering on cynicism is impossible if all you've ever seen is the fat years.

<comment><USER28> If you've done enough mathematical analysis of previous downturns and trends, there is no need to experience one yourself. You can obtain all of the information you need to make better (future) predictions through objective study, and in my opinion this is much more effective than some sort of intuitive hunch accumulated through the years.

<comment><USER30> Are you 18 yourself? I would be surprised if you weren't, because now that I'm 30, I don't believe the way you do anymore.

Some knowledge you can only gain through experience, no matter how smart you think you are.

<comment><USER28> No, I'm not. I'm 22. I realize a lot of people older than me enjoy saying "I used to think the way you did, but now I've seen the light", but I've found myself to be fairly consistent over the years. I've had no epiphanies or deep insights into the "way things should be" just because I've gotten older. I think perhaps it is a psychological trick -- you just assume that some sort of deeper thinking comes as you age. There's a lot of great physicists who did their best work in their early 20s and never did much great afterwards because they got locked into one way of looking at things.

If you want, I'll get back on this thread in 15 years and tell you if you were right or not regarding additional accumulation of "deep knowledge" (whatever that vaguely-formed concept should represent).

>> "Are you 18? I would be surprised if you weren't."

At least to me, this comes across as sort of an arrogant comment that I really wouldn't expect on Hacker News. This whole "wisdom with age" is a lot of unfalsifiable nonsense the way I see it. Any sort of experiment I could propose would be shot down with "Oh, don't worry about it. There's just something _magic_ about getting older, and well, you really can't say anything to challenge that.

<comment><USER29> It is true about physicists, also mathematicians (look at the Fields medal winners.)

On the other hand, novel writing is by and large a middle age and older persons' game. There are a handful of great novels from people in their twenties, but most of those authors go on to write even greater works later in life.

There are advantages and disadvantages to youth. Trying to pretend that everyone is equal and it is all a matter of how hard you try is one of the great fallacies of our era.

</comment></comment></comment></comment></comment></comment><comment><USER31> I kinda agree. I am 23, but even though age is a proxy for experience one shouldn't overvalue experience in first place. In face experience can be a huge hindrance. Experience can (but doesn't necessarily) lead to be less open, to be less creative and also can cause you to lose the ability to see things open and from different perspectives.

People (I) start to rely on their experience and while this can allow you to do things more effectively, because you have them in your working memory, etc.

However, when I look back to the things I used to do when I was eleven, I felt like there were no border. I was able to understand concepts instantly, just read things and I knew it.

Sometimes I think a wunderkind is just someone whose hobbies are related to school wisdom. When I look back to every teacher was constantly calling me professor just because I read the stuff in the math books, read other books, liked to watch the educational program (which I our class watched again in high school) one can just think so.

On the flip side I didn't learn a lot of the things with other hobbies did. Sometimes a wunderkind is someone with lots of hobbies and having basics skills everywhere seems like a good countermeasure to relying on experience you made in a certain field.

Well, my life wasn't that good though. I was that kind of geek that got beaten up by others for good marks and so stopped going to school for a long time (but decided to still get my finals at a later, just learning on my own doing the necessary tests). Still, when I look back to that time when everyone called me professor things changed. I think I made a lot of different experiences because of it though. These days I don't give the impression of a creepy geek anymore, because my social skills were forced to develop quite nicely.

Basically why I want to write this is because I know there are a lot of people who are outsiders and stay like that all their life. I know how it is when they say you have a high IQ and you try to be super nice, because you may find it nice to be a geek around some people, but feel strange around others. But hey being a geek means being smart, so one can just spend a nice time doing something social, looking what others do, how they react and also self reflect on your self. Even if non-geeks might behave differently, they are also just people like you. I think most geeks tend do focus on themselves and when they are shy they try their best to look good and then (correctly) come to the conclusion one shouldn't try to be different and just accept oneself. However what they sometimes forget is that one usually can learn most by just listening. Completely focus on someone else. One doesn't need to fear looking like a creep, if you just listen and people are even going to like you for it!

About the rest of this article: I don't know, but it looks like something that is going to bore one in the long run. Yeah startups are exciting and I am working for one too. It's great fun to actually do thing, but first off I don't really need a job to do something great and really wouldn't consider creating a successful company the greatest thing ever. It was done over and over and all you get is money, which seems like something rather boring if you are not a poor person or just addicted to it, which also won't make you happy.

So question: Do you really consider creating something like tumblr a great goal? I mean, if you take away all the hype then it's just a blog and the ability to like other blog posts. I wouldn't really call that something great, amazing and influential (not in the way I think most people want to be influential I guess). It's no revolutionary great thing and isn't more likely to save lives than to destroy them.

Of course I'd be happy and proud of myself, if I created tumblr, twitter or Facebook and see how it is successful, but at least I wouldn't feel like I had done something great with my life. If you do that's great, go for it!

Speaking about tumblr, I'd feel like a lot these "average" (that sounds really bad, sorry) people did more with writing a simple blog post and while I would find it super awesome that they did it with my software it just feels wrong to act like I'd really have contributed a lot by creating tumblr. There were easy to use blogs before that and hey, who says things actually didn't make it harder or something even better could have happened.

So before you go on, I urge you to think about what exactly makes you great about what you plan, else you risk to feel like you have wasted your time. When you are in your early twenties, you'll know what I mean. ;)

</comment><comment><USER32> I can't agree more with the contents of this article. It's important to abstract age away from how you represent yourself, for a number of reasons.

Age automatically restricts your opportunities. I have gotten a number of serious job offers from reputable companies, and none of them were aware of my age. While a lot of people in the startup industry are not age-biased, I have a feeling that if my age were advertised on my profiles, these opportunities would not have been extended to me. When I asked around for a summer internship this past summer, my boss said he had not realized how old I was, at first, when he extended the offer. I have found that it is much more difficult to prove your worth as an engineer when you are underage and self- taught. This is _why_ you need to work on personal projects, and finish them.

Also, while I have not experienced this firsthand, some people are not as nice as you would like to think. If they realize you are "just a kid", they might feel it appropriate to lowball you or cheat work out of you. It's despicable, but I'm sure it happens.

The advice in the article suggests that you attend conferences. I would generalize this. Network with your local community, as well as the global community that you come in contact with at conferences. Hailing from the wonderful land of Philadelphia, I am an active member and occasional speaker in PhillyCocoa, the Philadelphia CocoaHeads chapter. I also was a member of Venturef0rth this summer, a rising incubator space. I plan to attend a hackathon when I have time (I'm missing one at UPenn as I speak :p ). At these places and more, I have met a slew of awesome people, from whom I have learned innumerable things.

That's not to downplay conferences, either, as an attendee of The Last HOPE, DEFCON 19, Google I/O '12, HOPE9 and others. The thing about conferences is that they do cost money (including travel and lodging), and not everyone can afford to attend them.

And because it's relevant, today I am turning 16.

</comment><comment><USER33> This is a beautiful post.

Here's the deal. As you get older, more and more people fall into mediocrity. Age is a number - it's also a responsibility. You will meet 40 year olds who you'll think - what the fuck did you do with your life? And you'll meet 40 year olds who you'll wish that - at some moment of divine clarity - you'll be half as smart as. The second hand counts with stunning accuracy. Don't judge yourself against the mediocre. Look at the people who rose to the top. Some were smart at 18 and drifted off of that cleverness for quite some time until it caught up to them. Others rose above. Rise above.

</comment><comment><USER34> I hear you. People often seem to think I've done a lot for my age, whilst I'm thought strange for not necessarily agreeing.

I think the big thing is that most people don't have that interesting a life until after college, and many of those immediately get a relatively boring job.

Starting to get noticed and do interesting things at a younger age just came natural to me, so in a lot of ways I never considered it an achievement until recently.

</comment><comment><USER35> Ten Thousand Hours.

</comment><comment><USER36> I'm all for starting young, in fact I am downright angry because I think our educational system is holding us back (living in Germany). Just a note, though: you won't stay young. I am not sure it is even worth fussing about being too young, because while you are busy fussing, suddenly you are already old.

</comment><comment><USER37> Pretty cool both that you are accomplishing so much at your age, and also pretty cool that the industry is embracing that (try doing that in the biotech or financial services industry). Good luck!

</comment><comment><USER38> Keep pushing, don't stop. I have seen many people peak at 18. The key is to keep moving your feet even when it feels like you are not going anywhere. PUSH PUSH PUSH! Happy Birthday, Lad:)

</comment><comment><USER39> i would have to say age does matter i am sure by the time he is my age he would have done a lot more than i dream could do

but i would never have someone so young as my partner, or even hire him for any critical job

he have so little too loose at this young age ... its too risky to make business with him

</comment><comment><USER40> Fellow Baltimorean! It's not so boring... so long as you're over 21.

</comment><comment><USER41> i'm 20, work at a tech startup in NYC. fuck everything about this kid. real phony, rubs me the wrong way 100%</comment>


Lsys – Fast and interactive L-system generator written in CoffeeScript - <AUTHOR> http://benvan.co.uk/lsys/

<comment><USER2> If people are not familiar with L-systems, wiki is a good place to start: [http://en.wikipedia.org/wiki/L-system](http://en.wikipedia.org/wiki/L-system)

Besides their inherent interest in modeling biological systems, people here might be interested in them as an example of a stochastic grammar, i.e., a system of rewriting rules where multiple branches can be taken with various probabilities. L-systems are not necessarily probabilistic, but in applications, probabilistic ones are often used.

</comment><comment><USER3> This is great--I love stuff like this. There's also CFDG[1].

I noticed a drawing problem in Firefox and submitted an issue[2].

1: [http://www.contextfreeart.org/](http://www.contextfreeart.org/) 2: [https://github.com/benvan/lsys/issues/2](https://github.com/benvan/lsys/issues/2)

</comment><comment><USER4> A lot of the examples are much more impressive when being rotated with the mouse, they produce some pretty crazy patterns. Take a look at the Dragon Spirograph and Dance for me.</comment>