Indiras Maziukas: 5 Building Blocks for Successful Frontend Platform

This talk covers the five building blocks for a successful front-end platform, focusing on the significance of establishing a strong core team and fostering a supportive community. The speaker, Andas Mukas, shares insights from his experience at Swedbank, where a monorepository approach using NX is employed to manage their frontend development platform. Key aspects discussed include the responsibilities of the core team, such as ensuring developer experience, providing documentation, and maintaining best practices. Additionally, the speaker emphasizes the importance of community collaboration and knowledge sharing, which contribute to smoother workflows and innovation. The session also highlights tooling strategies for enhancing developer experience and maintaining up-to-date dependencies.

[Music] ladies and Gentlemen please welcome our next speaker in duras mukas presenting the topic five building blocks for successful front-end platform oh sorry I see the wrong screen sh hold on perfect okay uh so hey everyone uh I'm andas and thank you all for coming to the talk that will be the five uh building blocks for a successful front end platform so uh let's just go through

quickly through what we'll be uh going through so to start with we'll be moving through two two main areas that we will focus on which will include initially the core team and the actual Community itself and later on we'll move into the more of a developer experience part which will consist of tooling quick feedback as well as uh simple scaffolding so uh shortly about me uh I'm

as me I mentioned uh I'm in D and I've been studying software engineering initially went into systems biology and through the entire time I was working more or less in sweat bank so I've been with the company for over six years uh I've initially worked in a product team uh that was uh mainly focusing on corporate products and then I just moved on to the platform team

so been been with the team for over two years now and yeah I'm just one of our are over 3,000 it friends Almost 4,000 so yeah uh that's uh quite a big Community for us and uh what do we do in sweat bank for front end so we have our own platform that we use which is called fdp which is basically frontend development platform and we have

uh currently over a 100 developers on it with like a steady increase in it and we have over over I think or around 30 applications that we are constantly running on it and always expanding as well uh so our approach for the uh platform was using a monor repository uh with NX as our to tool for managing it uh we also run an evergreen policy which is

basically the idea that we're always trying to stay up to dat with all our dependencies using everything uh that we can that's the latest and greatest and the majority of the projects are based on angular uh so a short notice before we delve into the topic itself uh while this presentation was mainly uh prepared with on top of the experience that we had on a front-end platform

uh this is very likely applicable to a lot more than just front end so say if you have your own back backend platforms or anything like that uh this is probably easily applicable so uh let's set up a bit of a scenario uh shall we to start with well of course since sweat bank is a bank we'll start with a bank scenario so for example say you've

been working in a company and the company has tasked you with creating a new web application so you need to start making payments on the application so uh for the sake of of this presentation we'll uh be skipping the Tex stack choices because well a lot of the companies have different needs for the Tex stack so in this case let's say it's already set so you start

working on the platform you start doing the groundwork laying out the foundations creating infrastructure Services some core Services as some basic security as well you start hiring more people within the company your team is expanding a bit by bit it's growing and then in the end you start branching out from the team because you start needing new features new areas within those uh so just from this

basic scenario that we've set up uh we already have more or less the two of the core print principles that we'll be talking about so let's start with the core team so this is the team that will be your ambassadors for the entire platform they'll be the ones that are trying to not only promote the application to provide improvements quality of life for everyone but they will

also be the people who are actually trying to uh basically mix and match the needs of the business as well as uh the developers because uh well well for one thing business might have uh one say in the platform but if it's not fun to develop on nobody will want to do that so uh going further uh what this team will look like within the Spotify model

so if we take it as an example uh where we have a few tribes uh with our own specific areas we have uh chapters and squads so I will not go into those too much but for example when we have guilds uh people with common interest uh within different tribes those guilds usually have leads those leads are sort of like an informal guide for the entire uh

Guild of people who are actually interested in some topic and uh uh basically what the team is in this case is that there that's just a bunch of Guild leads gathered together in a single team who are driving the entire forward so uh what are the responsibilities for the team uh let's start with actually being the blers for the entire platform so what this means is that

uh the goal of the team is to create such an environment where every single team working on a feature can just work without any additional steps or overhead they are taking care they basically have everything taken care of such as CI the actual uh implementation of the core services and so on so they can just sit and do their own work uh the core team is also

uh responsible for providing uh uh the actual guard rails of sorts and the best practices within the platform so this is constantly evolving as well but uh trying to keep a clean Co a clean code policy trying to keep everything Evergreen this is something that you'll always need just to basically keep the growth in check uh another thing that the team will do is uh provide documentation

