Live from New York, it's theCUBE. Covering Big Data New York City 2016. Brought to you by headline sponsors, Cisco, IBM, NVIDIA, and our ecosystem sponsors. Now here's your host, Dave Vellante. Welcome back to New York City everybody. This is theCUBE, the worldwide leader in live tech coverage, and this is theCUBE first. We've got a nine person, actually eight person panel of experts, data scientists, all alike. I'm here with my co-host, James Kobielus, who has helped organize this panel of experts. James, welcome. Thank you very much, Dave. It's great to be here. And we have some really excellent brain power up there. So I'm gonna let them talk. Okay, well thank you for- And I'll interject my thoughts now on them, but I wanna hear them. Okay, great. We know you well, Jim. We know you'll do that. So thank you for that. And appreciate you organizing this. Okay, so what I'm gonna do to our panelists is ask you to introduce yourself. I'll introduce you, but tell us a little bit about yourself and talk a little bit about what data science means to you. Number of you started in the field a long time ago, perhaps data warehouse experts before the term data science was coined. Some of you started probably after Hal Varian, said it was the sexiest job in the world. So think about how data science has changed and or what it means to you. We're gonna start with Greg Pioteski, who's from Boston, a PhD, KD Nuggets. Greg, tell us about yourself and what data science means to you. Thank you, Dave, and thank you, Jim, for the invitation. So data science, in a sense, is the second oldest profession. I think people have this built-in need to find patterns and whatever we find, we want to organize the data. But we do it well on a small scale, but we don't do it well on a large scale. So really data science takes our need and helps us to organize what we find, the patterns that we find are really valid and useful and not just random. I think this is a big challenge of data science. I've actually started in this field before the term data science existed. I started as a researcher and I organized the first few workshops on data mining and knowledge discovery. Then term data mining became less fashionable, became predictive analytics. Now it's data science and it will be something else in a few years. Okay, thank you, Eve's Malkers. Eve's, I, of course, know you from Twitter. A lot of people know you as well. Tell us about your experiences and what data scientist means to you. Well, data science to me is if you take the two words, the data and the science, it holds a lot of expertise and skills in there. It's statistics, it's mathematics, it's understanding the business and putting that together with the digitization of what we have. It's not only the structured data or the unstructured data, what you store in the database, try to get out and try to understand what is in there, but even video what is coming on and trying to find, like George already said, the patterns in there and bringing value to the business but looking from a technical perspective but still linking that to the business insights. I mean, you can do that on a technical level but then you don't know yet what you need to find or what you're looking for. Okay, great, thank you. Craig Brown, Cube alum. How many people have been on the Cube, actually, before? I have. Okay, good, he's like to ask that question. So Craig, tell us a little bit about your background and data science, how has it changed? What's it all mean to you? Sure, so I'm Craig Brown. I've been in IT for almost 28 years and that was obviously before the term data science but I've evolved from the, I started out as a developer and evolved through the data ranks, as I call it, working with data structures, working with data systems, data technologies and now we're working with data pure and simple. Data science to me is an individual or a team of individuals that dissect the data, understand the data, help folks look at the data differently than just the information that we usually use on reports and get more insights on how to utilize it and better leverage it as an asset within an organization. Great, thank you Craig. Okay, Jennifer Shin, math is obviously part of being a data scientist. You're good at math, I understand. Tell us about yourself. Yeah, so I'm a senior principal data scientist at the Nielsen company. I'm also the founder of APATH Solutions which is a data science, analytics and technology company and I'm also on the faculty in the master of information and data science program at UC Berkeley. So math is part of that, I teach statistics for data science actually this semester and I think for me, I consider myself a scientist primarily and data science is a nice day job to have, right? It's something where there's industry need for people with my skillset in the sciences and data gives us a great way of being able to communicate sort of what we know in science in a way that can be used out there in the real world. So I think the best benefit for me is that now that I'm a data scientist, people know what my job is whereas before maybe five, 10 years ago no one understood what I did. Now people don't necessarily understand what I do now but at least they understand kind of what I do so that's still an improvement. Excellent, thank you Jennifer. Joe Caserta, you're somebody who started in the data warehouse business and saw that snake swallow a basketball and grow into what we now know is big data. So tell us about yourself. So yeah, so I've been doing data for 30 years now and I wrote the data warehouse CTL toolkit with Ralph Kimball which is the best selling book in the industry on preparing data for analytics and with the big paradigm shift that's happened for me the past seven years has been instead of preparing data for people to analyze data to make decisions now we're preparing data for machines to make the decisions and I think that's the big shift from data analysis to data analytics and data science. Great, thank you. Miriam, Miriam Friedel, welcome. Thank you. I'm Miriam Friedel, I work for elder research, we are a data science consultancy and I came to data science sort of through a very circuitous route. I started off as a physicist, went to work as a consultant software engineer then became a research analyst and finally came to data science and I think one of the most interesting things to me about data science is that it's not simply about building an interesting model and doing some interesting mathematics or maybe wrangling the data all of which I love to do but it's really the entire analytics life cycle and the value that you can actually extract from data at the end and that's one of the things that I enjoy most is seeing a client's eyes light up or wow I didn't really know we could look at data that way that's really interesting I can actually do something with that. So I think that to me is one of the most interesting things about it. Thank you. Justin Sadeen, welcome. That's correct, yeah absolutely thank you, thank you. So my name is Justin Sadeen. I work for more FDU, an artificial intelligence company in Atlanta, Georgia and we develop learning platforms for non-profit and private educational institutions. Some Marine Corps veteran turned data enthusiast and so what I think about data science is the intersection of information, intelligence and analysis. I'm really excited about the transition from big data into smart data and that's what I see data science as. Great and last but not least, Des Blanchfield, welcome mate. G'day, yeah I'm the one with the funny accent. So data science for me is probably the funniest job I've ever tried to describe to my mom. I've had quite a few different jobs and she's never understood any of them and this one she understands the least. I think a fun way to describe what we're trying to do in the world of data science and analytics now is it's the equivalent of high altitude mountain climbing. It's like the extreme sport version of the computer science world because we have to be this magical unicorn of a human that can understand plain English problems from C-suite down and then translate it into code either as souls or to teams of developers. And so this is black art that we're expected to be able to transmogrify from something that we just in plain English say I would like to know X and we have to go away and figure it out. So there's this neat extreme sport view I have of rushing down the side of a mountain on a mountain bike and just dodging rocks and trees and things occasionally because invariably we do have things that go wrong and they don't quite give us the answers we want. But I think that we're at an interesting point in time now with the explosion and the types of technologies that are out of fingertips and the scale at which we can do things now. Once upon a time we would sit at a terminal and write code and just look at data and watch it in columns and then we ended up with spreadsheet technologies that are fingertips. Nowadays it's quite normal to instantiate a small high performance distributed cluster of computers effectively a supercomputer in a public cloud and throw some data at it and see what comes back. And we can do that on a credit card. So I think we're at a really interesting tipping point now where this this coinage of data science needs to be slightly better defined so we can help organizations who have weird and strange questions that they want to ask tailor solutions to those questions and deliver on them in a I guess a commodity deliverable. I want to know XYZ and I want to know it in this timeframe I want to spend this much amount of money to do it and I don't really care how you're going to do it. And there's so many tools we can choose from and there's so many platforms we can choose from. It's this little black art of computing if you like we're effective making it up as we go in many ways. So I think it's one of the most exciting challenges that I've had and I think I'm pretty sure I speak for most of us and that we're lucky that we get paid to do this amazing job. That we get to make up on a daily basis in some cases. Excellent well okay so we get to get right into it.  Do they have unicorns down under? I think they have some strange species right? Well we put the pointy bit on the back. Hang on yeah you guys have it on the front. So I was at an IBM event on Friday it was a chief data officer summit and I attended what was called the data divas breakfast. It was a women in tech thing. And one of the CDO's she said that 25% of chief data officers are women which is much higher than you would normally see in the profile of IT. We happen to have 25% of our panellists are women. Is that common for data some, Miriam and Jennifer is that common for the data science field or is this a higher percentage than you would normally see in the small? Or a lower percentage. I think certainly for us we have hired a number of additional women in the last year and they are phenomenal data scientists. I don't know that I would say, I mean I think it's certainly typical that this is still a male dominated field but I think like many male dominated fields you know physics, mathematics, computer science I think that that is slowly changing and evolving and I think certainly that's something that we've noticed in our firm over the years and our consultancies we're hiring new people. So I don't know if I would say 25% is the right number but certainly we can hopefully we can get it closer to 50. Jennifer I don't know if you have. Yeah so I know at Nielsen we have actually more than 45% of our team is women at least the team that I work with. So there seems to be a lot of women who are going to the field which isn't too surprising because a lot of the you know with a lot of the issues that come up in STEM one of the reasons why a lot of women drop out is because they want real world jobs and they feel like they want to be in the workforce. And so I think this is a great opportunity with data science being so popular for these women to actually have a job where they can still maintain that engineering and scientific background that they learn in school. Great. Well Hilary Mason I think was the first data scientist I ever interviewed and I asked her what are the sort of skills required and the first question that we wanted to ask and I just threw that other women in tech in there because we love women in tech is about this notion of the unicorn data scientist right?  And I love Des's extreme sports analogy because that plays into the whole notion of data science. We like to talk about the theme now data sciences of team sport. Must it be an extreme sport is what I'm wondering. The unicorns of the world seem to be is that realistic now in this new era? Yes I mean when automobiles first came out they were concerned that there wouldn't be enough chauffeurs to drive all the people around. Is there an analogy with data to be a data driven company do I need a data scientist and does that data scientist need to have these unbelievable mixture of skills or are we doomed to always have a skill shortage? I'd like to have a crack at that. So it's interesting when automobiles were a thing when they first bought cars out and before they sort of were modernized by the likes of Ford's Model T and we got away from the horse and carriage they actually had human beings walking down the street with a flag warning the public that the carriage the horseless carriage was coming. And I think data scientists are very much like that that we're kind of expected to go ahead of the organization and try and take the challenges we're faced with today and see what's gonna come around the corner. And so we're like the little flag bearers if you like in many ways of this is where we're at today. Tell me where I'm gonna be tomorrow and try and predict the day after as well. It is very much becoming a team sport though but I think the concept of data science being a unicorn has come about because the coinage hasn't been very well defined. If you were to ask 10 people what a data scientist were you'd get 11 answers. And I think this is a really challenging issue for hiring managers and C-sweets when they turn around and say I want data science I want big data I want an analyst. They don't actually really know what they're asking for. Generally if you ask for a database administrator it's a well-described job spec and you can just advertise it and some 20 people will turn up and you interview them decide whether you like the look and feel and smell of them. When you ask for a data scientist there's 20 different definitions of what that one data science role could be. So we don't necessarily know what the job is we don't know what the deliverable is and we're still trying to figure that out so yeah. Craig Wayne. So from my experience when we talk about data science we're really talking about a collection of experiences with multiple people I've yet to find and at least from my experience a data science effort with a lone wolf. So you're talking about a combination of skills and so you don't have no one individual needs to have all that makes a data scientist a data scientist but you definitely have to have the right combination of skills amongst the team in order to accomplish the goals of data science team. So from my experiences and from the clients that I've worked with we refer to the data science effort as a data science team and I believe that's very appropriate to the team you know the team sport analogy. Yeah for us we look at a data scientist as a full stack web developer a jack of all trades. I mean they need to have a multitude of background coming from a programmer from an analyst. You can't find one subject matter expert because it's very difficult and if you're able to find a subject matter expert you know through the life cycle of product development you're going to require that individual to interact with a number of other members from your team who are analysts and then you just end up well training this person to be again a jack of all trades so it comes full circle. So I own a business that does nothing but data solutions and we've been in business 15 years and it's been the transition over time has been going from like being a conventional wisdom run company with a bunch of experts at the top to becoming more of a data driven company using data warehousing and BI but now you know the trend is absolutely analytics driven. So if you're not becoming an analytics driven company you're going to be behind the curve very very soon and it's interesting that IBM is now quitting the phrase of a cognitive business. I think that is absolutely the future if you're not a cognitive business from a technology perspective and analytics driven perspective you're going to be left behind for sure. So in order to stay competitive you know you need to really think about data science think about how you're using your data and they also see that you know what's considered a data expert has evolved over time too where it used to be just someone really good at writing SQL or someone really good at writing queries in any language but now it's becoming more of a interdisciplinary action where you need soft skills and you also need the hard skills and that's why I think you know there's more females in the industry now than ever because you really need to have a really broad width of experiences that really wasn't required in the past. Great Pioteski you have a comment? So there are not too many unicorns in nature or as data scientists so I think organizations that want to hire data scientists have to look for teams and there are a few unicorns like Hillary Mason or maybe Osama Fayad but they generally tend to start companies and very hard to retain them as data scientists. What I see is in other evolution automation and you know steps like IBM Watson data first platform is potentially a great advance for data scientists in the short term but probably what's likely to happen the longer term kind of more and more of those skills becoming subsumed by machine learning layer within the software. How long will it take? I don't know but I have a feeling that the paradise for data scientists may not be very long lived. Greg I have a follow up question to what I just heard you say when a data scientist let's say a unicorn data scientist starts a company as you phrased it and the company's product is built on data science do they give up becoming a data scientist in the process? It would seem that they become a data scientist of a higher order if they've built a product based on that knowledge. What is your thoughts on that? Well I know a few people like that so I think maybe they remain data scientists at heart but they don't really have the time to do the analysis and they really have to focus more on strategic thing. For example today actually is the birthday of Google 18 years ago. So Larry Page and Sergey Brin wrote a very influential paper back in the 90s about PageRant. Have they remained data scientists perhaps in a very very small part but that's not really what they do. So I think this unicorn data scientist quickly evolve so you have to look for really teams to capture those skills. Clearly they come to a point in their career where they build a company based on teams of data scientists and data engineers and so forth which relates to the topic of team data science. What is the right division of roles and responsibilities for team data science? Before we go to you, Jennifer, did you have a comment on that? Yeah so I guess I would say for me when data science came out and there was the Venn diagram that came out about all the skills it was supposed to have I took a very different approach than all of the people who I knew who were going to data science. Most people started interviewing immediately. They were like this is great, I'm going to get a job. I went and learned how to develop applications and learned computer science because I'd never taken a computer science course in college. I made sure I chewed up that one part where I didn't know these things or I had the skills from school so I went and just went head first and learned it and now I have actually a lot of technology patents as a result of that. So to answer Jim's question actually, so I started my company about five years ago and originally started out as a consulting firm slash data science company. Then it evolved and one of the reasons I went back into industry and now I'm at Nielsen is because you really can't do the same sort of data science work when you're actually doing product development. It's a very, very different sort of world. When you're developing a product, you're developing a core feature or functionality that you're going to offer clients and customers. So I think definitely you really don't get to have that wide range of sort of looking at eight million models and trying, testing things out. That flexibility really isn't there as your product starts getting developed. Before we go into the team sport, the hard skills that you have, are you all good at math? Are you all computer science types? How about math? You all math? What were your GPAs? Anybody not math or anything? Anybody not love math? You don't love math? I love math, I think it's a requirement. Okay, so math, yes. You dream in equations, right? You dream. Computer science, do I have to have computer science skills, at least the basic knowledge? I don't know that you need to have formal classes in any of these things, but I think certainly, as Jennifer was saying, if you have no skills in programming whatsoever and you have no interest in learning how to write SQL queries or R or Python, you're probably gonna struggle a little bit. That would be a challenge. So I think, yes, I have a PhD in physics, I did a lot of math, that's my love language, but I think if you don't necessarily need to have formal training in all of these things, but I think you need to have a curiosity and a love of learning, and so if you don't have that, you still wanna learn and you wanna, however you gain that knowledge, I think, but yeah, if you have no technical interest whatsoever and don't wanna write a line of code, maybe data science is not the field for you, even if you don't do it every day. And statistics as well, you would put that in that same general category. How about data hacking? That's right. You gotta love data hacking, is that fair or eaves? Do you have a comment? Yeah, I think so, well, we've been discussing, for me, the most important part is that you have a logical mind and you have the capability to absorb new things and the curiosity that you need to dive into that. Well, I don't have an education in IT, whatever, I have a background in chemistry and those things that I learned there, I apply to information technology as well. And from a part that you say, okay, I'm a tech savvy guy, I'm interested in the tech part of it, you need to speak that business language and if you can do that crossover and understand what other skill sets or parts of the roles are telling you, I think the communication in that aspect is very important. I'd like to throw just something really quickly and I think there's an interesting thing that happens in IT, particularly around technology. We tend to forget that we've actually solved a lot of these problems in the past. If we look in history, if we look around the Second World War and Bletchley Park in the UK, we had a very similar experience as humans that we're having currently around the whole issue of data science. So there was an interesting challenge with the enigma and the shark code, right?  And so what they ended up doing was running these ads and putting challenges. They actually put, I think it was crossword puzzles in the newspaper and this deluge of women came out of all kinds of different roles without math degrees, without science degrees, but could solve problems. And they were thrown at the challenge of cracking codes and invariably they did the heavy lifting on a daily basis for converting messages from one format to another so that this very small team at the very end could actually get and play with the sexy piece of it. And I think we're going through a similar shift now with what we refer to as data science in the technology world and business world where the people who are doing the heavy lifting aren't necessarily what we would think of as a traditional data scientist. And so there have been some unicorns and we've championed them and they're great. But I think the shift's going to be to accountants and actuaries and statisticians who understand the business and come from an MBA style background that can learn the relevant pieces of math and models that we need to apply to get the data science outcome. I think we've already been here, we've solved this problem, we just got to learn not to try and reinvent the wheel because the media hypes this whole thing of data science is deciding anew, but we've been here a couple of times before and there's a lot to be learned from that, my view. I think we had Joe next. So I was going to say that data science is a funny thing. To use the word science is kind of misnomer because there is definitely a level R to it. And I like to use the analogy when Michelangelo would look at a block of marble, everyone else looks at the block of marble, they say a block of marble. He looks at a block of marble and he sees a finished sculpture. And then he figures out what tools do I need to actually make my vision? And I think data science is a lot like that. We hear a problem, we see the solution, then we just need the right tools to do it. And I think part of consulting in data science in particular, it's not so much what we know out of the gate, but it's how quickly we learn. And I think everyone here, what makes them brilliant is that how quickly they could learn any tool that they need to see their vision get accomplished. Justin? Yeah, I think you make a really great point. For me, I'm a Marine Corps veteran and the reason I mention that is because I work with two veterans who are problem solvers and I think that's what data scientists really are in the long run are problem solvers. And you mentioned a great point that, yeah, I think just problem solving is the key. You don't have to be a subject matter expert, just be able to take the tools and intelligently use them. Now, when you look at the whole notion of team data science, what is the right mix of roles, like role definitions within a high quality or a high performing data science teams? Now, IBM with, of course, our announcement of project data works and so forth, we're splitting the role division in terms of data scientists versus data engineers versus application developers versus business analysts. Is that the right breakdown of roles or what would the panelists recommend in terms of understanding what kind of roles make sense within, like I say, a high performing team that's looking for trying to develop applications that depend on data and machine learning and so forth. Anybody want to contribute? Yes, I'll tackle that. So the teams that I've created over the years that made up these data science teams that I brought into customer sites have a combination of developer capabilities and some of them are IT developers but some of them were developers of things other than applications. They designed buildings, they did other things with their technical expertise besides building technology. The other piece besides the developer is the analytics and analytics can be taught as long as they understand what, you know, how algorithms work and the code behind the analytics, in other words, how are we analyzing things and from a data science perspective, we are leveraging technology to do the analyzing through the tool sets. So ultimately, as long as they understand how tool sets work and we can train them on the tools, having that analytic background is an important piece. Craig, is it easier to, I'll go to you in a moment, Joe, is it easier to cross train a data scientist to be an app developer than to cross train an app developer to be a data scientist or does it not matter? Yes. And not the other way around. It depends on the time frame. It's easier to cross train a data scientist to be an app developer than the other way around. Why is that? Developing code can be as difficult as the tool set one uses to develop code. Today's tool sets are very user-friendly with developing code. It's very difficult to teach a person to think along the lines of developing code when they don't have any idea of, you know, the aspects of building something. I think Joe, are you next or Jennifer? Who is it? So I would say that one of the reasons for that is that data scientists will probably know if the answer's right after you process data or data engineer might be able to manipulate the data but may not know if the answer's correct, right? So I think that is one of the reasons why having data scientists learn the application development skills might be an easier time than the other way around. I think Miriam, have I counted? I mean, sorry, go ahead, Joe. Yeah, sorry. I think that what we're advising our clients to do is to not think, you know, before data science and before analytics became, you know, so required by companies to stay competitive, it was more of a waterfall. You have a data engineer build a solution, you know, then you throw it over the fence and the business analysts would have at it. Where now it must be agile and you must have a scrum team where you have the data scientists and the data engineer and the project manager and the product owner and someone from the data chief data office all at the table at the same time and all accomplishing the same goal because all of these skills are required collectively in order to solve this problem and it can't be done daisy-chained anymore. It has to be a collaboration and that's why I think Spark is so awesome because, you know, Spark is, you know, a single interface that a data engineer can use, a data analyst can use and a data scientist can use and now with what we've learned today, having a data catalog on top so that the chief data office can actually manage it, I think is really going to take Spark to the next level. To Miriam. I wanted to comment on your question to Craig about, is it harder to teach, you know, a data scientist to build an application or vice versa? And one of the things that we have worked on a lot in our data science team is incorporating a lot of best practices from software development, you know, agile, scrum, that sort of thing. And I think particularly with a focus on deploying models, so we don't just want to build an interesting data science model, we want to deploy it and get some value, you need to really incorporate these processes from someone who might know how to build applications. And I think for some data scientists can be a challenge because one of the fun things about data science is you get to get into the data and you get your hands dirty and you build a model and you get to try all these cool things. But then when the time comes for you to actually deploy something, you need deployment grade code in order to make sure it can go into production at your client site and be useful, for instance. So I think that there's an interesting challenge on both ends, but one of the things that I've definitely noticed with some of our data scientists is it's very hard to get them to think in that mindset, which is why you have a team of people because everyone has different skills and you can mitigate that. Dev Ops for data science. Yeah, exactly. Dev Ops for what we call it insight ops, but yeah, I hear what you're saying. Data science is becoming increasingly an operational function as opposed to strictly exploratory or developmental. I think someone else had a cut, does. One of the things I was going to mention, one of the things I like to do when someone gives me a new problem is take all the laptops and phones away and we just end up in a room with a whiteboard. And developers find that challenging sometimes. And so I have this one line where I said to them, don't write the first line of code until you actually understand the problem you're trying to solve, right? And I think where the data science focus has changed the game for organizations who are trying to get some systematic, repeatable process so they can throw data out and just keep getting answers on things no matter what the industry might be, is that developers will come with a particular mindset on how they're going to codify something without necessarily getting the full spectrum and understanding the problem in the first place. What I'm finding is that people that come out data science tend to have more of a hacker ethic, they want to hack the problem, they want to stand the challenge and they want to be able to get it down to plain English simple phrases and then apply some algorithms and then build models and then codify it. And so most of the time we sit in a room with whiteboard markers just trying to build a model in a graphical sense and make sure it's going to work and then it's going to flow. Once we can do that, we can codify it. I think when you come up from the other angle from the developer ethic and you're like, I'm just going to codify this from day one, I'm going to write code, I'm going to hack this thing out and it's just going to run and compile. Often you don't truly understand what you're trying to get to at the end point and you can just spend days writing code and I think someone made a comment that sometimes you don't actually know whether the output is actually accurate in the first place. So I think there's a lot of value being provided from the data science practice of understanding the problem of plain English at a team level. So what am I trying to do from the business consulting point of view? What are the requirements? How do I build this model? How do I test the model? How do I run a sample set through it, train the thing and then make sure what I'm going to codify actually makes sense in the first place? Because otherwise, what are you trying to solve in the first place? Wasn't that Einstein who said if I had an hour to solve a problem I'd spend 55 minutes on understanding the problem and five minutes on the solution, right? That's exactly what you're talking about. Well, I think, I will say, getting back to the question, the thing with building these teams, I think a lot of times people don't talk about it is that engineers are actually very, very important for data science projects, data science problems. For instance, if we're just trying to prototype something or just come up with a model, then data science teams are great. However, if we need to actually put that into production, that code that the data scientist has written may not be optimized, right? It might not be optimal. So as we scale out, it may be actually very inefficient. At that point, you kind of want to engineer to step in and actually optimize that code. So I think it depends on what you're building and that kind of dictates like what kind of division you want among your teammates. But I do think that a lot of times the engineering component is really undervalued out there. Jennifer, it seems that the data engineering function data discovery and preparations over there is becoming automated to a greater degree. But if I'm listening to you, I don't hear that data engineering as a discipline is becoming extinct in terms of a role that people can be hired into. You're saying that there's a strong, ongoing need for data engineers to optimize the entire pipeline to deliver the models, the fruits of data science, production applications, is that correct? So they play that very much operational role as the backbone for... Right, so I think a lot of times businesses will go to a data scientist to build a better model, maybe build a predictive model. But that model may not be something that you really want to implement out there when there's like a million users coming to your website because it may not be efficient, it may take a very long time. So I think in that sense, it is important to have good engineers and your whole product may fail. You may build the best model, it may have the best output, but if you can't actually implement it, then really what good is it? What are you calibrating these models? How do you go about doing that and testing that in the real world? Has that changed over time or is it? So one of the things I think that can happen and we found with one of our clients when you build a model, you do it with the data that you have and you try to use a very robust cross-validation process to make sure that it's robust and it's sturdy. But one thing that can sometimes happen is after you put your model into production, there can be external factors that societal or whatever are things that have nothing to do with the data that you have or the quality of the data or the quality of the model, which can actually erode the model's performance over time. So as an example, we think about cell phone contracts. Those have changed a lot over the years. So maybe five years ago, the type of data plan you had might not be the same that it is today because a totally different type of plan is offered. So if you're building a model on that to say, predict who's gonna leave and go to a different cell phone carrier, the validity of your model over time is gonna completely degrade based on nothing that you put into the model or the data that was available. So I think you need to have this sort of model management and monitoring process to take these factors into account and then know when it's time to do a refresh. Cross-validation, even at one point in time, for example, there was an article in the New York Times recently that they gave the same data set to five different data scientists. This is survey data for the presidential election that's upcoming. And five different data scientists came to five different predictions. They were all high-quality data scientists. The cross-validation showed a wide variation about who is on top, whether it was Hillary or whether it was Trump. So that shows that even at any point in time, cross-validation is essential to understand how robust the predictions might be. Does someone else have a comment, Joe? I just want to say that this even drives home the fact that having the scrum team for each project and having the engineer and the data scientists, data engineer and data scientists working side by side, because it is important that whatever we're building, we assume we'll eventually go into production. And we used to have in the data warehousing world, we would have, you get the data out of the system, so out of your applications, you do analysis on your data and the nirvana was maybe that data would go back to the system, but typically it didn't. Nowadays, the data, the applications are dependent on the insight coming from the data science team. The way the behavior of the application and the personalization and individual experience for a customer is highly dependent. So it has to be, you said, is data science part of the DevOps team? Absolutely now, it has to be. Whose job is it to figure out the way in which the data is presented to the business? Where's the sort of presentation, the visualization plane? Is that the data scientist role? Is that dependent on whether or not you have that gene? Do you need a UI person on your team? Where does that fit? Good question. Well, usually that's the output. I mean, once you get to the point where you're visualizing the data you've created an algorithm or some sort of code that produces that is to be visualized. So at the end of the day, the customers can see what all the fuss is about from a data science perspective, but it's usually post the data science component. So do you run into situations where you can see it and it's blatantly obvious, but that doesn't necessarily translate to the business? True. How do you deal with that? There's an interesting challenge with data. I mean, we throw the, we bandied the word data around a lot. And I've got this fun line, I like throwing out them. If you torture data long enough, it will talk. So the challenge then is to figure out when to stop torturing it, right? And it's the same with models. And so I think in many other parts of organizations we'll take something. So if someone's doing a financial report on performance of the organization and they're doing a spreadsheet, they'll get two or three peers to review it and validate that they've come up with a working model and then the answer actually makes sense. And I think we're rushing so quickly at doing analysis on data that comes in various formats at high velocity that I think it's really important for us to actually stop and do peer reviews of the models and the data and the output as well. Because otherwise we start making decisions very quickly about things that may or may not be true. It's very easy to get the data to paint any picture you want. And you gave the example of the five different attempts at that thing. And I had this shootout thing as well. We're all taking a team. I'll get two different people to do exactly the same thing in completely different rooms and come back and challenge each other. And it's quite amazing to see the looks in their faces and they're like, oh, I didn't see that. And then go back and do it again until, and just keep iterating until we get the point where they both get the same outcome. There's a really interesting anecdote about when the Unix operating system was being written and a couple of the authors went away and wrote the same program without realizing each other were doing it. And when they came back, they actually had line for line the same piece of C code. Because they'd actually gotten to a truth, a perfect version of that program. And I think we need to often look at when we're building models and we're playing with data, if we can't come at it from different angles and get the same answer, then maybe the answer isn't quite true yet. So there's a lot of risk in that. And it's the same with presentation. You can paint any picture you want with the dashboard, but who's actually validating with the dashboard that's painting the correct picture? So, go ahead, please. I'm sorry if I could. So there is a science actually behind data visualization. You know, if you're doing trending, it's a line graph. If you're doing comparative analysis, it's a bar graph. You're doing percentage, it's a pie chart. Like there is a certain science to it. It's not that much of a mystery as, you know, the novice thinks there is.  And your audience, whenever we're delivering a solution, either insight or just data in a grid, we really have to consider who is the consumer of this data and actually cater the visual to that person or to that particular audience. And that is part of the art and that is what makes a great data scientist. The consumer may in fact be the source of the data itself like in a mobile app. So you're tuning their visualization and then their behavior is changing as a result. And then the data on their change behavior comes back. So it can be a circular process. Sure. So Jim, at a recent conference you were tweeting about the citizen data scientist and you got emasculated by some of it. I spoke there too. Okay. TWI on that same topic. Kirk Born, I hear, came after you. Oh, the Kirk Ment. Called foul flag in the play. Kirk Ment, well. So, no, great. I love Claudia Emhoff too. But yeah, it's a controversial topic. So I wonder what our panel thinks of that notion of a citizen data scientist. Can I respond about citizen data scientists? Yeah, please. I think this term was introduced by Gardner analyst in 2015. And I think it's a very dangerous and misleading term. I think definitely we want to democratize the data and have access to more people, not just data scientists but managers, BI analysts. But when there is already a term for such people, we can call them business analysts because that implies some training, some understanding of the data. If you use a term citizen data scientist, it implies that without any training, you take some data and then you find something there. And I think as Des mentioned that we've seen many examples, very easy to find completely spurious random correlations in data. So we don't want citizen dentists to treat our teeth or citizen pilots to fly the planes. And if data is important, having citizen data scientist is equally dangerous. So I'm hoping that, I think actually Gardner did not use the term citizen data scientist in their 2016 hype course. So hopefully they will put this term to rest. So Gregory, you apparently are defining citizen to mean incompetent as opposed to simply self-starting. Self-starting is very different, but that's not, I think, what was the intention. I think what we see in terms of data democratization, there is a big trend toward automation. There are many tools, for example, there are many companies like data robot, probably IBM has interesting machine learning capability towards automation. So I think I've recently started a page on KDNuggets for automated data science solutions. And there are already 20 different firms that provide different levels of automation. So one can believe either in full automation, maybe some expertise, but it's very dangerous to have part of automated tool. And at some point, then ask citizen data scientist to try to take the wheels. I want to quickly chime in on that. I want to quickly chime in on that. Yeah, pie along. I totally agree with all of that. I think the comment I just want to quickly put out there is that the space we're in is a very young and rapidly changing world. And so what we haven't had yet is this time to stop and take a deep breath and actually define ourselves. So if you look at computer science in general, a lot of the traditional roles have sort of had 10 or 20 years of history. And so through the hiring process and the development of those spaces, we've actually had time to breathe and define what those jobs are. So we know what a systems programmer is and we know what a database administrator is, but we haven't yet had a chance as a community to stop and breathe and say, well, what do we think these roles are? And so to fill that void, the media creates coinages. And I think this is the risk we've got now that the concept of data scientist was just a term that was coined to fill a void because no one quite knew what to call somebody who didn't come from a data science background if they were tinkering around in data science. And I think that's something that we need we need to sort of sit up and pay attention to because if we don't own that and drive it ourselves and somebody else is going to fill a void and they'll create these very frustrating concepts like data scientist, which drives us all crazy. Miriam's next. So I wanted to comment. I agree with both of the previous comments but in terms of a citizen data scientist. And I think whether or not you're a citizen data scientist or an actual data scientist, whatever that means, I think one of the most important things you can have is a sense of skepticism, right? Because you can get spurious correlations and it's like, wow, my predictive model is so excellent and being aware of things like leaks from the future. This actually isn't predictive at all. It's a result of the thing I'm trying to predict. And so I think one thing I know that we try and do is if something really looks too good, we need to go back in and make sure. Did we not look at the data correctly? Is something missing? Did we have a problem with the ETL? And so I think that a healthy sense of skepticism is important to make sure that you're not taking a spurious correlation and trying to derive some significant meaning from it. I think there's a Dilbert cartoon that I saw that described that very well. Joe, did you have a comment? I think that in order for citizen data scientists to really exist, I think we do need to have more maturity in the tools that they would use. My vision is that the BI tools of today are all going to be replaced with natural language processing and searching, just be able to open up a search bar and say, give me sales by region. And to take that one step into the future even further, it should actually say, what are my sales going to be next year? And it should trigger a simple linear regression. Or be able to say, which features of the televisions are actually affecting sales and do a clustering algorithm. I think hopefully that will be the future, but I don't see anything of that today. And I think in order to have a true citizen data scientist, you would need to have that. And that is pretty sophisticated stuff. So I think for me, the idea of citizen data scientists, I can relate to that. For instance, when I was in graduate school, I started doing some research on FDA data. It was an open source data set, about 4.2 million data points. Technically, when I graduated, the paper was still not published. And so in some sense, you could think of me as a citizen data scientist. I wasn't getting funding. I wasn't doing it for school. I was still continuing my research. So I'd like to hope that with all the new data sources out there, that there might be scientists or people who are maybe kept out of a field, people who wanted to be in STEM and for whatever life circumstances couldn't be in it, that they might be encouraged to actually go and look into the data and maybe build better models or validate information that's out there. Justin, I'm sorry, you have one comment. It seems data science was termed before academia adopted. Formalized training for data science. But yeah, you can make, like I said, you can make data work for whatever problem you're trying to solve, whatever answer you see. You want data to work around it, you can make it happen. And I kind of consider that in project management, data creep. So you're so hyper-focused on the solution. You're trying to find the answer that you create an answer that works for that solution, but it may not be the correct answer. And I think a crossover discussion works well for that case. So, but the term comes up because there's a frustration, I guess, that data science skills are not plentiful and it's potentially a bottleneck in an organization. Suppose the 80% of your time is spent on cleaning data and is that right? Is that fair? So there's a problem. How much of that can be automated and when? So I think there's a shift that's going to come about where we're going to move from centralized data sets to data at the edge of the network. And this is something that's happening very quickly now where we can't just haul everything back to a central spot when the internet of things actually wakes up. Things like the Boeing Dreamliner 787, that thing's got 6,000 sensors and it produces half a terabyte of data per flight. There are 87,400 flights per day in domestic airspace in the US. That's 43.5 petabytes of raw data. That's about three years of the disk manufacturing in total, right? We're never going to copy that across to one place. We can't process it one good. So I think the challenge we've got ahead of us is looking at how we're going to move the intelligence and the analytics to the edge of the network and precook the data in different tiers. So have a look at the raw material we get and boil it down to a slightly smaller data set, bring a metadata version of that back, and eventually get the point where we've only got the very minimum data set and data points we need to make key decisions. Without that, we're already at the point where we have too much data and we can't munch it fast enough and we can't spin up enough tin even if we switch the cloud on. And that's just this never ending deluge of noise, right? And you've got that signal versus noise problem. So I think we're now seeing a shift where people are looking at, how do we move the intelligence back to the edge of the network? Which we actually solved some time ago in the security space, you know, spam filtering. If an email hits Google on the West Coast of the US and they create a checksum for that spam email, it immediately goes into a database and nothing gets on the opposite side of the coast because they already know it's spam. They recognize an email coming in and that's evil, stop it. So we've already fixed it in security with intrusion detection, we fixed it in spam. So we now need to take that learning and bring it into business analytics if you like and see where we're finding patterns and behavior and prove that out to the edge of the network. So if I'm seeing a demand over here for tickets on a new sale of a show, I need to be able to see where else I'm going to see that demand and start responding to that before the demand comes about. I think that's a shift we're going to see quickly because we will never keep up with the data munging challenge and the volume's just going to explode. We have a couple minutes. That sounds like a great topic for a future CUBE panel which is the data science on the edge of the fog. I got a hundred questions around that. So we're wrapping up here, just got a couple of minutes. Final thoughts on this conversation or any other pieces that you want to punctuate? I think one thing that's been really interesting for me being on this panel is hearing all of my co-panelists talk about common themes and things that we are also experiencing which isn't a surprise but it's interesting to hear about how ubiquitous some of the challenges are and also at the announcement earlier today some of the things that they're talking about and thinking about, we're also talking about and thinking about. So I think it's great to hear we're all in different countries and different places but we're experiencing a lot of the same challenges and I think that's been really interesting for me to hear about. Anybody else final thoughts? To echo Des's thoughts. It's about, we're never going to catch up with the amount of data that's produced. So it's about transforming big data into smart data. I could just say that with the shift from normal data, small data to big data, the answer is automate, automate, automate. And we've been talking about advanced algorithms and machine learning for the science for changing the business but there also needs to be machine learning and advanced algorithms for the back room where we're actually getting smarter about how we ingest data and how we fix data as it comes in because we can actually train the machines to understand data anomalies and what we want to do with them over time. And I think the further upstream we get of data correction, the less work that will be downstream. And I also think that the concept of being able to fix data at the source is gone. That's behind us. Right now the data that we're using to analyze, to change the business, typically we have no control over. Like this, they're coming from sensors and machines and internet of things and if it's wrong, it's always going to be wrong. So we have to figure out how to do that in our laboratory, right? Yves, final thoughts? Yeah, I think it's a mind shift in being a data scientist. If you look back at the time, why did you start developing or writing code because you like to code whatever just for the sake of building a nice algorithm or a piece of software or whatever. And now I think with the spirit of a data scientist, you're looking at a problem and say, this is where I want to go. So you have more the top down approach than the bottom up approach and have the big picture. And that is what you really need as a data scientist, just look across technologies, look across departments, look across everything. And then on top of that, try to apply as much as skills that you have available. And that's that kind of unicorn that they're trying to look for because it's pretty hard to find people with that wide vision on everything that is happening within the company. So you need to be aware of technology. You need to be aware of how a business is run and how it fits within in a cultural environment. You have to work with people and all those things together, to my belief, make it very difficult to find those good data scientists. Jim, your final thought? My final thoughts is this is an awesome panel and I'm so glad that you've come to New York and I'm hoping that you will all stay, of course, for the IBM Data First launch event that will take place this evening about a block over at Hudson Mercantile. So that's pretty much it, thank you. I really learned a lot. I want to second Jim's thanks. Really great panel, awesome expertise. Really appreciate you taking the time and thanks to the folks at IBM for putting this together. And I'm big fans of most of you, all of you on the session here. So it's great just to meet you in person, thank you. Okay, and I want to thank Jeff Frick for being a human curtain there with the sun setting here in New York City. Well, thanks very much for watching. We are going to be across the street at the IBM announcement. We're going to be on the ground. We open up again tomorrow at 9.30 at Big Data NYC, Big Data Week, Strata plus the Duke World. Thanks for watching everybody. That's a wrap from here. This is theCUBE, we're out.


