This is M code, one of the most powerful and yet least discussed elements of Power BI. We are incredibly fortunate on this forum to have Enterprise DNA Expert @Melissa, who is a world-class expert in this area. 98% of what I know about M code has come from her videos that @jbressan recommends above and also from studying her forum posts, where she often provides detailed breakdowns of her solutions that are mini-master classes on Power Query and M coding.
When I asked her how she learned this, she pointed me to these resources:
but honestly I don’t think any of them are as good a learning resource as her videos and posts. Developing a basic proficiency in M has transformed the way I use Power BI, now relying much more heavily on the data prep and data modeling phases to carry the load in my reports, improving performance and simplifying my DAX. A great example of this is Problem of the Week #4 – in the past, I would have dealt with the granularity mismatch using fairly complex DAX in conjunction with TREATAS to allocate my monthly data down to the daily level, now I just do it straight in Power Query, making the remaining DAX trivial.
As part of our major platform course emphasis this year, @Melissa will be initiating the most comprehensive course series anywhere on Power Query/M. This is a massive, multiyear undertaking but will guide users from the very basics of Power Query through advanced M coding. We anticipate rolling out the first course in this series later this Spring.
So that’s a (very) long answer to your question, but hopefully encourages you and others to begin to delve into this underemphasized but amazing aspect of Power BI. Personally, I find M code programming really enjoyable – there are over 700 separate M functions (more than 5x the number of DAX functions), so much of M coding is what Melissa calls “learn by Googling”– basically figuring out what you want M to do conceptually with your data, and then going on a scavenger hunt to find the function(s) that does that – a very different experience than writing DAX.
– Brian