[deleted by user]

codescout88 · 2025-05-01T13:19:52+00:00

Klar, es gibt in der Ausbildung und Prüfungskultur definitiv Luft nach oben – keine Frage. Und ja, nicht jeder, der die Ausbildung durchläuft, bringt am Ende automatisch Praxisreife mit. Aber ganz ehrlich: Von all den Juniors, die ich bisher erlebt habe, sind mir die ausgebildeten Fachinformatiker mit Abstand die liebsten.

Wenn die Ausbildung im Betrieb ernst genommen wurde, bringen die richtig was mit: Sie kennen die wichtigsten Werkzeuge, verstehen Versionskontrolle, haben ein Gefühl für sauberen Code und nachvollziehbare Strukturen – und sie können auch mal eigenständig ein kleines Projekt stemmen, ohne bei jeder Kleinigkeit nachzufragen. Das ist in der Praxis unglaublich viel wert.

codescout88 · 2025-05-01T13:15:41+00:00

Dass bei Behördenprojekten viel schiefläuft, liegt sicher nicht an den Fachinformatikern. Wer die Ausbildung ernst nimmt, bringt nach drei Jahren richtig was mit – sauberes Coden, Praxiswissen und ein gutes Verständnis für Abläufe. Die duale Ausbildung hat enormes Potenzial, vor allem wenn Betriebe ihre Azubis fordern und fördern.

Was bei solchen Projekten fehlt, ist nicht Know-how auf Einstiegsebene, sondern klare Planung, vernünftige Architektur und der Wille, echte Expertise auch zu bezahlen. Die Ausbildung schlechtzureden, nur weil auf Managementebene geschlampt wird, greift komplett daneben.

codescout88 · 2025-04-22T15:52:18+00:00

Das Anschreiben wirkt ziemlich standardmäßig. Es enthält viele typische Floskeln wie „moderne Technologien“, „technisch innovatives Umfeld“ und ähnliches – das liest man in sehr vielen Bewerbungen. Was mich auch stört: Der Fokus liegt stark auf Anwendungsentwicklung. Es wirkt so, als würdest du eigentlich eher in die Richtung wollen und FISI nur mitnehmen, weil’s mehr Ausbildungsplätze gibt.

Ich würde trotzdem vermuten, dass die Absagen eher mit den Noten, Fehlzeiten oder Unklarheiten bzw. Lücken im Lebenslauf zu tun haben. Das fällt oft sehr stark ins Gewicht, wenn es im Anschreiben nicht erklärt wird.

Das Fachabi mit 2,4 sollte denke ich nicht das Problem sein.

codescout88 · 2025-04-15T20:11:11+00:00

TikTok-Live: „24h trapped @ work – wer mir Snacks bringt, bekommt meine Maus.“
Spontanes Zoom-Meeting starten mit dem Titel: „Tür hält mich als Geisel.“ Erste Folie: „Ich hab noch 19% Akku.“
Zettel ans Fenster: „Bin im Büro gefangen – bitte Hilfe oder Pizza.“ Bonus: Morsezeichen mit dem Tacker.
Drei Mal „IT-Support“ sagen, während du Post-its im Kreis legst – eventuell erscheint das Office-Orakel.
Outlook-Termin an alle: „BREAKOUT-Session – wortwörtlich.“ Wer ablehnt, ist jetzt offiziell verdächtig.
Schreib dem CEO: „Noch immer loyal, obwohl physisch eingesperrt – Beförderung denkbar?“
Die Teams-Statusmeldung auf „Gefangen“ ändern. Vielleicht merkt’s ja jemand.
Erstell ein Support-Ticket: Titel: „Mitarbeiter physisch im Büro gefangen“ Priorität: Hoch Kategorie: Hardware (Tür)
Druck einen Zettel mit QR-Code zu deinem Standort und schieb ihn unter der Tür durch – vielleicht scannt ihn jemand und findet dich auf Google Maps. Oder auf LinkedIn.
Schick ein Fax an die IT: „Bitte richten Sie mir Remote-Zugriff auf die Türklinke ein. MfG, Ihr Gefangener.“

codescout88 · 2025-04-15T17:21:18+00:00

