How to Become a Top Business Intelligence Analyst | Helen Wall, Founder at Helen Data Design & Microsoft Influencer

ld so much of it below the surface that people are only interacting with the pieces above, and they don't realize how much work is, below the surface of the, the water.

Richie Cotton: Okay. Yeah. It certainly seems like being able to build stuff is only the first step. Being able to build something great and what you, what your users want is the next level that takes you to being advanced. Do you wanna expand on that? Talk me through what are these skills you need in order to be this...

A great BI analyst. 

Helen Wall: Going back to, BI's often known for these visuals, and kind of the end user opens up a report and they see charts, they see tables, they see metrics. They can interact with it with slicers. There's, might be a map or two on the, on, report page.

But understanding how those pieces connect, below the surface, and what else do you need to be effective at in order to build that, right? So I would say when someone starts a job you have an idea of, what you're doing. There's... Someone will have built something beforehand.

But then in order to really, be good at it, and to be great at it, is you have to understand how to go deeper on those pieces, right? So you're not thinking just, "I'm one person trying to know everything in one topic," but also having this broader set of knowledge, but not something that's surface level.

So really try to get into and understand multiple technologies, and look at what you think you need to learn, and what you project or forecast will be helpful. And, look at acquiring those, skills. Because sometimes what makes someone great isn't necessarily something that directly applies to, whatever, like a BI platform, but it's being able to connect those with other, pieces.

So a lot of BI technologies use SQL, and so if you're good at SQL, you can think about how you're going to, make it load faster or, o- optimize running queries, doing those things below the surface. Realizing what you can expand on and what you're good at and really running with those.

Richie Cotton: Yeah. I love that idea of just- Considering like the, the business implications, like the, you need some kind of domain expertise in order to be good at this, in order to ensure that you're building the right kind of things, as well as the technical expertise. Do you have a sense of like what order you need to learn these things in?

Do you have to learn to build stuff first, then you like under some like the, the job side of things? Or do you go the other way around? 

Helen Wall: I think it's a combination of both. Okay, and a great example of this is SQL, because you can take SQL, courses, you can practice on your test examples, but it's really hard to build an enterprise level practice model, right?

Because an enterprise has especially for a bigger company, you have so many transactions a day, there's so many tables, and they're not going to be connected. It's not five tables connected together or that you can connect together with a SQL query. It's like these are more complicated examples that you have to sit down and think through how to do.

And then the other thing is that a lot of times if you're Writing a SQL query and running it, you might not be the person building it, and so you have to deal with time constraints. Because if someone else is trying to run a query and they're saying we need to do something else with this," being aware of how you fit in that and, like, where you can ask for help, who you can ask for help from, and then what you can add to that, conversation.

So I think if you go to someone if you're in the business side and you talk to someone in IT, is being clear about what you're trying to do and, like, why you're trying to find it. I think just saying, "I want all the data," that's a lot of work for the other person. And also, it's probably not what you want.

Really at the end of the day, we're using data to answer questions, and if we have something that's more easily available, then it's going to be easier to answer those questions. 

Richie Cotton: That's a really good example of the SQL stuff. If you're creating a SQL course, and I've done a bit of this myself, you can't have a data set where it's like, "Oh here are 10,000 different tables," and they're all badly documented and badly named.

No one's gonna take that course. But yeah, that's often the case when you're actually working on a real sort of company data set. 

Helen Wall: These are, real people that you're working with, and it's a lot easier to... If you're looking at a, a dimension table storing, users, is that you think this is unique user ID."

But people it's a lot easier to create fake user IDs and imaginary ones to use than to learn about things than it is to build something like that, because a lot of people are not aware whether they are a record in that table. 

Richie Cotton: Yeah. I was... And I think it's a sort of perennial complaint from analysts that, oh, the, the data's dirty.

It's not in the right format, all this kind of stuff, and you spend way too much time cleaning data. Is it the responsibility of the analyst to fix this, or should this be, like, separate like a governance team or data quality team who should be doing this? Like, how do you get to that state of better data quality?

