5 ms·

Also, a lot of data scientists find the science fun and the engineering boring. But they have overlapping skill sets - if you aren't good at one, you're probabl

Also, a lot of data scientists find the science fun and the engineering boring. But they have overlapping skill sets - if you aren't good at one, you're probably not good at the other either. Somebody who shows up to a team with the goal of only modeling and pushing all the dirty engineering work to their teammates is basically a worst case scenario because 1) They probably aren't going to produce good models since they're not sensitive to data nuances, but now they've taken over ALL the modeling work. 2) They bring down the job satisfaction of everyone else on the team who would like to be doing at least some modeling. 3) They're sucking up the prestige that should be distributed over the entire team and management thinks they should be paid more for work that it turns out everybody thinks is more fun anyway. My number one advice to entry level data scientists is to not be this guy. Don't give your interviewers the impression that you won't do your own engineering work because they won't want someone who brings negative value to the team.

NikolaNovak 6y ago
Here's the tricky thing: I love your post; I agree with your post; but it takes a 90 degree turn at the end: "My number one advice to entry level data scientists is to not be this guy. " Everything most people are saying here indicates it's GREAT to be that guy. You're paid, you're respected, you get the fun parts, you love your job and it's pretty safe. It just happens to suck for everybody else including team and business... but it feels that in a practical sense, gist of everybody's actual unwitting message is "BE that guy, if you can" :-<<<
- proverbialbunny 6y ago
  It sucks being that guy because everyone else ends up hating you. Depending on the work environment it's not a stretch to see software engineers complaining to management, sometimes going as far to create rumors to get the jr data scientist fired. So, no the grass is not greener. It's best to not be that person. This is why I go out of my way to prevent that scenario when I lead a team.
  - RobRivera 6y ago
    easy to ignore hate when youre pulling a 300k bonus at comp season and can jet to st. barts to go deep sea fishing and drink claws.
    - proverbialbunny 6y ago
      Data scientists do not pull that kind of bonus. Today many of them get paid less than the data engineers do.
      - RobRivera 6y ago
        news to me, and welcome news to hear at that since I'm more in the data plumbing and packaging business, not algo publications. my personal data points are from folks on buyside. trading margins have been downward trending for years
        proverbialbunny 6y ago
        Quant research work isn't data science work which is probably where the mix up is. On the quant side bonuses are distributed to the team.
  - urthor 6y ago
    Not really. You just get seen as the product owner/project manager.
    - proverbialbunny 6y ago
      That's a really good point. I tend to be seen as a product lead / owner / stakeholder, so I feel like I'm being called out. lol I think one difference is the software engineers see me as someone who is helping them by making their life easier. I'm not just throwing work at them blindly. I'm working with them. Also, they like it when I include them in the data science brainstorming sessions to solve difficult problems. I guess it's seen as exotic or something, but whatever the reason, they really love to be apart of it.
- noodlenotes 6y ago
  Specifically, this is my advice to ENTRY level data scientists who are trying to find a job and compete against a flood of candidates hot off the bootcamps. I guess once you get your foot in the door, you can be that guy if you want. It seems to be a successful strategy at companies without technical leadership.
- urthor 6y ago
  The flipside is that there are 4x the job posts for data engineering as there are for "that guy". Companies understand that you can't hire five of that guy and get things done. If you have 5-8 years of experience as a technical product manager/data science combo then you are very happy as the magician. But very few magicians are being hired out of college, and a lot of "software engineers in data"
  - mywittyname 6y ago
    Pretty soon companies are going to start realizing that the 4x DEs can largely replace that 1 DS, and they will be more than happy to do so. I went into DE because I was kind of forced into the space, but I'd strongly prefer doing full-stack DE. Anymore, I still have the opportunity to build models, they just aren't client-facing stuff, but instead are kind of Data Plumber Bots that help me do my job better so I can waste more time building other fun bots that I can't otherwise be paid for. Seems like a waste of resources, but my manager could have another DS tomorrow, but my role would take months to fill.
