How Aussie BIM Guru became Automation Expert in AEC? pyRevit Podcast #4

Transcript

I mean, I've got a bad habit of automating everything. Like, you're going to laugh when you see how this works, but it it worked sadly. And sort of realized, oh, like visual programming. I've done this before. This this sort of makes sense.

Actually, that's what used to come up in YouTube when you used to look for my channel. It used to be bum guru. It was just underwear ads. Oh, yeah. I mean, the package manager in Dynamo is a bit of a graveyard these days.

There's so many old abandoned packages. It's a bit sad. Then I was like, whoa, I need to learn that. Steel is one of my favorite things in Pyro. Just the amount of control flow that Python and written programming gives you.

I'm definitely Aussie and I'm representing Australia. So that's the Aussie part. I see the excitement about AI is a reflection of how frustrated everyone is with the state of technology in our industry. They have to give us the clear instructions what they want and then the second one like, okay, actually we're safe. They never do that.

But I mean at the end of the day, programming should be a personal journey for anyone. All right, guys. Today I have very exciting guest today on the show. You already know him. His name is Gavin Crump or you also might know him as Aussie Beam Guru.

Good day, mate. How are you doing? I'm doing well, thanks mate. Um really, really great to be on the show and finally sort of get to catch up again. Um I've been watching what you do with a lot of interest and I can see you're very passionate about similar things to me.

So I really look forward to um sharing our knowledge and our experiences and and also sharing it with your audience. So thanks for having me on board. Yeah, sure man. Likewise. I got to say that when I was starting with YouTube, I was looking to your channel non-stop like just to kind of validate my idea because in beginning I thought like okay there is not enough tutorials on pirate and it was before you started sharing about pyrait.

I thought like okay maybe I should share it but I was always having this like is anybody going to watch this? But then I look at your content because you cover Dynamo Python. So I saw that we are kind of aligned in this case. It gave me a huge motivation boo boost to kind of start. So thanks for that as well and all the content you share as well.

Oh you're welcome. I mean one of the main reasons that I guess I made my channel was I wanted to see more people um get passionate in sharing and teaching. So it means a lot to know that people see my content and take inspiration from from what I've done. And it's a very humble little channel. Like I don't I never really aimed to get a big following.

And I guess comparing to other industries, it's a small following, but for architecture, it's probably a pretty decent one. Um, but yeah, I just wanted to pass it on. Yeah, that's a big one because we were such a niche topic. It's not just architecture or beam, it's like beam, ravit, and then you go even in more specifics like Dynamo, all this stuff. No, you have a huge following for sure.

All right. I thought that I want to ask you like why Aussie Beam Guru? How did you end up with that? What was your like process when you were coming up with the name? It's a good question.

Um, so I guess in the Australian market, Bib Bim is known, but at the time I guess there weren't really any people that were really publicly representing it in a domain like YouTube. Um, there was people like the Revit Kid and Revit Pure Bim Pure now. Um, but there wasn't really anyone that I was aware of that was getting out there in the same capacity. So I thought, well, I'm definitely Aussie and I'm representing Australia, so that's the Aussie part. Um, BIM BIM was an interesting one.

I thought about doing something besides BIM because I always knew BIM has a shelf life, right? It's not going to be the way we do things forever like CAD and you know there's AI, there's all sorts of ways of approaching these problems that we look at. So, but I decided at the time BIM was very much what I was doing. Um, so I thought well it's going to last a little while hopefully and if I need to rebrand later it's okay. Um, and then I guess guru was a just a fun word.

I knew that um even before I went to YouTube, I I was on LinkedIn quite a lot and I had a lot of interactions with people from overseas um and particularly you know mentored a lot of people from India where BIM was really just taking off and I knew that that was a word that would probably resonate with them um sort of like a spiritual guide mentor um and whilst BIM's not a religion per se you know I like the idea of the the wise teacher who um is really just there to to guide you in life and I saw a similar opportunity in my channel for guiding people through the industry and some of those more difficult skill sets that you know were hard for me to learn initially. So I wanted to sort of make an easier journey for them. So it sort of yeah Aussie BIM guru sort of landed and I built my logo in Revit using field regions which yeah and then I just sort of started sitting in front of a camera and eventually people sort of liked what I was doing. Um I used to get like you know five views on a video. One of them was my mom.

So, um, I started I started small for a long time. I think I got a thousand subscribers after a year and a half. So, it, um, it takes a while for it to kick off as you probably, you know, experienced too. Exponential growth. Yeah.

But, but you've definitely, um, come a long way with your channel and and your brand as well. Like, I remember downloading your private toolbar and sort of saying, "Ah, Erik Fritz, who's this?" And then sort of started noticing you in the socials and you've really sort of made a name for yourself, too, which is great. So, yeah. Well done. Yeah.

Yeah. I got I found it really exciting. It started by accident. I mean like at first I thought like I'm going to make some tutorials on this and that and then more questions come in and I I just enjoyed the process. This is the big thing that if you if I would hate the process I would give up.

But I kind of enjoyed like making the videos sharing it and then further further along just more things came along. Actually in the beginning I was considering calling myself something like beam buddy. I was this close to make it but then I decided what if I Google it. Apparently in somewhere in Korea or in Asia, there is a big big Korean group called Beam and they have a popular song buddy. And I saw that as a competition.

I was like, "Okay, if anybody would ever kind of Google Beam Buddy, there's going to be this song with millions of views. It's pointless to like no, I gave up on that." And I'm very glad Erik Fritz is much happier with this than any other things. Personal brands are very powerful and I definitely encourage other people to like consider them because your name becomes your search. Um it does make you very accessible of course suddenly anyone can find you right but um you become more than your name in principle. I was actually um having a laugh because on the note of finding the wrong thing I when I first started doing YouTube there's a an underwear brand in Australia called Aussie Bum Guru and actually that's what used to come up in YouTube when you used to look for my channel.

It used to be Bum Guru. It was just underwear ads. was a very interesting search outcome. But luckily, I've beat them in the SEO now. They don't show up anymore.

So, now everybody looking for their stuff and finding you. They're like, "What the hell is Beam?" Like, "This isn't what I want. I want underwear." I see. That's funny. All right.

Listen, there are so many topics, but I like to start with the kind of the beginning of the programming journey of the guests. So, could you tell us just to the beginning to your first hello world statement also? What language was it? Just let's go there and kind of continue down this path. Yeah.

So, I I guess I sort of broke my programming journey down once and realized that I was sort of programming before I knew I was. So, I used to um hack Super Nintendo ROMs back in the day for fun, which involved breaking into the memory of the ROMs and changing addresses and memory and moving pointers around and doing things like taking doors and pointing them to different rooms to start rearranging maps. And I got really into this game called Super Metroid, which is one of my favorite Super Nintendo games. And um we effectively more or less rewrote the game from the inside out. And a lot of people since then have started making new assets in these old 32-bit ROMs.

Um and I guess at the time it didn't really click, but I was sort of programming already. I was looking at pointers and memory and you know very very like heavy programming concepts, but I was just having so much fun. I didn't think about the fact I was programming. Yeah. How old were you?

Uh so I'm 35. That would have been when I was probably about 15. I was doing that. Um, yeah. So, there there was like a few started with hacking.

Yeah. There was a few middle ground programs that other people built to help. So, there was like an address viewer where you could look at the raw hex hex codes that built the um built the ROM and there was a a tile editor that sort of built the world map for you. So, some of it was visual, some of it was um, you know, using pointers and memory addresses. Um, but I guess the second experience I had was about 2 years later.

I think I was just about to finish high school and I really enjoyed a game called Warcraft 3 um back in the day and it had a really good map editor built in built into it where you could build custom campaigns and it had a had a thing called a trigger editor where you could um program events to trigger on certain scenarios with conditions for actions to happen and it was a very simple concept but you could you could go a long way with it. There was four loops and sort of sort of things that you know Python does naturally um but built for video gaming. So that was sort of where I began. Um but I sort of took a break from there and didn't really connect programming to my career for quite a while. Um I found Dynamo in I think that would have been about 2014 I think I started playing with Dynamo and that was it was just a a huge gap where I just didn't really do programming um for recreation or for or for work for a very long time and then sort of realized oh like visual programming I've done this before.

this this sort of makes sense and sort of really found a new passion for for BIM and using Revit again. Um, which I'd got quite bored of doing manually by that point. So, I'd been using Revit for about four years and you know using Revit manually with no automation. You know, you've probably been there before too, right? It's not fun.

Um, you know, creating a sheet, renaming a sheet, all those steps that you know, just take so much time. When people discover now, they always have this kind of second kind of breath. they start hating kind of Revit so much and then finally find something new, something exciting, especially all this opportunity to automate. This is also for me when I discovered at first I was like ah this looks dumb. Then I start using it.

I'm like okay I'm only going to use this now. Forget about all the rest. The only way I mean I've got a bad habit of automating everything even if it probably doesn't need to be automated just because I know it's still going to be faster than doing it manually. So sometimes people freak out if they're like they want to do a task for two hours and I'm like I'll build you a script. it'll take you an hour to build the script and it'll take you 20 minutes to run the whole process instead of doing it for two hours and I'm like so for about an hour and 20 minutes they're holding their breath just praying that what I'm building that's actually going to work but um it's part of the fun I guess that that's a great way to learn as well I was on the same journey everything I had to automate everything the simplest task I just had to do it with the code and that what helped me learn it a lot faster yeah definitely and I guess um whilst I used Dynamo I was aware of like you know C and also pyRevit at the time and sort of found my way into those like extra layers of programming um as I went and you know just sort of became less abstract in how I approached programming over time which is probably what you found as well.

Did you begin with Dynamo or did you go straight through the Python pathway? Yeah. Yeah, I I began with Dynamo but I was very quick to jump on the kind of Python wagon because the way I started is I started watching some tutorials here and there and then we had this project in the office where we had to um make this computational design of the facade design. There are like lots of panels and they had to follow the curves and it was clear that we had to use Dynamo but nobody in the office knew Dynamo and I just started watching a few tutorials not long ago. I haven't done anything useful yet.

I was just kind of following tutorials and I just kind of started with this massive project in Dynamo. Somehow I made it. I still have no idea how. And along the way I also there was one node that was really really problematic. It was it was taking like 40 minutes to run and I thought well placing 15,000 panels sounds logical.

40 minutes is much faster than I would do manually. So I was happy. Then I noticed one node was so inefficient. I couldn't replace it with anything. I tried many things and I was so desperate.

Eventually I ended up seeing oh there's a Python node but I had no idea how to code anything again. I went to forums copy pasted bunch of stuff back and forth. It wasn't something complicated. It was something about list management. So it was like fine for beginner to kind of figure out.

made my horrible code and I saw like instantly like instead of 40 minutes, it took 40 seconds. Then I was like, "Whoa, I need to learn that. That's something cool." Yeah, I definitely had those moments. I literally um sadly enough actually stood up in my chair in the office and put my fists up when I first developed my first script that actually worked and everyone just looked over and said, "Well, what just happened?" And I'm like, "I think I just figured out the way I'm going to work for a very long time." I just suddenly it just sort of clicked all of a sudden. I was like, "Wait a second." like there's a lot more things I can do now because of this.

Um, once I understood list management, that was one that really made me frustrated when I first learned programming in Dynamo because I'd never really used lists as a concept. Um, when I used to program in in Warcraft, like you you had four loops, but you thought about them as groups of units instead. So, you were usually dealing with like battalions instead of lists. And I just abstractly didn't connect the the logic of what I'd done before. Um and I guess visual programming lists are quite different to like iteration in um in written programming.

So it was hard for me to connect to that. Yeah. You mentioned that when you made your first kind of Dynamo script, you were really exciting. Could you just explain what was the script? What did you do or what kind of problem did you solve with it?

Yeah, I took on a really classic problem um which was automatically numbering room uh doors based on rooms they were um pointing to and from. But uh I took it a few steps further in that I had to figure out when a door belonged to a room even though it swung the other way. Um so I tried to automate that condition. So I ended up having to build a relationship system where rooms knew they were more important than other rooms. So they owned the door in the event that they had the same level of importance as each other.

They went the direction the door swung. But like I made corridors really like unimportant. They were low in the system. self a door swung out into a corridor. It generally belonged to the room.

Um then once I'd wrapped them all up in groups by room, I had to then number them in a circle. So I tried to figure out how to sort them, generate circles by best point through through the points that were generated per room and number them from like the top vector and sort of spin around and pick up all the points. So it was a pretty complicated um first script. I did really challenge myself to begin with and it's it was an awful script. Like I looked back at it and went, "Oh my god, like this is like this could be 30 nodes maybe." Um, but it was something like 350 I think at the time.

