The real everyday life at erminas
Many companies have these trainee portraits in which everything runs perfectly. The trainee comes into the office at eight sharp, works on exciting projects, learns five new technologies on the side and goes home fulfilled in the evening. The reality is usually different – and for us anyway, because the basic assumption is not correct. At eight o’clock on the dot, nobody is usually there at erminas.
This text describes a normal day in training with us. Not the best day and not the worst. A Wednesday in March that shows how things really work – with the productive phases and the tough ones, with the moments when everything works and those when the code does what it wants, just not the right thing.
08:30 a.m. - Arrive when it suits you
Max gets off the bus and walks towards the “Hallig Hanken”, a large hall in which a number of converted containers serve as offices. You can already see screens glowing behind the windows, whiteboards with sketches, a 3D printer rattling somewhere in the background. Small start-ups sit between the containers, each company with its own style, but all sharing the same hall.
On the way to his container, Max passes the other teams, nods a quick “hello” here and there and perhaps stops for a moment at the shared kitchen, where someone is already making coffee. Then he stands in front of erminas’ door, unlocks it and steps into the office.
A few colleagues are already here, others arrive later. At erminas, we have real flexitime – not the kind where everyone is officially flexible but unofficially expected to arrive at eight o’clock. Here, everyone really does start when it suits them. The only condition: The hours have to be right at the end, and whoever is scheduled for a meeting is also on site.
10:00 a.m. - Dailies: Short but important
The dailies start at ten. Depending on the project, Max has one daily on some days and two or three on others. Today there are two – one for the IoT project that he is mainly working on at the moment and one for a smaller side project that he is supporting.
Each Daily lasts about fifteen minutes. The format is simple: What did I do yesterday? What am I doing today? Are there any obstacles? No lengthy discussions, no status reports for management, no pressure to justify. Just a quick check-in with the team so that everyone knows what’s going on today.
In the first Daily, Max reports that he continued to work on the sensor connection yesterday. The data is now arriving reliably, but the display in the dashboard is still causing problems. He wants to tackle this today. A colleague mentions that he had a similar problem last week and offers to take a quick look at it later if Max gets stuck.
The second daily is even shorter. The side project is running smoothly, Max’s part is mostly done, he’s waiting for feedback from the customer. Nothing new, let’s move on.
Both dailies are finished by half past ten, and Max has the rest of the morning to work.
10:35 a.m. - Coding, finally
The next hour and a half is dedicated to code. No meetings, no interruptions, just Max and the dashboard problem.
The problem is one of those things that seem trivial at first glance and then turn out to be stubborn. The sensor data is coming in correctly, he verified that yesterday. But in the dashboard, some values are displayed incorrectly – not all, just some, and seemingly without pattern.
Max starts debugging systematically. He checks the data at various points in the system. At the sensor: correct. After transmission: correct. In the database: correct. In the backend: correct. In the front end… that’s where it gets strange.
At erminas, this systematic debugging also means that software tests are a natural part of the work – regardless of whether someone is a senior developer or an apprentice. Everyone writes unit tests for their own code, plus automated checks in the build pipelines and later code reviews in the team. As a result, many errors are caught before anyone even sees them in the browser. But sometimes a bug slips through anyway and hides in a corner that nobody has tested yet – like today.
He takes a closer look at the front-end code. Somewhere between the database and the display, something happens that shouldn’t happen. He adds logging, runs the system, looks at the output. Slowly, a pattern emerges: the problem only occurs with certain timestamps.
12:15 p.m. - Lunch break with colleagues
At erminas, lunch break really means a break. Everyone usually brings something from home or the bakery and sits down at the tables directly in front of the containers. The team is small and the age groups are mixed. On some days, things get a bit more communal: then they order pizza or kebabs together and everyone sits together in a relaxed, informal atmosphere.
They talk about all sorts of things. A new restaurant that has opened. The absurd traffic situation at the construction site in front of the office. Someone talks about a podcast they’ve been listening to. Work is only mentioned in passing, and that’s a good thing.
1:30 p.m. - Trainee Weekly
After the lunch break, it’s time for the Apprentice Weekly. This is a fixed date every week when the trainer and all trainees come together – there are currently three of them, in different apprenticeship years and with different focuses.
The format is relaxed but structured. Everyone reports briefly on what they are currently working on and how things are going. Not just roughly as in the Daily, but with more detail. What are the current projects? Where are there challenges? What have you learned recently?
Today Max tells us about his time zone problem. A third-year apprentice nods knowingly – he once had something similar and gives a tip on where else Max could look. A fellow first-year apprentice listens and takes notes. At some point, she will face similar problems and it will help to have heard about them before.
Part of the meeting also revolves around vocational school. There’s an exam next week and someone has questions about the material. The great thing about the Apprentice Weekly is that the different apprenticeship years learn from each other. Those who are one year ahead already know the exam and can give tips. Those who are a year behind can see what to expect.
14:20 - Back to the bow
The time zone bug is still waiting. With the tip from the Azubi Weekly, Max now has a new idea of where he could look.
It finds the location faster than expected. A JavaScript library that processes timestamps interprets certain formats differently than expected. The documentation is unclear, which has led to the problem. In the end, the solution is just a few lines of code, but it took hours to get there.
That’s software development. Sometimes you spend half a day trying to find a problem that can be solved in thirty seconds. Max has now accepted the frustration of this. It’s part of the job. And the feeling when the bug is finally found makes up for some of it.
He writes a short entry in the internal wiki: Problem, cause, solution. If someone else faces the same problem, they don’t have to go down the same path.
15:30 - Tests and tidying up
The bug has been fixed, but the work is not yet finished. Before the code can flow into the main project, it needs tests. Max writes a few unit tests to ensure that the timestamp conversion now works correctly – not only for the current case, but also for special cases that could occur later.
From the outside, this often seems like unnecessary extra work: the bug has been fixed, the function works, why spend time testing now? In practice, it is precisely these kinds of tests that ensure that the code will still work in a few months’ time if someone else changes something or new features are added. Especially in larger projects with many developers, external partners and several parallel branches, several security instances are needed to ensure that nothing gets mixed up: clean code, comprehensible commits, automated tests and later code reviews.
Tests are therefore not a “nice to have”, but an important part of professionalism. They catch problems early on, before they end up with the customer or in production – even if it sometimes just feels like “annoying extra work” at the moment.
16:30 - Code Review
Max’s changes are finished and tested. He creates a pull request – a request to incorporate the code into the main project – and briefly describes what he has done and why. Automated checks run in the background: The tests kick in, linters check code style and formatting. The next step is only taken once this protective layer is green.
Now someone else comes into play. At erminas, you don’t review your own pull requests yourself – a colleague always does this. Depending on the project, sometimes even two people look at it. This is not because we distrust each other, but because a second pair of eyes almost always sees details that the first has missed: a marginal case, an incomprehensible variable, a comment that could be more precise.
Of course, this can sometimes feel like extra work: waiting for feedback, answering comments, rebuilding again. But it is precisely these loops that ensure that the project remains stable even when many people are working on it at the same time – internally, externally, across multiple locations and time zones.
While he waits for his own pull request to be reviewed, Max takes a look at a pull request that a colleague created this morning. Code review is not a one-way street. Even as an apprentice, he should and may review other people’s code. You learn at least as much from reading other people’s code as you do from writing your own.
At one point, Max doesn’t understand what the code is doing. He writes a comment with a question. No criticism, just curiosity. Maybe there’s a good reason that he doesn’t see. Or maybe the passage is actually confusing and should be written more clearly. The conversation will show – and if in the end the code is better and more understandable, the effort will have been worth it.
17:15 - Closing time
Max makes notes for tomorrow: What is still open? Where does he want to continue? The pull request review is still pending, probably tomorrow morning. After that, he could start building the next feature.
He shuts down the computer and says goodbye to the colleagues who are still here. Some will stay for a while, others have already left. At erminas, there is no social pressure to be the last to leave and no suspicious looks if you are the first to leave. The work is done, the hours are right, we’ll continue tomorrow.
And what does that mean for you now?
That was a Wednesday in March at erminas – not one where everything went perfectly, but also not one where everything went wrong. A lot of it is just normal everyday life: searching for bugs, meetings, writing tests, reviewing code. Sometimes it’s frustrating, sometimes it’s really fun, often it’s just honest, concentrated work in a team.
If you want an apprenticeship where you’re not just “employed” but really part of a project – with responsibility, real customers, real problems and real solutions – then this could be a good fit for you. You must be willing to fight through tough bugs, write unit tests, read pull requests from others and have your own code scrutinized by someone else. In short, you must have a desire for professionalism, even on the days when it feels more like “annoying but necessary”.
If this sounds like you and you can imagine spending your own Wednesday in March with us, take a look at our careers page and apply:
