donmatito

My framework to think through technical debt: I don't think of it as debt (negatively connoted) but business investment.

When you take a debt it's usually to finance something. Focusing the wording on debt highlights the negative side of the trade off. It's like we're suddenly all turned fiscal austerity hawks, where any bit of debt is evil.

I feel like developers are each placed somewhere on a continuum from purist to entrepreneurs. Purists can spend weeks to tweak an SQL query, while entrepreneurs would be happy with a no-code Zapier MVP that actually lands customers

It's not to say that one is always better than the other. A balanced team probably needs both. In our company, I'm more on the entrepreneur side (which I guess is good for launching a startup) but the recent addition of a "purist" to the team has improved our codebase significantly.

I wonder if they are going to address potential limitations to their systems (bad weather, snow etc). Their tech seems absolutely impressive but I suppose there will always be failure. Does the system fail "gracefully" ?

Total War Warhammer is a very interesting case for that. Many, many races, units, items etc. Much more than Starcraft. And yet the balancing seems quite good! There are obviously tier1, tier2, tier3 races, but even these tiers are disputed and tier1 races rarely win tournaments

Ok now are we getting DeepMind vs OpenAI competition ?

Dimensional analysis and soft matter physics always make for interesting and very readable papers.

What I like the most in this field, is the connection between mundane observations (crumbling paper, tearing scotch tape, pouring shampoo vs honey, etc, etc) and deep insights combining physical phenomenon.

It always makes me smile to see real world phenomenon explained with SIMPLE math but subtle physics

very good answer ! (ok_hand emoji, 100 emoji)

Your case is somewhat particular (and is a very good thing to do). Because you have a log of past events, your memory processes can match against a reference and filter out deviations.

Most people don't have such an external log/reference. Memories cannot be externally validated, only internally validated against other memories. So, small deviations can accumulate, and overtime create entirely false narratives (esp around uncomfortable or even traumatic events)

You make me want to start a diary :-)

An Amazon-published book, winning a prize, pisses the "traditional book industry"

A Netflix-produced movie, winning a prize, pisses the "traditional movie industry"

In both case, these are syptoms of tectonic shifts in the way media, entertainment and art are produced and consumed. Both fights look like rearguard actions, although I am much more sympathetic to the bookstore fight (they are not the one who chose not to publish the book)

I think you did good but employability is crazy good in computer science. Not sure how much is applicable in other fields.

Apprenticeship can work in other engineering fields (at least it does in Germany, for cultural reasons), perhaps a few other fields like sales... but you cannot extrapolate for all educational tracks

Same with other path to software engineers like self-taught or bootcamps. Very good but almost impossible to replicate in other fields with less desperate demand

I don't deny that Taleb brings some great insights, but specifically to the phenomenon you describe, a more relevant book could be Kahneman "Thinking, fast and slow".

The "gut feeling" is framed as the result of expertise + many hours of practice with short feedback loops. Intuition is very valuable and esteemed, much like a chess Grandmaster can say "Mat in 4" just by glance at a game, where you would need many hours of thinking to arrive to, at best, a similar conclusion.

Thinking slow is where we start when we learn a skill (from learning to count when we are toddler, to learning to code, play piano or chess, or practice medecine). It is a conscious, slow, energy-hungry process that leave us tired. After many hours of practice, and, importantly, short feedback loops to feed our internal pattern-matching algorithm, we start to "Think fast".

Thinking fast is quick, easy, not easily described by words as a lot of it happens below consciousness. It is very efficient but also error-prone, as it is based on heuristics. A lot of cognitive bias come from it.

I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol.

I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON.

When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable

Or, "worse is better"

Random-play Monte-Carlo was the first algorithm that lead to good computer Go software, before neural network. It was around 2008 I think. Before that, pattern-base algos were really, really bad (like, barely above human beginner level).

I'm not a mathematician, but the paper itself was a real beauty. I remember vividly the parameter that balanced "exploitation" of apparently-good paths, and "exploration" of unknown/apparently-bad path. I used it in many analogies discussing innovation programs within large companies.

I am not a designer but THIS IS SO AWESOME

Yes I had, but I forgot about it, thanks. Much better than HN own implentation.