- ramraj07 6y ago
  If you're that guy and you have a secure job it means you write models no one ever sees in a company which doesn't know or respect data, or you work in some data science factory as a small cog of a fairly well oiled team. The latter does happen from time to time, but it's often the former. In every other place, your job is on the line to be erased because people will soon realize no one wants a wise-ass who doesn't actually contribute much to the bottom-line in the end.
proverbialbunny 6y ago
Back in the day (3 years ago and earlier) at every company I was at we used the term 'productionization' to describe someone making a model aka a proof of concept, and then someone else, a machine learning engineer or some kind of engineer rewriting it to work on a server. This process is horrible, and not just because it doubles the work, but because it introduces bugs. When the version up in the cloud does not work as intended, is it a bug in productionizing or is it in the original model? Fixing bugs in this space can take longer than the initial model development and the initial productionization. Many companies have failed over this. So what's the solution? In recent years the industry has turned to deployment over productionization. The idea is you deploy the model to the cloud directly. Both engineers and scientists work together on the process. The scientist defines what cells in the notebook get called for the final algorithm (as there are EDA / plotting cells and documentation cells too). The engineer sets up the amazon IO stuff, database login stuff, and monitoring services. The scientist works with them to create tests and what to monitor so they get notified if there is a problem with the service. No more mystery bugs. The model gets directly deployed, the work load is minimal, and it brings people together. The downside is often the engineers and scientists are on different teams, and sometimes companies will not let them merge for a while, so it becomes a telephone game instead of everyone feeling like they're on the same team working together. imo moving the scientist to the engineering team during this time can be helpful, or moving the engineer to the data team. Some companies have services where entire notebooks get put up into the cloud and all of it gets called, so the scientist has to write the notebook in a way that works for the cloud. It's rarer, but how I prefer it is a wrapper py file is created that calls just the relevant parts of the notebook, kind of like a header file. This process works well for me, but it as far as I know it is not standardized in the industry yet. In short, if you end up in this situation, there is a better way. Import the notebook into a .py file or into the cloud, don't rewrite it. This (hopefully) will remove this scenario you're describing (comment this is replying to) so those issues will become a historical footnote.
- carabiner 6y ago
  How do you maintain notebooks in production? You use papermill? What about versioning?
ramraj07 6y ago
It's hard for most people entering this field because the incentives are perverted - there's this perception that DS is sexy and you actually don't need to know coding that much (just enough to scikit learn). Thus people with pipe dreams of tweaking model hyperparameters to spin gold come in and get a rude awakening. Not a lot unlike people flocking to become actors to LA.

NikolaNovak 6y ago

Here's the tricky thing: I love your post; I agree with your post; but it takes a 90 degree turn at the end: "My number one advice to entry level data scientists is to not be this guy. " Everything most people are saying here indicates it's GREAT to be that guy. You're paid, you're respected, you get the fun parts, you love your job and it's pretty safe. It just happens to suck for everybody else including team and business... but it feels that in a practical sense, gist of everybody's actual unwitting message is "BE that guy, if you can" :-<<<

proverbialbunny 6y ago
It sucks being that guy because everyone else ends up hating you. Depending on the work environment it's not a stretch to see software engineers complaining to management, sometimes going as far to create rumors to get the jr data scientist fired. So, no the grass is not greener. It's best to not be that person. This is why I go out of my way to prevent that scenario when I lead a team.
- RobRivera 6y ago
  easy to ignore hate when youre pulling a 300k bonus at comp season and can jet to st. barts to go deep sea fishing and drink claws.
  - proverbialbunny 6y ago
    Data scientists do not pull that kind of bonus. Today many of them get paid less than the data engineers do.
    - RobRivera 6y ago
      news to me, and welcome news to hear at that since I'm more in the data plumbing and packaging business, not algo publications. my personal data points are from folks on buyside. trading margins have been downward trending for years
      - proverbialbunny 6y ago
        Quant research work isn't data science work which is probably where the mix up is. On the quant side bonuses are distributed to the team.
