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 I 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 in 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, um

containers and 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 uh 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 incident that occurred in

Atlassian. And it was a it was an

application problem that lead led to a

denial of service. Uh so that was fun.

And then I think I was asked something

about how um 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's uh for example, I thought

that Route 53 did a triangulation based

on the actual latency of the client, but

it is more like that they use a uh they

probably use a geolocation database in

order to do latency-based routing of DNS

requests of the DNS answers, sorry. Then

after that was a values uh interview.

And to be honest, I don't really

remember most of the questions for for

the values portion, but

I do remember one thing, which was when

I asked the question of I asked I asked

the interviewers 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 [clears throat]

an application that they needed to be

built for the platform within Atlassian,

and the application would facilitate

self-service load balancers. 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

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 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 that at least 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 looky at what I

mean exactly. Let me just uh move my

face a little bit. There's more real

estate. Now obviously it's scalar draw

is not what I care about. So they wanted

me to build an open service broker. This

is

a a web app with an API which

facilitates the provisioning of

resources for 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 uh, is here on GitHub. You

can take a look at it. It goes into It

goes into, like, for example, the

catalog endpoint. And the catalog lists

all of the services and plans that are

available on the OSB, and, uh, just

metadata about them. And you might say

query the the service broker and then

display some of the metadata in your

Maybe you've got a a 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, um,

version control, and then those would be

uploaded, uh, during uploaded from a a

build server to deploy a service. Um,

but, yeah. So, you might have, you know,

other APIs like, uh, provisioning here.

So, put and patch for updating and

deletes and blah blah blah. So, you

would just basically go ahead and and

implement this. Or

I mean, if you wanted 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 for 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, uh, Fast API, which I

believe is what it still is at the

moment. Um, okay. So, it's the first 2

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

Elastic. So, like I mentioned earlier, I

started with this library called

connection, which took an open API

document, turned 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. Oh, that's annoying.

And we would have a client making

requests. That's why that's a fast API.

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

CloudFront 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?" And 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.

Um 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 got this

client requesting

uh let's say "Please provision a 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 uh 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 along. One of the architects had

this idea to replace the load balancers

at Atlassian, which were enterprise load

balancers 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. Um you can take a look at its,

you know, uh 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

[clears throat] to replace the

enterprise load balancers 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 run time

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 uh

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

uh 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. Uh this is

actually a I open sourced this this

software and I called it Sovereign. You

can actually go find that on Bitbucket.

It's 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

uh configuration are templates

and context. And so the app uh polls

these. Uh it's obviously got like uh say

let's just say this is the

configuration. Okay, let's stick 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 kind 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 uh

proxies. So then you can imagine let's

just say we've got uh 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 uh as the context changes. Now,

where does the context come from? Well,

this is part of this management server

that is dynamic. So well, let's just uh

let's just do a bit of flip around here.

Put the context

the context actually comes from this

database, but we are requesting it from

the broker. So, the we're 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 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 a

provisioning requests to our broker. The

worker is doing some provisioning tasks,

and then writing the new data to the

database. Then the the management

server, let's say. Stop this. Let's

encapsulate this a little bit. The

management server is then polling that

data from various places and generating

new configuration. That configuration

hits the proxy, and then it starts doing

different stuff. That is essentially the

second part of what I built. So, we've

got a broker, we've got a management

server, we've got the client, we've got

the proxy. Uh why did this detach?

Anyway, so now we've sort of figured

this stuff out.

This is all at a very high level.

>> [clears throat]

>> 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

um

they are provisioned by a CloudFormation

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 uh uh let's say

uh basic user. So, what kind of stuff do

we create in here? Well, if we were to

do this stuff from scratch, we'd

probably have like a VPC and then we'd

have uh you know, a subnet inside that

VPC and maybe we'd have

an internet gateway, maybe we'd have

uh

we'd all security group, maybe we'd have

a key pair, maybe an IAM role.

Um 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? Well, indeed it does

need an AMI. IAM role has to be attached

to

uh must be attached to all these. The

key pair goes on on the these. Security

group is attached to 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 uh blocks of

resources and stuff like that. Cool.

Let's let's put these up 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.

Uh we might have we might have like

uh an NLB in here, a layer four proxy.

Maybe we'd have uh 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

uh

say 2,000 proxies,

uh something like 13 regions, blah blah

blah. Um and we also had a little bit of

route 53 records for other 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 uh

repository that was using HashiCorp

Packer, and

uh we had um

a Salt Stack

uh let's call it configuration.

And so, we would use Packer to um let's

say we'd have the EC Oh, 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, and

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 um

created a little EC2 live running EC2

here. We dump the config on there, we do

a provisioning step, and then we take

the

uh essentially turn this into an image,

like shut it down, uh whatever, snapshot

it, and turn it into an image. So, that

essentially would just produce this uh

AMI. Now, what was included in here?

Let's Let's say we can just uh we can

include a few things here. Let's just

say we had um we had states for for

Envoy. So, like let's say install,

configure,

uh let's say just install and configure

Envoy Uh

logging agents, security,

let's say slash hardening, network

tuning,

containers,

tracing. Oh, let's just say let's just

say observability agent there. And that

can cover I can cover logging, tracing,

metrics. So, 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 the 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 Lyft. So, now when a

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, then 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.

That'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, um which is uh

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 for 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 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 previously,

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 uh 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 a developer

and to turn that into templated

configuration. Now, Envoy has a lot of

configuration. It has a lot of 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. 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 a thousand

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 these 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.

Um and that this stuff seems easier to

me now because I I've done so much with

it. Uh but there's a lot. There's a lot

in here. And if we go into, uh for

example, extensions, there's a lot of

extensions that can be applied to a

listener or a or a cluster. For example,

you might have, uh where is it? You've

got, uh 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 how to handle

proxies and web sockets 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 It took some time. It

took 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 smiley customer. And customer is

someone that's using our cloud products

or Atlassian cloud products. They are

hitting the

Let's just 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 and let's give it a square.

Let's call it a back-end service, you

know. So, the requests are flowing in

from 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. Um

and one of those things Now, this is

where the 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

move over to the side. We've got the

customer talking to the proxy and the

proxy is talking to back end. Of course,

the request comes back up and back out

to the customer. Fine and dandy. Yes,

this is a this is a proxy. Whatever,

there's no surprises here. Now, without

with with the products that Elysium

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 kinds of stuff

that needs to happen and it's just turns

out that we can deal with them here

instead of on a bazillion bazillion back

end services. Just imagine there are a

bazillion bazillion of these. Just

zillions upon zillions. See Daisy. Just

zillions and zillions. They're like

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

implementation of these features. So,

how how were some of these things

implemented? Well, DDoS protection was

really provided by

CloudFront. 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. Oh, 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 back

end services. Great, we've solved 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 them 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. We'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 program. So, we're

solving all these concerns before they

hit these

these back ends 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 I do after that? With

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 compliance

for 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 Atlassian. 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

um you know, particular expected

problems if they're not automated away.

Um and this could be like, you know,

Amazon could have an outage and the

database isn't access for example. What

do you do in that case? What if SQS

stops working 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 um

What happens if an 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

codebase 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 I suppose there's

this concept of churn in the codebase.

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

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

is easy. Changing it and making sure

that it 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 effective to to anticipate the

conflict that's going to arise and 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 [clears throat]

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 a last year. The

project that they worked on was very

impressive and how they approached it

and and built it was very impressive.

And so that's why they got that

excellent rating. 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 reached

that balance, but I suppose the results

speak for themselves. I I but I I don't

I don't I'm not sure if I can attribute

the results to me necessarily. The

intern was helped by some of my other

colleagues when 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 of feeling

that mentoring is difficult for me and

that I I don't have um a good way of um

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 uh uh 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

a quite a lot. If I remember more, I'll

probably just make a second video. Um

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

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. Um 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.