Most of this nit-picky advice will not increase my leverage. What I think would: occasional access to domain experts in specific niches of data science.
What would that look like? Data-scientist AMAs? Or in person? What would you like to see?
Data science tips and tricks from the developer community
61–69 of 69 posts
Re: Data science tips and tricks from the developer community
#62Earlier quoted context omitted.
In my experience if you develop a "data science pipeline" forcing the data scientist to build - reproducible - validated - back-tested - easy to deploy models, they are going to hate it. It just kills the fun and/or makes obvious if they made a mistake.
So we should sacrifice all the things that actually make a Data Scientist's work valuable in the name of fun and obscuring mistakes? Fun I almost get, obviously good for productivity (though I think you'd really be sacrificing productive output for non-productive output), but I just don't get where you're even coming from with the "making mistakes more obvious" angle.
Re: Data science tips and tricks from the developer community
#63Earlier quoted context omitted.
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.
Potentially problematic for those who want to check your findings in 30 years time?
http://www.newyorker.com/tech/elements/voyager-golden-record...
Re: Data science tips and tricks from the developer community
#64It'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.
Re: Data science tips and tricks from the developer community
#65Earlier quoted context omitted.
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…
The real 10x developers in my experience are the hardest to measure. Because they pull the whole team by always being helpful and improving things where they see potential. But that doesn't necessarily show up in their results, but in the whole teams results. Which is why metrics driven organizations in my experience with their disincentive to help others, slow everything down.
It's a matter of perspective.
Re: Data science tips and tricks from the developer community
#66Earlier quoted context omitted.
To put it cynically, if you other people can reproduce your results, you might not be demonstrating that you are x10 more productive than them. Which is to say I think starting with the idea that you're aim for x10 is pernicious and tends to create dysfunctional teams. The claim some developers in some circumstances are ten time more productive than others may or may not be true but software development needs process…
Yes, it's better to have an x10 team, rather than an x10 developer. Developers should strive to better themselves, but it's important not to fool yourself, too. Having a strong team is almost always better from a business point of view.
I shun "rockstar" and "10x" (and whatever other bullshit moniker they will come up with next) team members. Give me a group of smart people that gel well together, and are highly self-confident without egos getting into the way, and we can move mountains.
Re: Data science tips and tricks from the developer community
#67Earlier quoted context omitted.
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.
Did it ever occur to you they might not be bad developers, they're just goofing off because there's no consequence for being slow? Like when my old work actually started measuring ticket closure times, our best developers were only 2x more productive than our worst ones. But suddenly a lot more tickets were getting closed. I mean,I know that some complicated tasks needed the best developers, as the worst ones literal…
Re: Data science tips and tricks from the developer community
#68Earlier quoted context omitted.
The job you're describing may have the title of Data Scientist, but it isn't data science if it doesn't involve advanced methods.
That's a semantic battle you've lost already.
Re: Data science tips and tricks from the developer community
#69It'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.
Hey thanks for the comment! I'm the author of the talk-turned-post :-) You are completely correct about reproducibility being super important in data science workflows. While I did mention it in the post (and in the talk the post was based on), I mentioned it as a part of version control tools. That said, I think it's not something that is focused on enough (obviously I'm guilty of that too) so I plan on doing a foll…