so the docs can usually include not only the features of the platform but usually its limitations as well and on top of that uh uh from the limitations it also will be sharing about the base features and what the platform is actually used for because well let's face it a single platform isn't really good for everything at once so you might need different uh and uh one

more thing is uh providing a good onboarding experience so say once you have a new developer joining in you don't really want the developer to spend days or weeks to actually uh just set up their en enironment to start making the first commits that he can so the goal in this is just to make things easier for the rest of the people and just make everything as

smooth as possible for new developers as well uh talking about challenges so one thing uh that the team will face is uh sometimes uh a bit of a shakiness for example with business trust well it's not necessarily shakiness but more like uh actual negotiations because in a lot of cases some decisions may not be easily explained to the business just because say for example you're trying to

migrate to a new framework and how do you explain this to the business who sees a working product already so we actually had a fairly similar experience ourself we were migrating from angularjs to angular and well this is something that the team had to take care of and uh this was sort of well not exactly probably the easiest of sells but still uh so this includes both

the management and the teams that are working on features uh looking forward is uh incremental and big changes so for example when you have uh even smaller doesn't matter whether it's big or small changes but they might be impacting the entire platform so this is something that the team will usually have to take care of they'll have to navigate through all the hurdles that come in with

uh a lot of changes that might be a lot of conflicting changes or something that the teams don't want to interact with at first uh another part of it is creating a bond with the users of the platform so this is something that uh comes naturally within the community at some point but it still has to be developed so that the core team and the uh Community

around the platform actually has a good way of communicating with each other uh just to make every lives easier for everyone just to answer questions get guidance and uh and similar situ situations like that and uh the last part of the challenges is now mainly just uh having like a best course of action in mind uh and this is not always something that's easily uh decided just

due to the fact that there's a lot of changes that teams might be reluctant to implement there might be changes within the industry that everyone has to shift to and not everyone will be happy about that yeah uh so this is a question probably for a lot of people uh should you have a core team within your project and well the answer is more or less just

consider the consideration of the size of your project so uh when you start looking at a small project when you're work working with something fairly small scale like a single uh application that just does one thing you don't really need a core team that will just not make sense but at some point when the application grows more features are required this will become uh something that you

likely have to focus on but we have to probably keep in mind that this team is uh well not exactly a typical team in the sense that these people have to have a certain mentality for learning they have to be able to adapt to a lot of situations and do a lot of things at once so just for example in our case learning angular isn't really uh

an option uh yeah and just a few things to consider uh if you can for example if you are planning to create a platform with a lot of features uh then it's probably worth thinking about getting a core team early on because later on it might be a bit easy a bit more difficult to actually get it so just because the community might be split on what

they want what the vision for the platform is and uh yeah uh one more thing to consider is uh whether are whether you're planning additional Integrations or not so Integrations can be both internal within your company so say that's just a new team uh with their own projects coming into your platform or it could be a third party integration like some additional purchase tool or something like

that oh sorry wrong Buton yeah so we're moving on to the community uh so once we have established the core team we need someone to uh start working around it start actually developing additional features and why do we want such a community at this point so the first part of it is collaboration this is more or less straight forward the work goes faster smoother better quality work

if we have collaboration in between teams we have feedback so this is the principle of uh grow and let grow uh it's really great just to hear feedback from others and also provide provide it possible uh another part is knowledge sharing uh which is uh something that is constantly at least propagated in most companies it's really great to hear from people with different areas of expertise what

they can do and just in general might be a lot of interesting stuff for people and uh oh sorry yeah and the last part is uh Innovation so uh for example when thinking about Innovation it might be simple to think of it as one person getting an idea of something new to create but in the end you usually come into a stage where the actual additional ideas

additional developments are required and it's it can become really difficult for one person to do so uh let's go into how can you build the community uh some things that we've seen from our experience that work well uh are meetups so this is more of an online uh thing for us uh so for example what we do with our meetups is actually do a lot of knowledge

sharing so it can be not only the core team making presentations but anyone in the entire Community doing those they can present something that they learn they can present uh things that they seen online just or are actually working on already and yeah just general news in the industry and uh the other part is actual get togethers live get togethers so uh we have a picture of

one get together that we had uh last year this was the NG Poland conference and a lot of our community gather up there and it was just great talking to people in general and learning more about them as a person than just what whatever includes work which just kind of eases up all the communication going forward so just apart from conferences we have hackathons that are great

