I was laid off by Atlassian

I was recently affected by the layoffs made by Atlassian and I wanted to take some time out to reflect on the time that I spent working for Atlassian. I worked there for about eight years. During that time I built a lot of things and I wanted to talk about what I built, mainly the things that I personally found interesting or that I'm proud of. I hope that this video will be useful or helpful to someone who perhaps is or was in the same situation as me, and maybe it'll give them some inspiration in terms of how they can tackle the same things that I did or something similar and perhaps avoid some of the mistakes that I've made. I also might talk about non technical parts of my experience at Atlassian, although most of it will be technical. And this video will be split into chapters so that you can skip to sections that are more interesting to you rather than rather than watching the video from start to finish. So I suppose to start with, I'll talk about when I was first hired. And even though it was eight years ago, I still remember the interview process, which is different nowadays, and the reason why I was hired, or at least from my perspective, the reason why I was hired and the things that I started working on during the start. So yeah, let's just start at the interview process. So I was interviewed by some people that I now consider friends. And I remember having the impression while being interviewed that these individuals were quite intelligent and that was something that was exciting for me. The interview process consisted of a coding quiz on HackerRank which I aced with full marks. Then the first technical interview was with two interviewers and they gave me a white paper and asked me to read it while they sat out of the room for about 10 minutes. They came back in and then asked me questions about the white paper, asked me to basically articulate what was in the white paper. And the white paper was actually about custom domains and the white paper was by cloudflare. They then asked me a few questions about things like microservices and architectural things like that containers and whatnot. And they were happy enough. I don't remember the rest, but they were happy enough with, with me during that stage. So I continued to the second technical interview, which was a troubleshooting exercise where I was asked to essentially prompt the interviewer for information in order to troubleshoot a real INC incident that occurred in Atlassian. And it was a. It was an application problem that lead led to a denial of service. And so that was fun. And then I think I was asked something about how Latency based DNS works and my answer was not accurate but perhaps acceptable. I, I, I thought about it from first principles and I thought that, that for example I thought that Route 53 did a triangulation based on the actual latency of the client but it like that they use a, they probably use a geolocation and a database in order to do latency based routing of DNS requests of the DNS answers. Sorry. Then after that was a values interview and to be honest I don't really remember most of the questions for the values portion but I do remember one thing which was when I asked the question of, I asked, I asked the interviewer to think about 12 months from now and to look back retrospectively what is the thing that I would have had to achieve in order to, for, for you to say it was a good decision hiring this person. And then they told me about a, an application that they needed to be built for the platform within Atlassian and the application would facilitate self service load balance sort of similar to if you were using Amazon application load balances or the equivalent in any cloud provider but for the internal developers of Atlassian. And it was essentially just a framework that I personally was not familiar with and I said I could build it because I had confidence in building web apps with Python at that time and they accepted my level of confidence and decided to hire me. So that's the interview portion completed. So I joined Atlassian and they have this classic saying or impression that when you join Atlassian that you are drinking from the fire hose because there's so much information that you have to absorb in the first few weeks and months in order to just sort of get going. My first, my very first task, at least the task that I gave myself was to build the application that they had told me that they wanted. Let me just open a browser and we'll take a little look. See at what I mean? Exactly. Let me just move my face a little bit. There's more real estate. Now obviously Skeletor is not what I care about so they wanted me to build an open service broker. This is a web app with an API which facilitates the provisioning of resources or a platform essentially. So you can, you can see here it's sort of built to operate in a Kubernetes world where you're submitting these provisioning requests as things come up and down and it's going to bind a resource to your POD or your cloud instance or whatever it is as you can see here and it sort of sits in between These real resources. So you might provision something like a database and then you'll get MySQL so you'll get something that's SQL compatible but that's abstracted away for your internal developers. Anyhow, the spec is, is here on GitHub. You can take a look at it. It goes into, it goes into like for example the catalog endpoint. The catalog lists all of the services and plans that are available on the OSP and just metadata about them. And you might say query the service broker and then display some of the metadata in your. Maybe you've got a console, a console like the Amazon console, but maybe you've got something like that internally where developers can click and provision things. In the Atlassian case it was all through configuration files that were committed to version control and then those would be uploaded during uploaded from a build server to deploy a service. But yeah, so you might have, you know, other APIs like provisioning here, so put and patch for updating and deletes and blah blah, blah. So you would just basically go ahead and implement this or I mean if you want to build your own. And that is essentially what I did. You can see also there's a, an open API document here that has the endpoints. So I chose to build this in, in Python using Flask. Oh no. In fact what I, what I built it with first is with a library called Connection. This is a Python library which takes an open API document and then creates the API handlers or the paths for the API for the API routes that are in that document, which is cool. But then we eventually. I eventually migrated that to just pure Flask and then eventually migrated that to fast API, which I believe is what it still is at the moment. Okay, so it's the first two weeks and my primary focus is to build sort of what I promised in the interview, which is this web app that's going to be a broker for the platform and is going to allow self service provisioning of load balancing in Atlassian. So like I mentioned earlier, I started with this library called Connection, which took an OpenAPI document, turn that into routes, but I'm going to just go with what it ended up as, which is a fast API app. Let's just say we've got fast API here and then we've got a worker and then we have a database which was DynamoDB. That's annoying. And we would have a client making requests. That's why that's. The client would say hey, please provision something for me. And the web worker wouldn't do it itself. It would actually send that over sqs. It would drop the task details into sqs and the worker would then handle that. So what does a provisioning task actually look like? It's something like creating DNS records somewhere, maybe creating a cloud front distribution, maybe creating some API calls. And this would be the provisioning task that the worker would do asynchronously while the web and client would wait for it to be completed essentially. So the client's polling continuously to say is it ready, is it ready? When it is completed, the worker writes it to the database, the web server checks the status and then responds saying yes, it's finished. Or it'll say that something went wrong and there was an error. So then we can sort of encapsulate this. As the open service broker that I built, pretty straightforward to be honest. There's not much more to this. But we're going to go and talk about some of the more complicated bits in just a second and I will directly link to this as well. So we've got this client requesting let's please provision load balancing. And that is essentially what they were asking for was some kind of load balancing somewhere in the edge infrastructure of Atlassian to allow traffic to go to their service. So that's a good demarcation point to start talking about. The next thing that I sort of built, and I built it through necessity of essentially I began to understand and unravel the requirements more as I went. One of the architects had this idea to replace the load balances at Atlassian, which were enterprise load balances that had licensing costs, with a open source cloud native sort of commodity proxy. And the tech that we chose for that was Envoy Proxy. You may be familiar with Envoy Proxy. If you're not, then it's very similar to something like nginx but perhaps more modern than nginx. You can take a look at its, you know what's, what's great about it if you want you can just read through like why, why choose Envoy, blah blah blah. But essentially we wanted to replace the enterprise load balances we had, make them self service so that devs effectively didn't have to talk to us to go set up their load balancing. So Envoy has an API that allows you to configure it dynamically. Being able to reload the configuration at runtime means that you can deploy a whole bunch of proxies and have them sit there running all the time. And then when someone needs different configuration for their particular service, then they can push out A change through the provisioning task detailed here. And those changes should flow to the proxy somehow. And so now that's a good time to talk about the envoy management server that I built, which we called the Envoy control plane. And this was. It's essentially quite similar to this. Yet again we used a fast API app, but this was slightly different. Actually, let's go into a little bit of detail here. I'm just going to wing this because I should be able to wing it because I know it quite well. This is actually, I open sourced this software and I called it Sovereign. You can actually go find that on BitBucket. It's a public repo, at least for now. I don't know if that's going to be the case always, but essentially Sovereign runs a fast API app and some of the things that it takes in as configuration are templates and context. And so the app polls these. It's obviously got like, say, let's just say this is the configuration. Okay, that's sticky now. So the templates might be particular resource types and in Envoy you've got stuff like clusters, routes, listeners, and let's just leave it at that for the moment. You'd have these kinds of templates. And so when this, when this management server loads up, it'll read in these templates in the context and make these available as APIs for the proxies. So then you can imagine, let's just say we've got an envoy here, it is going to request these things and Sovereign is going to respond by taking the context, putting it into the templates and rendering out different content as the context changes. Now where does the context come from? Well, this is part of this management server that is dynamic. So let's just do a bit of flip around here with the context here. The context actually comes from this database, but we are requesting it from the broker. So we're requesting data from the broker and other sources. In fact, let's just add another source here. Let's just say we have a little S3 bucket with some data and maybe that data is changing over time. So we take that data, it's dynamic, we feed that into the templates. The templates have logic that spits out particular Envoy configuration and then the proxy changes over time. So what happens is we've got a client that's making provisioning requests to our broker. The worker is doing some provisioning tasks and then writing the new data to the database. Then the management server say, pop this, just encapsulate this a little bit. The Management server is then polling that data from various places and generating new configuration. That configuration, it's the proxy and then it's the starts doing different stuff. That is essentially the second part of what I built. We've got a broker, we've got a management server, we've got the client, we've got the proxy. Why did this detach? Anyway, so now we've sort of figured this stuff out. This is all at a very high level. So we've got this created. Now we can sort of think more about more infrastructure type things. We've got this proxy but how do we end up with this proxy? How does that actually get provisioned? What is it? Where does it live? Well, let's start with one thing which is that these proxies, there's many, many, many of them as you would expect and they are provisioned by, they are provisioned by a cloud formation template. This is an AWS thing that allows you to essentially do infrastructure as code and it allows you to create resources in, in AWS that you would normally create via the console if you were just, let's say a basic user. So what kind of stuff do we create in here? Well if we were to do the stuff from scratch, we'd probably have like a VPC and then we'd have, you know, a subnet inside that VPC and maybe we'd have an Internet gateway, maybe we'd have good old security group, maybe we'd have a key pair, maybe an IAM role. Oh of course we need to have the auto scaling group. Of course that's what's going to be creating these EC2 instances and well the auto scaling group needs an AMI, doesn't it? Indeed it does need an AMI. IAM role has to be attached to, has to be attached to all these. The key pair goes on, on these. Security group is attached to the. This. Well it's probably attached to the auto scaling group to be fair. Well the EC2 instances would inherit it from the, from the ASG, blah blah blah. So we've got all these like blocks of resources and stuff like that. Cool, let's put these, put these up together, blah blah blah. Cool. So yeah, we've kind of got like a little template going on here and it's creating these proxies in many different regions. We might have, we might have like an NLB in here, Layer four proxying. Maybe we'd have a bit of, maybe a bit of acm. Of course these acronyms might mean nothing to some people, but for people that have Used aws, they would know what these things are and they know it's not really that complicated. It's like pretty basic building blocks. And this is what we created, so 2,000 proxies, something like 13 regions, blah blah, blah. And we also had a little bit of Route 53 records for stuff. Now the AMI, it's not really provisioned by the, the template. It's more like it's referenced by the template, isn't it? So that would bring us on to the next piece of this thing that I built, which is, well, we need to produce an ami. We need to produce a standard image for these proxies and it's going to include all the important stuff in there. So how do we create this image for the proxy? Well, in this case we had a repository that was using HashiCorp Packer and we had a SALT stack, let's call it Configuration. And so we would use Packer to, let's say we'd have the EC, we'd use the EC2 provisioner and so we would create an EC2 in like a dev account. We'd then upload all of our SALT stack configuration. SALT Stack, by the way, is very similar to Puppet, Ansible Chef, in case you're not aware of what those are. It is configuration management tools. And that's a fancy way of saying that I want to run. I want to install packages, put files and run services on a machine in a particular way, in a particular order. And it automates that process, makes that process declarative for you. Well, not for you, but it helps you to, to make it declarative. So we created a little, create a little EC2 live. Running EC2 here, we dump the config on there, we do a provisioning step and then take the. Essentially turn this into an image, like cut it down, whatever snapshot it and turn it into an image. So that essentially would just produce this ami. Now what was included in here? Let's, let's say we can just, we can include a few things here. Let's just say we had, we had states for, for Envoy. Like let's say install, configure, let's say just install and configure Envoy logging agent security. Let's say slash hardening, network tuning containers, tracing, let's just say, let's just say observability agent there. And that can cover, that can cover logging tracing metrics. But that's essentially what's going on here. Produces the AMI cloudformation template, takes this AMI provisions these EC2s EC2 and they're running with all this stuff and then when they, when they get provisioned, that's something that we forgot here. There's parameters, parameters, bump that up, bump this up, make it neat. So we've got the parameters and these at runtime would pass in secrets and keys and blah blah, blah. And then these, these proxies would grab their resources, be configured and then they would be running and accepting traffic. Boom. That's it, everything's done working. This was essentially the first two years of working at Atlassian. So now when I developer says I want to run my service and I want it to be, I want it to be accessible on the Internet with all the fancy bells and whistles and routing and advanced stuff, we'd say yes, no problem, let me just get that provisioned for you. We send off the provisioning task, we write something to the database, we tell them it's ready and the management server, it's the broker says what's the current state of things? Takes that data plus other data, puts it into the templates, creates resources out of those templates, gives them to envoy on when it requests them. And this was all pre provisioned it's long lived infrastructure with cloudformation and the cloudformation is relying on an AMI that it can use to provision those images, those machines. So yeah, that is probably the first 24 months. So what was next after this? So this was the foundation of our team, essentially the product that we were going forward with, which is centralized load balancing managed by our team and all of the features that we provided to our customers would live in logic defined in these templates. We've now laid the foundation of the team. We've got proxy infrastructure that's reacting dynamically to services that are being deployed with different configurations over time. What was next after that point? The big thing after that was taking some of the larger products and making it possible for them to use this platform created component. That was one big part. And the second big part was migrating all of the microservices within Atlassian to use this. And that was relatively easier because we could enforce that through the platform. Essentially what that means is that the platform was previously providing very basic load balancing to every service and they forced a switch to where you could no longer expose your service publicly through their load balancer, which is too basic. And you had to go through our centralized load balancing infrastructure and to explicitly configure it as a way of signaling your intention for that service to be publicly accessible. Whereas previous it could have Just been maybe accidental that your service was public and not very well protected. So that was the big major push. We got products like Jira, Confluence, BitBucket, Status Page and many others behind this edge infrastructure. And then what was after that? Well, now we can sort of talk more about, let's say we can talk more about the, the Envoy based product that we had here. So this particular thing, we've got this groundwork of being able to take basic inputs from a developer and to turn that into templated configuration. Now Envoy has a lot of configuration, it has a lot of stuff, stuff you can configure. Let's just look at the routes, for example. Let's look at the virtual host, for example. You can configure what domains to accept traffic on. Pretty basic, you can do routing, sort of basic. But once you delve into how you can do this, it gets pretty complicated pretty quickly. You can match on different things, you can route it in different ways, you can do direct responses, you can do redirects, blah, blah, blah, you can add and remove headers. I guess, I guess you could say that's pretty standard. But you can also choose, for example, when you're configuring a route action, you can also choose to send to any cluster that's on the proxy. So then If I have 1000 devs or a thousand services and they each have their own cluster and any route can send to any cluster. Well, it sort of brings up this point of, well, this data here needs to be validating that and abstracting that and so on and so forth. So there was definitely a concentration of, a lot of the development work around this logic here, making sure it was validated here in terms of the parameters were validated such that when those parameters were run through the logic in this, in these resources, that it would produce valid resources. Pretty standard, I suppose you could say. I don't know, maybe I do feel like I have the curse of knowledge and that this stuff seems easier to me now because I've done so much with it. But there's a lot, there's a lot in here. And if we go into, for example, extensions, there's a lot of extensions that can be applied to a listener or a cluster. For example, you might have. Where is it? You've got network filters here, you've got all kinds of network filters and a big one that we obviously used was a HTTP connection manager where you could configure routing and, and how to handle proxies and websockets and all this stuff. And then if we go a little bit before that, there's also things like external processing and external authorization. And this sort of brings us to, oh, let's say something that happened next. So I did briefly mention that some of the big parts after building this was to migrate big products onto. Let's assume that's all finished. It took some time, it took probably a couple years because there were many features that needed to be built out here and, and wherever else in order to support the larger products and their special cases to work on what's effectively a generic multi tenanted platform. So let's just assume that they're all migrated. Then we have more features that we want to add. I did sort of allude to like we have this, we have this groundwork, we have this dynamic configuration. What I'm trying to say is that we, we created opportunity, we created opportunity to centralize logic and to handle concerns early in the chain of requests. What I mean by that is a customer. Let's just make a custom smiley customer. And customer is someone that's using our cloud products or Atlassian cloud products. They are hitting the, say they're hitting an NLB first and that's then being proxied to these boys. Yes. If we can deal with the problems here before they reach a service, let's say, let's give a square, let's call it a backend service, you know, so the requests are flowing in the customer to the proxies and to the pretty standard stuff. If we can deal with certain concerns here before it reaches here, we save a lot of time, we save some money, which is, and it saves the customer time. It's great for everyone really. And one of those things. Now this is where the diagram becomes complicated. So let's move off to the side. Let's just copy a few of these. Let's grab three things and move over to the side. So we've got the customer talking to the proxy and the proxy is talking to the backend. Of course the request comes back up and back out to the customer. Fine and dandy. Yes, this is a proxy, whatever. There's no surprises here. Now with the products that Atlassian runs, there's all kinds of stuff that needs to happen, like authentication for example, or authorization or ddos protection or rate limiting or access logs, all this kind of stuff that needs to happen. And it just turns out that we can deal with them here instead of on a bazillion, bazillion backend services. Just imagine there are a bazillion Bazillion of these. Just zillions upon zillions. See Daisy? Just zillions and zillions. A gazillion. Now, can you imagine if a thousand dev teams needed to deal with all this stuff plus more on their own service? It would be a tremendous waste of money for the company. It would slow down features. The customer wouldn't get their features when they need them. And stuff is already hard enough to deliver as it is. Thus the platform and centralized management of resources and centralized features, implementation of these features. So how, how were some of these things implemented? Well, the DOS protection was really provided by Cloudfront and that was, that was spearheaded by a colleague of mine who is very smart and conscientious and essentially, let's make this a bit more accurate. Let's just say let's get rid of these. There's an NLB here, blah blah, blah, blah, blah. And of course it's two way. So that's one way that we can take care of that concern for these backend services. Great, we've sold solved the concern for that. Fantastic. These others, well, access logs, what we can do is something like we can use these network filters. Yes, we use the network filters, for example, in the HCM we have. Where are the access logs? Access log. Now remember, all of this configuration is dynamic. It's all dynamic and it is created by templates which abstract away the resource configuration from the developer who wants to configure it. They provide simple parameters. Those parameters are then validated and then they are fed into the template as context so that we produce the correct template. That means that they send us a little bit of JSON and we set up this whole thing for that with all the access, logging and blah, blah, blah, whatever. So that is done in fact inside the proxy natively. Fantastic. Some of these things, however, a little bit more complicated these things we need to use a sidecar model where Envoy is talking out the side and then these are their own services running locally on the, on the proxy. So these would be like containers. Essentially you've got this sidecar model and those sidecars, some of them were contributed by other teams and some of them were created by me and our team. The authentication and the authentication sidecar was created by me, written of course in the Lord's language. Rust authorization was done by another team and rate limiting was done by another team. And so they were able to contribute these sidecars which by the way were set up and were downloaded and configured onto the AMI by this provisioning AMI provisioning flow Great. So now we have a programmable proxy with sidecars that have their own separate logic from the proxy and they too can actually receive configuration which is dynamic over the wire locally and, and make it even more programmed. So we're solving all these concerns before they hit these, these backends and in very, very little time. So that was essentially, that is some of the stuff I worked on after migrations and blah blah, blah, yay, what do I do after that? Move this big blob rid of this mess. So then we had some non technical requirements come through, more compliance and things like that. And that effort was very tedious and boring for me personally. It didn't involve building new stuff, it involved taking all of this, making sure that it was compliant for certain, in certain ways, very bored, boring checklist, ticking work, blah blah, blah. So I said earlier that I would also go over some of the non technical things that I had to go through while working at last year. Obviously all of that stuff is sort of high level technical stuff that I just showed what was some of the other stuff that I went through during my eight year slog at Atlassian. The first few things to come that come to mind is that I have grown tremendously in my diplomacy skills. Conflict avoidance probably conflict resolution as well. Being able to persuade, propose ideas, being able to teach, educate and mentor. These are the non technical things that you probably don't hear a lot about but after another thing is that the ability to maintain things, maintain software and systems to see where the cracks show up and to build things so that those cracks don't show up as, or at least to make them show up late as possible. That's definitely something that I picked up. Let's just talk about that maintenance for a sec. I noticed over the eight years that I was there when I built these apps, these services, that there's obviously that at the very start there's the requirement to onboard people and write documentation and train people so that they understand how things work, know how to contribute to them and debug them so that when they become, when they go on call, they know where to look, what could go wrong, where do things break essentially. So you know, that's whether that's knowing what kind of, what particular log messages mean, what sort of metrics to check when something is going wrong and what those metrics could allude to, how to resolve those, you know, particular expected problems if they're not automated away. And this could be like, you know, Amazon could have an outage and the database is in excess for example, what do you do in that case? What if SQS stops work and you can't do any provisioning tasks? What, how, what impact does that have on the services that need to provision the resources and how do you resolve it? What happens if a proxy receives bad configuration? What if it receives configuration that's valid but that destroys the traffic that's flowing through, how do you pick up on those, what do you check, etc. Etc. So there's obviously a lot of that at the start when you build something. There's a lot of that at the start. But the thing that's more difficult is over time people come and go, people get hired, people get, people leave for other jobs and whatnot. And so you get, you have to do that onboarding again, obviously, but you should have more people that are able to do that onboarding collectively. But then you sort of bring in new opinions. People look at an existing code base and they want to change things, they want to make it better and so on and so forth. And so they do that and change ends. There's, I suppose there's this concept of churn in the code base. The area that churns, it's sort of, it becomes predictable where all the churn is going to be at a certain stage and once you notice that there is some churn, it's sort of a smell. It is, it's an indication that that part of the service or project is going to keep increasing in size or complexity and something there needs to happen, something needs to be done to avoid that mess. It's just, just how software goes. I suppose it'll be interesting with all these Vibe coded apps and AI assisted apps to see how we handle that. When we have people that are not really familiar with what they've created and the maintenance burdens appear, they don't appear at the beginning. There's just not enough going through. It hasn't been around for long enough, there hasn't been enough changes. Building something easy, changing it and making sure that you can still change it over time is difficult because as you change things, it slowly becomes harder to change. Things start to get coupled and all of a sudden when you change something in one area, it affects another and you have to deal with the task of detangling something and you might be able to find these areas quite quickly. Get an LLM to perform the detangling for you. I think that's. If we can do that, that's fantastic. But I don't want to be too optimistic just in case. So there's that on. That's my opinion on the maintenance side of things. The next thing I want to talk about is when I mentioned diplomacy, what I'm really trying to say is that I was exposed to different types of managers and colleagues over time. And everyone has different personalities and styles of working. And because I was exposed to so many different types, I experienced conflicts with certain people. And even though I had conflicts, there's still people that I respect. It's just something that happens when you. When your personality doesn't mix with their personality. And that's just something that's a bit inevitable. And I think that the only thing you can really do in those situations is to try to have the self awareness and the awareness of the other person and the, I suppose, understanding of psychology and, and how people work to an extent so that you can be responsible for that difference and the potential for conflict and to handle it effectively, to anticipate the conflict that's going to arise and to do something to make the relationship work. And maybe it's impossible, I don't know, but that was definitely a source of great stress. And at times it affected my performance. And so I do think that because it affected my performance that I took it quite seriously and I learned and changed as a result. So the next time that those situations come around, I do firmly believe that I'll be able to handle them quite a lot better. And then some of the other things. In fact, one of the things that I found quite challenging was mentoring. And so I find it easy to help people to point out areas where they need understanding and to deliver that understanding to them. To break down complex things into simple terms so that they can build a mental model of the system that they're working on. I have that ability. I'm quite good at that. But mentoring is distinct from that. I had an intern in the last year and I will first say that the result of their internship was that they got the highest rating possible and it essentially guarantees an offer to work at Atlassian. The project that they worked on was very impressive and how they approached it and built it was very impressive. And so that's why they got that excellent rating. And what I found personally difficult was striking the balance between. It was essentially striking the balance between how much time I give to the mentee and what that time would consist of. Whether it's, you know, I didn't. I don't want to give them answers to problems, but I don't want them to get so stuck that they become frustrated. I have no idea if I reach that balance, but I suppose the results speak for themselves. But I. I'm not sure if I can attribute the results to me necessarily. The intern was helped by some of my other colleagues in areas that I'm much weaker in. So they effectively got subject matter experts in a few different areas to contribute to their success. But then they did the majority of the legwork to actually build the thing and to test it and to make design decisions and stuff like that, and it was very successful. But I still have this lingering impression or feeling that mentoring is difficult for me and that I. I don't have a good way of figuring that out because I've never been mentored myself. So I don't really know what to expect and what they do. But I want to emphasize that that's a very specific type of mentoring that I'm not too sure about. Whereas training my colleagues, getting them to understand, working, you know, working through problems with my colleagues, that was. That was essentially my bread and butter during the last half of my employment. You know, jumping on a call and going through stuff. Feedback that I got from my colleagues all the time was that I was always available to help and that I could boil down hard topics into something that was understandable, which I'm pretty proud of. And I've been yapping for a while. I think that covers quite a lot. If I remember more, I'll probably just make a second video, maybe. Maybe if people are interested, I could actually go through and build some of these things. I could actually go through and build some of these things, things from scratch, on stream or just a video uploaded to kind of show, I guess, essentially what I made and maybe recreate and sharpen my skills a little bit more, maybe. I've got a lot of stuff on my to do list, so maybe, maybe not. It depends on the demand. Anyway, I'm going to cut the video from here. If you listened all the way through or to portions, then thank you very much. I hope it was interesting and enlightening and whatever else. I'll catch you around.