skysight-inc/HackerNews huggingface dataset:
I've never bitten the Apple of TDD/BDD but:

* To me, you should balance the amount of testing on several things. Not all code is created equal - some are plain old quick tests which are meant to be thrown away. Other code is something you expect to be running for a long time.

* The most important balance is this: If you leap quickly over testing of a piece of code, it may or may not cost you more time in the longer run. In other words, not testing increases the risk variance of the code having a bug further down the road. You have to evaluate if that is going to be a problem or not. The problem may also occur because your code is too slow. With a good test-harness it will be easier to optimize and sometimes the tests can be used as a start for benchmarking.

* On the contrary, if you feel the grass is greener on the other side of the road, you may test too much and thus never move fast enough to getting something done. It will cost further down the road, but it hinges on the premise that you will not discard both the code and the idea and rewrite (so tests needs to rewritten anyway).

* Personally, I rarely use a TDD approach. I rather like property-based testing: I "fuzz" out errors. I've just written a protcol encoder and decoder and there is an obvious test: (eq orig (decode (encode orig))). So I automatically generate 1000 "origs" and test that the above property holds. To me, this is much more valuable than TDD/BDD - but I've never been a fan as I said.

* Sometimes the idea of BDD is to shape your process and thinking pattern. In that case, it hardly looks as if it a waste of time: Had you not BDD'ed, well then you may have been in the unlucky case where you implement a lot of code only to realize that you implement the wrong idea because the API has to be different and serve you differently.
Just Twitter right now, but email may find its way in if that turns off too many.
I completely feel you pain on this one. I attended the New England College Hackathon last weekend and was utterly disappointed. During the 12 hours we were there, they managed to only feed us once and we were bombarded by windows surveys and evangelists looking for free / cheap labor.

To make matters worse, the judges only picked winners from the local area (and made poor choices IMHO). The second place winner did NO coding at all the entire time and the first place project was 4 months old.

Something needs to be done about this. Hackathons need standards too!
I just got out of the Tor hack day in Cambridge MA (which I hear may become a monthly event, yay!). We divided into two rooms: soft ware (code) and soft skills (documentation, policy, how to run a server on your PC, fundraising,...)

I thought this worked pretty well, although I can't say either room was lacking conversation! But in our case this is also about community building for an open source project - slightly different agenda.
"Next month, Ignighter will open an office in India and hire a dozen local employees. The company has stopped developing its American site, though it remains online." I'd hope these employees aren't developers. If so I'm pretty sure I know how this ends...back in NYC with a team tasked with fixing the mess it has become.
What in this post makes you think that the OP is self sufficient and skilled?
As a 37 year old, I'd go along with almost all of what eengstrom said, in general. But there is a counter-point... being to cautious and patient can be a risk in it's own right. In my own case, I look back and feel that I waited too long to indulge my "wild hair" and move to a place with more opportunity. Now I'm struggling to deal with a world where a 37 year old is considered "old" to be a startup founder, and worrying about the real possibility of age discrimination as I continue forward in the technology profession.

I'm not recommending going off half-cocked on a whim or anything, but there's something to be said for being aggressive about pursuing things. And unfortunately nobody can really tell you how to judge when a decision is being too aggressive or just silly... judgment is one of those things you really only gain with experience. All I can really tell you is to study hard, consider all the alternatives, solicit as much information as you can from various sources, and then make the best decision you can. In the end, whether you succeed or not isn't going to come down to any one decision in isolation anyway (well, 99% of the time anyway. A decision to start imbibing crack cocaine is pretty much a one way ticket to failure, but I hope you get my drift.)

save your money

Definitely this. Building a safety-net / nest-egg will both allow you the confidence to make some risky decisions at times, and may just save your ass one day if one of those decisions fails to pay off.
Hackerspaces are something very different from incubators, so that's not a fair comparison. See http://en.wikipedia.org/wiki/Hackerspace
Natural Language Processing with Python [pdf, 491 pages]
It'd be nice to be able to see a list of the Sparks I've liked.
I only start writing tests once my startups profitable and stable (if that ever happens). TDD is just not as important as getting a product out the door.
I'll admit my ignorance about the existence of S-expressions (had to look them up here: http://en.wikipedia.org/wiki/S-expression )

I've used XML because .NET has a parser, and I'll probably use JSON because parsers are widespread... are there good standard parsers for S-expressions for .NET or other popular platforms?

A quick googling sends me here

http://stackoverflow.com/questions/3051254/parsing-lisp-s-ex...

which makes me believe.NET can't natively process s-expressions with ease, and that's a HUGE minus for me.
This article encapsulated one of my strengths, the difficulty of focusing exclusively on any one thing. As an individual that has always been somewhat easily distracted, I've learned to take advantage of this by always staying on the lookout for new opportunities each time my attention shifts. My startup idea was born from piecing together many different insights into one new idea.

