3 ms·

I think the issue here is where you put the ceremony. If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order t

I think the issue here is where you put the ceremony. If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways. If you're shipping that model to production and affecting people's lives, it should really be held to a different standard than the "fuck around and see what happens" experiments. And this is before we even get into unexplainability of deep neural nets.

hinkley 6y ago
Except we have that in software, we call it “hacking” and thirty years on some of us still act surprised when the business people try to ship the proof of concept. Stop behaving like you can fake it and then make it later. The code has already shipped and they’re pressuring you to move on to the next problem. Anything you haven’t nailed down by the time the customer is happy is not going to get nailed down. The time you get is the time it takes. So if you genuinely haven’t gotten enough time, then you need to slow down and take the time now, because there is no after. There’s only been two times my code could kill someone, and you bet your ass I didn’t deliver it a moment faster than I thought reasonable, and in one of those cases it ended up being fast enough (the other was, in retrospect, already doomed before I got there)
barumi 6y ago
> If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways. Professional software development has plenty of proofs of concept and "iterating on an approach to a" something. I don't understand what confused state of mind leads anyone to assume that any field of engineering, specially software development, doesn't deal with one off quick and dirty tests. What really boggles the mind is that any data analyst worth his salt knows very well that he needs to track his inputs to be able to analyse the outputs, thus software development practices are far more forgiving than data analysis ones. It seems to me that the author just wants to make excuses for shoddy work.
- hinkley 6y ago
  Or that any field of engineering doesn't have a long list of things that 'are a drag'. I've had no end of people tell me, when The Drag is getting to me, that this is part of why we are paid so well. I don't necessarily agree, I think it's more to do with market value of output, but a large number of people feel that way. Where we do always agree is that there are Things Which Must Be Done, even when you don't wanna.

hinkley 6y ago

Except we have that in software, we call it “hacking” and thirty years on some of us still act surprised when the business people try to ship the proof of concept. Stop behaving like you can fake it and then make it later. The code has already shipped and they’re pressuring you to move on to the next problem. Anything you haven’t nailed down by the time the customer is happy is not going to get nailed down. The time you get is the time it takes. So if you genuinely haven’t gotten enough time, then you need to slow down and take the time now, because there is no after. There’s only been two times my code could kill someone, and you bet your ass I didn’t deliver it a moment faster than I thought reasonable, and in one of those cases it ended up being fast enough (the other was, in retrospect, already doomed before I got there)

barumi 6y ago

> If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways. Professional software development has plenty of proofs of concept and "iterating on an approach to a" something. I don't understand what confused state of mind leads anyone to assume that any field of engineering, specially software development, doesn't deal with one off quick and dirty tests. What really boggles the mind is that any data analyst worth his salt knows very well that he needs to track his inputs to be able to analyse the outputs, thus software development practices are far more forgiving than data analysis ones. It seems to me that the author just wants to make excuses for shoddy work.

hinkley 6y ago
Or that any field of engineering doesn't have a long list of things that 'are a drag'. I've had no end of people tell me, when The Drag is getting to me, that this is part of why we are paid so well. I don't necessarily agree, I think it's more to do with market value of output, but a large number of people feel that way. Where we do always agree is that there are Things Which Must Be Done, even when you don't wanna.