to try some outof of thebox ideas just to see how different people work together and also Live tech meetups uh and this could include something like for example external meetups which could be for example like a JS community that includes a lot of people from different backgrounds and companies or internal Tech meetups that are just hosted within company uh so uh going into the open principle is

uh well uh having an open Community is quite important just because uh the ability to communicate freely is uh quite helpful in a lot of cases so I know that uh for a fact that a lot of companies usually just have for example an email or something that you could reach out to some team or some or the coure team for example but email is not enough

uh in this case uh a lot of useful things happen with in shared forums in general chats or something and there's just a lot of communities and subcommunities that can communicate a lot easier not in an email form but just in a chat form uh and one thing to always remember is that Community includes not not only the developers uh so we always have to take into

consideration people like uh Team managers product owners we have to consider our uh quality assurance engineers years who are working mainly on for example endtoend testing and so and such and this is uh just a part of the community that can also have subcommunities within the company and uh having a platform uh to facilitate this is just helpful in uh productivity ways and commun in communicating with

others and just finding like-minded people as well uh and uh one more part for the community is having them uh involved so in this case uh the decisions for the community are both uh both include both suggesting actually Solutions and voting on the decisions we had a fairly recent example for us uh when we we are actually using Cyprus on our platform for example and we just

ask the community whether we want to move on to play right and just hearing the votes from the community hearing the results and seeing what everyone thinks about it it just uh lets everyone feel more involved uh and lets people feel heard about what they're talking uh about what they actually are passionate about and want to uh work with and the other part is implementing the ideas

of uh Enterprise open source so this includes open source code both within the company so for example shared between platforms between uh uh between uh teams or Pro projects and also allowing the teams to work on Open Source Products products that are outside of the company so it might be a dependency that the team uses or that uh the other part is wider participation so thinking about

this is uh in a way that the platform itself has a lot of task that need to be done and there's a lot of people who don't really want to always focus on their own area only so it's really great to have uh some sort of a way to for the uh rest of the people within the platform to participate in so say having like a backlog

or a task board that actually includes tasks for anyone to pick up easily and just uh do on their spare time or something like that uh another part is easy integration uh so what this includes is just making things easy for teams to integrate into your platform so say there's a new product who wants to use the frontend platform that you have make it as easy as

possible for them to do it this could could also include for example third party dependencies but mainly let's just focus on uh the initial uh internal ones and one more part is bolstering inner team Communications so in this case uh let's say we take the chats that we talked on previously so if uh there are communities that are talking to each other it's a lot easier to

answer much uh a lot more questions so uh say a lot of teams just uh start pinging uh the core team asking questions about the platform asking for guidance but there's a lot more uh in terms of uh competence within the actual Community itself there's a ton of developers who can help uh and answer questions uh that someone might be interested in so just having the ability

to share this uh information easily is just great for the community general yeah so let's expand our scenario a little bit uh since we had a payment platform of sorts uh the idea that we want to do now is that we are starting to build additional features on top of it so we have a community that's running quite well we have a core team and uh we

start building things like for example features of insurance features of lending and there our team starting to work on it and what we do with that is uh we actually uh start moving on to more complex requirements we need to fulfill a lot more needs for a lot more teams and uh this is uh uh something that will actually require a lot more robustness within the platform

itself so we need to make things as simple and as uh green uh in terms of CI for example uh to be to to keep it going and this is where the developer experience comes into play so uh let's take take uh the example of a vicious cycle that we have uh what what this is uh for for us at least uh is that a good developer

experience and bad developer experience can be an easily vicious cycle so say if you take the good part uh once you start implementing good developer experience features uh within your company it becomes easier and uh just more Dev friendly to start working on things this encourages more feature addition in such cases so for example you can make additional tooling that makes just lives easier for everyone and

just from these PL practices and tools you can also attract new people who know that uh working within a company will be easy and well not necessarily easy but just uh not as tedious as somewhere else and this also uh encourages uh those people who have joined to give more feedback in their contributions yeah and I'll continue uh so uh thinking about the bad part if you

have a bad cycle of uh developer experience going uh the problem with that is is that people might not just uh enjoy the way of work that you have they will start leaving for example they will not want to implement any new better practices and this just goes worse and worse in the long run uh let before we delve into the actual points uh here let's go

to a bit of of a religious question so monor repost versus multi repost uh for the sake of other slides we'll just be going with a monor repo example because that's something that we're more familiar with uh within s bank front end but uh there well a thing to consider is that uh there is no one Clear Choice there isn't like a single winner for any project

