Looking at the comments in contrast with your edit, it's true that a lot of the comments are (unfortunately) not very penetrable/understandable to people who don't understand these things (most people don't know what DNS is for example - let alone dependencies etc.)
You might want to look at how the Murderbot series by Martha Wells handles talking about code and conflicts with code in a way that is plain language to newcomers, it will be more accessible and even show how to inject tension and fraught emotion into those scenes. It's being made into a TV series, so you can also watch the first three episodes, but honestly I think Wells is very clever for how she handles the details of a story where basically a human computer is frequently interfacing with other computers, and handles literally all kinds of security from the physical to the online.
Murderbot / Secunit frequently has to explain things going wrong to people who don't understand those things, as well as talk to computers who do, and yet that all has to remain understandable to the reader. So this is a good place to start for accessing this kind of language.
Alternatively, goddess47 's suggestion to write the scene without worrying about the jargon first is the best way to go.
There are many, many ways to write two characters growing closer, while also hiding something in plain sight, even if they both work in IT. I agree with some of the others that it would be a bit odd for people to upload custom security without that person being there troubleshooting it for them (or having a team to troubleshoot it for workers) as this is standard. When something custom is made for a workplace, typically, people will come into that workplace and run classes / literally set it up for them / walk them through how to use it / and notice any bugs that didn't make it through testing (which is something this security should *absolutely* have had) and also support and reassure workers who often don't *want* new systems and can be quite hostile to them.
Unfortunately some aspects of the scene you want to write are not very realistic to how a lot of these things are often implemented nowadays, especially when it comes to custom code commissioned by a workplace for specific needs. Especially when that code is around security.
This also might be why some of the answers aren't fitting what you need, because these situations don't really happen in the way you're imagining.
The easiest way to get around that is to keep the core of the scene - two people getting closer in a workplace, and also hiding something in plain sight (not sure what you mean by this - you mean they're altering the code? Hiding an object? They're hiding that they're helping out on the code in plain sight? etc.) - and to step away from needing the scene to unroll in this specific scenario.
Even if your characters are computer engineers themselves or work in code, they would not be troubleshooting something as serious as custom security if they didn't write it themselves. They would be sending a ticket / bug / report / calling the person or team who wrote that code.
(Experience: My mum worked for many years in a team that educated the government in how to install and run new codes and programs in the justice system in Western Australia, so the security was - as you can imagine - very important. What I learned from that is that you have many smaller teams involved in something like this on a large scale level - the testers are one part, the coders are another, the engineers are sometimes another, the people who educate those who are learning the program are another, the people who take tickets and complaints and bug reports are another, and they don't all communicate to each other very well. So the idea that two people in that setting (and we don't know your setting at all, so I can only share what I know) would 'troubleshoot' a bug independently when there are literally 60~ people working on this custom issue that you would report to first, speaks to great incompetency and misunderstanding on their behalf. This was my mum's experience in the 90s and 00s, to give you an idea of how long this has been the norm re: implementation.
Small companies often simply cannot afford custom security code (it can take many years to write, test, implement, troubleshoot, update etc.), they would be working with larger cybersecurity companies who provide more generic security code. Even small tech companies do not just find a random person to make their security code for them.
Larger companies that can afford custom security code and have a need of it (many don't), will be hiring a stable of people to usually work both in-house (in their company to familiarise themselves with the needs of the company and people) and back at their own office/s.
Unless you're writing science fiction, I genuinely can't think of many scenarios where *anyone* would simply write some security code, not test it among many MANY people first, and then pass it to a workplace, and somehow need to not be notified personally when something goes wrong (this would make me immediately not like those coworkers very much, lol, like why do they think they're so much better than the person who *knows* the code?)
It's possible that in being out of touch with this stuff, it's just now working in a completely different way to what you were familiar with. And in that sense, unless you want to go down a big rabbithole of how this stuff often works (which honestly is pretty boring, and very frustrating, because a lot of the time it's the phone team frustrated with the testing team frustrated with the engineers frustrated with the educators frustrated with the workplace people who won't just contact them when something goes wrong etc.) it may be worth changing the premise of the scene while keeping the emotional core of its function.
Alternatively, just make it so that it doesn't have to be security code or encryption, there are workplaces that have in-house folks who work on code for a program that has nothing to do with security (though cybersecurity touches more and more as time goes by), so that's something else to consider!
no subject
You might want to look at how the Murderbot series by Martha Wells handles talking about code and conflicts with code in a way that is plain language to newcomers, it will be more accessible and even show how to inject tension and fraught emotion into those scenes. It's being made into a TV series, so you can also watch the first three episodes, but honestly I think Wells is very clever for how she handles the details of a story where basically a human computer is frequently interfacing with other computers, and handles literally all kinds of security from the physical to the online.
Murderbot / Secunit frequently has to explain things going wrong to people who don't understand those things, as well as talk to computers who do, and yet that all has to remain understandable to the reader. So this is a good place to start for accessing this kind of language.
Alternatively,
There are many, many ways to write two characters growing closer, while also hiding something in plain sight, even if they both work in IT. I agree with some of the others that it would be a bit odd for people to upload custom security without that person being there troubleshooting it for them (or having a team to troubleshoot it for workers) as this is standard. When something custom is made for a workplace, typically, people will come into that workplace and run classes / literally set it up for them / walk them through how to use it / and notice any bugs that didn't make it through testing (which is something this security should *absolutely* have had) and also support and reassure workers who often don't *want* new systems and can be quite hostile to them.
Unfortunately some aspects of the scene you want to write are not very realistic to how a lot of these things are often implemented nowadays, especially when it comes to custom code commissioned by a workplace for specific needs. Especially when that code is around security.
This also might be why some of the answers aren't fitting what you need, because these situations don't really happen in the way you're imagining.
The easiest way to get around that is to keep the core of the scene - two people getting closer in a workplace, and also hiding something in plain sight (not sure what you mean by this - you mean they're altering the code? Hiding an object? They're hiding that they're helping out on the code in plain sight? etc.) - and to step away from needing the scene to unroll in this specific scenario.
Even if your characters are computer engineers themselves or work in code, they would not be troubleshooting something as serious as custom security if they didn't write it themselves. They would be sending a ticket / bug / report / calling the person or team who wrote that code.
(Experience: My mum worked for many years in a team that educated the government in how to install and run new codes and programs in the justice system in Western Australia, so the security was - as you can imagine - very important. What I learned from that is that you have many smaller teams involved in something like this on a large scale level - the testers are one part, the coders are another, the engineers are sometimes another, the people who educate those who are learning the program are another, the people who take tickets and complaints and bug reports are another, and they don't all communicate to each other very well. So the idea that two people in that setting (and we don't know your setting at all, so I can only share what I know) would 'troubleshoot' a bug independently when there are literally 60~ people working on this custom issue that you would report to first, speaks to great incompetency and misunderstanding on their behalf. This was my mum's experience in the 90s and 00s, to give you an idea of how long this has been the norm re: implementation.
Small companies often simply cannot afford custom security code (it can take many years to write, test, implement, troubleshoot, update etc.), they would be working with larger cybersecurity companies who provide more generic security code. Even small tech companies do not just find a random person to make their security code for them.
Larger companies that can afford custom security code and have a need of it (many don't), will be hiring a stable of people to usually work both in-house (in their company to familiarise themselves with the needs of the company and people) and back at their own office/s.
Unless you're writing science fiction, I genuinely can't think of many scenarios where *anyone* would simply write some security code, not test it among many MANY people first, and then pass it to a workplace, and somehow need to not be notified personally when something goes wrong (this would make me immediately not like those coworkers very much, lol, like why do they think they're so much better than the person who *knows* the code?)
It's possible that in being out of touch with this stuff, it's just now working in a completely different way to what you were familiar with. And in that sense, unless you want to go down a big rabbithole of how this stuff often works (which honestly is pretty boring, and very frustrating, because a lot of the time it's the phone team frustrated with the testing team frustrated with the engineers frustrated with the educators frustrated with the workplace people who won't just contact them when something goes wrong etc.) it may be worth changing the premise of the scene while keeping the emotional core of its function.
Alternatively, just make it so that it doesn't have to be security code or encryption, there are workplaces that have in-house folks who work on code for a program that has nothing to do with security (though cybersecurity touches more and more as time goes by), so that's something else to consider!