Welcome to the nonprofit show. We are so glad you're here for a Monday as we start off this week, extremely strong with Alex Lapa, extremely excited to have him. He is the CEO at Dryad Consulting, joining us on the nonprofit show today. He's here to talk to us about something that we often talk about, but he's gonna tell us how to use it right. So are you using tech or technology right? So Alex is here to talk to us about that. And before we jump deep into that technology conversation, we want to remind all of you, our loyal viewers and listeners who we are. So hello to Julia. Julia Patrick is here, CEO of the American Nonprofit Academy. I'm Jarrett Ransom, your nonprofit nerd, CEO of the Raven Group, honored to be alongside Julia each and every day for these nonprofit show episodes. We've been going strong now, coming up on four years, over 750 episodes. And we have to say thank you, thank you to thank you to our amazing presenting sponsors that allow us this platform and the opportunity to talk to the great minds like Alex today. So a shout out to our friends over at Bloomerang, American Nonprofit Academy, Fundraising Academy at National University, nonprofit thought leader, your part-time controller, staffing boutique, as well as the nonprofit nerd. Do yourself a favor, do us a favor, do all of our sponsors a favor, check them out. They're here for you. I really like to say their mission is your mission. So they're here to lean into your mission and help you do more good in, around and throughout your community. Hey, if you missed any of our episodes, that's okay. You can find us on Roku, YouTube, Amazon Fire TV, Vimeo, as well as podcasts. So go ahead and queue us up wherever you stream your entertainment in just a few hours after our conversation with our guests today, it will be live on many of these streaming, all of these streaming platforms. So without further ado, Alex, I wanna introduce you. Alexander goes by Alex. Lapa has joined us here today. Again, he is the CEO at Dryad Consulting. We are so glad to have you. So officially welcome. Thank you for having me. Yeah. Okay, Alex, we called you out on your beautiful, I would like to call it Northern accent. Where are you coming to us from today? Normally I'm in Montreal in Canada, but actually today I'm in Spain. So I'm a digital nomad where I spend half this time, half the year in Montreal, the summer season, and then winter seasons, which are really awful in Montreal, I head over to the south of Spain. Holy cow, you're like my dream person. What part of Southern Spain are you coming to us from? It's a small town near Malaga. So wonderful temperatures, 65 to 70 degrees in January and February. Wow, okay, now we're really gonna believe what you have to say because you're coming to us from this like totally amazing place. Well, talk to us about what Dryad Consulting does before we get into peppering you with more questions. Sure. So Dryad Consulting was formed about 20 years ago and we basically do Salesforce consulting. So Salesforce projects for nonprofits. Yeah, that's basically the core message and then we have a bunch of apps and other types of promotion items as well. Great, and you had shared with us, you have the app, you do a lot of Salesforce training and kind of forums, you have your own podcasts. So where do we find your podcasts? The podcast is called Agents of Nonprofit and I'm basically interviewing people in the nonprofit space, helping nonprofits using technology. Fantastic. Awesome, well, that's a huge thing and Jarrett and I have been talking about this and I can't wait to get to this conversation with you is that we feel like so much technology was kind of for nonprofits put on the back burner but then with the COVID pandemic it just really forced the nonprofit sector to embrace and move forward. I mean, in the beginning of the nonprofit show Jarrett, isn't this true? We spent a lot of time talking about how to get your staff on Zoom meetings and how to get on Zoom, I mean, hello. The very basics, even like connecting to technology from their home, computers, I mean, really the basics and here we are again, almost four years later. So a lot has changed. There was a very popular comic a few years ago just after COVID started that said, indicate which of the four following factors was the biggest driver toward technology? CEO, CTO and then COVID and all the answers were COVID. Really pushed the frontier forward in terms of technology. Yeah. I mean, I believe that and I've got to believe that you have spent a lot of time and talked to us about that before we go any further. Have you found yourself spending a lot of time just talking about the implementation of technology versus the actual technology? Almost like in a cultural sense? Yeah, the key for any technology is making sure it's the right tool for the job, making sure it's the right technology because you have so many choices out there. How do you know which is the right one for you, for your particular task? And that's like the first conversation to be had. And then it's narrowing down the categories of, okay, now we need this kind of software to do this. What are our choices? Where do we go for advice? And how do we filter it down to the what are two choices before making that final assessment? Amazing. Well, let's delve into that because one of the first points that you have that kind of amplifies that sensibility is understanding when to use technology and drama when not to use technology. What do you mean by that? So technology is a tool, right? And any other tool, you need to know when to use it and when not to use it. Just like when you have a hammer, you're supposed to hammer nails in, but you wouldn't want to use a hammer to do screw driving, to work in screws. So it's making sure that whatever you're trying to do, you have the right tool for the right job. And a tool is supposed to be about automation as well, right? It's supposed to automate these tasks that are more structured so that you can focus on the things that you really add value to as opposed to things that just can be done really quickly. So the whole concept is use the tool when it works in that favor and then don't use it when if it doesn't work in that favor. And I feel like there are so many tools when it comes to technology and we think of nonprofits around the globe, Alex, and some departments within an organization use one tool, another department uses another tool. Sometimes they intersect, sometimes they don't. So I'm really curious if you can talk to us again just off the cuff, what does that look like and what are you seeing when it comes to organization, systemization and integration? I've noticed that for smaller nonprofits, people and teams are very separated, right? Each one has their own preference. Some might be paper, some might be Excel. One team might have a CRM, might have a donor management system. And most likely they are very separate because they're choosing it within their own capacities and capabilities and they don't really wanna have too much inter-team communication. At least that's not a requirement at the beginning. But then as nonprofits have become more and more advanced, that's when the cohesion and the communication inter-teams make a big difference because you become more effective at what you do. So that's the point where you start evaluating as a team as a full unit, when does it make sense to approach what tool and which tool to use? That would be the starting point. It's so interesting because it seems to me that these tools that we use are so specific for our silos. And when we look at programming versus development, you know, wow, what a hard thing to try and even communicate. I think what the jobs are because I think a lot of times, and Jared, I'd love to get your feedback on this. Development has this whole ecosystem and concept of what they think programming does. And programming has a whole ecosystem and thought process about what they think the slackers in development are doing. Like they're just going out to lunch and having a good time. Right, right, getting paid to have coffee. Yeah, I think there's a lot of misconception, but Alex, you hit the nail in the head and I really do think that, you know, the smaller the organization, the greater the silos, and I really think it comes to the team, the executive team, really all players, you know, to really create that cohesiveness because you're right. Like coming together in technology, having this system overlap, that's when you see success. And I always, I love a good executive dashboard, you know, like show me a good dashboard, that will make my day. And there's nothing wrong, by the way, having a disjointed system at the beginning, right?  The tool you're using at the time probably doesn't matter too, too much, but it's as you get more effective, as you grow as an organization, that's when you'll start seeing a lot of cost savings and time savings and very money savings as you become more cohesive as a single unit. So apart and parcel of that, you always say, or I don't know if you always say, but in our preliminary discussion, you've talked about making tech work for you and not the other way around. What does that mean? So a big part of the tool in technology is making sure that the user experience works for you. And user experience is something I'm actually certified in as well as being with CRM, in that you learn that to build a system that your users are already used to using. And what I mean by that is, when you go to a website, for example, you already know more or less how websites work. You know, there's a menu going to be over here, you might have that hamburger, three-bar menu, and various other points.  You already know these things because you've used it hundreds and hundreds of times before. It's the same thing for any kind of technology. When you're building a technology, you wanna make sure that you're adopting user experience principles. So you don't have to train, this is what you need to click on, this is what you need to do next. It's intuitive based on the fact that it's been done many times before, you're not building anything original. So making sure that the tech works for you is making sure that the choices you're making, the technologies you're choosing has a good user experience. And you discard the ones that don't, the ones that don't work for you. It's interesting, cause you know, I think sometimes we get lured into the concept of this is new and different, exciting, and nobody has it. And I love what you just said about making something familiar so that you have greater success or comfort and engagement. It's really an interesting way to look at this. There's a lot of cool things happening on the edge of frontier of technology, but nonprofits is an area I wouldn't recommend should evolve to that cutting edge. They should be using systems that are a bit more established, a bit more refined and have been used and adopted by many users. There are some exceptions to that rule, but by generally you wanna make sure that it's been tried and tested before you actually adopt it. Yeah, I do feel that we, the nonprofit sector are often the latest to adopt innovation. And I really see that when it comes to technology. Now I was at the Association of Fundraising Professionals conference last year in Vegas this year. It's coming up in New Orleans. But what I saw at that conference, Alex, and again, this is really fundraisers, right? Is that it was a fundraising conference with technology first. Like the entire showroom I felt was just filled every row of technology, technology, technology. So there's so many things out there. I love that you said like, hey, let's not be the beta. Let's not be the first adopter. Let's have someone else kind of write the ship so that it's ready for us. What are you seeing when it comes to, like, I don't know. Once we adopt something, has it then become obsolete? Definitely not. Yeah, no. And before I answer that question, there was something you mentioned, you said nonprofits are the latest to adopt technology. You mean the last or the most? Yes, like we're not, yes. We are like, you know, the latest being. We're back. Yeah. The last, okay. And that's perfectly fine. I mean, you don't want to be the very last, obviously, but the idea is you want to wait for the technology to be a year or two old before you adopt it. Something that's really new might not succeed. It might not be around after a long period of time. You want to, like I said, make sure that it's been tried and tested before you start adopting it. There's a risk to becoming, to using that shiny new toy in that it might not be around, or it might be not exactly what you needed to do. Well, I think a year or two is safe because that's probably the average amount of time before we even hear about it in our sector. You know, the fact that it's kind of been tested. So you mentioned the shiny new toy and that is interesting to me because I do feel that there are so many shiny new toys out there. So talk to us about that shiny new toy syndrome. Like anything else, you want to make sure that the tool is established to a certain degree. And I mean, there might be some interesting things that you want to explore on your own personal time and might want to introduce to the organization at some point, but the need or the desire to jump to something new, every single day, week, month, whatever technology comes out, it can just be destructive. You'll just spend all your time researching things. We might, it would much be better to have some kind of help, external help like a strategist or a researcher do this kind of work for you and then propose certain technologies to you. So you don't have to spend your time and you doing all this kind of research on your own. Yeah. So going the other direction, Alex, I'm interested. I mean, and this is like such a broad question, but is there a shelf life? Like new technology really is changing, you know, every 24 months or like, should we kind of get into a pattern of understanding that we're going to need to make shifts or even just updates? What does that look like across the trajectory? Yeah, there is a misconception that once you buy something or you use a technology that you can just use it forever. And technology unfortunately requires a bit of energy, sustained, you have to sustain that energy constantly. And it's something you just have to reframe or reimagine or re-change your perception of and that technology just requires a certain amount of energy. So my idea usually is to do an evaluation, is to basically audit your systems, every let's say six months to a year to make sure that the technology you have is still working for you and then maybe see if there's something better out there that you can use. But it's not like a need where you have to do this every day or you wouldn't want to do it every five years, but let's say on a six months to a 12 month period, just to make sure that you're keeping that technology alive, you keep on feeding it and it's still working for you. Who's doing that assessment? Is that, is this like the IT person, if you're fortunate enough to have one? Is this each individual department? Who should be leading that charge? There probably should be one person at the organization if you're lucky enough to have a one person that kind of drives the conversation in the various departments. If not, it's a coordinated effort. If you don't have one person that can be dedicated or like I mentioned earlier, you could have some external strategist come and help you evaluate that process. So let's talk about this elephant in the room, AI, artificial intelligence. And what's that, what that is doing essentially to all of us and this spans beyond obviously the nonprofit industry, but that's a shiny new toy. And I love it. It's a really cool toy. So it's a toy in the sense of it's a tool as well, right? I mean, we already use automation in our daily lives. We don't do everything manually anymore. Everybody to a certain extent already uses some kind of automation. And this chat GPT for example, as an AI example, is just another tool that we can use. And people have this fear that it's going to replace people's jobs. And the consensus is more, it's people using chat GPT and AI in general who will be replacing people who are not using AI. So it's basically another tool in your trade to make you better, faster, stronger, more effective, more efficient, not to completely erase you or replace you. So I've used it and I think it is fascinating. Sometimes it's a hit, sometimes it's a miss, but really looking at, okay, what exactly is this? What's the possibility of it? So I'm really curious, if this is what's come out now, imagine what's gonna come out in just two more years or maybe even one year. Yeah, I would call this version 1.0. So I imagine version two, version three, I mean, it's just gonna get better and better. You're gonna be able to use it in more situations. Just again, you'll be able to focus on the things that actually bring value to the organization as opposed to writing a proposal or explaining certain technologies to you or certain concepts to you. That's what this tool can be used for. Ooh, you got me a proposal. I've not written a grant with it, but I think I'd like to try that to say, yeah, I think I would like to try that. At least as a starting point, at this point as version 1.0 as I call it, it might get you 80% of the way there and you'll have to make modifications, tweaks and whatnot, but at least it's 80%. So that will save you a lot of time so you can focus on the parts that you can only do. Sure. You know, I love that you brought this up, the piece of it in terms of the value of our own teams in that these tools are going to help to amplify the workload that we can take on, the work that we can do, and that ultimately, if we don't have these skills, then we will be replaced by people who do and that's the engagement of this technology. I think when you framed it that way, it makes it a lot less frightening for some people who feel like they're gonna be left behind. Yeah, right. That's really what it is. It's making sure they even have a name for it now. It's called Prompt Engineer. Someone who knows how to use this chat GPT is called a Prompt Engineer because it's like a command prompt back in the old days of computing. And the idea is that the better you are at using these kinds of tools, just like you are at any other tool, if the better you are using a CRM, the better you are using a hammer, the more effective you will be and the more in demand you're going to be. Oh, I'm gonna start looking for that key phrase, you know, on resumes. I'm curious if that's being integrated into resumes and just overall, you know, talking about the workforce in general, a prompt engineer. I've not heard that. Have you, Julia? No, I haven't, but it's, I mean, when you do use, just think about chat GPT. You have those prompts, you put those things in and the better you are, I think the more robust the work that gets spit out.  So yeah, it makes sense. You know, it's been so interesting to talk to you and I wanna spend the little bit of time that we have remaining. Having you talk to us about Salesforce and I realize that you are certified and that you work with that product, but Salesforce for nonprofits, it seems like it's really, I'm hearing more and more organizations use it. Can you kind of give us an overview of what you see going on with that technology? Yeah, I don't know where to begin with that one. And I do want to respect that one of your... That's a big question. Yeah, and I want to expect that one of your promoters is Bloomberg, which is a competitor to Salesforce. I want to respect that as well. The idea is it goes back to the right tool for the right job, right? There might be some situations and even I promote that as well. Even the fact that I do work with Salesforce, I don't necessarily mean that Salesforce is the right tool for every nonprofit. There will be situations where it's not. And the biggest difference I find between Salesforce and some other CRMs is that Salesforce is more of a platform. It's not just a CRM, it's bigger than that. So that tends to attract the larger nonprofits. The ones that really need to have this cross-system, cross-enterprise level of communication versus the smaller CRMs, which are very, very good at very specific tasks, they're meant generally for smaller organizations. One thing I've seen with Salesforce and happy to chime in on this, Julia, is that often when there's volunteers that come from the sales world and they're very familiar with like a business development CRM, they are easily integrated into Salesforce and can often help build customized forms, things like that. Not to say that it's seamless, but I just feel like there's a lot more knowledge around that and when it comes to that interchange as opposed to a platform that's been designed specifically for nonprofits. So I've seen that as definitely a positive and I know there's so many amazing user groups out there. We have some here in our community, which has been a lot of fun to watch. And what you had shared, Alex, about making sure it's the right tool, you're not gonna use a hammer when it's something that you need to screw in or maybe even dig a hole, things like that. I've found myself throughout my career, really getting into a system to say, okay, this is what I want it to do. This is how I used to do it with X, Y and Z platform. And I think you had touched on this a little bit, Alex, about having it be user-friendly and intuitive. We wanna say, if we wanna pull this report, for me, the way my brain works is, if this is how I did it in this other system, how might I do it in this one? Yeah, it's hard. Alex, what do you see moving forward that Salesforce and some of these product lines are moving towards that, or are they really digging in and holding on to their original direction that they took when they were originally designed? Yeah, it's hard for products to change like that over time. Usually they, like Salesforce and these larger enterprise organizations, they more like buy smaller companies, integrate that into the system, as opposed to changing their entire way of doing things. And you're right, there is a process, of course, of learning as you change from one system to another. But the fact that you know how reports generally work is probably a concept you can transfer over to your new CRM, for example. The details of how that's done might change, just like you were, and I'm dating myself as well, back in the day when I used to use WordPerfect and switch to Microsoft Word, you know what you can do with it, exactly. You just need to figure out how to do it in the new system. So there is obviously a change management and a learning process that can be awkward and uncomfortable, but the idea is it's difficult or I don't see it too often where a platform like Salesforce would change the way they do things. There are reskinnings that it did recently move from classic interface to lightning interface which made things better overall. But that's more of an interface level thing was supposed to, this is the way that the future changes completely. Yeah, and you mentioned automation and I see that happening more and more and coming up because I feel like our workforce, we talk about compassion fatigue, we talk about burnout, we talk about many nonprofits pride themselves on look what we do is so very little, and so really adding more and more to the plate. So automation, I think the software or the system, whatever it is that we're using really needs to have that automation. And I'm curious, Alex, if you see that automation from teams are actually being used to their full effect or if we're just like touching on that surface? You're talking about in terms of the Salesforce context or the overall context? Overall in general, I'm curious what you've seen. I'm not sure there's an end to automation. I think there's something you can always make better, faster, stronger, simpler. The idea is to again, use a level of comfort that you're, use automation to a level that you're comfortable with. So if it works for you, you're able to do what you're doing, you're able to focus on the work that you add value to and you can outsource some of these automation, great. If at some point down the road, you realize maybe there's something more I could automate, let's see if you can simplify this part of the task and try to automate that part or outsource it, for example, or different ways of shifting the work so that you don't have to focus on some of these tasks that someone else can do or a system can do, just as good as you can. I love that mentality. I think that's just, that's kind of magical thinking because we do have, as Jared said, we have so few resources in many, many ways and then we're trying to, you know, do the work of the angels, heavy loads on our backs and so, yeah, reasserting how we tackle a problem or a project, yeah, it's a good way to look at this. Alex Lapak, CEO of Dryad Consulting, coming to us from fabulous Southern Spain. Okay, I gotta ask, is it past your dinner time now? It is. Well, we're just getting started here in the West, Western United States. Check out Dryad Consulting. It's really an interesting website. You can read about Alex's journey as a digital nomad, how he has framed up his work in the nonprofit sector. Really quickly, you have an actual app just for the Canadian nonprofit sector. Right, so I noticed a need for Canadian nonprofits using Salesforce and that's for tax receding. There are not a lot of great choices out there. So I'm actually introducing this as a brand new product available now to do that. So tax receding for Canadian nonprofits using Salesforce. Okay, I know that. Yeah, Dryad receding. Dryad receding. Dryadreceding.com. Awesome, well congratulations. Thank you. That's really amazing and I've got the nonprofit show is gonna be announcing their app very shortly. I'm just, I'm not trying to be competitive, but I am trying to be competitive. That's great. Super cool, really, really cool. Well, everybody, again, I'm Julia Patrick been joined by the nonprofit nurse herself, Jared Ransom, CEO of the Raven Group. Again, we are so fortunate to have these amazing sponsors who join us day in and day out. They include our friends at Bloomerang American Nonprofit Academy, your part-time controller, nonprofit thought leader, fundraising academy at National University, staffing boutique and the nonprofit nerd. They are so important to every episode of the nonprofit show. And Jared, next week, my friend, I think we kind of start, in the next couple of weeks I should say, we launched our fourth year of broadcasting. It is coming up. And we also will be taking the show on the road much more this year than we did last year. So there's a lot happening. It's very exciting. It is. It's very, very exciting. Alex, our dream would be to come and do a live broadcast in Southern Spain. You're more than welcome. Yeah, we might have to make that one happen. Absolutely. Hey, everybody, we like to end every episode of the nonprofit show. We want to remind everyone to stay well so you can do well. We'll see you back here tomorrow.