- urthor 6y ago
  Not really. You just get seen as the product owner/project manager.
  - proverbialbunny 6y ago
    That's a really good point. I tend to be seen as a product lead / owner / stakeholder, so I feel like I'm being called out. lol I think one difference is the software engineers see me as someone who is helping them by making their life easier. I'm not just throwing work at them blindly. I'm working with them. Also, they like it when I include them in the data science brainstorming sessions to solve difficult problems. I guess it's seen as exotic or something, but whatever the reason, they really love to be apart of it.
noodlenotes 6y ago
Specifically, this is my advice to ENTRY level data scientists who are trying to find a job and compete against a flood of candidates hot off the bootcamps. I guess once you get your foot in the door, you can be that guy if you want. It seems to be a successful strategy at companies without technical leadership.
urthor 6y ago
The flipside is that there are 4x the job posts for data engineering as there are for "that guy". Companies understand that you can't hire five of that guy and get things done. If you have 5-8 years of experience as a technical product manager/data science combo then you are very happy as the magician. But very few magicians are being hired out of college, and a lot of "software engineers in data"
- mywittyname 6y ago
  Pretty soon companies are going to start realizing that the 4x DEs can largely replace that 1 DS, and they will be more than happy to do so. I went into DE because I was kind of forced into the space, but I'd strongly prefer doing full-stack DE. Anymore, I still have the opportunity to build models, they just aren't client-facing stuff, but instead are kind of Data Plumber Bots that help me do my job better so I can waste more time building other fun bots that I can't otherwise be paid for. Seems like a waste of resources, but my manager could have another DS tomorrow, but my role would take months to fill.
ramraj07 6y ago
If you're that guy and you have a secure job it means you write models no one ever sees in a company which doesn't know or respect data, or you work in some data science factory as a small cog of a fairly well oiled team. The latter does happen from time to time, but it's often the former. In every other place, your job is on the line to be erased because people will soon realize no one wants a wise-ass who doesn't actually contribute much to the bottom-line in the end.

proverbialbunny 6y ago

Back in the day (3 years ago and earlier) at every company I was at we used the term 'productionization' to describe someone making a model aka a proof of concept, and then someone else, a machine learning engineer or some kind of engineer rewriting it to work on a server. This process is horrible, and not just because it doubles the work, but because it introduces bugs. When the version up in the cloud does not work as intended, is it a bug in productionizing or is it in the original model? Fixing bugs in this space can take longer than the initial model development and the initial productionization. Many companies have failed over this. So what's the solution? In recent years the industry has turned to deployment over productionization. The idea is you deploy the model to the cloud directly. Both engineers and scientists work together on the process. The scientist defines what cells in the notebook get called for the final algorithm (as there are EDA / plotting cells and documentation cells too). The engineer sets up the amazon IO stuff, database login stuff, and monitoring services. The scientist works with them to create tests and what to monitor so they get notified if there is a problem with the service. No more mystery bugs. The model gets directly deployed, the work load is minimal, and it brings people together. The downside is often the engineers and scientists are on different teams, and sometimes companies will not let them merge for a while, so it becomes a telephone game instead of everyone feeling like they're on the same team working together. imo moving the scientist to the engineering team during this time can be helpful, or moving the engineer to the data team. Some companies have services where entire notebooks get put up into the cloud and all of it gets called, so the scientist has to write the notebook in a way that works for the cloud. It's rarer, but how I prefer it is a wrapper py file is created that calls just the relevant parts of the notebook, kind of like a header file. This process works well for me, but it as far as I know it is not standardized in the industry yet. In short, if you end up in this situation, there is a better way. Import the notebook into a .py file or into the cloud, don't rewrite it. This (hopefully) will remove this scenario you're describing (comment this is replying to) so those issues will become a historical footnote.

carabiner 6y ago
How do you maintain notebooks in production? You use papermill? What about versioning?

ramraj07 6y ago

It's hard for most people entering this field because the incentives are perverted - there's this perception that DS is sexy and you actually don't need to know coding that much (just enough to scikit learn). Thus people with pipe dreams of tweaking model hyperparameters to spin gold come in and get a rude awakening. Not a lot unlike people flocking to become actors to LA.