Suppose you are this business intelligence analyst. How do you go about making sure that you have good quality data to work with? 

Helen Wall: It's a lot more ambiguous than people realize. You think, "Okay, this is dirty data. Now it, it's 100% not usable. Now I've created something that's 100% useful and usable."

Is that there's a lot more gray area in between that. And also, the other thing is that if something doesn't work initially is you can't change the way it was entered or say I'm going to replace this with the correct..." Someone accidentally misspelled their name, for example is you do want to have that original record, right?

So I work as an actuary, and this term that we had we would-- And I'm, I haven't heard this used in other places. It's actually more of a legal term the term seriatim, and what that means is point by point. So when you think of data, it's record by record row by row. So at the end of the day, we look at all these tables row by row, but very few of us actually want to see every single row.

We want to see, the relevant pieces of it, or it summarized in a way that's, meaningful. Sometimes adjustments are made to data, and they're intentional. So for example now I work a lot with weather data and You can't always keep the same sites for collecting weather measures. A lot of them are collected at airports because it's easier to keep that, space.

But you might have to move it around the airport, and so in that case, sometimes adjustments are made, right? If you're moving it to a slightly higher elevation, slightly inland, is that it's not that either of those are wrong, but in order to have continuity for a broader location is those adjustments are made.

Leaning into that a lot and realizing that's part of the process. 

Richie Cotton: So yeah, so I guess getting to that stage of great data, it's as much a- an art form perhaps as, Yes ... anything else. 

Helen Wall: It's an art and a science. 

Richie Cotton: Okay. And so something you alluded to before was that often you don't get to work on brand-new projects.

You end up having to deal with other people's messes, or you're updating projects that are already in existence. Talk me through how do you go, how do you approach doing analysis in these situations? 

Helen Wall: So I think I learned this pretty early on because I worked with financial reporting, and my first step for that is looking at it from the high level, but then also here's what was done last year, right?

So they exactly a year ago, they reported this as a year-end number. How was this created? Like, where did this number come from? What are the steps to get there? It needs to match what was done last year before any changes were, are done this time, right? We're not redoing the process every year. A lot of processes in business are you might be fixing an error with an existing huge process, but very rarely is someone asked to create an entirely new database or cr- just build an entirely new model.

We're often fixing things that are already in production. There are two pretty hard parts of this challenge is keeping whatever is in production still working, you don't want to break that, and then making the correct updates. A- and so you have that balance of keeping it running and then also looking at how to improve it to fix things, the, the features and updates.

And I think that also speaks to why, when applications come out, the first few months that they come out, there's a lot of features that are updated, but then as you create more features, there are more functionalities and things to maintain. And so you end up, there's a lot more kind of bug fixing.

There's fewer big factor, like wow features because you have to keep what's already existing, balanced and still running. You can't just ditch what you did in the past. You have to still keep that, afloat, an iceberg, right? 

Richie Cotton: Yeah, certainly you don't wanna be diving into something that's working already, even if maybe not ideally, and then you go and break it, and you've made the situation worse.

Helen Wall: You want to keep everything balanced. And also You know, the person that, who may have worked on it before might be still there, so understand why they did something that way and, building that relationship with them, but understanding why something was done and going, "Okay this, worked for here, but how can we free up your time to do other things?"

Not like, "Oh, this was terrible. I'm going to scrap it all," is realizing that, there are people behind all of these adjustments. And yeah, you're trying to keep everything afloat and also, the, I guess another element is how are people interacting with it, right? And you can't reinvent things.

You have to understand how and why they were done that way before. 

Richie Cotton: Yeah, certainly is a bit of a gamble. And occasionally people do terrible work and you have to be like, "Okay, let's just quietly shut down that project and start again from scratch." But you don't wanna do that often for sure. I like the fact that you mentioned there's a people side to things working with other people who've been, your predecessors on a project.