Welcome back, everyone. This is Brian. And in this video, we're going to talk about date time. Dates and times in other languages are well a pain, but Python makes it ridiculously simple. This video, we're going to talk about dates, times, deltas, and formats. Let's dive in and take a look. The first step, of course, is imports, everybody's favorite. So we're going to say from, and we want the date time, we're going to import date time, and I'm delta. So what are these things? Well, date time is the module and date time is the class we're going to work with. And time delta allows us to take a different time, or I should say time in the past or the future, and add or subtract numbers to it. So you could say, Hey, I want to know the date 30 days from now or five weeks from now. And we want to be able to format these things. So I'm gonna say from time imports. And we want to string format time. What that's going to allow us to do is say something like, today is December 2017. But put it in a nice pretty string format. All right, to begin, let's go ahead and make a main function here. And we're going to talk about now, meaning right now, we're going to do this literally right now. What is now exactly? Well, it is a representation of the current date and time. So I'm gonna say date time dot now. Now you should understand what's going on under the hood when you do this. You're saying go out to the operating system and say operating system, what date time do you believe it to be? However, that might not always be the actual date time. So I'm gonna say date time dot UTC. Now, special note here, if the machine is on a UTC time zone, then there'll be absolutely no difference. So which one is right for you? Well, it depends on which one you want. Personally, I tend to use the UTC. Let's go ahead and just print some stuff out. I'm just going to through the magic of copy and paste here. We're going to say print out now print out UTC and I want that offset. So let's go ahead and print. You see, there's absolutely no offset here. So these are exactly the same. Now, they're not actually exactly. You notice these last two little numbers here. That is actually the difference in time between this print and that print. That is your computer running. That is an incredibly small amount of time. It is called a microsecond. Let's talk about time. Time is split into logical units and don't worry, you're not going to sit here and watch me type for hours on end. But it is split into logical units, meaning you have hours, minutes, seconds and microseconds. We run this. Everything just seems to work. It is the 16th hour, 17 minutes, 27 seconds, and there is our microseconds. And of course, milliseconds being up here. Now, you may be wondering, what's the difference between now and UTC? Again, because there is no offset, they should be identical. This is a very simple, easy way of grabbing this. There are a lot of tutorials out there that show you some long exhaustive ways of doing it. But why bother? Just grab the daytime now or daytime UTC now and then grab the hour, minute, second or microsecond, depending on what you need. Time waits for no one and time is precious. So I don't want to waste too much of your time here, which is why I'm doing a lot of copying, pasting. Dates are well just as simple. I'm just going to do the old copy and paste for dates. Year is now year month, now month, day is now day. Now, you may notice sometimes if you're typing away here, it may or may not depending on what you're working with. Let me find one here. Hour, there we go. So IntelliSense is picking up two of these, it's saying hour and hour. I'm going to just run this and let's see what happens here. Just wanted to put a quick note in there that sometimes IntelliSense will betray us. Daytime, daytime object has no attribute of hour. If you ever get that, check your case sensitivity. For example, ta-da. But of course, that's not the right thing. Major takeaway from that is case sensitivity does matter. Grabbing the hour, minute, second, microsecond, year, month and day is ridiculously simple. There's no sense in wasting a ton of time trying to figure it out. All right, this is where we slow down a little bit here. We're going to talk about deltas. A deltas is a difference between two numbers. So what we want to do is do some date computations here. For example, let's find what the date is going to be 30 days from now or a month from now, I should say. This is where Python's a little bit lacking it. There are other ways of doing this. I just wanted to show this to you really, really quick. So I'm going to say next month. I'm going to say now plus and we want time delta. Now you're inclined to go, Oh, this must be easy. I'm going to say month. And then Oh, doesn't work. And then you go, Oh, I know the problem. This is uppercasing it out. It still doesn't work. What the heck? Maybe it's months and it still doesn't work. This is one of the shortcomings of the time delta is that it really doesn't have that concept. You have to do it in simpler terms. So I'm gonna say days. Let's go ahead and do it 30 days out and see what this looks like here. Now suddenly I get next month's date, which will be January 16th. Hmm. So it's a shortcoming, but it's really not that big of a deal. There are other ways of doing it, but I don't want to get super, super complex here. So I'm gonna say last week. Now I'm going to say time delta and let's say weeks. And we are going to minus one. So what this does is it takes our current date time and reduces it by whatever number. So last week was 1210. It becomes ridiculously simple from this point. I'm just going to for the sake of brevity copy and paste the rest out. I think you're smart enough if you're watching this series to figure out what's going on here. So five hours from now would be time delta hours five 45 seconds would of course be seconds 45 200 milliseconds 10 microseconds and so on. It is just ridiculously simple to work with this. The major caveat being you're going to start stumbling into little inconsistencies like I displayed with the month. Now sometimes you need to work with a string representation of a date and that's where ISO strings really come into play. So I'm gonna say D equal and I want the daytime dot from ISO format and you notice how you've got a whole lot of things you can say from from calendar from ordinal from timestamp but we're going to do ISO format. Now there is a special format you have to follow. For example, I'm gonna say 2020 dash 12 dash 16. You can very easily go out and Google ISO format and find out what it is. We're gonna go ahead and say print. Notice how there's no time because we didn't include the time in the format. So it is at 00000 basically midnight. Alright, that is super simple to work with but there's one little gotcha you should really understand. So I'm gonna say m equals and I want to say date time. We're going to make this thing crash. And I'm gonna say from ISO format and this is where trusting your end users could be a very bad idea. So let's say 2026 dash I'm just gonna make up some gibberish here. I don't really care. We're intentionally trying to make this thing break. This looks like it could potentially maybe be some kind of date time and no value error. So it crashed our little program here. So you gotta just not trust your user. So I'm sorry, it's really what it boils down to. So once they try, let's do this. Get some screen real estate there bang and there we go exception as EX. And let's just go ahead and print out the args. That way we can see we had an invalid ISO format and it gives us the actual string representation of that. So in case you're kind of curious, yes, you can actually get the ISO format from our now object here. So let's say print, say ISO. And let's say now dot ISO format. And let's print that out. So this is the correct ISO format. And if we had put that in there correctly, it would have converted it. However, we just entered gibberish. So it crashed our little program. One of the more challenging things in programming is well formatting dates and times and every operating system seems to do it a little bit differently. And every programming language does it a little bit differently. So I put a link out here. W3 schools big shout out to them. I'm not affiliated with them by any way shape or form, but they have this really, really great chart and you can actually click this try it button. And it shows you exactly what's going to happen. So really what we're doing is a string representation of what we want the date time to be.  So for example, a percent sign means we're going to format. And then we have some letter or numerical value depending on what you want. Python really doesn't have numerical values in there, but other languages and frameworks do. So we have percent lowercase whenever you see lower think short version when you see upper think full version however, they don't always line up. So for example, upper case H is our and then this right here is our so what is the difference here? One is in 24 hour format one is in 12 hour format and it's just some of these little gotchas you got to kind of figure out what you need in advance and that's where a chart like this comes really super handy. All right, another really good example would be like capital a weekday full version, lowercase w weekday as a number. So you can do a lowercase and uppercase or W YW. Why not? It's just how they designed it. So let's just dive in here and take a look. Let's say print. And let's go ahead and format this out. And we're going to say, actually, no, I don't want to format that out. Go ahead and say now dot string format time. And this is where those special codes would come in. So I'm going to say we want to format something. So the percent sign. And let's do a Y, which represents the year. So it's 2020. However, that's kind of just the number 20 doesn't really represent how horrible 2020 spin. So let's just uppercase that bad boy. And there it is 2020. You kind of get the point. So I'm going to do a little bit of copy and pasting. Just to speed that up just a microsecond here. So for example, percent D, D, percent B, see what those do. And you can find out basically off that chart very quickly how you want to format that. Now you may be asking yourself, there's got to be a way to do this a little bit more complex than this. I mean, come on, this seems overly simple. Yes, this can make your life super, super simple. For example, let's say we want to do something like this. Today is and let's go ahead and say percent B. And then percent lower case D. Today is December 17. I hope you enjoyed this video. You can find the source code out on github.com. If you need additional help, myself and thousands of other developers are hanging out in the Voidrom's Facebook group. This is a large group with lots of developers and we talk about everything technology related, not just the technology that you just watched. And if you want official training, I do develop courses out on udemy.com. This is official classroom style training. If you go out there and the course you're looking for is just simply not there. Drop me a note. I'm either working on it or I will actually develop it. I will put a link down below for all three of those. And as always, help me help you smash that like and subscribe button. The more popular these videos become, the more I'll create and publish out on YouTube. Thank you for watching.