Algolia also implemented a linkedin contact search infinitely superior to Linkedin own search.

I remember thinking that both demos were really brilliant growth strategy because it showed clearly, by contrast, how much the status quo was painful

Every time I need to use Algolia in a project, there is this sense of "wow". It's such a magical feeling. Every single time.

The HN search implentation is a bit sad, because it lacks the most magic part of Algolia : the real time search.

Using Algolia in a full-page-load HTML request is using a Ferrari do drive to the grocery store. You can, but what a waste

I have been blessed that the last 3 projects I worked on (roughly past 3 years) were the most rewarding of my professional life.

- a simple hack to connect two Slack teams, just to learn the Slack API, turned into my first solo project to go from ideation, MVP, scaling, pricing (oh god pricing is hard), marketing etc

- helping an education activist spread her new approach to kindergarten education. Not hard technically (built a static page website, a Discourse forum, and organized a few conferences). But judging by the educators' community feedback, it's the most useful I've been in my life per unit work

- joining an early stage startup as CTO, to provide great insurance coverage to freelancers. A project that is at a trifecta of great team, business opportunity, and real social impact to help the "future of work" go in the right direction

Piecemeal batch production to continuous roll-to-roll production is most definitely a step change.

Continuous production allows for mass production, quality monitoring, and progressively increase in width, in a way that is not possible with batch process

Isn't it the temperature needed for enzymes to properly work their metabolic magic (1) temperature helps reaction rates 2) enzymes need a certain temperature to maintain their shapes)

That's a problem earn.com could have solved, but unfortunately only ICO promoters ended up using the platform, I think

Thank you for expressing all this much better than I could

would the 3rd-party database be natively open to 4rth party apps, like an open API ? Given that no third-party actor has offered a tracability solution from source to consumer (the only one that comes to my mind is the beef tracability in Europe following mad cow disease, very paper intensive), what has changed that makes you think the industry can pull it?

these are very good additional points, thank you

Sorry, I replied somewhere else, I don't feel like copypasting, but roughly the blockchain would not prevent false declaration. It would 1) considerably simplify the non-fraudulent papertrail 2) provide an auditable record for investigation in case of either fraud investigation or certification audit

how about scanning a barcode or a RFID reader ? This information is already read and stored in ERP. Is it such a technological step to imagine a RFID reader or an ERP module that would write the information in a blockchain? I don't see the objection here.

The blockchain would be a decentralized papertrail accessible to all actors of the supply chain, down to the end consumer ideally, instead of the current nightmare of shipment papers, siloed ERPs and so on

I agree, that's the issue. I suppose it will depend on the application need, and the criticality.

If you need to prove that life-saving drugs have been kept at the correct temperature throughout their shelf-life, you can probably afford a RFID tag per pack, with a unique ID.

On the other end of the spectrum, if you are talking about low-criticality tracability of shipments of bulk materials, you can probably admit supplier-defined batch numbers. You could imagine that a rogue manufacturer would try to cheat and re-use a batch number from a "premium" raw material while using a cheaper one. Blockchain would not provide a protection against false declaration, it would on the other end provide an immutable papertrail in case of later legal investigation / certification audit (ie "you purchased X premium parts and Y inferior parts, but you logged using X+Y premium parts, how do you explain that?")

Because you have sent them a purchase order and they have sent you a truckload of parts that you ordered? I'm sorry I don't understand the objection here

I know that, but I don't understand why it is seen as such a roadblock. A supplier would add its tag on thousands of parts each day, which would find their way into thousands of products and thousands of end-consumers each day. The suppliers would be well identified by their physical location and the physical products they produce.

I think people raising these objections have not worked in a physical supply chain in the floor plant? I don't know, I have a difficulty to wrap my head around the objection. I am receiving a truckload of parts that I ordered - these parts have a barcode or a RFID identifier that tracks their provenance - the only change in the system would be that when I acknowledge the reception of the truckload, another block is appened to the blockchain-based history of the parts : Supplier + me the manufacturer. And so on across the supply chain.

I don't understand, are we talking about a scenario where a rogue actor would send me for fere a truckload of parts I have not ordered or something like that ?

my answer was not about discussing Git. I was saying that it seems healthy to have a system that tracks errors and corrections