Data Science Hangout | Sep Dadsetan at ConcertAI | Infrastructure that Encourages Reproducibility

Transcript#

This transcript was generated automatically and may contain errors.

Welcome to the Data Science Hangout. Thanks, Sep, for jumping on and co-hosting with me today. So welcome back to all the familiar faces and to those joining for the first time. It's really fun to see this like recurring group starting to form. But for anyone new today, these discussions cover a variety of different topics on data science leadership in the enterprise, but really focus on questions that are most important to you all. So again, no agenda and everyone is welcome to join in live or put any questions that you have in the chat.

That said, I'd like to just jump in here and introduce Sep Dadsetan, Executive Director at RWE. And I am checking with you that is real world evidence analytics at ConcertAI. But Sep's passion about learning and exploring new concepts and ideas and, and bringing them to life. I found that on your website somewhere. And I will say, Sep, I did learn a few random things about you making that into like DJing and footgolf. But would you be able to kick things off by introducing yourself and sharing a bit about the work you do?

Yeah, happy to. I'm glad to be here. I think I've already been in part of several weeks of discussion and it's highly valuable. So I definitely encourage you guys to share your perspectives. I think this is a great opportunity to just learn from everyone. So yeah, so my name is Sep Dadsetan. My formal training education is in actually like molecular physiology. So I studied immune cells and T-cells. And then made a, did a brief postdoc at Genentech studying B-cells, another immune cell. And then that's when I said I was going to leave academics and join a startup company, which was CyApps, where we worked with real world data and real world evidence there. So that was most of my tenure, seven and a half years there. Brief stint at Kite for a couple of years doing IT for their R&D group. And then recently joined ConcertAI back in the real world data space about six months ago now.

So that's kind of the brief tour there. With respect to what I do, at Concert, I'm mainly kind of focused on achieving kind of scalability, reproducibility, doing some training, and trying to, at this point, really kind of focusing on architecture and trying to kind of gather our teams and smooth some edges, so to say.

But if you do it right, the next time they come around, it turns around a day, they they fall out of their chairs, right? And I think that that's where all of a sudden, you're you're showing that, look, this is this is the value of doing things in a manner that's that's reproducible and scalable, because we're saving costs, where we are turning things around that impresses, you know, the customer.

And so kind of scale and all those things are kind of an interest for me, but I don't know, now I'm just probably blabbering, I'd love to hear other people's take.

I think, you know, you probably the adage that's like 80% of a data scientist's time is spent cleaning, cleaning data and organizing data might be appropriate. I don't know, I've never really kind of thought about it. To be honest, I just kind of like get it done and try to do it in a manner that I don't have to do it. Like repetitively try to build on knowledge.

Yeah, I mean, I think that goes to, I guess, to go back to Rachel's question about what gets me excited, right? So what gets me excited is that great, all these businesses are very interested in data, we're here to stay, right? But there's a flip side to that is that data literacy also is required. And so there are various levels. So some people are happy to understand the nuance and the nitty gritty of why it takes so long to kind of stitch these things together. And then there are others that are saying, look, we need to deliver to the customer, this is what we want. And I get that it takes time, but hurry up, right?

And so, yeah, I mean, I always try to kind of simplify and really kind of point out, give status updates. I mean, transparency for me is really important. So if you're transparent with your stakeholders and they recognize what the blockages are, and I think everybody that you're going to get engaged with is going to want to know something that you might be able to help out. I think that again, helps with establishing that relationship and having them get a little bit closer to the data and understand some of the hurdles that you might face. But yeah, sometimes patience is perhaps thin and they don't quite, quite get it. But that comes with this other side. If you're going to be more data company, we're going to have to have more data literacy and what are better methods of perhaps working with data and how it can enhance us rather than, let's say, throw people at a problem, do it intelligently from an engineering standpoint, so that you can scale your operations.

Setting up the infrastructure to encourage reproducibility

Yeah, great question. So yes, I mean, reproducibility and scalability all, I mean, it relies on the success of training, making sure everybody's doing things and the processes are all the same. And it also is related to this partnership and relationship.

So part of reproducibility for me is, you know, everything, I mean, it's like, it really involves everything. So, you know, making sure everyone's kind of using, you know, let's say version control the same way, that naming conventions are the same. We built a, basically a package, an R package so that when people create new, because we use RStudio . So we create a new package. So when you create a new RStudio project, that project will always be the same. So it creates the same folders, the same setup. So when I'm talking infrastructure to make it reproducible, everything from how you use code, how you name your code, how you name your variables, how your projects are set up, how your files are named, all of that stuff. They're really, really annoying little things, but they bubble up to be so much more because when you create a project, for example, an analytical project, everybody that it becomes a transposable unit. That means I can take my project. I go on vacation for a year, someone emergency request, someone else can pick it up and know exactly where the data is, know exactly where the scripts are, you know, et cetera. And they could, they should be able to pick it up with a lot less, you know, overhead for having to figure out, oh, well, how did Sep organize this stuff?

I think a big part of it actually, to be honest, is a lot setting up a lot of that real basic stuff. And then it also makes it much smoother so that every time you set up a project, you don't have to like, think about, think about those things. You just kind of go, this is where you write your stuff and whatever. And then we happen to use RStudio Connect as well. I know that there are other solutions, but that allows us a feedback loop. I think one of the aspects that, you know, that we ended up talking a lot about in these weeks are like communication and how you communicate with business stakeholders. And so, you know, if we're going to set up that, you know, RStudio project, we want to then be able to publish it, whatever that output is, whether it's an API, whether it's a product, a report, whatever, an application, we want to be able to publish it and publish it in a central location. So people aren't trying to search for it everywhere. And then we have a URL, we could share that URL and we get this feedback loop. It's not sitting in somebody's email and part of a chain. You have to then go through your email. And so we've kind of streamlined it. And that allows us to kind of, you know, basically hit a conveyor belt. If there's iterations, changes, we can kind of do that. And then it's modular so other people can kind of pick it up. So that's the kind of, I guess, reproducibility and scalability that I'm referring to.

The importance of architecture and data quality

I mean, generally you have to partner pretty closely with your data engineering team. It kind of depends. Sometimes data engineers themselves have a little bit of an analytical bent to them. So they're always kind of constantly checking. Other times there's a dedicated QC team that's constantly evaluating and kind of sampling as data moves from place to place, just to make sure that you are collecting the right information and that all the transformations are going accordingly. Other times, and again, depends on the size of the company and how roles are broken up. The data science team should have someone that is actually kind of evaluating or at least generating some sort of report out of wherever the staging areas of your existing data is sitting to kind of hopefully prevent that where you do all this work and eventually you get it and you're like, oh boy, this is not what we wanted at all.

Yeah, I don't know. I think, you know, Sep spoke pretty well to it. I just find that communicating upfront and I think design kind of does this intrinsically is when you spend a lot of time on designing kind of what the output solution is going to be. It requires you to bring all the stakeholders to the table upfront, you know, the owners of the data, the owners of the platform, the people who are going to be using your solution, you know, on the ground day in and day out, the technical folks in your analytics team, and then also the IT team that might be enabling the solution to even work, security, infrastructure, stuff like that. I think when you focus, when at least you attack the project with a design mindset up front and really focus on nailing down, you know, what the end-to-end process is going to look like, I think it pays off quite a bit in the end in ensuring that, you know, whatever you put together is well architected. I find myself nowadays probably drawing as many, spending as much time drawing architecture diagrams as I am writing our code, which, you know, is fun if you're into that, but I think it's an important step to take in any project, and I think it's a good team mindset to have as well.

Balancing formality and speed on teams

Yeah, that's a great question, and it is a common situation for better for worse. Again, it depends on the culture of the team and what the business is really kind of after, I think, and it depends on, I don't know, what relationships are like. I like to try and lead by example, so at the very least, if I'm finding that it's difficult to kind of, you know, hey, like look, this is a large team, or the team's really, everyone's kind of just doing their thing and in their own lanes, at the very least, I try to simplify it for myself and try to make my work more reproducible. And in many cases, what ends up happening is whether there's, you know, code review or whether there is, you know, future fire drills or whatever, that process will always win out, right. And when someone else sees it, they're like, oh, maybe that's cool, maybe I want to try that, how did you do that, right.

And so, yeah, sometimes it's not so easy just to kind of, you know, go dictate to people and say, look, like this is how you should do it, until they kind of come to the realization themselves. And so that was, you know, that's one method that might work, where it's just, at the very least, you could do it for yourself, it does take time, but even small wins are important, right. So I've been in situations where, I mean, especially in a startup, where it's like, okay, we need something in two weeks that we don't have anything, like nothing exists right now, but we need to deliver in two weeks, right. So it just ends up being, okay, just dive onto the keyboard, but even in those cases, wherever I can have kind of an engineering mindset and modularize what I can, I know that those pieces can be used either on other projects, or this project becomes much easier with future revisions.

Yeah, so just to add a bit there, so one of the selling points for us when we talk about data science, and about using tools like R, is about efficiency, right? The ability to produce reproducible code, or results, and efficiency. So even though we may think documentation and structure is boring, and it is, we know if it's not in place what the results are, right? So essentially, something that will take you two minutes, may take you an hour, right? And in terms of even communication, communication with members on your team, or even outside, when there is no commonality, you're talking about, in Jamaica, we call it Chinese telephone, where you're trying to get to someone, you can't get to them because the language is different. So, you know, what is so interesting about this conversation now, is that we're talking about infrastructure, we're talking about communication, and none of this is really about data analysis itself. But how important all the tenets are, all the connecting points around the data analysis itself is extremely important.

What is so interesting about this conversation now, is that we're talking about infrastructure, we're talking about communication, and none of this is really about data analysis itself. But how important all the tenets are, all the connecting points around the data analysis itself is extremely important.

Yeah, yeah. I mean, it's, again, it's like showing the art of the possible. And I think when they realize, you know, you do things in a smart way, then you can gain speed. They're more than happy to then support that, right? So, if a new request comes that's outside of the scope of the original request, they then have an understanding of what it took to make that original one, and then they'll want it again. Because it's, again, it's like building knowledge, and it's a building scale, right? You're not going to get everything in one go, but if you do things, you know, majority the right way the first time, over time, you're going to have a bolus of knowledge that you're enabling the remainder of the business, whether that's other groups, whether that's marketing, whatever, to be able to do what they do.