Reading this article made me really happy that... ooooh, shiny!
Don't drop out. College is awesome, I don't regret a single day in college. I did a ton of internships to keep myself busy, partied a ton, started a company (Mugasha) and made a ton of friends. College is not all about academics, you will meet amazing people, having a lot of fun and look at the tech/startup world from a different angle.

As others have mentioned, transfer to a university in the bay area. Best of both worlds, Berkeley, Stanford, SJSC, Santa Clara, SF State etc.. tons of choices.
If the lawyers don't set the ground what will the developers work on to? The developers, all contributors, and users of LibreOffice need this.
A lot of your copy focuses on how this is just the beginning, how important this site is to you, and how you want feedback, etc. That's great for someone who already cares, but most visitors to any site are going to be ambivalent until they know what they're getting out of it.

Put yourself in the shoes of someone who doesn't care about you at all. Explain the unique benefits that that person can access right now. Appeal to their selfishness. Focus specifically on things that Sparkmuse enables (right now) that cannot also be said about alternative sites, such as Hacker News. Trim everything else away.
Jumping from college dropout to one of the most expensive and competitive job markets in the country seems a little bit too much. It's a big country with hundreds of big and lively cities full of opportunity that don't cost a fortune to live in or near.

Even the little commuter town I live in (Winder, GA) has a couple of web-heavy businesses started in the last decade. One's a design firm, and the other makes clothes.
Paradox inside innovation...
I suspect that the identification and then resolution of paradox inside a well defined situation has a causal realtionship to innovation... maybe.
You don't mention it in your question, but what is your experience? You say you want to work at an awesome startup, but do you have projects (such as websites) or anything you can reference to prove you know what you're doing?

San Francisco is a great place, but you're already going to be fighting against quite a lot of people with more experience. Unless you some impressive projects to show, finding a startup who is going to take a risk on a 19 year is not a good bet to make.
Well I never said I'd drop out, even if it came off that I implied that. The idea I'm working on involves K-12 education. It's essentially a file-sharing network for academia and hobbyists. But the file-sharing part is mashed in with your courses, so when a teacher posts the homework any other teacher can use that homework as well or if a student doesn't understand how to do the night's homework they can just search for the concept (i.e Quadratic Equations) and it will come up with a list of videos made by teachers for that concept. That's a very informal and not a very elaborate description but that's essentially it.
I wouldn't take face cook's claim that they have 600M active accounts to mean that they actually have 600M active users. If you wander very far from your own "neighborhood" you'll reali ze that there are a lot of bogus accounts used by spammers.
Whether your "simple loop" is actually simple depends on the complexity of the underlying problem. At a certain point, it takes less time to understand the abstraction + the code using that abstraction than to understand the fully-expanded code without the abstraction.

If you're just adding up the elements of an array, no big deal use a simple loop. If you're iterating through three lists of potentially unequal length processing some triplets and skipping others and returning some data structure based on that iteration, a raw loop is going to be anything but simple and readable while using an abstraction like CL's LOOP is going to result in something very manageable.

To give an empirical example off the top of my head, look at any compiler code written in C. Iterating over flow graphs is a big PITA because they're nested heterogenous structures (a procedure has basic blocks which has instructions which has uses and defs). You iterate over them a lot and a lot of iterations end up being complex triply-nested affairs. Nearly all compilers written in C use some sort of abstraction to deal with this complexity. Eg: GCC has a bunch of macros of the form FOR_EACH_ that use the pre-processor.
You are correct and I mistyped. Python has limited lambdas not a lack of lambdas.
Tons of highly popular languages don't have XML parsers built to the spec. Very few of them can handle schemas at all, or recursive definitions in schemas, or external document types, or external entities or schemas (and the few that can are usually disabled intentionally, because they can make parsing a tiny XML file take minutes if the server of the schema doesn't serve it up fast enough). That the XML spec defines such things is irrelevant if they're wholly unreliable because enough parsers refuse to handle them. And there are more than enough horror stories out there to argue that a significant amount of systems don't handle to-spec XML.

There are plenty of RFCs out there that define things that no longer practically exist - should they be used, because the spec defines something that you need? Especially if it's meant to be used as an interchange format?
Not to mention that Chile is part of Mercosul, which makes it easier for south american enterpreneurs to move to Chile.
IIRC generics came in 2.0 which narrows it a little.
Nice. I'm going to throw this term out next time I'm with my agile junkies.
> techrights.org

That's where I stopped reading, but I'll say this: Nowhere in the FSF's critique of the MCP is it mentioned whether or not the promise itself is legally binding. From a bunch of people who are supposed to be legal experts. What does that tell you?
Much of the same sentiment jlouis sums up above plus I always keep in mind:

Time, Quality, Cost, Scope

If what your coding will have limited impact on use or functionality, scalability or performance later down the road... Fine. However, it is my experience that standard approaches are standardized for the greater good and health of a "more mature company". As a manager, director and head honcho I sure don't want a developer making that kind of evaluation. It will work for you now, but for your own sake and others later down the road; artfully comment your code!
I'm in the program and am happy to answer any questions. Short version is that this is very much the real thing.

The expenses need to be reasonable (there is a nominal review process), but I haven't run into problems. You can expense most things except alcohol and cigarettes as long as they are related to the business. This includes giving yourself and your staff salaries of up to around $3k USD per month. So a team of two can rent a nice apartment, pay for airfare and insurance, and spend the remainder on personal salaries -- effectively paying themselves to start a business.

Eating out costs about the same as the US and Canada, but cost-of-living is otherwise much lower. And Santiago is an amazing city. Chile has a smaller pool of technical workers than elsewhere, so you can work with people here but are probably best off being a developer. And there's no requirement to incorporate and leave your base of operations in Chile.
Why The Golden Idea Is A Myth
This is the first post from my blog I'm submitting to HN. I hope you get something useful from it. I'd love to hear any thoughts you might have about it.
The only benefit I'm aware of is slightly faster code and even then the dynamic version is almost always more readable and easier to maintain and refactor. The ideal would be a dynamic language with optional static typing but I have yet to see a language like that.
I'm doing BDD as the lead (of 2) Rails developers at our startup, and _its the reason_ we can go so fast.

Some differences we're doing from your situation:

We use Cucumber to cover the whole web app(but not flash or video processing), and only have some small rspec model specs on important methods involving billing.

Cucumber coverage is also very powerful per line of test code. We have 1000 lines of cucumber covering 5000 lines of code.

We aren't covering everything by tests. For example, I would have given up on the Facebook login test coverage, and just written some tests that mock a facebook-logged in user but not covered the actual login funtionality itself.

If we were not doing BDD, my time estimates for each ticket would have to double because the hair-pulling debugging time would skyrocket and kill productivity.

I would also hate working on a team that didn't have test-coverage because developer B might build something I don't understand or know about but I inadvertently break it and we find out 4 days later.

Another benefit: we can ruthlessly refactor and tear out code because the tests immediately identify if something broke.

There's also more payoff for your tests over time. The longer your project lasts, the more those tests pay dividends. Even they seem painful now, they are an investment towards maintainable code in the future.

My advice: keep going with TDD/BDD and consider Cucumber for everything but your most important business-logic methods.
Difference between Session Level Reject and Business message Reject in FIX
In the professional Linux community, almost everyone views Mono-haters as nutters/trolls. If you have real concerns about Mono, I suggest that you contact Miguel de Icaza directly.

Email: miguel@gnome.org

Twitter: @migueldeicaza (http://twitter.com/#!/migueldeicaza)

Blog: http://tirania.org/blog/index.html
Or using those ideas for anything useful. Ideas are just a multiplier of execution.
Hah! Me? Too cautious? I would never have listened to my own advice, but then I had a job in hand and money saved, which seems an entirely different scenario than the OP.

How, also are you too old? Go to your pitch meetings like I plan to: I will be surrounded by octogenarians in overalls and Victorian wimples! Social camouflage!
But there is a counter-point... being to cautious and patient can be a risk in it's own right. In my own case, I look back and feel that I waited too long to indulge my "wild hair" and move to a place with more opportunity.

I would emphasis this as well - I don't think you will get to your death bed some day, and think - "golly, I sure am glad I didn't take any risks. I sure am glad I never did anything stupid."

Sometimes, the real risk is caving to fear.

Another note - never underestimate the value of persistence, and effort. One of my favorite quotes is from Coolidge:

Nothing in the world can take the place of Persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent.
Assume you have little willpower, and set up if and then statements.

a) Little willpower: we react to our environment. Think you have limited willpower then act to create an envrionment which supports your good behaviors.

b) Plan using 'if then' thinking. Studies show that this conditional approach is the key to getting things done.

For example, If I see the delicious unhealthy item on sale for $5 at Store X, then I do behavior Y.
We've now run 5 Health 2.0 Developer Challenge Code-a-thons (we have some Federal gov cooperation and they wont let us call then hackathons!). Sure at each one there is chatting and networking but at each one somewhere north of 100 people produce anywhere between 8-12 teams each of whom show what can be built in a short day (9-5). While they're not always fully completed apps, most are, and most have been terrific.