so let's just go through a couple of uh points that we have Within These uh so say for a monor repost uh the dependen the dependency manager is a lot simp management is a lot simpler just because every single project uses the same version everything will be compatible it's it's all updated at once there's a bit less overhead when starting on a new project so say a

lot of the things can be generated or come by default with the platform there's also consistent tooling so say once you start working on a project you know that the tools will be available in other projects and they will work in a similar way and uh one more thing is that the access to different projects is easier you don't need to look for repost you don't need

to think about uh how to actually start a different project on your machine how to start development on it just because you have everything in one place however on the multi repo approach uh one thing that is constantly mentioned is team autonomy this is something that is a lot less visible within mono repos so the team controls the re uh repositories and everything the way that they

want so isolated configs are also uh something that is quite helpful just due to the fact if there's a breakage or something doesn't work or you want just want different configuration it's a lot easier to do in a multi repo approach so if you think about flexible Integrations that's uh a thing that uh uh keeps uh basically your platform uh as open to additional Integrations from external

and internal projects so if you take one repository it's easy to make an integration to that and the rest are unaffected and the ownership model is quite obvious because you just take one of the repos and it's clear who owns it so for us in front end the monor repo approach seemed a bit more natural just because uh there's uh things like to tooling consistency that's quite

required quite a bit because a lot of the code is uh more tightly coupled than for example in micros Services uh and one more thing is that we need a sort of a UI consistency so say you're using a UI library and we need to be consistent with it so if we tooling uh what will Tool uh tooling do uh for your uh platform it it's actually

a Make It or Break It thing in a lot of cases good tooling can just help your platform run smoothly while with bad you might just want to abandon the whole platform in general so here at the bot bottom we have a lot of uh tools that are used for mono repos but there's plenty for example uh I think like Gradle that are used in multi repo

approaches as well and uh one thing that will help you choose the right tooling will be thinking of the idea in a bit of a longer term so for us the choice was an X with a monoo approach well this was more of a say an easy uh an Easy Choice as we just started uh uh our platform with the X and it seemed to match our

needs further on so we were sort of Lucky on picking the tool but it works really smoothly uh when looking into it and a couple more things to consider is that uh tooling will always be required no matter which path you go down with so whether you do uh multi repo or monor repo you will have to find tools and you will likely have to write your

own tools so this is something that you'll always have to take into consideration and yeah there's no Silver Bullet there's always going to be both gains and tradeoffs that you'll have to make with any tool or approach that you will go into so uh just to go into why do we use an X is uh for example for us uh the things that were needed were efficient

caching Solutions so uh for example solutions that are offered both locally and within remote deployment so remote locations where the cach can be accessed uh consistent results is something that's quite important is uh so that once you run a task locally you can actually always expect the same result when it's running in CI uh so in this case you just always know that something is going to

be just a lot more straightforward uh and you won't have to worry about things breaking in C when you push out your code uh extensibility is also really important within a larger platform because there will be plugins and custom tooling required uh that and once uh your platform tool allows that this will be a great addition uh shared Tool uh tooling and rules is another point that

we take uh into consideration deeply just because once the platform rules are set they're usually applied to the entirety of the platform and share tooling is just available AC ac across any project so uh a couple of the last things that we have here are automated code generation and migration generation as well as executors so this just takes off a lot of boiler plate and um I

will go a bit deeper into this in a couple of slides but uh yeah this just makes uh uh the the life of the developers easier and the executors uh on top of that will allow you to make changes that you need for your use cases so uh going into uh one part before the last I think uh is quick feedback but think of this quick feedback

not as developer to developer but more like the platform to developer so if we look into uh what this means for uh a bigger platform for example is that you don't really need to wait for continuous integration to do its thing to go through the pipelines to know what the output will be so say you run your testing tasks you run your lint tasks it just goes

the same both locally remote uh that's in part due to the setup that's being used so if the setup is uh identical on both local and remote it will just be that straightforward tooling is easily accessible so uh why why this is a part of quick feedback is that it's available everywhere and you'll know on every single project that you can use it and what the results

will be uh one thing to focus on is actually speed of the platform uh this is something that you need to take into consideration uh when creating it just because you want the platform to be as fast as possible when it's responding to the developer and one thing that we do this is uh uh from our example is that we actually make previewing the applications that we're

