Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Move Slow and Make Things

multithreaded.stitchfix.com

Post reply on HN
Print view View original

51–60 of 133 posts

Re: Move Slow and Make Things

#51

Post by jokethrowaway »

ZephyrBlu wrote: post #29
fxtentacle wrote: post #23

Earlier quoted context omitted.

People usually just call it AI then and pretend that it's not a problem. For example, there's been plenty of issues like racial bias with the computer vision algorithms that police uses, which effectively is data science on pictures. But nobody knows why the issue occurs and nobody can specifically fix it without the risk of breaking a thousand unrelated other things.

> But nobody knows why the issue occurs They do know why that occurs. It's because the data set is biased.

Is it a case of BAME have less stable families, are poorer, commit more crimes and therefore are more represented in the data which lead to even more incarcerations?

Re: Move Slow and Make Things

#52

Post by marcinzm »

solarmist wrote: post #3

I’m sad this is an April fools joke because a lot of the sentiment rings true and I love the slogan “move slow and make things.” Artisans make beautiful things and software artisans make beautiful software, but it’s hard to do it and still be a viable business. And artisans moving slowly isn’t arbitrary. They move slow on the things that matter. The things that shine when attention was paid to the details.

The issue is that beautiful software is invisible except in open source projects (and even then few people look under the hood). So to an end user only the UI/UX/bugs matter while everything else doesn't.

Re: Move Slow and Make Things

#53

Post by jkingsbery »

solarmist wrote: post #3

I’m sad this is an April fools joke because a lot of the sentiment rings true and I love the slogan “move slow and make things.” Artisans make beautiful things and software artisans make beautiful software, but it’s hard to do it and still be a viable business. And artisans moving slowly isn’t arbitrary. They move slow on the things that matter. The things that shine when attention was paid to the details.

I had a similar reaction. It's a nice April fool's joke, but I hoped for an actual counter-balance to "move fast and break things." The book that taught me the value of moving slow in programming was Test Driven Development by Kent Beck, who ironically spent several years at Facebook.

Re: Move Slow and Make Things

#54

Post by loceng »

valuearb wrote: post #5

This would have been a great slogan for Steve Jobs. Apple was rarely first with anything, but often first with something useful and special.

A good example of this wise type of management: Apple let music platforms mature before learning from them to create their own offering to then easily market to their hundreads of millions of users - with the advantage of customers who 1) are generally willing to pay a higher, and 2) Apple gives the App Store fees to themselves.

Their watch, and next the car - will be the next arguably iconic products.

Re: Move Slow and Make Things

#55

Post by marcinzm »

disgruntledphd2 wrote: post #17
jiofih wrote: post #12

Earlier quoted context omitted.

Same feeling here - instead of laughing I was disappointed when the second paragraph laid out the April fools joke. I would love to see “small batch data science” where people actually understand the results. Black box recommendations never feel really right.

It's called statistics, to be fair. In general, if your DS's can't explain the model then something has gone horribly wrong.

>In general, if your DS's can't explain the model then something has gone horribly wrong.

With modern ML models data scientists can generally explain why the model should work but not exactly how it gives any specific prediction. Explaining how a model with a trillion parameters comes up with an answer is not a trivial task.

Re: Move Slow and Make Things

#56

Post by mauvehaus »

jokethrowaway wrote: post #51
ZephyrBlu wrote: post #29

Earlier quoted context omitted.

> But nobody knows why the issue occurs They do know why that occurs. It's because the data set is biased.

Is it a case of BAME have less stable families, are poorer, commit more crimes and therefore are more represented in the data which lead to even more incarcerations?

First: I don't think you can claim that without also doing some very rigorous statistics. I'm not asking you to, but if you're going to base policy on that statement rather than merely arguing on the internet, you'd need to.

Second: even if you do, you're going to have a hard time controlling for the fact that the police and criminal justice system has a long history of disproportionately enforcing the law against people of color. The base data about who commits crimes, gets convicted, etc. for well over a hundred years is going to reflect this bias.

I'm not claiming to have done my homework here either, same disclaimer applies. I suspect you could find somebody who does study this if you wanted to look.

All of the above assumes we're discussing the US, btw.

Re: Move Slow and Make Things

#57

Post by pdimitar »

I have to admit: if they didn't go overboard with hand-printed cards and carrier pigeons, I'd believe the article.

As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent.

I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to the past -- make it impossible on a hardware level as a start, then the programming languages will adapt in a matter of a few months at the maximum.

Re: Move Slow and Make Things

#58

Post by marcinzm »

tremon wrote: post #48
ZephyrBlu wrote: post #29

Earlier quoted context omitted.

> But nobody knows why the issue occurs They do know why that occurs. It's because the data set is biased.

No, you don't "know" that your dataset is biased until you perform the statistic analysis explicitly. It might be that your neural net has a non-uniform weight distribution in some dimension (e.g. in time, or in the ordering of the training data), so dismissing any unwanted results by claiming "your dataset is biased" is a form of appeal to (artificial) authority.

It's not an appeal to artificial authority. It's a very likely root cause and comes with a solution even: get a different data set or adjust your existing data set. Your response rings of No true Scotsman to me since you can argue any analysis is not rigorous enough or doesn't cover all potential issues.

edit: And a statistical analysis isn't some sort of magic data genie. Statistics can give rigorous results because it makes strong assumptions. If those assumptions don't hold then the results aren't rigorous anymore. A trillion parameters model can pull interactions out of your data that almost no statistical analysis of the data would identify ahead of time. So what you need to analyze is the model and try to infer why it's predicting different certain results and then work backwards from there.

Re: Move Slow and Make Things

#59

Post by swiley »

pdimitar wrote: post #57

I have to admit: if they didn't go overboard with hand-printed cards and carrier pigeons, I'd believe the article. As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent. I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to t…

Shared state is fundamentally hard. I don't think you can make it bullet-proof at the hardware level without sacrificing performance.

Re: Move Slow and Make Things

#60

Post by pdimitar »

swiley wrote: post #59
pdimitar wrote: post #57

I have to admit: if they didn't go overboard with hand-printed cards and carrier pigeons, I'd believe the article. As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent. I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to t…

Shared state is fundamentally hard. I don't think you can make it bullet-proof at the hardware level without sacrificing performance.

Exactly because it's fundamentally hard, it must be avoided -- we the humans simply can't be trusted with it (speaking as a former C/C++ dev here).

It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot of kernel data structures could be atomically updated; this alone would fix a lot of contention problems).

The hardware can also just work in a CRDT/OT-like manner, namely accumulate update requests for a memory location in small queues (that get flushed after 10 nanoseconds or after the mini queue fills up). This could help with a good chunk of the buggy scenarios as well.

Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.

It gets a bit disappointing and grim after you have been in the profession for a while, you know?

Post reply on HN