And I know you're consultants, you must step into kind of other people's work quite a lot. Do you have any tips for, like, how you get up to speed on a new dataset or a new project very quickly? 

Helen Wall: First of all, there's a lot of work that people do that they haven't published it, or it might not be available saved on a company share drive, push, pushed to GitHub.

It's thinking about how you're going to test something out in your own environment being able to pull that out and understand how that gets put together. Again, you don't want to mess up something that's already in production and something that's live. And that's always the s- the scary part.

More recently, BI tools have got into those deployment pipelines, but that wasn't always the case, right? And when you have those type of deployment pipelines, you often have more pieces to put together. I think the other thing that people don't often talk about is when we look at something that someone put together, you don't necessarily have all the time in the world to build something.

And sometimes what ends up happening, this is similar to buil- y- a building, is that something gets built and it's like this works for now." We have built we have built a structure a, a database, a model. This works for now, but I'll come back and work on it later because there are time constraints and things that need to get done, and whatever is due now is often of the highest priority.

So sometimes there's that time constraint that something they didn't think would be in use years later was built and that worked, and somehow that, kept rolling forward into each future time period. 

Richie Cotton: Yeah, absolutely. There's so many finer points around how do you understand what's going on there.

Helen Wall: Yeah, a lot of psychology behind it. 

Richie Cotton: Yeah. I, yeah certainly once you're interacting with new people then definitely there's a, a, a psychological aspect to it. And I guess the related thing is you're gonna be dealing with different technology stacks, different kind of ways of working, all, all these different workflows.

How do you deal with having to learn new technologies, new workflows, things like that? How do you go about fitting into these things? 

Helen Wall: I think it helps to be around a good team. There's more convergence on technology. I know a lot of people that used to use other programming languages, for example, a lot more people are using Python now because of the way it works with AI models.

It matches the capabilities of R, but it also has, additional capabilities and just, you know- As things have more documentation and whatnot. But teams often use very obscure technology. There might be someplace something gets stored and you've never heard of it until you work on that team because it was something that was built.

There might be a mainframe program, right? That you have to work with. So there is just working with people and knowing how to ask questions, and when you're sitting down and working with someone or at a meeting, make sure to take notes, like first and foremost for yourself, like what is someone asking of you?

What do you need to ask of other people? And then more generally, what's going on? Because you'll revisit those and it also just helps, to ask a question that was already asked. That inevitably those things happen and there's nothing wrong with clarifying things.

But if you're, making notes and really like interacting with your work, then that will really help later. Again, figuring out why s- how something is done, perhaps why it was done that way. And then that also helps, build camaraderie with, the people you're working with.

Richie Cotton: Yeah, certainly if you're the person where someone has to ask you th- seven times to do something or you have to ask the same question seven times 'cause you didn't really get it and you didn't remember what was going on, yeah, that's not gonna endear you to your colleagues at all. We talked about how you can quickly fit into other people's ways of working.

I guess the, the flip side is if you are working on a project and you're likely to have other people joining you, like whether it's new team members or I guess new people joining your organization or maybe consultants how do you make it easier for other people to work with you? 

Helen Wall: So I think that my own documentation is just, okay, how can I put something together that's going to help other people later?

So a lot of things, you have one time interaction with, right? You're going to be like querying the database, querying a database a lot of times. But first, how did you get access to that? And we're not talking about, server ID, database name, but like who did you go to ask for access to it?

And that's often you have, here are the people to reach out to, having that, making that introduction. This is someone that is getting on the project. Here's what they need access to. Because that's something you do once. Even if I request access is I did that once, now how should I go through doing this again?

And it helps with a smaller team because you can either there are fewer people that you would potentially ask. There are these little things that- What that can make a big difference. If you see there's a piece of a project, like how can I get access to that without it being, like asking around the same people again?

