Hacker Newsnew | past | comments | ask | show | jobs | submit | tinymollusk's commentslogin

Just a quick vote to reinforce what you did. You made something, and asked for the most absurd audience to critique it.

Keep being you. HN hated Dropbox, of all things. I am hesitant to announce my product here because I struggle with as widespread of negativity as I perceive here.

If someone isn't going to buy what you're selling, I feel they should be silent and just not buy. If they would buy with a small tweak, there are ways for Bad PMs to put up their credit card. Otherwise, ignore their advice, ignore mine, and keep pushing.

For the people who ask for more, yeah. There's always room for improvement. But if you take down people within our community, you can go sit and spin.


Jon, I run a few sites in a similar space. I feel 1MB is fine for my customer base. If HN isn't your customer, don't worry about them. If HN is your customer, you have the hardest job in the world because none of us will ever pay you anything you can build a business off of.

Go forth and prosper amongst the people who will pay you for the value you provide. Ignore us.


With 100k grants to give, I think you'd want quite a few crackpots, and maybe even some lazy mathematicians. Those could be the types who come up with a game changing result.


I switched to 90+% audiobook after being an avid reader my whole life. I think my eyes have gotten worse, so physically reading because tiring quickly.

The secret for audiobooks, for me, is to listen to them while walking. Currently doing about 50 miles / week, which gets me through 1-2 audiobooks (1.5x, but I rewind and replay a LOT).

I notice my attention is crucial, and varies depending on interactions while walking. When by myself, not crossing streets (down by the walking areas of my town), I can retain a ton.

YMMV, but for me the sweet spot of information consumption is while walking, so audiobooks + exercise beat reading, hands down.


I interpreted that remark as a commentary on humans preference for failing in a conventional manner being perfectly acceptable, versus possibly failing in an unconventional one.

(I also grew up professionally in the 2000s, well after IBM was widely considered elite by the tech nerd community.)


Something I've been wondering about for a while now... Would it be possible to train an algorithm to identify similar characteristics of data from different schema? Looking at the actual data, I mean, and inferring a translation table or the like?

I have a background in data engineering and don't really know where I'd get started. But if you could figure out a way to throw differently schema'd data at an algorithm and have it try to create a universal schema, you'd be wealthy.

There would be a ton of challenges, but the problem you described seems like a societally valuable one to solve.


That's pretty much a description of a chunk of process re-engineering gigs, and even with the data, metadata, domain experts, meetings, and documentation, the results are a struggle to obtain, so any solution will need to set some appropriate expectations. You might find some traction looking into automated ontology building, which has some promising tangents. But I think expecting any black box approach to yield high-fidelity results will end in tears, so there has to be more than just the schema'd data.

For some kinds of data like account numbers, phone numbers, names, and addresses, it is possible to envision some kind of algo. But that's not where the interesting action happens. After working with lots of application developers over the years, I've learned they cram the damndest bits of information into databases, and it's dangerous to make assumptions about how they use the data (whether temporally, structurally, computationally, *etc.). Sometimes with absolutely no rhyme or reason to what or why, either; the rationale and logic is embedded entirely in front of the database within the application code.

Without access to that code, even process re-engineering teams are flummoxed at just understanding a schema, not to speak of porting it. So I find it challenging to envision a scenario where inspecting only the data can yield better results; by the time we're restricting ourselves to only the data, and only at a snapshot in time, we've lost too many bits of information, and the resolution of the solution is too coarse-grained to be universally useful. As we add more inspection time, more fine-grained snapshots, and more kinds of data however, resolution goes up; the real question becomes just how much is needed to generate a MVP.


Richard Feynman's famous quotation is applicable here: "The first principle is that you must not fool yourself — and you are the easiest person to fool".

False positives are often more dangerous than false negatives. This is why the "fake it until you make it" trope can come back to bite you in the read end.


Madoff said he is happier in prison than he was while fearing his scheme would be discovered. [0]

That doesn't really make me any more sympathetic to his criminal and unethical activities.

[0] https://www.cbsnews.com/news/bernie-madoff-happiest-ive-been...


Humans, on the other hand, have all kinds of biases (intentional and unintentional, conscious or not) that creep in because they do have context.

The important thing is that we build systems that account for the process-based problems, not that we build components that are perfect. Things that matter more are how frequently these mistakes happen? What's the impact? Can we eliminate these errors with multiple layers of processes designed to identify the exploits?


The company decision makers could be making a bad decision. They're likely in dire straits to be in this position in the first place. Add in shareholders, some slick marketing/badmouthing from Bain reps, and you have a good opportunity for people to act irrationally, in their personal dis-interest.

Also, you can imagine that Bain has a few inside managers who do very well personally from this kind of deal.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: