 Hi, everyone. It's Monica Wahee, epidemiologist and data scientist here to give you advice on how to use your health data analytics skills in the field of data science. In fact, lately, a lot of health data analysts are faced with analyzing data that comes out of apps. You are familiar with health-related apps like Epic or other kinds of health tracking apps that you might have on your phone. But it's really hard to analyze data from apps if you don't understand the backstory about apps, like how they are built and how they are structured. Part of what I teach in my online applications basics course is terminology about applications that health analytics professionals should learn and know so they can better understand the data they are analyzing that come from apps. Some professionals into health data are moving in a more data science direction. They want to be on data science teams and take on data science roles. But what are these roles exactly? Okay, while we are on the subject of defining roles, let's talk about the technical definition of an engineer. In application development, you will see a lot of job announcements for a position called software engineer. Engineers in these positions are people who are basically good at developing front ends and good at making front ends connect with and talk to back ends. The term software engineer sort of implies having some expertise in front end programming. On the other hand, the position of data engineer implies expertise at back end programming. Specifically, data engineers are good at improving data IO. These are the programmers who know where to put the ifs and the wheres in the SAS code to make it perform optimally, for example. You may have also heard the term network engineer. These people tend to be experts at optimizing IO over an entire network. Remember the LAN I talked about at my old workplace? Network engineers are good at optimizing how LANs work and how they talk to the internet. You will also hear the term engineer used with other words, like security engineer. As far as I can tell, engineers are typically very good at math, at programming, and at building and fixing things. But unfortunately, engineers are typically not good at other important functions on an application development team, such as documenting what they actually built. They are also typically not good at understanding non-engineering data, meaning data from a particular knowledge domain that is not engineering. And also, engineers tend to be bad at designing anything. If they get it in their head, they just try to build it. Why wait? Skip the design step. And you can have other roles on the application development team depending upon what the application does. Think of an online role playing game. That's a type of application. That type of application would include graphic people and music designers and probably artists. If the user experience is very important, like you're building a dashboard for pilots piloting a commercial airline, then you might have UX slash UI specialists on your team. Sometimes there are documentation technicians on an application development team, and all they do is the documentation behind the application, presumably the documentation that the engineers are not doing. And again, it depends on the features of the application being developed as to what extra roles there will be on the development team. Now I'm going to come to a topic I'm very opinionated about, and that is the concept of a subject matter expert or SME for short. An SME on an application development team is seen as someone like the sponsor and the PM, in that they usually have zero technological background. What they are there for is to represent a typical user who is trying to use the application for its intended function. So if you are building a medical records application, you might have some nurses who will use the application serve as SMEs on the development team. Or in the case of developing an email client, you would have SMEs who are workers that use the email system at work. Okay, here's something fun I found on the Internet. It's a Gantt chart for making a film production. Remember, what I'm talking about with project management is used in many different fields in addition to application development, building construction, media production, and in this case, film production. See the colorful horizontal bars on the Gantt? Each one of these represents a task. You will notice that on the left along the Y axis, there are headings. The bold headings are kind of like headers for a big task. The top one says pre-production. So that top pink line indicates all of the pre-production phase. See how across the top of the Gantt, along the X axis, the names of months are written, Jan, Feb, Mar. That's the timeline part of the Gantt. So right away, we see the pre-production phase, the pink phase will last from January through about the middle of February. And if we want to know what all is happening in the pre-production phase, we can see the breakdown of tasks in pink below it. Notice how the first two tasks in the pre-production phase, right shooting script, and researching interview partners kind of overlap at the end. This just indicates that these two tasks can be going on simultaneously. But then, look at the end of the top pink line. See how there is a vertical black line that leads down to the next phase, which is production. That line indicates a dependency. What that means is that production is not parallel to pre-production. It is actually dependent upon pre-production. In other words, production cannot start before pre-production is complete. So if pre-production is delayed, it delays the entire project. However, if you look back up to the first two pink tasks, if either of them gets delayed, it won't impact the other one. Neither has a dependency on each other. In this example Gantt I found on the internet, there isn't much of a demonstration of deliverables or milestones. You will see an important milestone at the end where it says launch. But along the way, you would see deliverables typically. Usually, they are marked with a big star or asterisk. If you look at the second green line under the post-production phase, you will see the word music at the end. Perhaps that is how they are indicating that this is the due date for the music deliverable. So how does the PM know what tasks to put on the Gantt? Well first, the PM helps the team nail down the application requirements, or what the app is required to be able to do when it is complete and in use. What operations must it accomplish? What functions must it include? Everyone impacted by the app is called a stakeholder. This includes the sponsor, the PM, everyone on the application development team, all the users, and even people who are impacted by the app in a secondary way, such as government regulators of apps. So the PM figures out which stakeholders need to be consulted and how, and helps get them together to write requirements. And that is what is done at the very beginning, often before the full application development team is assembled. This requirements writing process helps the PM set up the team and all the tasks on the Gantt. After the application is developed, finally at the end, specifications are written. These are more like technical details that the app has to meet once it is being used and in production. Sometimes specifications say how fast certain queries should run, or how often data should be backed up. Specifications are mainly for quality control. So this was just a quick crash course in some of the terminology used in application development. If you are into health data analytics, and you aren't familiar with application development, there is actually a lot to learn. I encourage you to take my online course titled application basics to teach you, well, the basics of application development. That way you can learn all the terminology you need to know to understand data coming from applications. And if you want to take your health analytics career up a notch, consider joining my group online mentoring program. One of the first courses you will take in this program is this applications basics course. I'll put links in the description of this video for more information on the course and mentoring program. I hope this video gave you insight into how teams develop applications and the different roles on the teams. And hey, if you serve on an application team, please let us know your role and the kind of work you do in the comments. And if you enjoyed this video, please like it and give it a thumbs up. Have a great rest of your day. Thank you for watching this video, which is part of the public health to data science rebrand program. If you are interested in joining the program, please sign up for a 30 minute Zoom interview using the link in the description.