And while it's OK to bring in something that's been worked on before, most of the teams at the code-a-thons meet at the day and integrate medical professionals with coders.

So anyone who wants to come code at an event where what you build might really make a difference (not that we dont love Zunga & FourSquare, but....) check out www.health2challenge.org
Definitely, adding that to the list.
Processing is pretty cool, I messed around with it a while back. Problem is, once you start making complex enough sketches, you hit a point where it would be really useful to have a debugger, and last I checked processing didn't provide that.

I expect you could probably debug it with java tools somehow, but given that I only learned java via processing on a lark, I didn't explore that path.
A quote of his: "XML is a giant step in no direction at all"
Solowheel: A next-gen Segway in unicycle form
That's ridiculous. You can't just change the meaning of words to suit your opinion!

From the dictionary (I would specifically point you to #3, in case you're feeling too lazy to read all of them):

mor·al
[mawr-uhl, mor-]
–adjective
1.
of, pertaining to, or concerned with the principles or rules of right conduct or the distinction between right and wrong; ethical: moral attitudes.
2.
expressing or conveying truths or counsel as to right conduct, as a speaker or a literary work; moralizing: a moral novel.
3.
founded on the fundamental principles of right conduct rather than on legalities, enactment, or custom: moral obligations.
4.
capable of conforming to the rules of right conduct: a moral being.
5.
conforming to the rules of right conduct ( opposed to immoral): a moral man.
6.
virtuous in sexual matters; chaste.
7.
of, pertaining to, or acting on the mind, feelings, will, or character: moral support.
8.
resting upon convincing grounds of probability; virtual: a moral certainty.
–noun
9.
the moral teaching or practical lesson contained in a fable, tale, experience, etc.
10.
the embodiment or type of something.
11.
morals, principles or habits with respect to right or wrong conduct.

You've clearly got an ax to grind here, but it's not with anything I've said in this conversation. You've thunk up some people out there trying to force you to work in software slave labor camps producing free software all the live long day. I have no idea where you got these ideas from, but it's not from anything I've said, and it's not from the FSF website or the GPL license and relevant documentation.
I've done TDD to a variety of degrees on different code bases, with a variety of success. I think when you achieve the right rhythm and approach for your particular code base and team, TDD can make you go faster. If it's not helping you build quality software quicker than you could without it, don't do it.

A number of these points aren't familiar to me (trouble finding testing for deleted code? harder to modify tests for changing requirements than start from scratch? Renaming variables is hard?). These comments make me wonder if you've been treating your tests the way you treat your code.

When TDD has worked best for me it's because I've spent a lot of time thoughtfully putting some organization into my tests, making sure they're ridiculously fast to write, and ridiculously fast to run. Your source code becomes slave to your tests, that's the whole point. The fact that your tests are in your way, suggests that you're doing it wrong. If you were doing it correctly, and TDD was failing you.. I think the symptom would be your operational code getting in the way instead.
I do that with the TWiT podcasts because they're twice the length they should be and tiresome love-ins half the time.
Hah! Me? Too cautious? I would never have listened to my own advice, but then I had a job in hand and money saved, which seems an entirely different scenario than the OP.

:-)

How, also are you too old? Go to your pitch meetings like I plan to: I will be surrounded by octogenarians in overalls and Victorian wimples! Social camouflage!

Oh don't get me wrong... I don't think (or at least acknowledge) being too old, but I am cognizant that there is a certain sort of bias towards youngsters in this field. I'm still thrashing away like mad on my project, and I'll be pitching it as aggressively as I possibly can (or harder) when the time comes. If anything, in my case, age is just making me hungrier exactly because I have that "I haven't done anything yet" feeling.
Hadn't heard about Greplin before. Interesting.
It sounds like the issue is with how you are writing you tests. For instance, you state "refactoring breaks a lot of test cases". As the normal TDD cycle is test-code-refactor, refactoring shouldn't break your tests. Without seeing your actual code, it is hard to give you advice, but it sounds like your test cases are too coupled with the internal workings of your code, rather than testing the interface.
Two comments:

1. You forgot namespaces. Gotta put SVG in your XHTML.

2. By the time you've done your translation, you've created json that is uglier and harder for a human to visually parse than the equivalent xml.

It turns out that json is useful when you don't want xml's features. Trying to shoehorn every one of xml's features into json creates another brand of hell.
Being an HN member does not grant you magical survival abilities.

There is nothing magical about a large percentage of HN's members possessing a valuable skill(ie. programming, hustling).

Also, despite being an awesome place to be, SF is expensive to live in.

Agree. But there are enough hacks around it. Dining out too expensive? Cook at home. Apartment too expensive? Commute to SF on BART or get an apartment in the Tenderloin. etc.
Good points, I need to present the value proposition more clearly.