Hi everyone, Joe for Jaspy's casebreaks.com coming at you with 2020 Leaf Greatest Hits Multisport a one-box random letter break Now this is their first letter of their last name If we pull a Charles Barkley, it'll go to be Kareem Abdul Jabbar will go to a Abdul Jabbar hyphenated his last name Carl Anthony Towns Carl Anthony is his first name Towns is his last name if we pull one of his that would be a tee um Each year oh If it just says each row on the card, it'll go to I If it says each year old Suzuki on the card, it'll go to it'll go to s Depending on what's written on the card. There's compost spots there too. So there you go All right big. Thanks all of these folks for getting into it. There are the first letters of their last names right here Let's roll it. Let's randomize it three and one four times for each list one two Three and oh one fourth and final time after four times will be God Takumi down to Takumi and then three and oh one Four times for the letters one fourth and violent time W down to G. I know not yet Danny Not sure I wouldn't hold my breath on that. That's usually just surprises. It shows up All right, Takumi Abe with W Roger with s Danny with K Jeremy with B Josh with E Jared with C Eastwood with P Jeremy with J Richard with R Jesse with H Richard with M Brian with L Matthew with T Brian with the combo letters here Jared with D Anthony with a Mike with F and Takumi with G. Let's order these by letter alphabetically Suppose you could trade letters. It's pretty rare that people trade letters, but you can if you'd like We're gonna select one die. I'm gonna select that one right there one two three for the top box and four five six for the bottom box Three so it's one two three And we'll save this for next time T and J are great letters wasn't TJ just here a second ago. Hi TJ. All right. No one's trading, right? TWC trade window closed. Let's print. Let's rip. What do we got? We got three graded cards in here. I feel like feels like three graded cards in here So first one out of the gate is gonna be Brett farf From 1992 stadium club Brett farf PSA 9 So letter F and it'll be for Mike Tower. There you go Mike Next one is gonna be It's gonna be Joe Adele 2018 Bowman's best best of 2018 autograph PSA 10 a gem mint 10 that's nice big big prospect for the angels a for Adele goes to Anthony there you go Anthony and The last one is gonna be a Zion from NBA hoops 2019 Panini hoops basketball PSA 10 gem mint 10 Zion Williamson, I'll cover the spot and then some for whoever has W Takumi Abe with that one. There you go, man.  Jaspy's case breaks calm I'm Joe and I'll break that with you next time. Bye. Bye