Ideas must change in response to feedback from the problem to be solved.

The initial idea and its nth iteration are downstream from the real problem. What matters, therefore, is the iterative execution of those solutions. So instead of basing our judgment on the quality of the idea, we should rely on the execution ability because that is fairly constant in the development loop.

If you end up on the far-side of an idea-driven development process, you'll have solutions looking for a problem.

We don't build software like a bridge; we grow it like a garden. The industrial revolution was about building machines that dominate its environment. The software revolution is about writing code to resonate with its environment. The software grows in harmony with its user and business needs. Except, of course, for special cases such as this.

"The whole approach to developing software is intentionally designed not to rely on any particular person."

Our programming culture is not ready for this. Any programmer who identifies with their craft will never want to be another cog in the machine. A programmer could have chosen to be a doctor, lawyer, engineer, etc. but they choose to code because it is one of the way they can "express" themselves.

> A programmer could have chosen to be a doctor, lawyer, engineer, etc. but they choose to code because it is one of the way they can "express" themselves.

Not necessarily. I chose to code because I'm good at it and because I'm not good enough at anything else to do it as a job. Well, at least not in the same salary range.

I agree with your point otherwise but I'm not sure that people solely choose to become software developers because they wish to express themselves through their work. A lot of developers I know personally see coding as just a job. A job they like, but a job.

If you put as much effort into law as you have into software you would be a good lawyer and a terrible developer. It is a choice. Today your effort learning software pays better (with exceptions both ways) then law, but historically law has been good. I decline to speculate on if law will earn better than software in the future.

You can say the same for medicine, any other engineering field, farming, ditch digging, or any other job. Regardless of which you choose some love it and some it is just a job.

The analogy of maps and boats is just an instance of the exploration-exploitation idea. I have seen instances of this pop up every time we discuss problem solving in some form. It falls in the perennial variety of ideas that can't be revisited enough.

Updated. Thanks for pointing it out.

Thanks for the great feedback.

The paper by Sproat and Jaitly which introduces the challenge rightly notes that the acceptability of errors and quality of output is more important than accuracy for a real application. The number of instances in all of the critical semiotic classes is too low (1-2k for some, even less than 100 for others) for a meaningful comparison in accuracy.

But you are right to point out that the 'unacceptability' of errors could be analyzed better. However, we could not think of a way to quantify or form a metric that measures such errors. These 'silly' errors are subjective by their very nature and depend on a human reading them. As you have suggested, we are working on preparing a table of sorts to summarize all these errors and show a link between the availability/frequency of particular types examples to the performance of our model on those particular types. Something of this sort for example:

* The training set had 17,712 examples in DATE of the form xx/yy/zzzz. Upon the analyzing the mistakes in DATE class we did not find any mistakes made in the dates of the above form.

* On the other hand, if look into the mistakes made in MEASURE class we find that the DNC network made exactly 4 mistakes. The mistakes were reported in the units (g/cm3, ch, mA). Upon searching for the occurrences in the training set of these units, we found out that 'mA' occurs 3 three times, 'g/cm3' occurred 7 times and 'ch' occurred 8 times, whereas other measurement units like kg occur 296 times and cm occur 600+ times.

If you have any other ideas on how to analyze and report the results, please let us know. We will be glad to improve the quality of our work (By the way, we are undergrads and this is our very first research paper). Thanks again!

I have compiled all the valuable advice and suggestions here into a blog post for other students like me:

http://amandavinci.me/hackernews-advice-for-budding-makers-h...

Thanks. I'm currently taking the OS course this sem and we plan to build a minimal OS for raspberry pi from scratch using the linux kernel, writing system programs on top of it.

For internships, I believe start ups are the best bet to gain experience and maybe gain a mentor for life.

That course sounds amazing, you should blog about it.

Start-up internships and GSOC are the best use of a summer vacation, I agree.

And regarding software education, I believe MOOC is going to play a very big role in the near future especially in countries like India where hard working and deserving students lack quality world class education.

And given the Indian affinity for certificates and credentials, I believe this could be a great start up idea too.

In an ideal world, you won't need MOOCs. One thing I keep repeating is:

    Make > Learn > Read

Where Make = Actually working on a project, Learn is actively learning a topic (via a course or a book you're following), and Read is just reading through books or online guides.

This has served me well as a guide, however it doesn't apply neatly to all areas. Invest in Skills, not Credentials.

That seems a great hack :)

I love to talk to other passionate CS students too. Helps me reorient and correct my perspective.

And I'm gonna follow your advice and blog about my learning experiences. Infact, there are valuable gems of advice here and I'm thinking to compile them together in a blog post for many other curious students like me.