It's just looking at, what that previous exchange was. And then just, a lot of it's an email exchange. It's summarizing it. This is, here are the details, you emailed this person, and, just who are they copying beforehand? Documentation has a tendency to not be as extensive as it needs to be, right?

Again, this idea of timing, and in the future you're going to remember a lot less, right? It's easy to think, "Oh, I'll remember that tomorrow," right? Y- And the likelihood of remembering something tomorrow is even lower this afternoon. But what do I need to remember in the future? So just think about your future self and what you need to do, and then that often really helps other people as well.

Richie Cotton: So I think you hit the nail on the head there where it's really great to document your processes so other people know what to do i- if they're taking over from you. And I guess this is also the solution for if you want agents to work for you, they need to know what to do as well then, so you need to write stuff down.

But also, I'm terrible at writing things down, so is there any hope for me? 

Helen Wall: So one thing I found can be helpful is if you have a lot of things you're trying to get out, is to use voice-to-text recording or tools. Putting something together that you know is not the final product or not necessarily correct, and then giving yourself kind of a head start so you feel like you already have that framework.

It's easier to build things from scratch, but sometimes it's easier to start documentation if there's already documentation there. So technology has specific terms, and it might mean something to the general public, but it means it's something different, in a specific field. Like any type of data f- field is often, okay, this is a term that People in this field know about, right?

Like a data lake or an acronym specific to what you're working on like S3. A-and then you've got these general terms, but then within a company, there are often specific terms. So again, the documentation of those things because some of those you will never hear outside a company.

It's very specific language. So if you document that, and you alluded to working with AI and agents, it will be easier to do those things later because it's n- right, there's nothing for it to train on if it's a very specific, vernacular within a company.

Sometimes it's even within a company department. 

Richie Cotton: Absolutely. So yeah. I'm a big fan of company glossaries. You have all those acronyms documented. I used to work for the UK government, and there it was just like a minefield of acronyms everywhere. But i-I

mean, same's true at DataCamp. We have all, all sorts of kind of company-specific jargon. So yeah getting all that documented is incredibly important. We've done a lot of talk about how to do projects effectively. I'd love to get back to what we were talking about originally, which is around BI and BI careers.

So I know you've been maintaining a list of Power BI updates for a few years now. Do you wanna talk us through what have been the most important sort of features there? 

Helen Wall: So it's very interesting because these are the published, the published features. So Power BI came out in September, or it was, yeah, September of 2015.

And the, the updates go back to 2021, which is actually now looking at it, like that's almost five years. That is half of the pro- the product life cycle. And granted, there were updates, before it, before then. One of the things that's interesting is the updates right?

Because each monthly update, these are the things that needed to be fixed, which are often not listed on the updates, you know, that... And sometimes those do get pushed out in between the months if it's really critical. But you have these updates that go out every month. And so some of them are these requested functionalities.

If a client is big enough, for example, they use Power BI and they're asking for a certain connection, that was something that was seen a lot We don't see as many connection updates. For a while, there were a lot more like, "Here are the new connectors," and then, "Here are the new visuals," but those don't go out often enough.

A lot more recently, like in the last month, has been these, Things that make it better to look at and easier to use, cross your T's and dot your I's. We don't want to create a chart where the bars exceed the top part of the X or Y axis, right? These little details that make or break a report.

If someone can't read a title label because it's cut off or because it it shrunk, 'cause those are issues that are understandable why the user m-might feel frustrated from that. And as builders, developers, we want to account for that. There's certainly been a lot of AI updates.

So it's interesting too, because a lot of the AI, a lot of the AI products, they existed below the surface for a long time, right? You could connect to cloud provider, and it might be running behind the scenes, right? There might be a machine learning model that is already built, right? You're never going to see it or interact with it.

But more recently, those features have surfaced a bit more, and we saw that when the Q&A visual of functionality came out. One of the challenges though with that goes back to the jargon-specific things, because I worked with SAP's database, and SAP's German. A lot of people that work with SAP will know those acronyms.