deploying or trying to merge to the main branch for example uh is uh just making deployments for every project that uh needs it so that it's easily shared it's easily visible without any additional steps that you can open just a website from the build and see what it does uh uh one more part of it is affected trees so this is actually something that uh uh increases

the efficiency uh of the tooling and the platform itself so what this does is for example if we look at the uh shared product types at the bottom there uh this is a project that's within uh our library library let's say uh if uh that product is affected since there are two only two others above it that are actually uh dependent depending on it only those will

be rebuilt the rest of the app will stay untouched so this is where the granularity of the cache comes into play and this also helps us keep focused relevance to the developer to what they're doing uh and one more part is uh that that a lot of NX users use is NX Cloud so what this allows us to to use is actually uh distributed task exec ution

so just to put it quickly into perspective is that it allows multiple machines to run paral tasks in parallel at the same time so these uh machines are able to access the remote cache just run through the builds a lot faster and they can easily be scaled depending on how much work needs to be done and yeah a couple more things when thinking about quick feedback so

uh if we take into consideration things like the main driven design there's an article that I've linked here through the QR that's by manfreda that was uh posted I think at the start of the year how domain driven design actually helps with easily figuring out who owns the project or what area is it in because it focuses on uh separation of the uh features of the application

in more real life uh areas so say for example in our banking application that would be lending payments Insurance uh one small thing is code owners so just pretty straightforward open a file see who owns the code and you pretty much know who to contact or who to reach out to and one more thing that I will not go too deep into details is module Federation and

micr frontends so this is an approach that is helpful for both builds but it also sort of helps to create an organizational structure that's more vertical so uh a team or a couple of teams could own an entire feature line just by themselves without anyone else interfering and we go into the final part this simple scaffolding so what this part consists of is uh for starters docs

so this is just the basics of the platform features limitations use cases straightforward rules uh this is something that we always have to consider when uh looking at the platform so this could for example include code formatting rules this could be linting just to keep some practices in check further on onboarding so this is a part of the scaffolding that is just uh fairly easy easy to

see in terms of both onboarding a new developer and a new project if there's a clear path for it the scaffolding will be there so you open up the project you you create something new say a new application within the platform it just starts off with basic CI setup basic rule sets everything that you need in terms of practices as well that's just uh good to go

and good to start coding your features on automation is also very important just because it removes a lot of load from the teams and it just provides a lot of outof thebox uh code that you will need on your platform to speed up development and not to make tedious and uh this is the code generation part that's uh to some extent I guess uh uh link to

automation just due to the fact that code generation can help remove the annoying parts of development so uh to look into a bit of enforcement so when this is more when talking about rules uh there are both benefits and pitfalls with this so to start with uh when we take consistency into consideration uh this is something that's that will be important ac across the platform to keep

and the one of the enforcement benefits is precisely that just to uh be able to move from Project to project easily uh discouragement of anti patterns is also pretty straightforward in terms of that it will help you for example create lint rules that will just keep the patterns in check and use the proper coding variations that you use and preemptive uh bug prevention is something that's uh

that's quite easily considerable when you start thinking about deprecating some old code maybe changes within the Frameworks that you use for your front end application this can help a lot when it's enforced but for the pitfalls of it uh we have uh over enforcement so this can become quite annoying very easily and very quickly just because of the sheer amount of rules developers might just be restricted

to how they can code uh Grace periods are something that you have to consider as well just due to the fact when you're implementing new rules uh the thing is that you cannot just make them a hard rule out of the box within a large platform there still have to be changes made there still have to be uh additional uh time for teams to actually uh move

it into the new rules and configuration and exemptions is just something that you will have to think about as well because there will be projects that will require some sort of exemptions from Rules uh so yeah moving towards the end of this part is uh new code generation within the simple scaffolding this is a part that's sort of near and dear to my heart because I've been

working a lot of on a lot on it recently so new code generation includes both generating the base code the boiler plate the CI configurations for new platforms it also not platform but uh like applications uh it also creates the boiler plate needed all the configurations everything for libraries within the platforms so the smaller feature parts that will come with uh best practices by default and uh

one more thing is easy integration so this is something that uh uh we actually have some experience with doing so uh for us what easy integration meant is for example using uh backend API generators so say we have a backhand that provides us with an open API uh spec we take the spec we it into uh an actually readable file for our generators and once we have

that we can generate all the types all the calls that are needed for the platform to use so it's just easier for developers to pick up and start using uh the apis instead of actually having to write their own clients and their own implementations of the calls uh and migration part uh of uh scaffolding is that's uh that's actually usually provided a lot by the platform that

