4 ms·
Definitely agree with this. I do see more folks out there (like myself) with one foot in both the data science and production engineering worlds, and my persona
by jlees 12y ago
Definitely agree with this. I do see more folks out there (like myself) with one foot in both the data science and production engineering worlds, and my personal approach to the problem of black boxes would be to have more of us! Rather than some 'sucker dev' implementing a statistician's hack, a full-stack mindset means the data science is done with engineering considerations all along.
But even then, half the joy of data science is not really knowing what you're doing at first as you research and experiment, just as your first attempt at a production system for something complex will also not necessarily be the final thing. If you have both of these at once, you can end up with a 'production' system that looks pretty well-designed and, indeed, works well enough at first -- until the product outgrows it, leading to a somewhat uncomfortable transition later on.
My personal anecdote starts with my PhD research which initially used a combination of Perl scripts, WEKA and god-knows-what-else, on fixed pre-formatted corpora, and became a Python engine powering a Django web-app using the Twitter API - not exactly rocket surgery at Google scale, but I found the whole shift in mindset from research to execution extremely useful and totally recommend to any data scientists who have focused solely on research that you try the other side of the fence, at least a little.
Stripping things down and simplifying, getting that 80/20 balance right, that's also some of the investigative fun of data science and we shouldn't get carried away with our own cleverness to ignore the poor sods who have to use the models we build years from now. I was consulting on a project which had very complex visions of a layered AI system using machine learning to make key decisions, but given the stage of the project and the depth of ML knowledge of the team, it was way easier for the initial stages to use what was effectively a switch statement on pre-defined values instead. You can always add complexity!
- atrilla 12y agoI see lots of common points with the "lean" method here (at the expense of technical debt), but can't forget Knuth's advice that premature optimization is the root of all evil. To me, the utmost important aspect to take into account is the "key" of the business. I had a similar story with my PhD research (AI+NLP): I wanted to focus it on adding value to commercial products. I worked on the core of the implementation, I built it with Java, with a configurable pipeline, plus an online app with servlets. I did attain getting noticed by some companies, but at the moment of closing future lines with them, my adviser told me this was not what he expected from me, and I was forced to get back to the non-useful-goal-centred research of academia. I am still glad I did what I did, regardless of how useless it was eventually, but my knowledge grew, and I learned how important it is to know your business model before you do anything at all. I learned how unbalanced is the academic market, always relying on public funds to survive instead of worrying about building useful appealing stuff. I realized where I wanted to be, so I dropped out and joined the private industry where I now feel very fulfilled. My present approach goes from small to big, little by little, getting as much feedback as I can so I can fix mistakes asap and prevent them from getting bigger and more difficult to manage. My agreement with your words.