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

Data science tips and tricks from the developer community

blog.algorithmia.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Data science tips and tricks from the developer community

#21

Post by escribmac »

mattmanser wrote: post #19

A 10x developer is not ten times more productive than the average developer, they're 10x more productive than the worst developer. Wish this myth would stop perpetuating, they're very clear in the original study. Here's some more details from the horses mouth, Steve McConnell who popularized the concept in Code Complete: http://www.construx.com/10x_Software_Development/Origins_of_...

The worst developers I've worked with take 2 weeks for tickets that should be simple. That would mean doing 1 easy ticket every day or two makes you a 10x....

I've always hated this term and the mindset around it. I think organizational practices, intelligent engineering strategy, etc are far more important to the output of a team than hiring one genius dev.

Re: Data science tips and tricks from the developer community

#22

Post by acdha »

flaviuspopan wrote: post #11
minimaxir wrote: post #2

It's worth nothing that the article does not discuss the reproducibility of results (e.g. with a Jupyter Notebook) and the implementation of said results (e.g. deploying/validating models), both of which matter much more than any code style conventions for data-related projects.

Nothing feels cleaner than storing everything (notebook, raw data, cleansed data, misc scripts, etc.) in a docker image when you're finished with the project. Data science and docker are meant to be besties.

I would prefer recommending a stable build process: — a Docker image can be just like having a VM image or that one PC in the corner of the lab nobody is sure is unneeded. It's far better than having nothing or just the result file but it still has the possibility of needing to reverse-engineer the internal state and given how fast the Docker world moves I would not want to bet on format compatibility 5 years out.

Docker could be that stable build process but it requires the additional assertion that there wasn't, say, a truckload of changes made using `docker exec` or a bunch of customizations to files which were copied into the image. Simply putting a note on the source repo which says that might be enough.

(I really like what C Titus Brown has written about reproducibility in computation research over the years: http://ivory.idyll.org/blog/tag/reproducibility.html)

Re: Data science tips and tricks from the developer community

#23

Post by KirinDave »

flaviuspopan wrote: post #11
minimaxir wrote: post #2

It's worth nothing that the article does not discuss the reproducibility of results (e.g. with a Jupyter Notebook) and the implementation of said results (e.g. deploying/validating models), both of which matter much more than any code style conventions for data-related projects.

Nothing feels cleaner than storing everything (notebook, raw data, cleansed data, misc scripts, etc.) in a docker image when you're finished with the project. Data science and docker are meant to be besties.

This doesn't guarantee reproducible results though.

A lack of reproducibility is a major problem for DSEs and practitioners right now. In fact, I'd argue its the single biggest problem.

Re: Data science tips and tricks from the developer community

#24

Post by KirinDave »

gilbetron wrote: post #15
Angostura wrote: post #13

Earlier quoted context omitted.

Potentially problematic for those who want to check your findings in 30 years time?

Is there a good solution to that problem, though? (Serious question). I recently did a laptop refresh and am using it as an opportunity to solidify my approach to ML development, and would love to hear if there is a good solution to long-term reproducibility. I'm currently leaning towards Docker, but maybe Vagrant or another "pure" VM approach is better...

Not perfectly, but a good start is to keep all the software assets AND data assets you used to train the model.

There needs to be an immutable, high performance read data store that has a 30+ year plan for survival if we're really going to retool our world around expert systems.

Re: Data science tips and tricks from the developer community

#25

Post by sosuke »

gilbetron wrote: post #15
Angostura wrote: post #13

Earlier quoted context omitted.

Potentially problematic for those who want to check your findings in 30 years time?

Is there a good solution to that problem, though? (Serious question). I recently did a laptop refresh and am using it as an opportunity to solidify my approach to ML development, and would love to hear if there is a good solution to long-term reproducibility. I'm currently leaning towards Docker, but maybe Vagrant or another "pure" VM approach is better...

I think the only real problem times you'll find are when the architectures are changed. x86, arm, you'd probably want to port your solution images then if ever. There will always be folks emulating hardware in software on new architectures.

Re: Data science tips and tricks from the developer community

#26

Post by KirinDave »

mattmanser wrote: post #19

A 10x developer is not ten times more productive than the average developer, they're 10x more productive than the worst developer. Wish this myth would stop perpetuating, they're very clear in the original study. Here's some more details from the horses mouth, Steve McConnell who popularized the concept in Code Complete: http://www.construx.com/10x_Software_Development/Origins_of_...

But also, even this data is questionable in the extreme.

It may simply be that "10x" people who do exist do so in ways that are challenging to observe. As an example, not making difficult-to-detect mistakes early in the software lifecycle that cause major problems later (classic real world example: mongodb). Or that their influence on a software org causes overall productivity improvements.

In any case, it's a toxic myth that pits individuals against each other for demonstrations of productivity. I'm of the opinion it's a "self-defeating prophecy" or a good example of the "basilisk" effects in game theory.

Re: Data science tips and tricks from the developer community

#27

Post by Spooky23 »

escribmac wrote: post #21
mattmanser wrote: post #19

A 10x developer is not ten times more productive than the average developer, they're 10x more productive than the worst developer. Wish this myth would stop perpetuating, they're very clear in the original study. Here's some more details from the horses mouth, Steve McConnell who popularized the concept in Code Complete: http://www.construx.com/10x_Software_Development/Origins_of_...

The worst developers I've worked with take 2 weeks for tickets that should be simple. That would mean doing 1 easy ticket every day or two makes you a 10x.... I've always hated this term and the mindset around it. I think organizational practices, intelligent engineering strategy, etc are far more important to the output of a team than hiring one genius dev.

You nailed it.

Those organizational practices and strategy make the best developers better.

If you hire shitty/unqualified developers who cannot communicate, don't know the tools and aren't functional, even the most amazing developer is kneecapped from a productivity point of view because she must be accountable for everything, forever -- the idiots drag her down.

It's like anything else -- if you work at McDonald's, a bunch of slow unmotivated workers will slow down a fast/hard worker. It's just that the value of the labor + output for cheeseburgers is much lower than software!

Re: Data science tips and tricks from the developer community

#29

Post by gilbetron »

delazeur wrote: post #17
gilbetron wrote: post #15

Earlier quoted context omitted.

Is there a good solution to that problem, though? (Serious question). I recently did a laptop refresh and am using it as an opportunity to solidify my approach to ML development, and would love to hear if there is a good solution to long-term reproducibility. I'm currently leaning towards Docker, but maybe Vagrant or another "pure" VM approach is better...

Carve it onto stone tablets.

I prefer gold.
Post reply on HN