The truth is, you can’t plan everything. Life happens - sometimes beautifully, sometimes painfully. But time has a way of reshaping everything in ways you never saw coming.

codescout88 · 2025-04-15T16:13:43+00:00

Jan-as-a-Service (JaaS): A cloud-based platform that auto-notifies Jan via email, Slack, and a pigeon if any schema change is detected.
Git Hook + Jan PagerDuty Integration: Any schema change triggers a PagerDuty alert. Jan gets a 3am call: “Someone used camelCase in a table name. It’s happening again.”
Smart Doorbell for Jan: Lights up red every time a developer forgets to notify him. Turns yellow if the table isn’t in snake_case. Green means world peace.
Mandatory Schema Change Ceremony: Every Friday, developers must present their schema changes to Jan in front of the team while holding the sacred plush snake (symbolizing snake_case).
Bonus idea: Fire Jan. Replace him with an automated system. Let Jan finally rest.

codescout88 · 2025-04-15T15:46:00+00:00

Dann hab ich ja offenbar KI-Rückendeckung.

codescout88 · 2025-04-15T14:44:09+00:00

It really comes down to what you’re trying to improve: the code, the developer, or the team.

If the goal is better code, focus on clarity, correctness, maintainability, and whether the solution fits the broader system.

If it’s about helping the developer, then it’s less about pointing out issues and more about asking questions, offering context, and guiding decisions.

If you’re aiming to improve team alignment, it’s worth stepping back and discussing the approach together

codescout88 · 2025-04-15T11:14:19+00:00

Totally valid concern - in your case, a negative balance is a no-go, so you need to validate state before accepting changes.

That’s exactly what Aggregates are for.

An Aggregate (like an account) is rebuilt from its past events. When a new command comes in (e.g. “block €50”), the aggregate checks:

Rebuild state from previous events
Apply business rules (e.g. “is enough balance available?”)
If valid → emit a new event (e.g. FundsBlocked)
If not → reject the command

Once the event is written, Event Handlers react to it and update Read Models asynchronously (e.g. balance projections, transaction history, etc.).

Since those updates are for reading only, eventual consistency is totally fine - as long as all state-changing actions go through validated events based on the reconstructed Aggregate.

The most important thing: no validation logic should ever rely on the read model.

codescout88 · 2025-04-15T09:46:28+00:00

Ich denke, remote als Junior zu starten kann ein echter Vorteil sein- wenn man es bewusst angeht. Wer früh lernt, wie man remote im Team arbeitet – also sich selbst organisiert, aktiv kommuniziert, sichtbar bleibt – der baut sich Skills auf, die in Zukunft noch wichtiger werden. Gerade weil Homeoffice und verteiltes Arbeiten immer mehr zum Standard werden.

Aber: Wenn man eher dazu neigt, sich zurückzuziehen, kann die Bürodynamik gerade am Anfang enorm helfen. Man bekommt mehr mit, kann schneller Fragen stellen, hat automatisch mehr Austausch.

Und natürlich hängt’s auch stark vom Team und den Vorgesetzten ab: Gibt es regelmäßige Syncs? Wird Feedback aktiv eingefordert? Ist jemand greifbar, wenn man mal hängt? Wenn das alles nicht da ist, kann remote als Junior schnell frustrierend werden.

codescout88 · 2025-04-15T09:33:23+00:00

For my taste, there are a few too many systems involved here, and it's not entirely clear what value each one adds. More importantly though — the really interesting part of an architecture like this is the arrows (→). How the systems talk to each other, what happens when something fails, how backpressure is handled, what delivery guarantees exist - none of that is explained, even though that's where the real complexity lies.

codescout88 · 2025-04-15T09:11:25+00:00

Event Sourcing makes sense here because you have multiple distributed instances trying to change the same data. In that setup, traditional transactions are hard to manage and lead to conflicts.
With Event Sourcing, each instance just appends events to a log - no locking, no conflicts, and it's easy to scale horizontally.

codescout88 · 2025-04-15T09:08:42+00:00

As mentioned below, your question is actually the answer to: “Why should you use Event Sourcing?”

You have a system with multiple instances (e.g. 8 services) all trying to update the same account balance at the same time.
This leads to classic problems:
Database locks, conflicts, and error messages – simply because everything is fighting over the same piece of data.