Um, and I didn't know how to do things like index and shorthand. So there's a lot of get item at index, get item index, put them all back together. So I was sort of breaking lists apart and putting them back together. And it was very inefficient. But um, through that inefficiency, I guess I learned along the way different ways you could do things.

And and one really good thing I did which I recommend anyone does is I engaged with the forums like really early. So I use Dynamo forums from almost the start. Um because that was a tip someone gave me. They said don't neglect the forums. U make sure you don't just sit staring at a screen getting frustrated because you won't make it if you don't have the support generally in a new language.

So but yeah that's a good advice. I wish I followed that one. I avoided forums. Yeah. Every time I would go on a forum, I would write out all my problem in details and so on and then I would hesitate to send it because I already made the brainstorming and I was like, okay, I'm halfway through the brainstorming.

I might just continue kind of and I switched to Google and continue. And I I was very stubborn learner. I could have learned so much faster if I would just ask like, "Hey guys, how do I do this?" They would somebody would definitely explain me. It's easy. But even in that case, the forums become the forums become this, right?

They become the rubber duck. So by explaining your problem to the forum, you think about your problem. You might find your own solution even if you don't send the thread. So you can sort of use it like a duck debugger um if you have to. I guess that's the fun part of using forums.

Yeah. No, no, no. Forums very useful. I just always kind of I don't know why it's some maybe it's some some kind of ego or I just didn't want it to kind of look like absolute beginner even though I absolutely was. Oh yeah.

I don't know. There's something that always stopped me. I always like to find solution myself. there is I don't know kind of journey to find through solve your own problem. Ego is a hard one in programming, right?

I mean you've got to be vulnerable here and there and know when you're out of your depth and know when you might be wrong with a choice you've made and have to refactor bad code that you produced a year ago. Like I I have to do that all the time where I work like I go back and go whoa like I didn't I I really took a long way around here. I've got to go back and fix this. So, I think being vulnerable and humble um is often one of the first traits I say you need in programming because you're not always going to be right and someone's going to know more than you at some point and you know it's better to get a good exchange out of that. Yeah.

Yeah. I don't think that was the issue because I constantly rewrite my code. I I'm never happy with my code. I can spend like days rewriting the code and then I'm going to look at it. I'm like I should have done it better.

But I also talked with Ashan about this. He says like it never goes away. Yeah. Yeah, it's just kind of thing. It's just the iterative design kind of approach.

Totally. Because an architecture we kind of kind of uh change designs all the time and we are comfortable with that. This is what Ashan also shared that he thinks that what he learned from architecture kind of applies to programming as well because he's very free to kind of rewrite code over and over and over. And yeah, I think that's also very helpful because that's how you also learn some something in kind of when you rewrite you also change something it makes better or worse and you learn and I think learning we we learn to be more abstract over time um where it works better. I found that um as I go back to my code I introduce more abstractions to simplify how someone would read my code whereas the first time I usually write my code it's very raw dirty like lots of comments all over the place cuz I wouldn't remember what I was doing at the time.

Um then I come back and you know put break things down into custom classes and interfaces and things that help me you know code better in time. So I find that's that's part of the iterative process as well. It's like f refining our craft if anything as a as a programmer is so important um to make sure that we're always just improving on ourselves uh as well as just learning new things as well. Yeah, refactoring is definitely important. I also advise to any anybody that when they start they have to get to the end goal as soon as possible.

Doesn't matter how your code looks, doesn't matter how unoptimized it. It just like you have to go from A to B at least kind of get there just to kind of like a proof of concept and then you can start optimizing make it shiny because I also fallen into this trap where I spend days just on the first steps just to realize that I cannot reach the end because it just went too advanced because I had the bad idea from the beginning and I spend in the beginning so much time for nothing. Yeah. So yeah, it definitely helped to just kind of go dirty and quick through everything at once. One really valuable thing the CS50 course taught me was pseudo code.

Um, which is where you just basically write out your code in steps, but you don't actually write the code. You're almost just breaking your process down step by step. And and that helps you make sure that you're probably going to get to the end of your problem or figure out where there's unknown areas that you need to solve first before you go and do the really, you know, the stuff you know is going to work. Um, I found that's really helped me in especially C# where I realized I'm going to need a class or I'm going to need something that I have to build before I even bother doing this in the first place because I don't even have like the objects that I'm going to need to to enable like a form to work or something like that. I found that the pseudo code approach was really valuable.

Um, so I I use that in nearly every tool these days. Like if I'm planning out a set of tools, I'll write the whole thing as pseudo code and then sort of start filling the gaps. And the other thing that I found was really good about pseudo code is you start to recognize where you can use functions and methods in multiple places. So if you spend enough time thinking about the shape of your toolkit, you don't have to, you know, write out the same thing six times. You can start to find those common steps that you're taking in different tools that don't seem connected at first, but once you sort of lay them all out, you go, wait a second, I've done this over here and here and here, and it starts to build sort of the classes and all those methods you're going to need to to run them.

Yeah, I like to do it on paper, like a wireframe. I just write the steps and the way I do this I just rewrite over and over and over from scratch. It might be already like complete but I still rewrite it. It's this is just my thinking process because when I rewrite I come up with this kind of middle steps like I might have an issue between step one and step two. Yeah.

I like to compare it to um rock climbing um when rock climbers begin before their ascent they just stare at the mountain for the first 20 minutes and find their path before they even start. So it's like it's important to just survey what you need before you jump right in because once you're in, you're in, right? You're locked in. You're not getting out till you finish that thing. So better to know how long how long you're in there for.

Um as well, especially in a professional setting where you have to deliver code for a company with a timeline or a deadline. It's hard if you jump in blind and you know 2 minutes could become three hours, could become two weeks, could become a whole year. So it's it's a hard one. Mhm. There's a very big quote from I think it's from Abraham Lincoln that if he was given six hours to chop down a tree, he would spend the first four sharpening the ax.

Yep. Yeah. It's all about this kind of preparation, thinking ahead, and it really helps. Many people neglect it, but that they regret later on for sure. It's fantastic.

All right, so let's get back a little bit to programming. So you started with Dynamo, you started making your tools. How did you end up with Python? Like did you use Dynamo a lot before you kind of started kind of playing with Python or? Yeah.

Yeah. Um I used it quite a lot actually. Probably too long. I've always had a habit of staying too long in a something I'm comfortable with um before I sort of jump out to what I see as like the next step or the next iteration of my programming journey. And I spent about two and a half to three years just using nodes and custom packages by other people before I really said I need to go further.

um there's something missing here or I've got too much dependency. That that's actually what got me into Python. It was just having too much dependency on packages and and the trigger for it was actually my YouTube channel. So I realized eventually that doing tutorials where you use other people's packages is actually quite tricky because they change. So as a result your videos don't age too well sometimes like the node might get deprecated or it might change entirely.

And some of my videos are half half the comments are just oh I tried this and nothing happened. And then it's like, yeah, that node doesn't work that way anymore. Someone's completely changed its behavior, but people are just plugging in wires and not understanding what's going on. So, they just run it and it fails and better better make a comment. So, that sort of got me into at least trying to reduce my dependency where it wasn't necessary.

So, like if a package was like 3 years old in Dynamo, I was like, okay, I'd better get rid of this and figure out which things I actually need from it and then learn how to write this myself. Um, and eventually it got me to the point where I wanted to build my own package. Um, because there was a lot of things that weren't in any of the packages that I saw lots of utility. And I just said, I'm just going to wrap it all up. Some of the things I've built, other people have, but I built it my way or I've just built upon ideas that I've seen and said, I think that it can be a bit more robust or a bit different.

And that led to what I call crumple, my Dynamo package. And a big part of that was focused around uh bulk family editing or processing which was really relevant to my business because I was doing content uh management and editing and production Revit families in bulk. So it sort of lined up with my work at the same time. And the only package that could do that was one called Orchid um which is stored on GitHub and written in C. So all of the code was locked away and not available to me.

And I found the package a bit tricky to use. So I said, you know what, I'm just going to figure out how to do this and break this dependency away. And eventually it led other people to my package as well through the same sort of frustrations with other other dependencies. So that sort of got me into Python. Um I learned from a lot of other people's packages.

Just looking at code is often how I learn. I go, "Oh, that's how that that syntax works or you know how how do I get like an enumeration to work?" Those sort of things. Um I still go back to my own code. I still forget things and learn from myself constantly. Um, but that sort of yeah eventually led me to pyRevit I guess through just knowing that Python naturally leads to pyRevit and in the Revit API.

Uh, just to step back, so when you decided that you want to kind of break away from this dependency and create your packages, what was your Python skill? Did you already know Python? Were you absolute beginner kind of? Yeah, so I probably spent the first three months in very much a beginner space. Um, breaking things generally breaking fast like you said, failing fast.

It's the way to do it. um is the best way to learn. So I took a course from um I think it was a website called data camp at the time and they had a lot of like little mini courses on Python fundamentals and you know things like for loops just general principles. Um but I really probably spent the first two three months mostly just using Python and not really using the Revit API. And if I did have to use the Revit API it was very much through imitating other people's code that I could read and go I don't really know what's happening here but I know if I put this here and I do this here it's going to work.

So um and then eventually realized I had to actually take on the Revit API as its own its own sort of challenge um once I went into space where I found no nodes to reference. Um so I had to learn about classes, methods, properties and the API. Um I hadn't really built classes in Python myself at that point. So the whole concept of classes was still really new to me. Um, but I think the API helped me sort of learn about class structure and inheritance and other principles that I brought back to my own sort of um, Python code in building custom classes, which I know you use like quite a lot in your code in in EF tools, for example.

But um, yeah, that was sort of the Oh, it's a mixture of good and bad. There's so so many things wrong, but yeah. Oh, yeah. Totally. Yeah.

All right. So, you pretty much learn by doing. Yeah. Yeah. Always learn by doing is my take.

The way I see it's very similar to me that you had a problem and you just knew that Python can help you somehow and you just kind of brute force it pretty much. I think that's really the only way I found has ever worked for me. Um just brute forcing my way through finding little bits of tutorials and resources here and there but mostly just mcking around until something works and then suddenly I realize I wait I actually understand what this does and now that part is solved and I can move on to the next thing. And even jumping into C recently, I'm still to some degree learning that way. I'm still having to, you know, muck around a little bit, guess a few things.

We'll talk about AI later probably, but I use a little bit of that now as well. Um, but yeah, back in the Python days, there was like pretty much no AI solution. So, it was just, you know, bend it till it breaks and then figure out why it broke and put it back together and keep bending it. And it just sort of sort of kept going that way until I felt comfortable enough to build my own package and distribute code um through the package manager. and and that was also its own learning journey.

Like it's got its own rules and things you have to follow. Um but yeah, it was sort of just a a process where I just built layer upon layer as I went and sort of fell down occasionally to another layer and realized I did these two layers wrong. So I got to go back down three layers and then build up again. But it's sort of naturally just how I how I learn. Um how about yourself?

Um did you spend long in Python and Dynamo or you went straight to pyRevit or the way it was like so I started with this big project. There was like also massive massive spaghetti code and I just saw right away that RA API can be really useful because I just had like from 40 minutes to 40 seconds. So I knew like well I need it and then from that moment at first I kind of focused more on Dynamo because it was a little bit kind of I guess easier to get started with because I didn't know Python and I didn't have time to just take courses and stuff. So I started kind of using Dynamo and sometimes when I looked I had like 10 different notes and I'm like that shouldn't be that complicated. I should make it simpler.

I started kind of taking this kind of simple data manipulation algorithms and making a Python note. In the beginning, it was just math, right? You take A B C and then you do kind of simple math. A plus B divided by this just to kind of find spaces and stuff. And then over time, I started learning more and more.

Then I was like, oo, I need to do something with parameter. And then I found a video. Somebody showed me how to get parameter, how to set parameter. I'm like, okay. And it's kind of just back and forth between kind of Dynamo and Pyraits.

And I was just kind of trying as you said in the beginning automate everything. This is what helped me a lot that I would just practice practice and you know like little pieces from everywhere I would learn but I missed I neglected on basics so much just to explain it. I didn't know that for loops existed. I only knew about while loops for a while. I don't know how I missed it.

It is just absolutely the stupidest mistake programmer can make. But I literally when I needed to iterate for the list I would create a counter. I would count every iteration in my while loop and I would sort of recreate for loop with a while loop for some reason. When I found out for loops I felt so stupid for so long. The funny thing is I guess you sort of took the journey that the original programmers built because um you know you've probably seen the for loops and C um they have an internalized counter variable.