But, and hopefully if you're able to ask, if you're using generative AI to interact with the model, whether it's Copilot, MCP Server another, another tool, is that, okay it should know what that field is. But then a lot of companies, you'll see several different amount fields.

Which one are you using? So you know, it goes back to it's easy to take whatever that result is, but how are you checking, how are you checking those those numbers against something else that already exists? So these features, there's-- These features can help, right? They're-- But you still have to understand what the model consists of and, like, why something is there.

And often again, that goes to it's easy to say it wants all the data, but really you want the right data. You want the right data to answer a question or to, build something that's gonna be helpful in the future. 

Richie Cotton: Okay. All right. So it seems the, a few quality of life improvements, but like the, the big sort of trends there around more connections to other pieces of software earlier on- 

Helen Wall: More connections piece, it wasn't like the last month, last few months, there haven't been new connectors.

I've noticed they've even deprecated some of those. So there's already hundreds of connectors though, so maybe, there weren't as many requests or more things were being connected through, like Fabric, for example. I think they're managed in different places. And we talk about like map integration.

There's a lot more... You can see the map, but then there's a lot more you can build out in another tool and then connect to that, like ArcGIS or Azure Maps, Mapbox, whatever y- tool of choice. These updates have been less of that like, "Oh, this is, we couldn't do this until now," and more like, "Let's make this more user-friendly, test out some of these, you know, AI integrations that you can interact with on the surface."

We're not connecting to something that other people can't see. 

Richie Cotton: I guess lots of different ways of doing things. Yeah, you said yeah, obviously Fabric has been a, a big thing as well for connecting other tools together. So the other theme was, of course, generative AI.

It's taken the world by storm in the last few years. And, of course, agentic AI with it. How do you see the the general sort of BI tool landscape changing? Is it just a big push for, like more agents everywhere, or are you seeing other things as well? 

Helen Wall: I think that, I always think about what-- who are the people that are using my work.

You used the example for, like weather numbers, right? So if my thermostat on the wall, I want to be able to get the same information collected in the same way. It's going to be consistent over time. I don't want to, ask use a generative AI prompt to get the weather every day.

So what I would say is, you can use it to build things, to prototype them, but then how are you fastening it down or, like really strengthening the part of the process, right? 'Cause it's going to produce this output, but you shouldn't be creating the same output. You shouldn't be asking it for the, for output every day, right?

Asking the same question every day, like that's very inefficient, and it's going to- differ over time. Because they're, again, going to this idea of multiple like amount fields in a model different, filtering capacity. The other thing, businesses grow and they might have new locations added or new products.

And so it's easy to miss that by asking these questions and not having this comparison point. So what you want to do is you can use you can use generative AI to create something, but then how are you going to make that so it create, so it produces the same result each time that you open up a report, for example.

Because inconsistency, again businesses, is that they're counting on things to stay consistent and to be stable and producing the same results over time is a form of stability. 

Richie Cotton: Yeah. If you ask a question to your favorite BI chatbot, you'd want it to Think about what the problem is, and yeah, and then come up with some new, generate some new SQL every time that might be the same or might be different, 'cause that's incredibly inefficient.

So ideally you want to do generate the SQL once and call it each time. I suppose this naturally leads to the idea of a semantic layer, which I know you're a big fan of. Do you wanna talk us how through, how this works? 

Helen Wall: So you think of, this iceberg, and the visuals are on top, right?

Any interactions you have with that it's 10% of the mass of an iceberg is visible. So underneath it is... I often refer to semantic models underwater, and I don't mean it, it's that you c- a lot of people can't see it, right? Unless you're building, developing creating something, you're not going to be able to see the semantic models.

So Power BI was actually built on other tools. And one of those was SQL Server Analysis Services and having this tabular model was going to be more efficient than often someone running a SQL query every time. So think about if you connect to a cube and you put that in an Excel file, right?