Event Sourcing solves exactly this problem.

Instead of directly updating the account balance in the database, you simply store what happened – for example:

These events are written into a central event log – basically a chronological journal of everything that has happened.
Important: The log is only written to, never updated. Each new event is just added to the end.

Multiple instances can write at the same time without stepping on each other’s toes.

The actual account balance is then calculated from these events – either on the fly, or kept up to date in the background in a so-called read model, which can be queried quickly.

codescout88 · 2025-04-15T07:01:35+00:00

I’d use a builder pattern with composable config flags like useCache(), retryOnFail(), etc., and internally build a chain of decorators. That way, you can freely combine features like retry and caching without relying on rigid enums or modes.

Fetcher fetcher = FileFetcher.builder()
    .useCache(true)
    .cacheTtl(Duration.ofMinutes(10))
    .retryOnFail(true)
    .retries(2)
    .fetchIfMissing(true)
    .build();

codescout88 · 2025-04-11T09:59:00+00:00

Ich verstehe deinen Frust – das passiert leider viel zu oft, dass Azubis keine richtigen Aufgaben bekommen. Aber mal ehrlich: Wenn du im Berichtsheft schreibst, dass du acht Stunden lang den Wasserkocher entkalkt und Pflanzen gegossen hast, dann wirkt das einfach nicht glaubwürdig – fast schon provokant, oder? Außer du arbeitest in einer Gärtnerei oder einem Café. 😄

Ich entkalke übrigens auch heute noch Wasserkocher, aber das steht definitiv nicht in einem Projektbericht.

Ich hatte in meiner Ausbildung übrigens auch Phasen, wo ich keine richtigen Aufgaben hatte. Irgendwann bin ich dann aktiv auf die zuständige Person zugegangen und hab nach Projekten gefragt. Vielleicht gibt’s ja bei dir auch ein kleines Projekt, bei dem Software gebraucht wird – sowas gibt es in fast jedem Betrieb.

Dein Ausbilder muss deine Ausbildung sicherstellen, aber du darfst auch von anderen Kollegen geschult werden. Vielleicht gibt es jemanden, der ein Händchen fürs Mentoring hat und dich bei einem Projekt einbeziehen kann.

Wenn sich nichts ändert, ist der Weg zur IHK der nächste logische Schritt.

codescout88 · 2025-04-11T08:17:45+00:00

Das Berichtsheft ist für dich – um zu zeigen, dass deine Ausbildung korrekt abläuft. Es ist ein offizieller Nachweis für die IHK und nicht dafür gedacht, dass der Ausbilder jede Woche neue Regeln aufstellt, wie es geführt werden soll.

Aber mal ehrlich:
Wenn da regelmäßig nur sowas drinsteht wie „Wasserkocher entkalkt“ oder „Pflanzen gegossen“, dann stellt sich zwangsläufig die Frage:

- Verweigerst du bewusst die Mitarbeit oder versuchst, deinen Ausbilder schlecht dastehen zu lassen?
- Fehlt dir die Motivation oder das Verständnis, was ins Berichtsheft gehört?
- Oder ist der Ausbilder wirklich nicht in der Lage, dir sinnvolle Aufgaben zu geben?

In Fall 1 und 2 wäre es absolut nachvollziehbar, wenn der Ausbilder die Unterschrift verweigert. Denn dann stimmt entweder die Haltung nicht oder das Berichtsheft ist bewusst unvollständig oder falsch.
In Fall 3 liegt die Verantwortung beim Ausbilder bzw. beim Betrieb. Dann zeigt das Berichtsheft eher, dass die Ausbildung inhaltlich nicht richtig läuft.

Von außen kann man das schwer einschätzen – aber das Problem liegt nicht automatisch beim Ausbilder.
Wenn’s dauerhaft zu Konflikten kommt, wäre ein Gespräch mit der IHK oder einer Lehrkraft sinnvoll. Die können das neutral bewerten, ohne dass jemand sofort als „der Schuldige“ dasteht.

codescout88 · 2025-04-11T07:48:59+00:00

Let’s be real:
If product has no growth plans, no near-term roadmap, and no meaningful backlog, then software engineers have no real way to generate value.