So if anything you actually probably learned the C loop method to some degree. But I just I didn't this is the only in I remember how bad I was because I was like oh I think I didn't even went through the course properly because every single course will tell you there is a for loop here's how it works and I never heard of it at this point but then yeah I started watching courses I watched I don't know I was just watching basic courses like non-stop like from this guy from that guy from like this university whatever and you know little by little I like watching over and over so I kind of find this little nuggets in between because majority of courses they're the But then there's the little things that everybody accidentally mentions or just something nice and that's where I learned a lot like list comprehensions like you watch many courses you never hear about them but then you see them they're like wow that's amazing because it's like just compresses. I found a good C# course the other day I think it was a Rhino platform and they spend about 20 minutes talking about um delegates and and events and they actually explained it really well and I had went nowhere near delegation and all these concepts before I knew of them. I knew how they worked and it was just such a golden nugget amidst all this generic stuff and I thought, "Oh man, that that's like a course in itself." So, I know what you mean. There's just those little golden nuggets that make them worth watching.

That's exactly the point cuz 80% is always the same sort of but this 20% sometimes it's so important. Definitely. Yeah. Yeah. So, you started with Dynamo, you started making your crumple package with Python and then you said that you started to hate all these dependencies and you discovered Py Ravit.

Could you just kind of take us to the moment where you first heard of Py Ravit and how eventually you got to actually start using it? Yeah. Um, so my my first encounter with pyRevit is probably like a lot of people, it's the patent tool. Everyone finds it through that that patent maker. That's it's a solid tool.

Um, and still is. I still use it for that. But um, I actually had a few people recommend to me here and there, oh, you like Dynamo, you like Python, you should go and do Pyrevet, like this is like the next thing. And I went, yeah, it probably is. And just sort of forgot about it.

And eventually I heard it enough times I'm like, "Okay, I should be going and doing this. Obviously enough people are finding this good." And a guy called um Kai Kaiu um who was in Melbourne at the time and I think he's coming back from from overseas. He he um he used at his company and said, "You've got to use this. This is like the thing to use." And I started looking into it and at that time I was joining the company I work at now, Architectus. Um and I was coming in with really just Dynamo and Python knowledge.

and Dynamo you can make it scale but it's really difficult to make it work at scale in my opinion. Um there's a lot of things you can do because of the package dependencies or uh dependencies backwards and forwards compatibility challenges like not every Dynamo is the same but Dynamo is tied to Revit. So like if you run a script in 2020, it may not work the same way in 2024 or back the other way. Like um like for example today I was I was getting a parameter that should go null if it's missing in an object and instead it gave me an empty string and I'm like and it threw off the whole logic of the script I was trying to build because I assumed it was going to work how it should work. So just little things like that.

Um and then one of my co-workers at the time she she told me do pyRevit just do it and I said okay I'm just going to do it. And um I actually looked at BF tools. That was probably the first custom toolbar um that I look at. Interesting. Because I didn't realize pyRevit's own tools were exposed.

I thought they were they were hidden um in the addin. Um eventually I realized Yeah, you can look at those too, but Oh yeah, that's so huge. Alt click and you see the code there is like what? Yeah. Yeah, the alt click.

It's such a such a tip that people all people need to know, but not everyone does. Um but yeah, look, I looked at your toolbar and um yeah, realized you can do custom extensions and run them. I hadn't quite realized it was that easy um to just structure toolbars using folders and files. It was very straightforward compared to doing it in C because I had tried to learn C and I just didn't find a course that managed to break it down well for me. Um but as soon as I saw your toolbar, it really showed me, okay, like I can do this.

This makes sense. And then I went whoa like I I have to abandon Dynamo now. I have to do everything in Python. I didn't do the whole Dynamo script with a button approach. So I just went nut if I'm doing this in a Python app in Python.

So that was pretty intimidating at first cuz you know all those geometry operations are very different in the API to Dynamo's own geometry engine. Um all possible but all quite different. Um and I guess that that sort of got me in and then I just started building one tool at a time. um started figuring out tools that belong together and stacks and pulld downs and eventually I said, you know what, I should probably just share this with all the users at the company and start releasing this as a as a toolbar to the firm I worked at and it sort of gained its own sort of little following and before I knew it, the whole company was running it. And then eventually we started putting like really big tool kits in there like um printers and room layout sheet generators and it started becoming actually depended on by quite a lot of people.

So it just sort of naturally snowballed over time and I guess I just found a new community in the private forums as well and all the interesting people that that work on the program and it sort of gave me like a second community to enjoy being a part of. So um yeah, it was a really interesting experience and I'm glad I found it. But I guess yeah, thank you for for making your toolbar I guess um available because it was a great learning result for me. Yeah, I didn't know that I created e tools before you. I thought you already also doing something in pyit.

No, no, no. I think you you were well before me. Um I think when did you start EF Tools? It would have been like what about 5 years ago? Oh man, I think in 2019.

Yeah. So about years No, six years. No, no, no, no, no, no. I started it but I released it I think in 21 man I don't remember what is it 25 probably 21. I remember it was September.

I don't remember exactly but I remember I thought like I'm going to spend a month take my best tools I made for the company and released as EF tools. It took me like seven, eight months to rewrite a lot of stuff because my first code they were like horrible and I wanted to make them somewhat decent. Yeah. I mean I rewrote them I now if I look at them I would still consider all of them horrible. I need to rewrite again.

They're great. But at the time I was like okay they're useful. I share it and let's see what happens. And it went pretty good. Yeah.

I also remember looking at your tools and going wow you take your commenting and um your your name spaces very seriously with all the ASI sort of art that you make for all the import names. pretty cool. Uh you see when I was a beginner I had this issue looking at my code. I tried to make it very kind of I like when things are very nice to look at because then it's easier to read and so on and I tried so many things. I tried like dashes equal signs making this separated this and that and then accidentally I found out that I can use asi art.

I was like oh I want to use that. I haven't seen anyone use it. I don't recommend anyone to use it. I don't many programmers probably cringe when they see this but I love it especially for tutorials. It makes it so much nicer to kind of make these blocks.

All the um all the game fact guides back in the day used to have a big asy art at the top of all the facts that they write. So it reminded me of that. Now it's sort of my like my signature when I see like newcomers start using these comments. I know definitely where they got this tip from because majority of people would never recommend anything. They just say like don't even use too many comments.

Name everything proper. You know people try to go the opposite. Just be minimalistic. Oh no no no. I don't I don't believe in self- authoring authoring code.

the self- commenting code as they call it where the comments are meant to not be there and your code's meant to be so obvious that someone can understand that it's just it's it's a nice idea but I haven't reached it yet. Yeah, I I know what you mean. Sometimes it makes sense on smaller examples on bigger ones. I just like the comment even if my function name and the description they kind of mean the same. I still like to have it just for consistency, you know.

Yeah, I was going to say I might just take a quick break. I just need to turn my air conditioner on. It's a bit it's a bit hot here as you can see. Hi, real quick. If you into Pyravit and you want to boost your skills in record time, then check learn rateapi.com platform.

You'll find free in-depth courses for any stage of your programming journey. You'll get access to pyrait basics pro and modern UI courses. Plus, you'll also get access to my code library and join my exclusive community for pyRevit developers. In the community, we can chat, discuss programming in Ravit, and most importantly, you can ask for help when you need it the most. If that sounds interesting, go to learnra ready.com to learn more.

And now back to so let's get back on track. You were saying about your pyate story and it actually remind me a lot of mine. I had very similar I also started with Dynamo was playing a little bit with Python nodes and then one of the colleague was like you should try pyate you should try parate. I was like yeah I looked at it I was like I didn't understand it like you. I was just like yeah it looks cool but probably complicated or there's there was this kind of barrier that that was non-existent but I made it myself.

And then he was like saying over and over, ah, you you will love it. You will love it. I was like, okay, I need to look into this. And then it was like so weird. I started looking at it.

I'm like, okay, I tried to prove kind of find a reason not to use it. I was like, probably it's hard to make. Then I see you make folder structure. You have your extension. I'm like, no way.

That's too simple. What the hell? Then like as you mentioned like out click, you get access to hundreds of available open source tools. I'm like what the hell is going on? Why is it like it doesn't make any sense to me.

like it's free, it's open source, there is community behind there are like tons of examples creating extension it was is still crazy to me you just make folder structure it makes it and like and since then I was like okay I need to actually dive into that and I was similar to yours I'm like okay I'm going to go full python why not it was a bit bumpy road because in the beginning there wasn't as many resources the python and pirate side was fine the problem was like ravit API and making it work because many examples in C and back and forth so yeah but once you nail the basics it actually starts to become so much fun because you start automating non-stop. Yeah, remember even just um the amount of tools that pyRevit gives you as a programmer. Um some things I was using and I didn't realize they weren't the Revit API, they were part of Py Reevit like Asan had built them. Um like some of the collectors and like the forms library, oh my gosh, the forms library so good. Like having RPW UI and his forms that he's built already was just amazing.

like cuz in Dynamo we used to have to use this package called data shapes to build um better user interfaces like staged interfaces versus Dynamo player and um that was the main reason I was hesitant to to leave Dynamo because I was like well I've got interface creation there and as soon as I found those those forms that were in there like I was like wow like this is this ships with the addin we don't have to install the dependency on top of pyRevit it's already there it was pretty powerful and the thing that really sold pyRevit to me and is still one of my favorite things about it is script.exit. Just being able to stop a script wherever you want. If if you hit a cancel point, you don't have to run the rest of the script through like Dynamo where you have to just null the whole script to the end. Um it was really cool to just have the ability to sort of gain that control flow um in tools that I guess I hadn't experienced in visual programming. So that that was like still it still is one of my favorite things in part of it.

Just that the amount of control flow that Python and written programming gives you. I think in Dynamo there was some note to stop execution like you say but I don't know there was something wrong with it but it kind of worked. I don't remember exactly. I just remember I had this need as well but I gave up on that for some reason. I think the main issue with stopping a Dynamo script would be race conditions.

Um because if you put like the terminating node on a different branch I wonder what would happen if like the other one's racing with it to to converge at like another node later. Like I wonder if that would work. So, my guess is they must intercept the idling event that Dynamo depends on or somehow um stop it, but yeah, it sounds interesting. I never came across it, but um it would definitely have been a useful tool in um in Dynamo for sure. I'm not sure how well it worked because I remember I gave up on that really quick, but I remember I found something.

It kind of became red or it was a while ago. I'm not much into Dynamo. I barely remember anything now. I'm so in pirate now. Oh, yeah.

I mean, the package manager in Dynamo is a bit of a graveyard these days. There's so many old abandoned packages. It's a bit sad. Like there's some really good package managers still around, but like for every good package, there's like a hundred bad ones stuck in the same list as like this one. Whereas like obviously switching to a GitHub style approach with CLI and saying I'll just pull the extensions that I want um was a really good change for me as well because in Dynamo it's it's so hard to find what the good quality packages are.

Whereas usually in pyRevit, the more information on the GitHub, the better the packages generally because they've put effort into it. So it's obviously a good thing. So um like there's still packages on the Dynamo package manager called test that people have uploaded like six years ago and they're still sitting there and it's like it's crazy. But Pyre was a big change in that regard too. I think the biggest issue is that the biggest kind of Dynamo users they a little bit outgrown the Dynamo.

They went to py ravit car you know they started looking for the next step because they they have like the most advanced dynamo users there's still many advanced users especially when it comes to 3D geometry and kind of this maybe a little bit gener generative design but many people kind of still started using at least on the side par so this also took a lot of kind of champions away yeah shout out to um Kum Karum Baky there have you I don't know if you met Karum Karum Baky before He he builds a synthesized tool kit and a few other tools like that. He's um he's doing crazy stuff with Dynamo geometry. He's basically built his own little mini engines of geometry inside the program. So there's still like a lot of amazing people in the Dynamo community and you know people like John Pearson that have supported and and made it such a fun program to use from a community perspective. But yeah, you're right.

it does eventually you sort of outgrow parts of the program I guess eventually and once you want more control over your application and you don't want to depend on the whole platform to run your code and eventually down the line you get into C# and you want to protect your code as well which is like another another challenge like Dynamo and Pyro to some degree um that you know that's the final frontier how can I stop another company from just taking my code and running it on their side yeah no yeah that's a selling point for C#. All right, we're going to get to C and AI later on. I think now you prepare that demo for us. You want you mentioned that you want to show us how you use P at scale. I think now is the good timing to jump into that.

Sure. Yeah. Now, now that we know how you learned Pybit, let's see what you made with it. Yeah. So, I guess for full context, this is technically the toolbar that I guess we distributed around our company.

Um, and it still sits on a majority of the computers in the company right now. um until about two weeks from now when when my C# tool automatically deletes it sadly. Um but um yeah, we ran it for the better part of a year and probably 3/4 year and 3/4 roughly two years um on pretty much all company machines. Can you show the screen? Yeah, I'll share my screen too.

I was just a bit of context. Um so you mentioned that you're going to run the C# code to delete your pirate extension. What was that? literally a tool inside my toolbar that's just going to gobble up the um extension folder um once my toolbar finds it sadly. Um but I guess this is this will distract.

Yeah. Tool leading tools. So this is the toolbar here. Um I called it pyarch. So like pyRevit for architectus.

Um and each of the tools eventually sort of became like stacks or pull downs stacked pull downs. And and I still very much subscribe to this way of arranging tools for the most part. and they also sort of joined together by function. Um, but I mean the first tool I built was uprev sheets. It's a very traditional tool that I learned to build in most programming languages.

And immediately you know that there's a a form that is given to me by pyRevit to pick a revision. Like cool, didn't even have to write it. Pick a revision, pick a sheet. And this is all built in pyRevit as well. So you've got sheet sets and filters and all sorts of good stuff.

And then I found a progress bar in pyit too. So um it definitely spoiled me like all those forms in that process were just provided by pyRevit. So I think that particular tool I'm just using PyCharm at the moment just was an IDE that I used to use. And I think this tool's got a little bit more stuff going on. But in terms of identifying like what what the tool was doing, there's a select revision form that's built into pyRevit.

If there's no revision selected, exit the script. So that's that sort of script exit thing that I really like using. Um, and then picking sheets to uprev script exit. Um, this is a fun little thing I figured out I needed to start doing in Python. Um, and in in pyRevit and I still have to do it in C.

And that's actually editable elements. So when you're building in Dynamo, you have the luxury of often running in like test models and you don't realize that, you know, most of the time your tool's not going to be able to run because it's going to have permission errors with trying to check things out. And this disc function effectively just tries to check all the elements and only keep the ones that it can. And it gives you like a little dialogue that says, you know, would you like to keep um what you can or would you like to stop the script at this point? And then we head into the progress bar, which is again a pirate pyroit feature.

Um and then I'm using like with transactions. So again just a pyit feature. This is like the context manager that I think pyit naturally abstracts for us. Um, and then yeah, formatting a message at the end. But the first version of this tool didn't look anything like this.

It was like something like 250 lines and much less efficient. Um, now it's like I think 80 84 lines including comments. Um, but that was sort of like my first tool that you know really got me into pyRevit. Um, and then there was more aggressive tools like the Nuke tool which is sort of like the eans. So that just, you know, launch Nuke, bang, and it just strips out the model.

So you're doing pretty powerful and quick stuff with um pyRevit. Like this has just stripped out all the sheets and views and whatnot. Um another really cool feature I like is um you can pro provide context to tools. That was something I learned pretty early on as well to stop tools running unless their conditions are met before you run them. So like um Oh, you mean like contextual this?

Yeah, like context. So I think if I go to like create work sets for example um it can only run in like a workshared model which is a feature that pyRevit um provides as well which in C is called avail availability. Um so I learned about you know bundle files and hooking up like wiki links to tools so that people can F1 to all the tools and it was just such a a great toolkit um that naturally sort of just lent itself to to large company setup. Um, and then I guess eventually we got to more custom complex tool kits like bulk printing. I think there's no sheets so I don't know if we'll be able to print.

I might need to go to another model with some sheets. What did you use for printing sheets? Uh, so this one actually we used to use XREV um, which is an Australian company that they're probably one of the most well-known batch printers. And then eventually I realized I can just get PDF24 as a print driver onto everyone's computer. And then I figured out if I overrided a couple of settings um in the settings to just say always print to this folder with a wild card and always print file name, I could actually get Revit to send prints through to a set folder.

Um so eventually we just built a toolkit that could could batch print and um you know you can do A1 A3 I'll just do the R rim layout sheet for example. Naming rules we built a naming rule system behind the scenes. Um, I can do of revision from a list of drawing sets, pick the sheets. And my question was more about the engine because I was wondering if I'm going to see PDF24 that open source tools mainly use for printing PDFs. Yeah.

Yeah. These days surprisingly doesn't Yeah. These these days I use the inbuilt driver for Revit where I can. Um like the for example the toolkit has evolved to give users the option of using print drivers or using the inbuilt um print print driver in Revit because they all have their challenges. But um I mean that immediately was like a selling point because we could just cut XR out of our cost um and just manage it ourselves.

Um and we could do things like building the company standard naming rule which is just like pretty much the only naming rule you have by default. Um, but with that there was like obviously complexities that came with like having to build like very strict string formatting for naming rule systems and educating people how to build their own naming rules out of like little strings and separators and you know characters that indicate a project parameter or a sheet parameter. Um since this we've we've built like more complex tools using C and forms. Um but we could have pushed this like harder um if we wanted to but as you can see it's a lot this forms that you show is it RPV flex form or that is yeah so that one I believe if I look for it cuz one thing I I learned to do in pyRevit was start to build libraries of utilities and sort of use them across multiple tools um which Dynamo sort of does in packages but not really. So um oh yeah that's a big one.

I think in this case it's probably in the export utils. So somewhere in here there's an RPW form. I think it's fair way down. Yeah, it's one of these. So like a flex form I think I was using in this case.

So um yeah, I was just building options out of there and checking if the form ran and um yeah, pretty much going from there. I was I was very flexible with return types. So like one thing I've learned since coming into C is that return types can be a bit more tricky in other languages whereas in Python they're like super flexible. So I was doing things like sending out like four booleans as a return type from a function which is like very unorthodox like usually you'd probably like make a class to hold the settings or something like that. Um but yeah these libraries of functions so that was that was pretty handy.

I think in the end of the day it's just personal preference. Oh yeah I've moved on programming now like most of my things are static classes. Um but back back in the day I like to use just just institute functions. Um, and I did like that you could like just import like a namespace from the library folder. That was really handy as well.

So I can just say like from pyRevit import and then reference the or import um everything from export utils. So if I go to the printing the printing code which I don't mind showing because it's changed a lot since the tool. Um, I liked that it let me abstract my code to make it simpler. But at the same time, I could just like I could very specifically import particular functions to save time or I could just import like a whole library. Like this one deals with reading Excel files for example.

I think this is actually my printer. My printer is down here. Reusing code helps so much. I missed it for quite a quite a while. Once I discovered it, I'm like that I need to start reusing my code.

Yeah. Yeah, definitely. printer is 66 lines of code including comments. So fairly concise, but behind the scenes obviously a lot more a lot more utility functions that are holding it all together. Like I mean my printing library is about yeah 750 lines of code including comments but um yeah it really helped me to be able to put these together and I think I was just starting to play with WPF right before I jumped into C#.

So that was me just starting with WPF and then eventually I sort of jumped over. Um, but yeah, it was really it was really fun just just being able to build such a wide variety of tools and utilities and there's more like fun ones that use like linkify like I don't know if there's any images in this link are huge. Might be. Yeah. So I was starting to use this like output or the console window as well.

So I think I'm just trying to find groups. I think I can probably find groups. There we go. So I used linkify quite a lot um just to output certain types of thing. These are all like the instances of groups in the model.

Um, for people that haven't seen it before, like I can select a detail group, but I can also go to its view, which is pretty powerful. So, I've just found that detail group. Um, but one of the fun things is that Linkify gets blocked by it security um, in some companies, and unfortunately, one of those was the one I work at. So, we couldn't actually take full advantage of Linkify. Um, but it still was a valuable report with IDs and things we can reference.

Um, but yeah, obviously if I showed you every call, we'd be here for probably a while. Um, yeah. Yeah, it's just kind of to it's nice to see that there are so many different tools, so many different problems you solved. Could you just share how do you kind of where do we start? I want to find out two things.

First one is what is your kind of coding process? Let's say you have an idea and just you don't have to code anything. It's just kind of general explain. And second question is probably the deployment. How did you share it with the team?

So, which one you want to jump into first? Um, probably coding style is a good place to begin. I mean, I can even just emulate the way that I commonly begin a piece of code. Um, I guess like anything, everything begins as a script and a folder. So, generally new folder or directory.

Um, you know, I'll usually have a name for it and it's not too big of a deal what you call it a bundle file. You know, test, you know, push button. I might think about the structure of the tool. Is it a pull down a stack? Is it going to have to sit in a certain way?

But from there, you're pretty much in pyRevit. You're in. You just have a script. py and this is where you actually create it always from scratch or you just copy existing tools. Um, a lot of copying.

Like I I would reuse a lot of utilities from like other scripts. So I usually have starter scripts that I often like to use. So this was like usually at the very least this is like the boiler plate for a lot of scripts. It would it would usually have like at least the pyRevit imports at the start. So the four pillars I depend on are Revit, DB, forms, and script.

Um they cover a majority of what I used to use. Um and then this was a little like function that like logs the um the run of the script. So I didn't really use telemetry. I preferred to run off a different approach. So this one was just actually writing files to a a server location.

It was much more straightforward. Um but it took kind of logging manually. Yeah, it was pretty dumb, but it got the job done. Um but I guess from there I'd be using pseudo code. So let's say I want to build a tool that's going to like let me select all revisions in the project and delete them.

So I'd begin by saying you know show list to user revisions. And I used to usually say okay what do we have now? We have like list of revisions and then I'd say okay um check if revs in use uh show revenues to users. So you'd like warn them okay the revisions can't just be deleted. You're going to like merge them with other revisions and you know finally delete revisions.

And this would be like my pseudo code. Um, and then I'd start going back through and actually starting to replace things. So, you know, it's actually been a while since I've written in Python. So, um, I'm trying to sort of even remember the syntax that I used to use cuz one thing I didn't have stub set up at the moment. So, I can't actually get like IntelliSense on this computer.

So, like this is where I'd literally be going to like other tools and going have to code it. It's just kind of the kind of the process more like brainstorming. What do you think about where you focus? It's more like this. I wonder if there is something that one thing I did sometimes is I'd talk to someone else about my tool and make sure that what I was building was actually useful.

Um which is something a lot of um programmers don't do at their companies as often as they should. Um to say wait if I build this thing is anyone actually going to use it? Um like usually it should be built because someone asked for it. But then you've also got to go wait am I solving like a big problem or am I solving a really small problem for one person? So it's like sort of going through that process of like sanity checking yourself is like so important as well.

Like there are some tools in this toolbar that I can say got ran like once like feasy feasibility toolkit. Three people in the company used it out of 350 Revit users. It's like it didn't make it through to C# put it that way. Um whereas like this tool got like you know thousands of runs a week just printing. Um as sad as it is room layout sheets we have a health sector um that depends on this toolkit now.

So like some of them were complete pillars of like justification for the toolkit and other ones were me sort of getting too excited and building toolkits because I could and then going wait a second like does anyone actually want to use this like so generally I recommend like building the prototype putting that in someone else's hands and saying do you reckon this is going to help you if I keep pushing it and you'll probably find that sometimes they'll just say no actually I don't need this and you'll probably save yourself a lot of time and your company a lot of money um but yeah most of these responded needs but not all of them. Um, and also the structure of your toolbar is so crucial as well because you might run out of room eventually, right? Um, so I found that it's where EF tools right now. I found real estate was so important like even the length of names of things like try to bury the length inside the pull down where it doesn't push the toolbar out. Even in G whiz like this is my little C# toolbar I'm building outside work for fun um because I can't show the actual toolbar at work which looks a lot more like this.

Um, just keeping things small, lean, navigable. Um, use pull downs and split buttons wherever you can. Um, try not to use too many button buttons. But, but that was sort of just like the I guess how I started off my tools. Um, I have a lot of trick question.

Yeah, sure. Yeah. Have you ever created tools that already exist in Ravit natively? Uh, sort of. Yeah.

So, there are some that like that they're pretty much the same thing. Like I made um super select everything of the same category or type and I think of same type already exists. Um and I I didn't realize you can select more than one thing at once and select all an entire project or visible in view. I it's only in 2023 or 2024 they added it. Um so I didn't even notice and I actually ended up building a tool that basically just does that and I was like oh okay.

Um, so I thought it was like really cool and then I just tried it out of curiosity and I was like, "Oh no, it already exists." Um, but funnily enough, sometimes people don't realize a feature exists until you build a tool that makes it more obvious. For example, like at work in my new toolbar, there's a dark mode and everyone's like, "Wa, dark mode?" Like, "I can't believe there's dark mode in Revit." And they're in Revit 2025 and I'm like, "This was in 2024. This isn't new." Um, you actually made your own dark mode. Yeah. So, this one, you can't see it in here because this is C, but um if you're in 2024 or higher, there will be a tool for dark mode there as well.

Um so, it's all it does is just toggles the UI um that Revit does normally, but because dark mode is like buried under file options, uh graphics, I think it's under colors, there's like another section they've added here. There is a button somewhere. Yeah. Users just don't know it exists. Um because often our Revit users, they're not like die hard Revit fans.

So they're not checking like the new features every day. Some people just use they have to, right? So So sometimes tools can help expose those opportunities more more natively to people as well. Um I think technically like this tool, yeah, I I'm a huge fan of dark modes, but Rav dark mode is just like yeah, it's the only software I stay with the light theme because dark is just makes it worse and reminds me on autocat for some reason. I think the main problem with dark mode, and I've told Autodesk this a few times, is every time you open a secondary menu, you get like a flashbang.

It's like dark to light, dark, terrible. It's like it's impossible to work that way. Like, cuz you just get blinded every time anything opens. Um, I mean, some tools are like really simple. Like, some are stupidly simple, like just boot up the internet, um, boot up Revit API docs, and they're not like hard tools, but like sometimes these little shortcuts just Hey, little little promo for you.

Um, but I guess even those things, they just make things that little bit more obvious to people. Like a button that takes you home to the home screen because people don't even know that Revit has a home screen in a model. Um, they just made the way that Revit behaves more obvious to to users. Um, some tools I even hijacked. Um, like I used to have a settings button that took you to the pyRevit settings and it was just a copy of pyRevit settings and you know, oh look, make pattern I've put the patent tool inside our toolkit.

Um, so I didn't write any of that. I just copied it. Um, sorry. Um, yeah, it was good fun. Um, but yeah, sometimes there are tools that like probably don't need to exist that get created occasionally by accident.

Um, but but at the same time too, sometimes the good thing about writing your own tools is you can make that them that little bit better than other ones. Like for example, purging views not on sheets. Um, so this is like a very common task that people do. Um, but the problem is that a lot of add-ins out there don't think about view dependency. So, if I delete this view, what other views will get deleted with it?

Um, and a really common problem. Oh, you mean like dependent views? Yeah. So, like if you have like a master view and three dependents, some add-ins actually give you the master as a deletion candidate, which is really bad. Or there might be a call out depending on a call out on a call out.

Um, so this tool we built actually exhausts all those relationships and says I'm going to check like and and as you can see it's not going to offer this view because it knows there's like three dependent views. Um, and that can be quite tricky to do with callout relationships but um it help it it helped us you know better understand what some tools don't do well for us as well cuz when you have those programmers in house they can look at these tools and go whoa like that's not right or this could be better. Um, so yeah it was just a a good fun opportunity that came with it. Oh quite impressive toolbar. Oh, thank you.

And how did you manage deployment and how big was how big is the team that you're working on? Sure. It sounds like a big office, right? Yeah. So, we have um about 700 people in the whole company.

Um and then we have about 350 of those are regularly jumping in Revit and probably I estimate about another 50 will, you know, open Revit on like an off day. Um so, it's quite a lot of people um spread across I think it's 12 12 studios I'm pretty sure that we were getting out to. And I'm I'm fortunate to have an IT department that is quite quite flexible and quite willing to work with us to figure out what we can do. Um, but I'm also very fortunate to work on a team of about 22 I think it's 22 of us at the moment that all specialize in digital and BIM. And some of us belong to sectors.

Some of us work together on computation and application development or web development. So I had a few people on my team that weren't necessarily building it with me but understood what I was doing which really helped in terms of deployment. Um I looked into CLI and some of those more automated approaches and realized that getting something like that to work in a large company with security barriers and um not being able to get the whole company the work off GitHub especially if it's a private GitHub because we can't share the toolbar. Um that sort of made CLI not really a feasible solution for us. um at least initially.

I'm sure there's probably ways we could have made it work, but it was a lot. Um so what I ended up doing is just saying the goal that we want to aim for here is we want to end up with this folder with my panel.extension in it in this this location on every computer uses your username at data roaming pyarch for people that know it app data percentage percentage. Um and that was our deployment location to get it locally on all computers. And then from there we have the um pyro config.in any and we were effectively pushing this out um without the clone. But in this case, we just put a wild card in here and pass the extension through.

So all we had to do was really just do like a a robo copy in principle. So we had like an installer through an application called Intune uh that would run when a computer boots up and just get the a copy of Pyarch onto the computers when we wanted it to to be there. Um, but eventually I realized that sometimes I'd be on a call with someone and there's a bug and I'd go, "Wouldn't it be great if I could just literally get a bug fixed to them like almost straight away." Um, so I ended up building this like hacky installer called update to latest. And this thing is like this thing is a total hack. Like you're going to laugh when you see how this works, but it it worked sadly.

Um, and this let me get updates to people like whenever I wanted to. So I think it's here. Um, all this thing did was download a zipped copy of my toolbar off of our SharePoint. So, obviously you can only access the SharePoint if you're in the company. So, that helps sort of secure it.

Um, and then it goes through steps. So, firstly, it downloads the zip. It I use a I think a loop to just wait um eventually to I think I I count and I use a while loop and I just basically wait until that zip has shown up in the downloads folder. Once it has, I unzip the zip and then I delete the old pierarch from the location it should be in. And then I just copy the panel.extension over the top.

And pyrovate extensions have this really cool behavior where as long as this has been loaded into Revit, um, if you delete the whole toolbar files and put them all back in the same place, it's going to still know where to find the scripts and it's not going to break. So I literally could like go and update that SharePoint.zip it um in in the middle of a call with someone and just say hit the update to latest button and I've just fixed your bug in the same call. So it was pretty pretty rapid in terms of how we could get this out. Um obviously not very secure. That was probably the main drawback to to having I guess such an open toolbar.

Um I don't know if anyone's taken my toolbar outside the company. I'm sure they've probably tried here and there. There's a few security measures built into it. They're very very subtle. Um but yeah, that was probably the main drawback.

But being able to give people updates like that quickly um was obviously a pretty amazing experience that you know pyRevit enabled us to do. Mhm. Sounds to me that py CLI could work eventually. Maybe not with the GitHub but with something like Big Bucket. I'm not exactly sure but as I understood Big Bucket is more enterprise oriented with more security features.

I might be wrong about that. Never use big Bitbucket. M but I think just the idea of the git for the code it would make updating much faster than because you would have an option to just update one file instead of the whole thing. Totally. I mean doing a comparison yeah would be faster.

Yeah I guess um I sort of looked at CLI and I sort of tried to appreciate that it wasn't really trying to be a closed solution as well. So I didn't want to use pyRevit in a way that was against the spirit of pyRevit as well. So, I didn't really want to come and bother um you know the community and say, "Hey, can you like make this enclosed way of using the toolbarss and I didn't want to make that like against the way that the community develops." So, I sort of said, "Well, I've got to solve this on my own two feet. If I want to use it for my own company purposes, I should I should figure this out myself." And that was sort of my my middle ground that I used at the time. Um I guess the thing too is I was donating to pyRevit um through um Patreon at the time and that was probably about as much as I could really do to support pyRevit.

So, I didn't want to put any extra pressure on the community to to modify the way that, you know, such a fantastic toolbar was already functioning. Um, because I know that they were going through the 2025 migration at the time, which as you know has been, you know, really big amount of work for them. Um, I think they've just just got the the final installer out, which is great. So, I think I'm actually running the latest actually. This is the latest pyit.

I've just hidden all the tools, but yeah. Yeah. There you go. Enough team. We made it compatible with 2025 half year before they released it cuz they wanted to like fix all the little things here and there before release.

I think that's what many people started kind of looking at pyit a little bit. Oh, we need to wait for the update. Yeah, that that's honestly that is one of the reasons we moved away from using pyroate at the company because I guess it just signified to us that again we we had gained a dependency. Um a brilliant tool and a brilliant toolkit and with the right amount of work and trust and and collaboration it will keep going into the future comfortably but there was like a year roughly a year of downtime I think on the installer. So, um, we actually figured out how to modify some of the pyrovit files to get it to work in 25 for us.

Um, because we didn't really use any of the actual pyRevit tools. So, we didn't have to worry about some of these tools breaking. So, we we actually just figured out there was a few variables in some of the um the loader files. That was the main issue I think they had at first and we fixed those internally. I did go on GitHub and say, "Hey, this if you do this, it it works." But there was all sorts of other problems that that change causes for the tools in pyit itself.

So that was sort of our work in the short term. We we installed the whip version and then we ran like a small script that modified some of the the internal files of pyRevit to to to keep working. So we had 2025 working about probably oh probably probably about seven eight months ago. Um but obviously pyit itself was still being developed at that time. So we appreciated that was our solution.

Yeah. All right. And eventually as you mentioned you moved away from parit to C# and where you are right now are you completely abandoning paravit? Are you going full speed on the C# where you are? Yeah good question.

So I guess um yeah we we more or less put it down for now. Um I'd pick it back up again if enough people in the company were really keen to collaborate in that language because I think Python is a really friendly language to work in. C is a little bit more um applicationorientated. there's a few more things you have to learn in order to make it work and and I think that class orientated programming is harder to begin with. So not everyone naturally finds C sort of I guess aligns with how they want to learn.

Um so that will probably be why I'd pick this up. But for now we are sort of putting this on the shelf. Um and there is effectively a whole new C# set of tools with like additions and changes and features. So, I literally had to sit down and from the ground up, I figured out how to build all the little bits and pieces that pyRevit had spoiled me with um over all those years. And some of them I built outside the company.

Like the real core of my C# tools I've actually just built outside and just called it G Whiz. And this is sort of like a a C project that's on GitHub. Um that literally just has like utilities and extension classes and all sorts of like cool functions. It has forms. So like I've built up some windforms.

So like I have I have like a list view like Pyroet has a list view. Um and I sort of just figured out over time how to build these things are still loading but it it looks very similar to Pyroit's list view if a little bit more more basic. And how long did it take to rewrite it? Because there are so many tools and files you have also the libraries. So some of it was easy.

So some tools were like very modular in how I wrote them originally. Like they were almost like a toolkit of things that work together. Um other things took longer. So I think I spent the better part of like 3 months of not quite full time but probably like half time um doing it. So about a month and a half of resourced time and that was sort of me learning so sharp at the same time as well.

Um I did some of this outside work just to lighten the load at work but also to make sure that I could actually share at least the core utilities that were like building this sort of framework cuz I knew I wanted to teach people on YouTube as well. So um luckily my contractors you know got a bit of flexibility built into it. I'm I'm sort of allowed to do what I want on my own tools as long as it doesn't, you know, obviously conflict with company interests and and and IP and values. So, in this case, I brought like some of these core utilities in house. So, I had to build like some things again, like for example um checking if the shift key is held down so that I could build my own sort of secondary fire modes like um Pyrevet does.

Um and then some of the forms I had to figure out how to build like a progress bar for example. That was really fun. Yeah, I saw your post recently on LinkedIn where you discovered something about progress bars. Um, obviously like C# lets you be a lot cleaner with how you lay out your code. So I use regions a lot.

Um, but like there were similar things in there. I use a lot of classes and custom classes and um, I might just show some of them in action. Like the up rev tool is just here as well. Bulk revision picker revision pick sheets. So, it's very similar in terms of like the general behaviors that I I've I've experimented with before, but now built just using C instead.

Um, I obviously tried to emulate some of the features in Pyet like colored tabs. So, I figured out how to do colored tabs. It was pretty fun. Um, I've got like a a command interceptor like Guardian. So, if you try to import CAD, it'll say, are you sure you want to do that?

Really not good practice. And you can say no. So, a lot of little things. So event triggers. Yeah, it was good fun.

And like I had to figure out how to do um like context again. So like at the moment these tools are all available but like before if I make a new project and it's not work shared um again I'll find it disable them if they are not matching something. Yeah. As you can see like but now I had to figure out okay how does this actually work? Because pyRevit actually abstracts this for us.

It creates a context system but in in Revit API it's actually called um availability. So I had to like learn how to build toolbars and control buttons and I really came to appreciate Py Rivet in that regard like that it it hides so much of this stuff from you. So you have to actually build like availability classes that provide um context conditions. Like if I'm in zero do I just always return true and that lets my tools run with a document closed. Um because by default it's just is it a document?

Um and then I had to build like what I call extension methods. So some people will know what they are and thanks to Sean Page for showing me how to do these. So you can extend the what class objects can do. So if you say like this in front of your first variable, it actually becomes like a method for a base class. So now the pull down button, the pull down button class has the ability to add push buttons to itself.

Um, but as you can see, I use a lot of comments and I try to keep it super clean. Um, and then eventually you actually have to build your toolbar. So I have like a section that's dedicated to just like I'll open this one for example. So like constructing the data for pulld downs to hold on to then stacking the pull downs into stacks. So it's a lot more complicated than pyRevit.

Obviously the way they do it is very simple. And then actually adding push buttons to pull downs. And you can see this is the point where I say you're available when we're in a document. So that's like context if you will. Yeah.

And then I had to figure out like how do I get tool tips? So I had to build like a tool tip resource where I actually read the tool tips from a big file instead of having to write them in in code. So there's a lot of yeah really different things I had to learn. It gave me a lot of appreciation for pyRevit and how much it does for me. Yeah, it definitely simplifies a lot.

Yeah. And what's your general opinion on this kind of debate between C and Python? Because many people have conflicting views. Somebody hates C#, somebody hate Python and everybody has their own reasons. What's your conclusion on this?

Yeah, I like both. I think that the best language is the one that works for you and the people you need the support, right? That's like that's the right answer to that question. So, if you're working at a company that only writes in Python, sorry, you're going to have to like Python, right? Like you've got to work with your team, not against them.

And and yes, there's going to be benefits to working in one over the other. I think with Python, the benefit is you can get going a lot faster. Um, but the drawback is you have to depend on a lot more being built. So you can actually run Python like usually through an interpreter or something like that. Mhm.

So like Pyrevet for example, like if you use Python, you're not really using Python. You're using pyRevit, but using Python to work with pyRevit to get the interpreter to run your code um in the API. Whereas in C, obviously there's benefits like there is a slight speed benefit here and there, but um obviously you have way more control over your code. You can compile it. You can protect it to some degree.

Um there are more complex features that I think are easier to do in C, especially when it comes to like event subscriptions. Um, I found WPF is a bit more intuitive in Visual Studio. Like for example, if I go into Visual Studio, um, so if I look at one of my forms, like you obviously have a visual editor, but then behind the scenes, C actually builds your form for you. So this is all written by the editor and you don't have to write any of it, whereas usually you'd be writing this out in Python, right? Or you'd be doing it in C# and then copying it into into Python, sort of refactoring it to suit.

Um, and then behind the scenes, it's very easy to just sort of wire up your your class and tell it how to construct itself. And again, a lot of this is just sort of very very intuitive. I found like this is an event sender. So it just it just takes the when I hit select, what does it do? Um, so I think that is powerful, but um more work.

Yeah. Can you go back to the previous file? Yeah, this one. Did you use ZAML for the layout or did you lay out it with this code? So this is all written by Visual Studio for me.

So I actually start here. So if I want to make like a new form um add new item uh Windows form. It should pop up eventually. So I want to pick a Windows form. I'll just say my Okay.

Using the Windows forms, not the VPF. Yeah. So I've used WPF at work a little bit more. Um but I found that initially it was too complex. There's there's always a broken call that happens here because I have a class name space clash somewhere in here.

I have to go behind the scenes and tell this thing it's a Windows a Windows form. Um but yeah, I generally started this way with most of my Windows forms. Um WPF obviously is a bit more a bit more complicated, but um I found that I guess Visual Studio is a very good IDE um to sort of hold relationships between objects very dynamically. So like for example, if I'm in a in a command class for example, I found the IntelliSense is very powerful. So if I go to like a command and I go to make a new I'll just work in a command.

Um I'll just start at the front of a command. So if I want to just pull in like a a class usually I use what are called like aliases. So I I say that forms is gform is my shortcut for like gwiz.forms forms and I just say you know G form and then I can say custom and then I can pick like a a form and it starts really prompting you through like I want to do a select from list I need some keys I need some values so it is a very a very nice experience I found um I did work with stubs in Python and try to get some intellisense going with the API um but it was nowhere near like what I found the guidance was like for C as well um one thing that a lot of people find really weird in C# is you declare the types before you declare before you say what the object is. Um obviously you can say var for like any type but I can also say I'm expecting a form results object or actually let's do a collector. So if I say um no the type hinting is a big one.

So if I list walls is new FilteredElementCollector doc. Um this is something I really like too system link as well. It's really cool. So I can say, okay, I want to get like all walls and to lists. So Visual Studio will say, uh, no, like that's not good enough.

Like you're not going to end up with I think in this case I probably made a mistake somewhere, but um, where have I went? Yeah, two elements probably is the one probably. I think I've made a typo somewhere or I've just put something a bit out of line, but cannot. Yeah, here we go. This is what I'm looking for.

So it's literally telling me I'm ending up with a list of elements where I actually need a list of walls. So you can sort of check yourself against your types and I think um you can like type hint in Python as well. Um but I wasn't really generally finding that was the the pattern that people followed in Python whereas I really like in C# that you can sort of force yourself to end up with like a consistent return type to know that you're you're definitely dealing with like what you want. Um so then if I just you know cast wall and you can see it knows what I want to do. It literally like the IntelliSense is pretty strong in um in here and it knows I don't even need to I just go to list now and it'll satisfy the issue.

So like things like that just little little helpers that I found guide me through the script writing process really help me um yeah just get to where I need faster. Um but I can totally understand why this is like a huge hurdle to overcome because I had to overcome it. It was a lot of work to get my head into this space and actually start going oh what's this? What's this? What's this?

And it just keeps building up. But um once you've got a few things working, you can start to sort of build on it, figure out where there's better ways of doing things. But yeah, once I sort of got my head into it, it it it got pretty easy. Um but yeah, probably like two months of frustration and then like now I'm pretty much sailing at this point, I'd say. Yeah.

So yeah, but I think I think it's not for everyone. I think C's like a very different way of writing code. It's much more about building an application than less about building a toolkit. Um, so yeah, it's not for everyone, but I guess I found it was for me once I sort of got my head around it. Yeah.

How about yourself? How do you feel about C#? Uh, I like that in the beginning you said that between C# and Python, you need to find what works for you. This is also very aligned with what Ashan said. I'm going to release the episode very soon.

It's almost edited. But yeah, he also said that everyone has their own kind of thinking and if the programming aligns with the way you think, it's great. And it's just like you said like whatever is used in the company or you know everyone has their own needs. My case I'm not really I haven't coded with C#. I can read C# really well because I' I've translated so many C# code into Python that I naturally understand all the kind of logic.

I don't know the deployment much. I don't know how to actually kind of make the installer this kind of part. But in terms of code I understand the logic. I understand all of this and that it's very object-oriented programming related. For me I'm die hard for Python.

it's going to be very hard for me to switch to anything just because I don't want to. And for the same reason, it's I saw recently a really good kind of argument for the Python. There's like Python is not always the best kind of solution to the problem, but it's often like one of the easiest and universal because if you want to build a website, probably you want to go with React, SWE, all these kind of frameworks. But if you know Python, you can use Django or you can also use vecttail and make it very quick. If you want to do something like data processing, you can use this and this and these languages, but you can also use Python.

It's not going to be always the best choice, but it's often going to be more than enough for majority of people. And I think for me that's a big point that because I focus a lot on beginners how to get people into programming. And with Python, I like it much more. It's much more readable to me. It's much easier to start.

And in my case, as I mentioned, I started without watching any Python courses. I didn't know what a for loop is. And I managed to make some code. It worked. It gave me results.

to solve the problem and I think in the end of the day that what matters to a lot of people but I see that many people many people say when they start with C# it was easier some people say when they started with Python it was easier like I think just everyone has their own way and the biggest issue I see when people start going there like and ask when they ask hardcore like Python user like myself is C# or Python better please I'm being honest and I say well first of all if you ask Python user probably going to hear that Python is better and if they're going go to a hardcore C# user and like is Python or C# better? They're going to find all the reasons to why C# is better. It's not always the case. Many people very transparent and say like look if you're new you never cod it probably start with Python and then kind of build on top of that because object-oriented programming is definitely a big big roadblock in the beginning. I don't know how was your journey but when I was with kind of learning Python I understood like okay here are the if statements there are the for loops there are functions.

Eventually I got to object-oriented programming and I understood how to write classes but for me big thing I never understood why would I want it I have functions I can do it with functional programming and it didn't click for a long time I already kind of okay I don't need classes gave up on that a few weeks went by I didn't try to kind of do anything with them and I I don't know this was one of these moments where I just like something clicked in my brain and I was like ah I think I understand why I need object-oriented programming and it started making more sense out of nowhere I wasn't coding. I was just kind of going about my day. So, I think it's the way of thinking that we need to adapt a little bit and some people can get it right away based on their previous experiences. Maybe as you said with Warcraft, it already kind of gave you kind of planted the seed for the programming, but maybe you didn't realize it. But for some people it takes a while to understand certain concepts.

This is why also when people say how long does it take to learn programming? I'm like I don't know. Some people start in second day, some people take month. It's Yeah. very depends on how fast something clicks for you because you have to make your own like connect dot certain way.

Yeah. Another follow-up question I guess that people I always give people is what do you want to do with it? Like you know what what are you trying to do because that will very much influence the answer of your question as well. Like if you're doing data science, you might not need C#. You might just because you might use this mapplot lib and pandas and you're sailing like it's already built for you.

Um whereas if you're you know building you you don't want someone to be able to open your code up. It's meant to be protected. Yes, probably you're likely going to be in C# at that point. So, it just comes down to those factors. And I found object-oriented programming took a while for me to get.

I have a really good example that I show people sometimes of like where, you know, object-oriented programming really helped me, especially in my own toolbar. I'll just share my screen again. So, like all my forms that I build, for example, and this is a little bit different to the forms in pyRevit. Um, they all actually end up outputting the same object, um, which is a form result. So I ended up building a custom class that has objects or an object.

And this is how I can handle like sending multiple objects or single objects in a multi select scenario. Um was the form canceled? Is the result valid? And was the result of the form affirmative? Yes or okay.

Um and that's like my return type of every single form that I I build. So I still do a lot of like functionbased programming, but I found like C with a return type. Um I'll just find an example of a return type of a form result. There it is. Um helped me sort of better understand.

Okay, like sometimes classes really help you abstract something into like a really simple scenario. So like for example, when I run my revision script, um if I open up the operative tool, when I'm actually getting revisions, I'm getting a form result, I'm checking was the form result canled because I send out a form result and then if it wasn't, then I get the object as a revision. Um and then for the sheets, I can ask for the objects instead of the object. So, it's a really flexible like sort of custom thing that helped me make my forms really intuitive at the surface level. Um, and and I always find it's a good example of, you know, where object-oriented programing programming makes sense because you can really abstract things to a more logical way of working.

Um, and a lot of things I do now are very much still very inspired by Pyrevet. Like this is very much how a progress bar in Pyrevet looks. You kick off a progress bar, you kick off a transaction, you you check if the progress bar has been cancelled, and then you increment the progress bar. Like pyrovate's almost the same in principle. So like I still take so much inspiration from like the way that Pyrevet sort of educated me to manage certain classes and objects and yeah, definitely I definitely um don't feel like I've abandoned.

I'm still very much spiritually in pyRevit when I work um but just using using programming in a slightly different way now. So yeah, just thought I'd share that. Hey, UI design is very good example for object-oriented programming because this is where classes actually they make so much sense there because in the beginning when you learn about classes then you try to apply classes to everything you do and it doesn't really work. This is why it doesn't click because you're just trying to take the same code make it you can do it that also going to work but in the beginning you just see it a bit pointless because it worked before why change it. Yeah, but with UI forms, especially when you go in VPF, it makes so much sense because you kind of have already separate like UI XAML format, then you have your Python format and everything is also a class.

Your form is just one big class of form and then you can modify it. It starts to make sense more but in the beginning it's just hard to come up to this example that you actually need because you always see this kind of tables about employees. You have a class of employee then you like you know the dogs, animals, all this and you're like cool I get the concept. Why do I need it? Definitely.

Yeah. I mean, that's what I encourage people when they ask me what what should I do to learn to program and I say find a problem that matters to you. Um, so cuz yeah, like you said, the employee table like I don't I don't run a company. I don't need an employee table. I don't have a ben examples that everyone uses like a class of person like all this.

I mean it's good abstract enough but eventually you start asking questions. Why do I need it? Yeah, exactly. But I mean at the end of the day programming should be a personal journey for anyone. I always find there's sort of like two types of programmers I run into on average that are learning.

There's the one that's doing it because everyone else is doing it. It's just what they have to do, which is generally like the wrong reason, but eventually you might find your way to programming for you. And then there's the ones that just they literally are just so sick of their job or doing things in a dumb way and they're like, I can do this better. And programming is like my escape from, you know, the mundane sort of of my career. They're the most common types of people I run into.

And I always encourage everyone to be more like the second person because you have like a really strong motivator to keep going and and to to escape from a problem that you can solve using programming. Yeah. Yeah. You need a little motiv motivation in the beginning. Totally.

Because there's like you know this learning dip beginning whatever skill you take in the beginning it's fun and cool. Then you hit your first big roadblock and this is where many people quit. But if you keep going this is where the things get fun once you go past this kind of learning dip. And I think on this note, it's also a good place to ask. I like to ask all my guests, what is the number one advice you would give to beginners like to programming in general?

Probably brave users since that's where we are. I think the number one thing for me is keep going. Um that that's advice I need to tell myself all the time because it is easy to get frustrated and it's very easy to get stuck in corners and not quite know where to go next or not know why something's not working. You just you've just got to keep going. Um make sure obviously you're being smart about how you keep going.

like contact people that might know answers, engage with forums, um try to find resources that might work for you. But um it's hard programming like it's not a it's not an easy thing, I think. Like it is an extra skill set on top of being an architect, an engineer, uh a designer, a business manager. It's it's an extra thing and it's not the core business service of architecture especially. That's a really important thing to remember.

like your code is only useful if it makes the business money at the end of the day like by making it more efficient or by adding to the service they can offer. Um so like it'll be frustrating because you'll have to sell why you're doing it to people sometimes that will be frustrating too but you just got to keep going. You've got to be patient with people, patient with yourself. Um and just it's all a journey. Like there's going to be struggles.

There's going to be good times. Um there's going to be really confusing times. There's going to be scary times when like AI comes along and tells you that no one's everyone's going to be a coder. I'm still waiting for it, but um you know like there's going to be a lot of emotional experience. They need to sell the hype.

Yeah. Yeah. Exactly. I think we're almost in the trough. Um but but I guess that that's my main advice.

Keep pushing. Um and if you get stuck, come to people like us. We're generally quite accessible people. Like um I think we're always happy to give even just quick tips if we're busy. Um I try to be super accessible.

Um I won't always be that accessible. like I'll probably have kids and stuff one day and it'll be harder, but my my hope is that other people get inspired and continue to support the industry and and I'll I'll try to keep developing resources as long as I can for the industry as well. But yeah, keep pushing. How about yourself? What's your your main sort of tip?

I think there are a few things. One of them is sort of you need the basics because without basics it's not fun. Yeah. You just like in the beginning people like ah why do I need Python? It's easy.

I'm just going to jump straight to Revit API. And then what I see people struggle with is they have Python questions when they deal with Revit API and they don't know either of them and now they're trying to juggle two things and it's very distracting and it also gives you this false feeling that everything is super hard but this is just beginning like once you have the basics like absolute like just the computational kind of logic how to create logical flow how to like you know if statements then once you go to Revit API you already have one problem less you don't think about logic as much you just think about how do I communicate this logic with ravit which is completely two different things right one is logic other is like I don't know how how do you work with specific things yeah so I think my main one is more into like this kind of focus on the basics don't skip on them because I skipped and firsthand I can tell you that you're going to struggle with so many stupid things that you would just in beginning would spend a little bit prepare yourself it's like the quote I mentioned about the axe just sharpen the axe before you're going to cut the tree and it's going to all work yeah I always sort of um use an analogy for that one because I agree fundamentals. Like if you're not bored for a bit, you've probably skipped something. It's usually what I like to say that there there are some necessary things you have to go through. So when I when I first played um Pokémon on the Game Boy, um I didn't actually read the instruction manual and I didn't realize you can catch Pokemon.

I thought the only Pokemon you get is the first one they give you and you've got to beat the whole game one Pokemon. And I beat the game. Haven't you watched anything? I beat the whole game with one beefy Charizard and then I realized, oh, you can catch these things. So like read the manual is another thing too, right?

read the docs. Like check out what what you're getting into before you start coding. Like have a look at the the primers, the wikis. How did you miss it? Yeah.

So yeah, just read the manual as well. Haven't you watched the cartoon where all they do is throw Pokeballs all the time? No. No. I didn't watch the cartoon and I just I just I guess like Ash is the same.

He only uses Pikachu, right? So he catches all these Pokemon and he only ever uses Pikachu. Um so I sort of did the Ash journey because this was my first question. How do I throw a Pokeball when I played in this game? Yeah.

the the old man in um Vidian City tried to show me and I just completely missed it and I kept going. So, but read the manual is the other tip I have. I see. Now, uh how are you on time? Do we have a little bit time?

Yeah, if there's more you want to talk about. Yeah. Yeah. Perfect. I just want to ask you about Well, AI is a big topic.

Somehow I missed this topic in the previous podcast because I I packed so many questions I had to skip a lot but now I'm smarter. Uh just in general, how do you use AI in programming? Do you use a lot? Do you rely a lot? And yeah, so um C was probably taught to me a lot through GPT.

Um I had a lot of conversations with the GPT um to really start understanding how this all works. I I learned you can feed code into AI and get answers back with context about the code. So that helped me. Sometimes I'd see something and go, "What does this mean? Please break it down for me.

I've got no idea what this piece of code is doing." Um, or I'd send code back at the GPT and say, "Is that the best you can do? Is there something more efficient than this?" Because occasionally it writes very verbose code, like very complex code that doesn't actually need to be that complicated. Like for example, the shift key, checking when the shift key is held down. ChatGPT taught me how to do it using internal pointers in C which aren't exposed to you naturally that you have to draw upon a DL to access. And it turns out you can just go keyboard key pressed shift.

Yeah, it's not always the sharpest tool in the box. So, like it showed me how to do it in a very memory efficient way, but it didn't show me the best way. So, I threw the code back at it and eventually it was like, "Oh, whoops. Yeah, there's actually like a really simple way to do this." Um, but I found that that was really beneficial for me, but only because I knew what I wanted to get out of the exchange. I wasn't coming in blind.

I had a really set goal in my mind. I had a good understanding of the fundamentals already. I'd used Python. I knew about object-oriented programming. So I could have a con conversation with it.

Um, if I came at it as a Dynamo user, it probably wouldn't have worked because I would be talking a very different language to like what I was trying to get out of the the conversation. It would be like talking to someone in a different language and you only know like two or three words and they go, "Oh yeah, I know that word, but I don't know what the rest is, so I'm just going to make the rest up." And that's probably like the worst thing about AI is that it makes stuff up. It doesn't say, "My confidence is at 2%." So take it as you will. It just says here's the answer. And I wish it would change.

I wish they would put confidence ratings on things and say this is actually how this thing is in the answer it gave you because that's like the worst part of AI for me. That's actually a good idea, the confidence marker. Cuz with AI, what I noticed is that your kind of the output is going to be as good as your input. Yeah. Because you need to kind of direct it when you don't know anything.

It's still good. It's going to help you a lot. But what happens later on is that it's not replacing people completely with programming. It just makes good programmers much better programmers because they know how to ask questions. They also know how to guide it and they also they not just say like hey I have a tool I want to delete all revisions and that's it.

Now if you're going to describe okay I have this tool I want to do it this way step one step two step three step four. If you see something else just let me know. Blah blah blah. It's already so much better output. Yeah.

Yeah. And for the prompting, I have I've noticed one prompt that works really miracles for explaining code because you mentioned that you kind of gave the code and I also wrote on it. I just going to say that what I like to do is like I I dropped like the regular like I want you to act as seasoned Python developer and so on. But then I ask you to make a tutorial out of it. Then it thinks completely different.

Not like for the video or something just for me like explain it to me. And I I say like I will provide a piece of existing like pyroate code and I need you to provide short clear code override outlining all steps then write step-by-step tutorial tailored for beginner pyrovate user explaining each section of the code in simple terms and also for beginners I like to throw in like describe all Revit API concepts necessary for this example. This one I literally noticed big difference in the reply because once you say like make it a tutorial it just like okay tutorial beginner it just starts explaining each step and in the end it also says like oh you need to know FilteredElementCollector which does this you also need to know transaction which does this this one is actually you know I'm not so much into prompt engineering I barely like I want to take some courses to get better at it I just don't have time for this but this one I just kind of I don't know how I just end up coming up with this I was just trying like this this this and then I'm like oh that's actually a good Does it put the ad for Raid Shadow Legends at the start as well for the mobile? Does it put the ad for the mobile game at the start of the video as well? Because it's like doing the tutorial, guys.

Anyway, I'm going to tell you about our sponsor today. It's good fun. I think I think that's right. And I mean, one thing that does worry me about the culture of AI is I'm not sure if anyone feels motivated to learn like they used to anymore because they feel like it's got it covered for them. And I do worry that we're sort of disabling the next generation of people that become middle managers and upper managers.

And we're already seeing a real lack of middle management opportunities coming out of the younger generation because they haven't really been given those opportunities. And AI does become this like concept where it's like, you know, we don't need juniors anymore. And where do where do you where do your middle ground developers come from? Where do your senior developers come from? They're all going to retire one day.

Like it's like, are we cutting out the knees of the industry if we're not careful? That's the thing that concerns me. I know Meta's, you know, saying we're going to have like just everything's going to be done in AI. It's like, oh yeah, they're still doing their metaverse, which nobody wants and ever use. I don't know.

I don't know anyone who uses it. I tried it. No, thank you. Yeah. And I also subscribe to the idea of like dead internet theory where eventually it's just robots talking to robots, right?

And it's like at some point we're just going to ruin man-made environments. Like the internet will just get ruined beyond the point of use. And it's like is it even worth it? Like so there's and I feel like that the moral and the ethic fabric of AI is being sort of conveniently ignored to some degree as well, right? Like there's a lot of companies that are skipping some very due diligent based steps here where it's like, you know, I think you forgot a few social barriers.

So I'm just I'm a little bit on the fence with those sides of AI, but I see the promise. I've experienced the promise. Um I think it's going to take a long time before we see, you know, like the whole architectural process replaced. I don't think that's ever quite going to happen, but we might see it redefined in the next like 10, 15 years. There is a good joke about this one.

There was like all right guys, AI is going to replace us. All clients have to do, they have to give us the clear instructions what they want. And then the second one like, okay, actually we're safe. They never do that. One of my new quotes I like to say as well is um AI won't replace your job, but someone saying that someone who knows AI replacing your job will definitely not replace your job because we got this new generation of people saying AI is the best.

It's going to do all this stuff. I'm like you're not a threat because you just talk about it. You're going to do it. So yeah. No, definitely.

Yeah. AI is just kind of tool. This is what people mainly kind of all this hype made that AI is like our replacement. It's just a tool like anything else. Back in time, like if you go like 50 years ago and show them Revit, they're also going to like freak out.

They're like, "Oh my god, they're going to take over our jobs." No, it just creates new jobs. You just don't understand it. Just made more work cuz back in time, there were like jobs that you would find hilarious. There was a person who would just wake up in the morning and go and light candles in all the light posts. This was an actual job.

Then would when electricity comes and all these guys think like, "Oh, they take our jobs. It's no, it's just going to be a new job. Now you're going to service the light bulbs once in a while or something. Yeah, they became the light bulb repair shop instead. Yeah.

Um but I guess the other thing too I see is like I mean I see the excitement about AI is a reflection of how frustrated everyone is with the state of technology in our industry. Um in that people are getting quite sick of Revit being like one of the only viable solutions for delivering the way that we deliver an architecture right now. If you want to use a different platform, you have to sort of change how you work. I think like if you want to use Blender Boom, like it's it's a whole different process to using Revit, there's going to be challenges and differences and you've got to learn how git works at the company level. So I think that's part of it.

Like people are just so tired of the same thing and they're like, "Oh, this thing promises to take it all away, right?" So that's sort of why the hype train is is so is going so fast at the moment because I think people are really hoping this is going to be like the next big thing. And I mean, I don't know if it's going to be in our industry. It's definitely going to be in some industries, but like I don't know if it's going to Oh, yeah. There's certain industries already at risk like call centers. Oh, they're screwed.

That's for sure. Because AI is definitely better at that one. But something like re I don't know. AC is so slow to changes. This is why Ravit is so dominant.

Like there are there are tools that arguably better than Ravit, but it's so hard to find people who know the tool. It's so hard in case you have this kind of tricky questions. There are no forums like which go 10 years back who had this issue. And this is why Ravit is so dominant. It's like the community, the forums and just the presence just that all the companies AC they're so slow to react changing from Ravit to anything else.

Oh my god, people still part of it is ego as well. I mean there's a lot of BIM managers out there who have invested very heavily in Revit. But not only that, they've convinced their their companies to invest heavily in Revit. off you if you pull the carpet out from under their feet and pull them off somewhere else, they're going to go, "Wait, why did we spend the last 25 years building all these families?" So there's this there's this like sort of pain point where it's like how easy is it to just pull away from this thing that has become like the lifeblood of your company's delivery model. So I think that's a real a really interesting point the industry is going to find itself stuck in.

Um and the only way out is going to be through it. Um a very difficult solution to just pick up a whole new platform. I think it depends on the way the company works. Like for example, test fit. If a company just does residential buildings, like my god, get on test fit.

Like because that thing will just completely change the first 40% of your delivery process into like a day. Um but don't tell the client, right? You charge this product service. So like um and that's where the service orientated business model is going to be the transformative component here. If we keep delivering on hourly rates as an industry, like we're encouraged to do more, to charge more.

But if we make our server our product a product out of our service instead and we we sort of no longer just make it how many hours are we spending on this, at least on the surface behind the scenes, we still resource, we still do that. That might give us the opportunity to change the delivery process, which will let different platforms shine. Um, so that's where I hope to see our industry move. And maybe AI might help with some of those pain points by making the administration side of the industry a bit more fluid. Um, a bit easier to interact with and not so rigid and sterile.

So maybe that might might be a change multip force multiplier for change if we see it go. But yeah, that it does feel like it's still a very long way away. Like it feels like it's out of reach still. It's like we can reach for it, but I still can't surprisingly can't grasp it. Yeah.

And in the meantime, we can keep building cool tools, I guess. Oh yeah, definitely. Now I have huge hopes in Blender Beam but I understand that the company is going to be so resistant to change but I think the heavy price tag of Ravit sooner or later going to finally like the blender beam going to catch up because Ravit is like three three and a half thousand like a year for user and once you have like I don't know team of 20 that's already substantial amount you're like okay maybe I spend the same money in training in the problem is like it's just not widely accepted yet there not as many use cases it's crazy what people some people do in blend with even Blender Beam. It's a bit of both. I mean, I guess like if you look at Blender, that's obviously a really unique example because the platform in itself is free.

A lot of the other like competing platforms in the market like you Hey, very cute. Um you like test and these sort of platforms, they're not cheap. Like they still charge a pretty hefty subscription. Um so like it's not like 10% of Revit, it's maybe like half of Revit if you're lucky for those new platforms. So you can only really replace Revit with like two platforms when it comes to cost I think in a in a business.

And no platform does even half of what Revit does for most companies at the moment. They pick up very small parts of the design process. Like most of them are feasibility applications. And I'm like not another feasibility app. It's like there's so many of them.

Uh, and I think like until something can take on the delivery side of Revit or like um producing drawings, printing drawings, the you know that really basic stuff, vector graphics, um that's that's what it's going to take to break free of Revit because for now our governments are still demanding that we give them drawings in PDF produced to graphical drafting standards and Blender BIM does seem to be exploring that space. how can you generate a drawing from the model? Um, it's got a long way to go, but like it's amazing how far they've come. I know Dion um relatively well. He's in Australia as well, Dion Malt, who manages the the Bonsai project um working for Len Lease, and he's a really interesting person with a lot of passion um both in a in a positive for the industry and a negative against Revit sort of sort of sense.

So, um so it'll be interesting to see where it goes. Yeah, definitely. thing like in marketing they say you cannot be like 10% better to replace something you have to be nearly 200% better to just like because people like yeah it's better but why change yeah I think there are some platforms where like they're challenging the delivery model um one one that I've got my eye on and I've been having a play with is called Arhole and um they're sort of like occupying a similar space to what like apps like former and other apps occupy where you're doing your blocking your stacking your areas your yields But um they they've taken it from a very interesting direction. They're looking at it more as a a craft in developing your application. So the user experience is like so fluid, so friendly.

Um you've got sheets with views on there that change dynamically and you've got labels sort of like parameters for families on sheets that respond to changes in the model and it's much more fluid and sort of feels like using mirrorboard mixed with Rhino. Um, so I think some of those applications are going to like actually hopefully tilt some firms or maybe some firms might find they only want to do part of the design process and then hand it off to another firm or an outsourcer. Like you might just do the design stage and that that's it. You're done. Hand it off in design development to a firm that still uses Revit.

So some firms might find different niches that they can specialize in versus doing everything and anything. And I think they'll find they can probably reduce their employee count as well if they do that. Like if firms just do the design stage, they might be able to cut 90% of their workforce out and still deliver like you know maybe 50% of the work. So that that's where maybe the future might change for some folks. Yeah.

You mentioned the acral there's also this trend going a little bit more web browser cloud-based uh applications. What I like about acro it's following the trend. There's like do you know Figma? Yeah. Yeah.

So they're very much inspired. just like interface. Once I saw that, I'm like, "Oh, that's that's probably going to be a huge if they put enough effort because this kind of trend for the Figma, I use framer, which is pretty much Figma for building websites really quick." This is like if you're a designer, but you don't want to mess with the code, that's perfect. And like the acral I like when companies move in this direction of the trends because they clearly work. It's just the AC is a little bit slow to the changes and they might not appreciate it.

But I know like similar apps from other industries. So I appreciate this part. I haven't tried it. I think one of their main investors in the startup mode was actually the CEO of Figma. So they definitely are very closely aligned with that mentality.

And you can feel it when you use the app. It just feels like everything's been designed very intentionally and very cleanly. Like it's everything's out of the way until you need it. It's not just like the interfaces where there's like 50 buttons and you just got to find the one you need. It's it's a very different approach.

I think web based is obviously fantastic when it comes to deployment as well like you know just open up a web browser you're in you're installed like straight away that's obviously like a huge benefit as well. Yeah it's also updating is no issue it's just done in background you close you come next day new version done. Yeah I mean I guess we've got so used to the idea of no backwards compatibility with Revit that we've sort of forgotten what modern application development looks like. Um, you know, like it's just so strange to be in that scenario. Like when you go to Rhino and Rhino 6 can open a Rhino 8 file, it's like what?

Like cool. Okay, wow. Because they've like planned ahead and they've figured out their delta process for like new features and they've figured out how to flag the new features in their in their format that they write. Um, like Unreal, when you use Unreal Editor, it's like it's a whole different program experience. Like the interface is so much cleaner.

So yeah, I think hopefully people will just try these apps out and maybe get either frustrated enough to make Revit change or make the change I guess if they don't if they find a way out. Yeah, I think the issue is the legacy code because I heard we had an issue with the rooms and one of the colleagues reach out to Autodesk team talk back and forth a lot and eventually we get an answer that the algorithm that controls how rooms are taken. it was written in the 90s and they are a little bit either they afraid to touch or they just don't want to because it takes a lot of effort to rewrite it from scratch and therefore there is certain bugs. Yeah, we found a workaround that usually like draw lines this and that move things. But it was funny to hear that they also kind of admit that there is legacy code that they not willing to touch at the moment because there is just well they don't have resources or not.

Oh, fair enough too. I mean it's a huge product. So, I mean, I look at my code base for my addin and I can't imagine what it must be like to work on like a Revit in source. Like, that would be insane. So, like I my my heart goes out to the developers that are like having to maintain this beast and also add new features into the API and rewrite parts of a very old program.

Um, I have major respect for the development team at Autodesk. And I think like even they're in a point where Autodesk is like, "Wow, we've got a lot of tech debt here. we just got to manage what we can. Um so like whilst not I don't agree with everything Autodesk and the team's done in the past, I I admire um that they've managed to keep this thing running in a modern developer ecosystem the way they have and you know making the jump to net core in 2025. That that would have been an insane amount of work behind the scenes for them.

Um dark mode even if it's not perfect. I mean, that would have been so much work to just go back to all those forms and find all the variables they need to suddenly insert and control and the bindings they would have had to make. I don't know how they how they do it with the amount of people they have, but um yeah, mad respect to them. Um but yeah, I wouldn't want to change the stair tool or the railing tool. My gosh, imagine that.

Yeah. See, all right, I think we can wrap it up. It's already past the twohour mark. Can you just share what you're up to where people can reach out to you just kind of Yeah. Yeah.

So I guess um I mean in my 9 to5 I'm I'm working um so if I don't always get back to people during that time that's probably why. Um but these days I I've just come back to YouTube on my my channel the Aussie BIM Guru. So I'm actually teaching C at the moment. Um I think we're up to lesson two out of probably like 300 at the moment. Um but I'm starting with the absolute fundamentals.

So like like on Monday I I taught people about variables, very basic stuff. and we're just going to build up step by step until we're finally developing a Revit addin. And I'm more or less going to share how to build roughly the toolbar that I've already shared on GitHub. So, if you want like to get ahead of me, like just look at my toolbar on GitHub and see if you can figure it out. But, um, my goal is to get people pretty much to the point that I'm at because I feel like it's a skill set that people deserve to have available to them.

Um, especially given it's C# programming's been around for a long time. It's just been hard to access. Um, so I'm trying to create a series that I guess, you know, even the, you know, probably the Python beginners could could probably pick up and have a look at and figure out if it's for them. Um, but at the same time, I guess I'm probably hopefully going to get back to like Python and pyRevit eventually. I do have like another toolbar that I was playing with for a while that I wanted to sort of expand a little bit.

So, I think it's still like a really valuable. Yeah. So, I was just um just playing around with that, but I I stopped after I got about probably like 12 tools in there. Um, but I think I might might be able to get a few more in there and clean it up a little bit. Um, and I guess like personally I'm I'm actually just trying to teach myself uh more about WPF and model view view model at the moment.

So creating modless forms to to run whilst Revit's running as well. And I've just built my first MVVM form the other day. So that was pretty pretty cool. So that'll be like probably the next few weeks for me. How do you find MVVM concept?

Uh I think it's I mean like MVVM against like behind code. Yeah. I like what compared to like MVC or like other types of approaches. Um I mean I find it's a a fairly intuitive concept once you understand how they work together. Um it took me a while to figure out like okay like what points to what and what controls what.

Um bindings obviously were like the key to make it work. So getting my head around bindings and converting um converting objects that was probably like the hard part. Um, but I think it more or less makes sense to me now. Um, obviously building really complex forms is like always going to take time. So that's what I'm finding the challenges.

If I want to create a really flexible form, it's it's a lot of code um to get it to work. But um, but I guess once it does work, it's like super rewarding. Um, but I guess from there, like I'll I'll probably just at work be trying to focus on just scaling up my both my toolbar, but trying to find ways to empower, I guess, the people I work with in other platforms like Rhino and trying to introduce other programs to the company like Arcohol to see if there's like opportunities um to try out different platforms and approaches. Um, so that's sort of like my my road map in the in the short term. And I guess if people want to reach out to me, probably the easiest ways is obviously in the comments of my YouTube videos if you have questions.

Um, you can contact me on LinkedIn through direct message or just respond to a comment if you like what I say or don't like what I say. I'm always happy to have a debate. Um, I I actually spend a lot of my time on LinkedIn debating people because I find it's fun to see how people think and react and um, I think it's good for people to defend their opinions. So, I like to sometimes put people on the spot and say, "Yeah, okay. I don't agree.

Um, let's talk about it." So, if I ever do argue with anyone here in the comments, don't worry. I don't hate you. I just I just I'm interested in what you're talking about and I want to talk more about it. Um and probably the last way you can contact me is aussiebimgurmail.com. So that's my just my standard email in my um in my my YouTube closing screen.

So yeah, don't be a stranger and if you're struggling with something, just reach out. I'm happy to give you tips. Yeah. Mhm. Perfect.

Well, thank you for coming on the show. This was really exciting. I definitely wanted to invite you one of the first guests, but you invited yourself before I had an opportunity. I love that I'm an introvert so this helped me a lot. Yeah.

No, it's a real privilege to be on there and I really respect what you're doing in building an API community um and giving a I guess a secondary community for pyRevit users as well. I think it's a really exciting way to bring the two learning spaces together and I highly recommend anyone watching who's not checking out Erik's platform to go and have a look. Um it gets my endorsement. It's a very clean, well setup platform. Um, your videos are very to the point.

Like my videos, I don't get to the point. I talk for a long time, and it takes me a long time to explain my concepts, but I mean, Erik, you put a lot of work into your editing and your graphics, and I really admire the the the effort you put in, and it shows. So, yeah, check it out. Thank you. I think the biggest difference is because you're a native speaker.

When I watch your videos, I'm so jealous because you can just turn on the camera and talk for hours. Yeah. I still have this a bit camera shy or something. Oh, that's okay. And I need to plan more.

And usually when I watch my videos, I just cannot post it. I just cringe a little. I need to add a little bit of editing. And so now it gets better. In the beginning, it was like I would spend sometimes 20 hours editing a video to get 200 views.

It was just insane. Like now I look I think I should have just like posted videos like and ignore how bad it was. I would learn faster. But it's all part of the journey. I think I mean honestly your English is perfect.

Um I think you've come a long way. like I remember when you first jumped on YouTube and I'm like, "Oh, he's getting the hang of it." And now you're you're a pro, mate. You're a pro. Thank you. Oh, I've made a full-time job out of it.

You've done so well. So, um yeah, be be proud of yourself. Yeah. Yeah. Thank you.

I appreciate this. Yeah. All right, guys. Thank you for watching and have a good day, I guess. Bye-bye.

Bye, everyone.