You can create a pivot table, and you don't see any of that data. So all the work occurs below the surface. So within the semantic model, you've got, connections to model, you, SQL queries in this ETL framework. And then Power BI, you want to actually have the tables separate, and this is something that is a challenge.

I've used the term data science models because this is how I referred to it, five, five years ago or so. But y- data science models, y- you see everything in a table, right? So each record, and then you've got the dimensions, person, but then also attributes about that person.

So it's all in one table. But then with Power BI, you actually want to have that separately because you can reduce the size of the model by using a dimension table to refer to like user IDs rather than having each one of those as a new column to each existing record. So it compresses the size of the model.

So you want to have those like dimension tables, dates, user details, and then, f- what we call the fact tables. So the data tables, transactions, the big tables. So then that's-- you can connect those tables together and you ju- so rather than do that SQL query, you physically join them together, choose the join type, and then you build calculations on t- on top of that, and you can build those actually as part of the ETL framework, and then you can build them with DAX.

So the d- advantage with that is if you're working across a bigger team or mul- even more than one person is that people can connect to that model without having to write their own queries. You can use it in Power BI, and you can also use it in other tools, right? You can actually connect an Excel model to a Power BI model, and then you create a pivot table of aggregated summary of those data points.

So the idea behind using the semantic model is scaling a data model that makes it easier to update, for more people to work with and then, refresh and scale across an organization. Because you want to be able to reuse models where you can. If using generative AI and, these tools that are part of it makes it easier to build something as Why are you building it to start with?

Do you need it? Do you need something additional, or can you adjust what you already have? It's often, again, as mentioned earlier, it's harder to change or to edit existing models, and models meaning code, something that's already built. It's a lot harder to edit it than to build something new, because when you build something new, you're creating more potential variation later and more confusion, right?

Again, it's easier now, but it's going to be a lot harder to to explain or to make changes later if it was, like, created new because that was the easier way to do it at the time. 

Richie Cotton: So I love that idea of semantic layers and semantic models helping you scale things. 'Cause with particularly with vibe coding, it's very easy to say, "Oh, yeah, I'm gonna create something new from scratch," and if everyone does that, they all create slight different things.

But having that kind of standardized shared reference between teammates yeah, it just allows you to not keep reinventing the wheel a- and to have a sort of a, a consistent get consistent answers from your problems. There's the other aspect to this, which is around cost control, 'cause you mentioned that yeah, if you're generating stuff from scratch, if you're, like, asking, writing the same prompts every day and getting your AI to do all this work over and over again, not very cost efficient.

And I think certainly it was when Anthropic released a fable model which is a- an amazing model, but it's just very expensive. So I think every... My LinkedIn feed just turned into lots of people saying, "Oof, we need to start thinking about how to save money on AI now." Talk me through, what are your tips for not blowing your entire budget on AI in in a few days?

Helen Wall: First of all, realizing that it's it can easily be very expensive and looking at what you're building and not using AI as the solution, right? Because ultimately, if I continue doing this, what's going to be the cost in the future, right? Because right now it's priced a lot less than what it will ultimately be charged.

But if you've put, any organization, team, individual you don't want to put yourself in a position where you can't do it without AI. That if you're reliant on AI to do something, then that's going to be a lot more expensive in the long run. And what I say reliant on AI to do something like the entire process.

The other thing too is that agents can create multiple steps at once. These are probabilistic models, and they're not deterministic. They can produce different results each time, sometimes even with the same instructions. It's just that's the nature of how stochastic modeling works. So how are you breaking down the process to start with?

If you use it to create something, it's what are these steps that are going into it? If you're not sure of that, what steps does it create for you? Do you have benchmarks to compare it to? Because yeah, it can easily become expensive. It becomes some over reliant. The other thing too is that I'm curious about studies that, will come out on this in the future, is learning retention and really human brains are very powerful, very creative.

They're very efficient. Is that if... Are we, hopefully we- we're not losing memory and skills to do something because those, you know, those are what these models are training on is these are how people are doing things. And these are the steps they follow. They're breaking down.