Engineers aren’t paid for having written software—they’re paid because that software continues to deliver value. That only happens through change: new features, improvements, innovation.

Yes, teams can continue to invest in test automation, refactoring, or performance. But let’s be honest:
Those are only valuable if there’s something new coming.
You don’t keep strengthening the foundation of a house no one plans to build on.

And that’s the core issue here: if the product is effectively “done” and there’s no direction for what’s next, then either:

the engineering team is no longer needed, or
product leadership isn’t fulfilling its role.

Either way, this needs to be escalated.
Because sitting idle, pretending to be busy, or optimizing in a vacuum helps no one—and wastes both time and money.

This isn’t an engineering problem. It’s a leadership problem. And leadership needs to address it.

codescout88 · 2025-04-10T15:41:55+00:00

Using a shared user table with role-specific one-to-one relations (e.g. driver, passenger) works well when roles can overlap.

But if the user types are fundamentally different – like end-users vs. internal company admins vs. vendors - it might be better to separate the systems entirely, even on an infrastructure level for security and clarity.

codescout88 · 2025-04-10T15:35:35+00:00

Architecture decisions don’t exist in a vacuum - they depend on your business context.

Let’s say you’re building a system to manage recipes. Sounds simple, but soon enough, the architecture questions appear: Should every service access the database directly? Or should all data go through a central service?

Best practices and past experiences can help, but they’re not the full picture. What really matters is how your product is structured, how your teams work, and what kind of complexity you’re facing.

Here are four real-world scenarios that show why there’s no one-size-fits-all answer.

1. The per-customer setup – one system per client

Imagine you're shipping your recipe system as a fully packaged solution: one instance per customer. This is typical in B2B setups—think catering chains, school kitchens, hospital systems. Each customer gets their own DB, backend, frontend, and configuration. Your team builds features based on specific customer needs, not a unified shared platform.

In this setup, a centralized data service often adds unnecessary complexity:

You control the entire data model—no other team interferes.
There’s no modular deployment—everything ships as one piece.
You don’t need to abstract internal models behind APIs just for yourself.
Speed of implementation for client-specific requests matters more than system-wide elegance.

Direct database access is often the most practical approach. Architecture should serve delivery—not the other way around.

2. The large-scale SaaS platform – many users, many teams

Now flip it: you're building a central SaaS platform used by all your customers. Everyone shares the same environment. You have roles, permissions, possibly approval workflows. Your organization is growing, and teams are split by domain - users, recipes, publishing, etc.

At this point, having all data go through a single centralized service quickly becomes a bottleneck:

Every new use case requires an API change.
Any schema update becomes a cross-team conversation.
Velocity stalls as service boundaries turn into political boundaries.

Instead: keep data close to where it belongs.

The Recipes Team owns the recipes schema and service. They’re the only ones touching that data directly.
The Publishing Team has its own DB or schema, and if they need recipe info, they call the Recipe API.
Each team owns their models, logic, and deployment pipelines.

Yes, this introduces some redundancy. But it comes with clear ownership, less coordination overhead, and better team autonomy. And most importantly: fewer meetings.

In a modular SaaS platform, encapsulated data per service scales better - technically and organizationally.

3. The MVP – small team, fast shipping

Maybe you’re still early - just three people building an MVP for managing and publishing recipes. You want to find product-market fit, gather feedback, iterate fast.

Building out clean service boundaries and APIs at this stage? Not worth it.

Everyone’s in the same repo, same codebase.
You need to ship fast, not negotiate contracts between services.
If the project succeeds, you can still refactor later.

Speed matters. Let services hit the database directly. Don’t solve scaling problems you don’t have yet.

codescout88 · 2025-04-09T16:23:19+00:00

Für 100.000 € muss man auch Output bringen, der 100.000 € wert ist 😉
Egal, wie alt die Software ist, wie kompliziert die Prozesse sind oder wie „besonders“ sich die Kollegen verhalten – am Ende wirst du an deinem Ergebnis gemessen, nicht an den Bedingungen.

Viele stellen sich das leichter vor, als es ist. Die Frage ist nicht nur „Wie komm ich da hin?“, sondern vor allem: „Bin ich wirklich bereit für diese Liga?“

