As a backend developer at Bankdata, he spends much of his time working with the technical foundations that other developers build on. His role is often to understand the complicated parts, create shared solutions around them and make life a little easier for everyone else.
“What I find interesting is taking something complex and making it simple. All the functionality still needs to be there, but the complexity should be removed for the people using it.”
That idea runs through much of the work he does.
Removing complexity so others can focus on their work
Kasper works with frameworks and shared components that are used across Bankdata. Many of them are built to solve problems that would otherwise have to be handled again and again by individual teams.
For him, the goal is not that everyone understands every technical detail.
He compares one part of Bankdata’s infrastructure to a postal service. Messages need to move from one place to another, just as letters need to reach the right recipient. Understanding exactly how that machinery works can be complicated. But if the right abstractions are in place, most developers should not have to think about all of it.
Instead, they can spend more of their time on the business problem they are actually trying to solve.
“It’s about removing cognitive load. People should focus less on everything around the solution and more on the business, which in the end should lead to better results, better products and better experiences for both the banks and their customers.”
The same mindset applies when new technologies are introduced. Rather than asking every team to figure out the underlying setup themselves, Kasper and his colleagues try to provide tools that make it easier to get started. 
Curiosity before grand plans
One example began when a tool used by several teams was discontinued.
Kasper’s own team needed an alternative. He could have created a small replacement that solved only their immediate problem. But he also knew that other teams were using the same tool and would face similar challenges.
With approval from his manager and product owner, he started building a replacement.
What emerged was a solution capable of translating COBOL into Java. According to Kasper, it is now used in several systems at Bankdata, including systems related to real-time prices.
When the interviewer suggests that the project sounds like strategic future-proofing, Kasper immediately tones that interpretation down.
“I was just interested in whether it was possible.”
In this case, curiosity came first. Could the problem be solved? Could the tool be rebuilt in a way that others could use as well?
Since he was already going to solve the problem for his own team, Kasper saw little reason not to make the solution useful to others at the same time. 
Headphones on, problem in front of him
Kasper describes himself as a heavy backend developer.
User interfaces and visual design are not where he feels most at home. Friends who work with interfaces have a simple description of his work:
“It’s practical. It’s not pretty.”
What he enjoys are problems that require concentration.
“The more complex a task is, the more interesting it becomes.”
Sometimes that means spending an entire day trying to understand why something does not work. Not necessarily fixing it immediately. First, he wants to understand what is actually going wrong.
“There’s a moment where suddenly everything makes sense. It may not be easy to solve yet, but now we know what the problem is. Then we have something to work from.”
One project occupied almost an entire week. Headphones on. Technical music playing. Most of the working day spent on the same difficult problem.
Kasper describes it as intense and hard, but also relaxing in its own way.
When the problem is complex enough to demand his full attention, that is where he says he can settle into it.
From a website bought by mistake
His interest in what happens behind the screen started early.
At the age of 13, Kasper accidentally bought a website. Since he had paid for it, he decided to find out what he could actually do with it.
That led him behind the visible parts of the site and into the technology underneath.
Later, at technical upper secondary school, he met others who shared his interest in programming. One of them, also called Kasper, became one of his best friends. They programmed together, compared different approaches and eventually ran a business together while studying.
The programming appealed to him. Running a business less so.
“There was so much work involving everything that wasn’t programming.”
By the later years of his studies, Kasper had become interested in working in the financial sector. He applied for a position at Bankdata and joined the company in 2019.
He later moved to Greenland, resigned from Bankdata and continued working for the company for a period as an external consultant before eventually becoming an employee again.
Helping others move forward
Complexity may be what draws Kasper in, but helping others is another important part of his work.
Throughout the interview, he returns several times to the satisfaction of helping colleagues overcome technical obstacles, understand a difficult concept or move forward with a task that has been blocking them.
On the day of the interview, he had already been on several calls with colleagues asking questions or looking for clarification.
He particularly enjoys the moment when someone he is helping suddenly understands the problem for themselves.
“If I can see that someone has that ‘aha moment’, then I feel I’ve helped make their day a little better.”
There is also a more pragmatic side to his approach.
Kasper describes himself as somewhat lazy when it comes to repetitive work. If the same problem keeps appearing, he would rather solve it once and make the solution reusable than repeat the work.
“If 80 per cent is the same, why should we keep building it again and again?”
The same instinct follows him home.
He runs his own servers, experiments with home automation and has a 3D printer that has produced everything from hooks for baby monitors to a holder that stops a cable from falling off his desk.
Not all of the projects are completely finished.
“We make it functional, and then we finish it later.”
At work, however, “good enough” also has clear limits. Kasper points to stability, security and correct data as priorities that come before additional features.
And much of his work comes back to the same basic idea: understanding something difficult well enough that others do not have to spend as much time on it.
The more complex the problem, the better.
Are you looking for new challenges? See our open positions here