you use so for example if we take angular it recently had a new control flow implemented instead of using ngfs it used different Syntax for ifs so there's automated generators that just change the entire code base in a oneandone fashion where you don't have to worry about teams uh taking their time to change it and this sort of also helps mitigate the risks a bit so that

the old practices don't stick around for too long and they don't cause any issues further down the line uh one Pitfall to think about when uh creating generators is uh that you actually can uh do over basically oversaturation of gener of generators so if you create too many of those for easy access you'll have a lot more maintenance to do within your platform as well once these

standards change uh and the last part of simple scaffolding is to always think about what you'll be doing in the future so for example those same generators could also be using uh built-in AI so say you have a custom uh form implementation within your pages you want the generator generators to be able to discern what type of components do you use and what's the implementation of those

and uh for example the same generators could be used for actual detailed prompts so say you provide what you want to create on the platform what you want to generate but the uh generator itself creates a more detailed prompt with more context what you have within your project or application yeah so let's go through the key takeaways uh the first thing is knowing your platform so having

those core teams having the competences needed uh are quite helpful within the platform when you're actually creating it it's not just a small bunch of people who know everything it's a lot of shared building a community this is really effective when uh starting to work on a larger scale projects just because of the sheer amount of benefits that come community uh going to finding tools so this

is uh a part where you actually come into the coding space this is where you have to consider what you'll be doing and what direction your platform will be heading in find the tools that you need and create your own tools because you will not always have tools available uh that come out of the box uh make feedback quick so the goal of this is just to

drop uh the tedious waiting processes to drop all the unnecessary thinking or boil or boiler plate just to be aware of what the platform will do and finally making things simple no boiler plate no overhead to think about and just straightforward coding on the features that you actually want to do yeah thank you [Applause] it I you have questions okay so let's start with probably the first

question what what our platform is is uh uh mainly it's like a set of tools and a set of practices that we provide so say we have for example an internet Bank application or we have some intern applications that we run we provide everything that you need to start with a front-end app that will be up to date you will not have to do custom uh tooling

on it you will not have to write maintenance do additional maintenance on the platform features so for example it provides Integrations as well as I mentioned with the API generator that will make a lot of things easier and it's just uh something that uh is uh for people to take into uh to dive into uh and just code there are the features that they actually want to

do instead of thinking about all the surrounding stuff like infrastructure logins and and similar patterns okay I'll probably read it out loud so Sim business wants to create a new app how would the onboarding look like within your platform and uh does the what does the core team provide yeah so uh that's actually a few good points made there so the boiler plate is available on the

platform by default you run a single generator you get a new application by default that comes with uh things like as mentioned in the question uh kubernetes support is actually uh baked in just because once you create a new platform it comes with some basic deployment configuration uh so it's instantly available to be deployed into our clusters that we have on top of it we also uh

have the ideas of uh continuous integration also coming with the newly generated platforms so once you make the first pull request it has the entire C pipeline running for that and yeah it also provides everything that you need in terms of the basics such as dependencies and uh and a lot of the guide uh guard rails that we use yeah let's go next one uh how often

uh does do your team have to jump in and actually help Implement support something yeah uh this is something that you that is actually taken into consideration a lot uh the core team are often the ones who help uh say the outside teams with the more complex stuff so it does happen from time to time but just because that uh have we have a community around the

platform it's a lot easier to maybe delegate some tasks to other teams and uh to actually provide just some basic info instead of jumping in ourselves into the code so uh something that we do is for example we have a role of a problem solver within our team uh that we actually rotate around with so this is just a role for someone to take off the load

of the rest of the team and just jump in and help uh the rest of the developers in the community out and this is just say for example a weekly rotation but uh it's not like it's very common that the team has to jump into the code of others and uh do changes but instead it's just like uh answering a question and let and giving it's like

uh giving a fishing rod instead of the fish itself just teach the community how to do something instead of doing it for them okay uh does the platform have restrictions on IDs due to security concerns actually no our platform doesn't really have any restrictions on IDs uh we a lot most of us just use either Visual Studio code or webstorm but I know that some people use

neovim and similar uh IDs so there's not really much in terms of restrictions because there's not like uh many things that can interfere with the security I guess plugins always have to be uh monitored but this is something that a developer consciously looks into and it's just easy to pick up any ID that you're used to uh and just start working with it on platform yeah uh

I guess that's all that we have thank