It's just replica- it's just pattern matching and prediction. So you want to understand how something works before and then AI can save time in the future. Things that are redundant, things that take a lot of time. When you have to fix something that, let's say someone else created or you created, even if you created it is having those skills to fix that, and that's often really done the hard way by being the person to build it, because that's how you ultimately understand how things work.

And sometimes you don't need to understand how something is built. But, for finance models there's a lot of risk that companies take on in that, right? If something goes wrong, you have to report a mistake. And there's different thresholds for different companies, and when something like that gets reported, as a human has to be, a human is held accountable.

And I think that even if you use AIs, how are you accountable for those n- those numbers that are in a model, those outputs? Because the, there's a lot of potential for things to go wrong in data and for problems to emerge, and the last thing you want to be in is a position where you don't have a way to recognize what they are how they occurred, why we, why they got there.

We're not keeping an eye on the things that we should be keeping an eye on. 

Richie Cotton: Finance example where you've got to report that there's a mistake is really interesting, 'cause it seems like both extremes are really bad. I- if you use AI and you don't know how stuff is built and you don't spot problems, then that's gonna cause you a lot of problems.

You're gonna get someone, a regulator will spot it and you'll get fined. But if you don't use AI, you're missing out on all the produ- productivity gains, all the benefits of using AI. So- Not using it also seems a ban. Is there a sweet spot where you can get the benefits of AI but also not suffer the problems of regulatory non-compliance?

Helen Wall: A thing that's important to point out though, refer to AI now, we're referring it to generative AI models. When I started learning about AI models, it was referring to machine learning models, and yes, there were LLMs, but they were not, it was pre-ChatGPT, o- when OpenAI had, a place where you could access, the model, the g- more general public.

A lot of older AI models have typically produced more stable results. Again, it's a prediction based on past data points making a prediction for new data. When we look at generative AI h- has more powerful field, but also it can be very deceiving because-- and we can look at something, it looks right and it's wrong, and there's no indication as to why.

So what I always think of it as is something that I don't want to do multiple times. So for example if you're adding like alt text to images, it can be super helpful, great way to add accessibility. It really makes a lot of things easier for, improve things for, all audiences, even if they don't necessarily need it.

But these things that feel repetitive that you think you can get a model to do. The other thing is you can use it to try things out or to see see how things compare or what it would build to start with. But again, you want to have a, way to check things.

One thing that's really im- important too is that as these coding tools become more common as you have this citizen developer mindset. And one thing that really I lear- I remember learning early on in my career is a lot of people wanna say actuaries, you can build something, you get to a number, and you assume the number is right.

Developers inherently assume it's wrong until they've proved it right. So you almost want to go, when you're, whenever you're using the more approaches, don't think, "Oh, that sounds easy," or, "That, that's easy now," just, moving past these. How am I going to check it? Do... This is a number that I've been given.

Do I have a way to check this against? I'm going to assume this is wrong, and now I need to pro- but I need to prove it's right. And I think that's something that's really important. And it's not the glamorous part that I think people want to talk about. That's, again, going back to this idea of, mistakes and things that occur is that there is definitely an approach.

And checking things twice almost seems sparse. A lot of people, check numbers, far more ti- far more times than... And then also looking at how it was done before. If, when you have a calculation or a model produce this result last month, checking against this, just Having scenarios over time 

Richie Cotton: Absolutely.

I love that idea of assuming numbers are wrong until you can be sure that they really are right. It's, I guess paranoia is a superpower. I like that. 

Helen Wall: Yes. 

Richie Cotton: Okay. And so this leads to, I think, a larger question around if agents are doing a lot of the work what should humans be doing? I think every sort of discipline is dealing with this.

Do you wanna give us like the answer in the context of like your BI analysts? What should BI analysts be doing now agents are doing a lot of the number crunching? 

Helen Wall: People that aren't, that don't work with code, developers do sometimes just h- sitting down hammering out code all day, but really you're kinda thinking about a lot of things and writing them.