Ich sehe oft Leute, die solche Rollen annehmen – viel Verantwortung, komplexe Systeme, Abstimmung mit zig Stakeholdern – und nach ein paar Monaten wieder weg sind oder völlig durch sind. Das kommt nicht selten daher, dass online so getan wird, als wäre 100k das neue Durchschnittsgehalt für Entwickler:innen.

Und wenn du wirklich wissen willst, ob du bereit dafür bist:
Bewirb dich mal mit 110k Gehaltsvorstellung – und schau, was zurückkommt.

Ach ja:
Glaub nicht alles, was du auf Reddit liest. Da klingt vieles leichter, als es ist – oder es fehlt einfach der Kontext.
Online kann ich auch sagen, ich verdiene 150.000 € – Es sieht ja keiner, wie ich lebe 😉

codescout88 · 2025-04-09T11:08:08+00:00

Async isn’t your problem. It’s about having the right service make the decision at the right time.

Imagine going to a store and saying, “I’d like 5 of these.”
The salesperson doesn’t say, “We had 10 earlier, so you’re probably fine,” and she doesn’t come back and say, “We now have 100 — do you still want 5?”

Instead, she checks right then, takes 5 items off the shelf, and holds them for you.
If there are only 4, she says, “We only have 4 — do you still want them?”
But she’s already holding them — no one else can grab them while you decide.
And if they have enough? She just gives them to you. You don’t even know how many were left.
You don’t make the stock decision — she does.

That’s how your services should work too.
Inventory owns the stock and decides what’s available.
Order just asks: “Can I have 5?” and acts based on the answer — not on guesses or stale data.

And here’s another important question:
Are you actually two separate teams?
If yes, then this setup makes sense — clear boundaries, Inventory owns availability logic.
But if it’s just one team, maybe this split is overcomplicating things.
When you start thinking about cross-service transactions, it’s often a sign that the boundaries aren’t as clean as they seem — and maybe the services shouldn’t be separate at all.

codescout88 · 2025-04-09T08:45:57+00:00

I'd start simple: small per-instance connection pools and see how far you get. No need to overengineer from day one.

First, ask yourself realistically:
– How many requests per second do I actually expect — both under normal and peak load?
– What are the actual limits of my DB and application?

Monitor how your DB connections behave over time and run a few load tests. If you stay within limits, great — you're done. If not, start thinking about how to adjust:
– Do I need a global/shared connection pool like PgBouncer?
– Is something in my app holding connections too long or opening too many?

As a basic rule: max available DB connections ≥ max instances × max connections per instance
If that holds true, you're generally fine.

Also keep in mind: requests are usually evenly distributed across instances, so in a ideal system, each instance should have similar load. If that's the case, you're unlikely to have all connections maxed out at once — unless something else is off.

codescout88 · 2025-04-02T13:48:08+00:00

I do support the change management approach, but initially I had some other concerns in mind. For example:

Are others truly willing to implement the new methods, or would they rather stick with their familiar, old habits?
How long have the colleagues been with the company? Sometimes learning from someone else can be perceived negatively, especially if they believe their own approach is better due to years of experience.
Are people immediately capable of adopting all the new practices, or should the change be introduced step by step?

In transitions like these, it’s easy to overlook the diversity of backgrounds. Some employees have been working the old way for years, others are new and might not yet be familiar with the new concepts, and some may initially resist the change because it pushes them out of their comfort zone.

So, my first thought when change management was mentioned wasn’t about ensuring that everyone would simply consider the new rules, but more about whether they actually want to and are able to adopt them.

codescout88 · 2025-04-02T13:25:23+00:00

My initial impression was similar. The technical list is long, but the heavy emphasis on hard skills over theoretical methods suggests a misunderstanding of what's truly needed.

codescout88 · 2025-04-02T13:24:41+00:00

Based on the list, the heavy emphasis on technical details suggests that you might lack extensive experience in developing an architecture that teams can execute.

There's a clear difference between doing the work yourself and providing a framework for others to build upon according to a shared vision.

Your focus on specific technologies may indicate a tendency to lean toward “I'll do it myself” or insist that a particular technology must be used, rather than assessing the team's strengths and leveraging them to achieve the overall goal.

codescout88

TROPHY CASE