Sometimes not a lot of work gets, done as far as coding. Lines of code are not a good... It's a measure of output, yes, but it's not a measure of outcome, because if you were able to take, 200 lines of code and reduce it to two, then that's, your metrics have gone down, but it's certainly, i- it's likely more efficient.

And also this just idea of the agent produced this, but you don't have to take what it gives you, right? If people are using to produce out- outputs is that going to make, the overhead heavier? Is this something that I'm going to have to remember how it did this, next year?

It's easy to build things and accumulate s- accumulate, models, accumulate data. But sometimes you want to have a way to cut things down or to see how it can merge with other processes checking that things are right. There's a lot of psychology behind it. And if you're working with an agent, it kinda takes the wrong turn.

Think of anyone driving, taking, a map is if you take a wrong turn at some point, you could easily end up really far off course. So how are you getting to, the right location or the correct ending location? In a world where it's easy to make things more complicated, try to make them simpler where possible, right?

You want to have that really clean semantic model, even if it's a lot of work below the surface. Sometimes you have to let go of things you've worked on before. Not all code Even if it's useful now, it's going to be useful next week, next year. There's an element of, letting go of things that are already there, you know deprecating old processes, and often stepping away from the model.

Think about how you would diagram something. How would you would use kind of creativity to work with things. Again, using new tools that you can integrate, right? I certainly didn't imagine that I would get really into mapping data when I started with Power BI, but I found it useful to be able to do stuff that I wanted to do.

Richie Cotton: Nice. Yeah, and I love these kind of finding new areas where you're like, "Oh, this is amazing. I've not tried this before," and it turns out to be a lot of fun. And yeah definitely playing around with maps is is one of the, the joys of analysis, I think. Okay. Just to wrap up I always want more people to learn from, so whose work are you most excited about right now?

Helen Wall: I think that, I've followed, the people that are working with maps certainly people that worked with visuals, developers of p- different Python and R packages. I can, I can add links to to some of these people. I just don't want to, mispronounce or any of their names.

But I think that any-- that look at people that are building things, right? And there's kind of two there's different groups of people if you're-- are-- if you're referring to, people to follow on LinkedIn, is that there are people that are, building things like packages, and then you have, people on more of a sales side or a marketing pitch.

And so realizing, what work you're doing, if they're working on something you might be interested in trying out. I know that David Neckerbacher has has a product that you can help find like events in cities, which I think is neat for like World Cup stuff right now. So definitely, follow him.

And my friend Lucas Marr works AI for Good Lab, and they do a lot of stuff with natural, like conservation, wildlife, and things like that. Find data that you think is interesting too. The Boston housing prices and the Titanic, certainly have their place, but when you go into projects and companies, how do you get used to data that...

Or get familiar with data that's unfamiliar? Using something that-- where there's a lot of documentation, discussion, there's certainly going to be a lot of preexisting examples, but what data is interesting to you? What data is relevant to your organization or your industry in a way that you can use it to build your own skills and make something that people find interesting too.

When you're working on stuff for your, personal work and for learning, there's not that risk of tipping everything over or sending, like s- making a database or a website go down. You can really learn things and jump in and try things out. So I think it's important to really have that enthusiasm a- and, try to use it in your own work.

And if you're looking for work that can help, if you're already working, how can that help you with what you're working on? And it might be some things are more useful than others. You might think that something is really neat, and it might not necessarily translate to a project you're working on, but it might be useful in the future.

Richie Cotton: Absolutely. Yeah, big fan of working on projects, just finding interesting datasets and trying them out as an important thing for your career. So that AI for Good project, yeah, AI, it's got AI and good in the title. How can it be a bad thing? I love that. So yeah, definitely, yeah, something for people to check out.

And yeah David Knackebockel is is great. I've seen some of his previous work. All right, wonderful. Thank you, Helen, for your time. That was great. 

Helen Wall: Thank you.