IT-Berufe-Podcast

Was ist eigentlich diese Cloud und welche Möglichkeiten bietet sie einem Anwendungsentwickler? Und was davon ist eigentlich prüfungsrelevant? Antworten gibt es in der einhundertachzehnten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Für deine Ausbildung als Fachinformatiker:in Anwendungsentwicklung habe ich die Grundlagen zu Cloud Computing zusammengestellt, die auch in IHK-Prüfungen vorkommen. Cloud-Angebote helfen dabei, Anwendungen schnell bereitzustellen und ihre Leistung an wechselnde Last anzupassen. Bei Bare-Metal und On-Premise betreibst du physische Hardware selbst und trägst die Verantwortung dafür. Virtuelle Maschinen verteilen die vorhandenen Ressourcen auf mehrere Betriebssysteme, während du dich weiterhin um deren Pflege kümmern musst und mit großen VM-Dateien arbeitest.

Kapitelmarken

[00:00:00] Einleitung

[00:00:20] Cloud Computing in Ausbildung und IHK-Prüfung

[00:01:36] Geplante Themen der Cloud-Reihe

[00:03:22] Grundidee und Aufgaben eines Cloud-Anbieters

[00:04:53] Wechselnde Last und skalierbare Ressourcen

[00:06:26] Web-Anwendungen und mobile Backends

[00:07:17] Start-ups und kurze Time-to-Market

[00:08:14] Cloud Computing im Internet of Things

[00:10:00] Bare-Metal und On-Premise

[00:12:24] Kontrolle über Infrastruktur und Arbeiten ohne Internet

[00:14:09] Kosten und Aufwand eigener Hardware

[00:16:52] Physische Server im fremden Rechenzentrum

[00:19:09] Grundlagen virtueller Maschinen

[00:21:07] Ressourcen verteilen und VMs skalieren

[00:22:55] Betriebssysteme wählen und selbst betreuen

[00:24:10] VMs auf andere Hardware übertragen

[00:25:02] Schichten von Hardware bis Anwendung

[00:27:27] Aufgaben beim Betrieb eigener VMs

[00:28:13] Größe und Transport von VM-Dateien

[00:29:03] Ausblick auf As-a-Service-Angebote

[00:29:34] Rückblick auf die behandelten Grundlagen

[00:31:20] Beispiele für Virtualisierung

[00:31:38] Feedback und Kontakt

Inhalt

Anwendungsfälle

Webanwendungen und mobile Apps, Startups mit kurzer Time to Market, Internet of Things

Bare Metal bzw. On Premise

Klassischerweise wurden Unternehmensanwendungen auf eigener Hardware betrieben. Wenn sie im eigenen Unternehmen steht, spricht man auch von "on premise".

Vorteile

Komplette Infrastruktur ist unter der eigenen Kontrolle, keine Abhängigkeit von Dritten.

Kann komplett autark vor Ort betrieben werden.

Auch "offline" nutzbar.

Nachteile

Die Hardware muss selbst gewartet werden.

Teure Investitionen zu Beginn nötig.

Schwierig/unmöglich zu skalieren.

Evtl. lange/teure Leerlaufzeiten der Hardware.

Beispiele: Server im eigenen Rechenzentrum, Server-Anbieter wie 1Blu, Hetzner, HostEurope etc.

Virtuelle Maschinen

Um die verfügbare Hardware besser ausnutzen zu können, wurden virtuelle Maschinen eingeführt. VMs simulieren verschiedene Hardwareumgebungen, obwohl sie auf einer einzigen Hardware laufen.

Vorteile

Leichter zu skalieren als Hardware (CPU/RAM kann einfach angepasst werden).

Bessere Ausnutzung der zugrundeliegenden Hardware (mehrere Systeme auf einer Hardware).

Freie Wahl der Betriebssysteme ist möglich.

Nachteile

Installation und Wartung der Betriebssysteme muss selbst durchgeführt werden.

VMs sind sehr groß (mehrere Gigabyte).

Beispiele: VMware, Xen, Citrix, Hyper-V.

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Cloud Computing

Zusammenfassung

Cloud Computing in deiner IT-Ausbildung

Für meine IT-Azubis bereite ich eine Lernzielkontrolle zu Cloud Computing vor. Das Thema kommt auch in IHK-Prüfungen vor und begegnet dir als Fachinformatiker:in Anwendungsentwicklung beim Betrieb von Software.

Anwendungen bei einem Cloud-Anbieter betreiben

Wenn ich eine Anwendung bei einem Cloud-Anbieter betreibe, stellt dieser je nach Angebot Hardware oder virtuelle Maschinen bereit. Auch Netzwerkkomponenten können dazugehören. Welche Aufgaben beim Anbieter liegen, hängt vom gebuchten Dienst ab.

Dadurch lässt sich der Aufwand für eigene Infrastruktur verringern. Ein Unternehmen muss weniger selbst betreuen und kann Leistungen einkaufen, für die es sonst eigene Hardware und Administrator:innen bräuchte.

Bei einem Onlineshop steigt die Last beispielsweise vor Weihnachten. Zusätzliche Leistung lässt sich beim Cloud-Anbieter gegen höhere Gebühren bereitstellen. Wer eigene Server für solche Spitzen anschafft, bezahlt deren laufende Kosten auch während der Zeiten, in denen wenig passiert.

Typische Anwendungsfälle

Web-Anwendungen: Dazu gehören Websites und Onlineshops.

Backends für mobile Apps: Eine App tauscht beispielsweise über eine REST-Schnittstelle Daten mit einer Anwendung aus, die in der Cloud läuft.

Start-ups: Cloud-Angebote erleichtern es, mit wenig Startkapital eine Anwendung bereitzustellen. Neue Funktionen können schnell bei Kund:innen ankommen. Die Zeit von der Idee bis zum verfügbaren Produkt heißt Time-to-Market.

Internet of Things: Vernetzte Geräte senden große Mengen unterschiedlicher Daten. Dafür werden Serverkapazität und ausreichend Bandbreite gebraucht.

Auch andere Softwareprodukte können in der Cloud betrieben werden. Die hier behandelten Beispiele stammen überwiegend aus dem Web-Bereich.

Bare-Metal und On-Premise

Mit Bare-Metal ist ein physischer Rechner gemeint, auf dessen Hardware du Zugriff hast. On-Premise beschreibt den Standort innerhalb des eigenen Unternehmens, etwa im eigenen Rechenzentrum.

Wenn ich dort einen Server betreibe, kann ich defekte Hardware austauschen oder den Rechner direkt ausschalten. Für Reparaturen und den laufenden Betrieb bin ich selbst verantwortlich.

Was du selbst kontrollierst

Du bestimmst, welche Hardware eingesetzt wird, und kennst den Standort der Server.

Deine Daten liegen in deiner eigenen Infrastruktur. Das ist relevant, wenn du aus Datenschutzgründen die Kontrolle über sie behalten musst.

Du entscheidest selbst über den Betrieb und bist dabei unabhängig von den Zusagen eines externen Anbieters.

Anwendungen im lokalen Netzwerk bleiben bei einem Internetausfall erreichbar, sofern sie ohne Internetverbindung arbeiten können. Eine durch Bauarbeiten gekappte Leitung habe ich selbst erlebt.

Welchen Aufwand du übernimmst

Server können hohe Kosten verursachen, bevor deine Anwendung überhaupt startet. Gerade für ein kleines Unternehmen ist das eine finanzielle Hürde.

Du brauchst Fachkenntnisse oder Administrator:innen, die Hardware betreuen und Betriebssysteme aktuell halten.

Wenn die Zahl der Benutzer:innen schnell steigt, musst du zusätzliche Hardware beschaffen oder vorhandene Rechner erweitern.

Wenig ausgelastete Server verursachen weiterhin Stromkosten. Hinzu kommen Kosten für ihre Pflege und für Ersatzteile.

Physische Server in einem fremden Rechenzentrum

Eigene Hardware kann auch bei einem Dienstleister stehen, dessen Netzwerkinfrastruktur du mietest. Ebenso lässt sich ein kompletter physischer Server mieten, beispielsweise bei Hetzner oder 1Blue.

Diese dedizierten Server ordne ich hier dem klassischen Hosting zu. Du erhältst ein bestimmtes Stück Hardware und bist für die darauf installierte Software verantwortlich. Fernzugriff kann es ermöglichen, den Rechner auch bei Problemen mit dem Betriebssystem zu steuern.

Virtuelle Maschinen

Auf einem physischen Server können mehrere virtuelle Maschinen, kurz VMs, gleichzeitig laufen. Jede VM erhält virtuelle Hardware, auf der ein eigenes Betriebssystem arbeitet. So lassen sich etwa Linux und Windows auf demselben Server betreiben.

Über die Software, die deine VMs betreibt, teilst du ihnen CPU-Leistung und Arbeitsspeicher zu. Braucht eine VM mehr Ressourcen, kannst du diese Zuteilung anpassen. Die verfügbare Hardware wird dadurch besser ausgelastet.

Was VMs ermöglichen

Mehrere Betriebssysteme teilen sich einen physischen Rechner.

Du kannst selbst entscheiden, welches Betriebssystem und welche Version du installierst.

CPU und RAM lassen sich softwaregesteuert zwischen den VMs verteilen.

Eine VM kann auf andere Hardware übertragen und dort gestartet werden. Das erleichtert es, nach einem Hardwareausfall weiterzuarbeiten.

Welche Aufgaben bleiben

Du installierst und pflegst die Betriebssysteme weiterhin selbst. Damit mehrere VMs miteinander kommunizieren können, musst du ihre Verbindungen einrichten, gegebenenfalls über virtuelle Netzwerke. Auch die Laufzeitumgebung und deine Anwendung brauchen weiterhin Betreuung.

VMs enthalten vollständige Betriebssysteme und können mehrere Gigabyte groß sein. Eine umfangreiche Windows-VM kann beispielsweise 50 GB belegen, wodurch das Kopieren oder Übertragen entsprechend lange dauert.

Als Beispiele für Virtualisierung werden VMware und Xen genannt, außerdem Citrix sowie Microsoft Hyper-V.

Die Schichten unter deiner Anwendung

Wenn ich meine Anwendung betreibe, bauen mehrere Ebenen aufeinander auf:

Hardware: Sie stellt die physischen Ressourcen bereit.

Betriebssystem: Es steuert die Hardware und macht deren Ressourcen für Programme zugänglich.

Laufzeitumgebung: Beispiele sind die JVM und das .NET Framework. Sie stellen Funktionen bereit und können Unterschiede zwischen Betriebssystemen verbergen, etwa beim Dateizugriff.

Anwendung: Hier läuft die Software, die eine fachliche Aufgabe erfüllt.

Dienste oder Funktionen: Einzelne Teile der Anwendung können anderen Anwendungen bereitgestellt werden.

Bei selbst betriebenen VMs ist die physische Hardware hinter einer zusätzlichen Softwareschicht verborgen. Ab dem Betriebssystem richtest du die weiteren Ebenen selbst ein.

Themen für den nächsten Teil

Mit Infrastructure as a Service setze ich das Thema im nächsten Teil fort. Angekündigt sind außerdem Platform as a Service, Container einschließlich Docker, Software as a Service sowie Function as a Service beziehungsweise Serverless Computing. Edge Computing, Kriterien für die Wahl eines Anbieters und konkrete IHK-Aufgaben sollen ebenfalls folgen.

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:00] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker

...

In der zweiten Episode meiner "Wissenshäppchen" geht es um ein weiteres wichtiges Prinzip der Softwareentwicklung: You Ain't Gonna Need It (YAGNI) (alternativ auch You Aren't Gonna Need It). Wir sollten immer nur das entwickeln, was wir wirklich brauchen!

Always implement things when you actually need them, never when you just foresee that you need them. (YouArentGonnaNeedIt)

TL;DR

Beim Entwickeln konzentriere ich mich mit YAGNI ("You ain’t gonna need it") auf das, wofür es konkrete Anforderungen gibt. Zusätzliche Features und vorsorgliche Abstraktionsschichten kosten Zeit und erschweren es dir, den Code zu verstehen und zu erweitern. Welche Architektur dein Projekt braucht, hängt von seinen Anforderungen ab; Sicherheit und Benutzerfreundlichkeit gehören früh in deine Planung. Test Driven Development hilft dir, gezielt das geforderte Verhalten umzusetzen, während voreilige Performance-Arbeit und aufwendige Nebenaufgaben Zeit verschlingen.

Kapitelmarken

[00:00:00] Einstieg ins YAGNI-Prinzip

[00:00:38] Bedeutung und Anwendung von YAGNI

[00:01:49] Zusätzliche Abstraktionen und komplexe Architektur

[00:03:16] Java-Beispiele mit Factories und Providern

[00:05:49] Projektabhängige Anforderungen und Datenbankabstraktion

[00:07:21] Wünsche des Fachbereichs hinterfragen

[00:07:59] Sicherheit und Benutzerfreundlichkeit früh einplanen

[00:09:06] Featuritis und Feature Creep

[00:09:47] YAGNI mit Test Driven Development umsetzen

[00:10:40] Premature Optimization und Laufzeitprobleme

[00:12:26] Yak Shaving und aufwendige Nebenaufgaben

[00:13:57] Rückblick auf YAGNI

[00:14:30] Extreme Programming und Literaturempfehlung

[00:15:07] Shownotes und weiterführende Links

Inhalt

Durch den Fokus auf das wirklich Wichtige vermeiden wir unnötige Komplexität (vgl. SimpleBeanFactoryAwareAspectInstanceFactory) in unserem Code, die zu schlechterer Wartbarkeit führt.

Außerdem widmen wir damit den Großteil unserer wertvollen Arbeitszeit der Lösung des eigentlichen Problems.

Das bedeutet nicht, dass wir absichtlich zu einfache Lösungen bauen sollen.

Wir sollten nur keine Features einbauen, von denen wir lediglich glauben, dass wir sie später einmal brauchen (bzw. der Fachbereich sie gerne hätte).

Die Praktik des Test Driven Development forciert YAGNI, da immer nur der produktive Code geschrieben wird, der den nächsten Testfall grün macht.

Anforderungen bzgl. der Architektur unserer Anwendung, Sicherheit oder Benutzerfreundlichkeit können nicht im Nachhinein eingebaut werden und müssen daher schon von Beginn des Projekts an eingeplant werden.

Durch YAGNI kann Featuritis vermieden werden, das Problem, dass immer mehr Features hinzugefügt werden, anstatt die wirklich gewünschten perfekt umzusetzen.

Auch das Problem der voreiligen Optimierung (Premature Optimization) steht im Zusammenhang mit YAGNI. Meistens optimiert man Kleinigkeiten, die im Verhältnis zum großen Ganzen kaum Auswirkungen haben.

Ein weiterer Begriff, der mit YAGNI in Verbindung gebracht werden kann, ist das Yak Shaving. "Nur noch eben schnell meinen eigenen ORM programmieren und dann kann es weitergehen!"

Literaturempfehlungen

YAGNI wird oft im Kontext von Extreme Programming zitiert. Kent Beck hat dazu das Standardwerk Extreme Programming Explained* geschrieben, das ich jedem Anwendungsentwickler wärmstens empfehlen kann. Auch der Sinn von Praktiken wie TDD und Pair Programming und Werten wie Einfachheit und Feedback wird hier detailliert beschrieben.

*

Links

YAGNI (hier sind auch zwei treffende Bilder aus dem Software-Craftsmanship-Kalender zu sehen)

What are the most ridiculous Java class names from real code?

How To Build A Horse With Programming [Comic]

Feature creep

Premature Optimization

yak shaving

Zusammenfassung

YAGNI im Entwicklungsalltag

Wenn ich beim Programmieren Ideen für weitere Features bekomme, hilft mir YAGNI, bei den konkreten Anforderungen zu bleiben. Die Abkürzung steht für "You ain’t gonna need it", auf Deutsch ungefähr "Du wirst es nicht brauchen". Das Prinzip stammt aus dem Extreme Programming.

Du setzt damit das um, was der Fachbereich oder du selbst aktuell braucht. Für zusätzliche Features entstehen Kosten, auch wenn ihr Bedarf ungeklärt ist. YAGNI betrifft ebenso einzelne Methoden und die Architektur deiner Software.

Wie zusätzliche Architektur den Code erschwert

Eine weitere Abstraktionsschicht kann Aufwand verursachen, sobald du den Code wartest oder erweiterst. Wer eine Funktion ergänzen möchte, muss zunächst verstehen, wie die vorhandenen Schichten zusammenspielen. Als IT-Azubi brauchst du dafür Zeit, besonders wenn dir die Ideen hinter der Architektur noch fehlen.

Als Beispiel greife ich die Spring-Klasse SimpleBeanFactoryAwareAspectInstanceFactory auf. Ihr Name enthält zweimal "Factory" und regt dazu an, über den Umfang von Abstraktionen nachzudenken. Die Aufgabe dieser Klasse kenne ich selbst nicht. Dazu passt ein Comic, in dem beim Programmieren eines Pferdes mit Java zunächst eine Pferdefabrik entsteht.

Bei einer kleinen Änderung an einer Java-REST-Schnittstelle musste ich selbst zuerst einen Provider samt Factory bauen. Die Architektur machte es aufwendig, die Funktion hinzuzufügen. Ob die vorhandenen Abstraktionen im jeweiligen Projekt gerechtfertigt sind, hängt von dessen Anforderungen ab.

Welche Architektur dein Projekt braucht

Bevor du eine Schicht zum Austausch der Datenbank einbaust, prüfst du, ob dein Projekt diese Fähigkeit braucht. Für ein Framework, das Kund:innen mit verschiedenen Datenbanken einsetzen, gehört sie zu den konkreten Anforderungen. Bei meiner eigenen kleinen Webanwendung mit dauerhaft eingesetztem MySQL oder MariaDB wäre ein selbst gebauter objektrelationaler Mapper zusätzlicher Aufwand ohne absehbaren Bedarf.

Auch ein komplexes Problem kann eine entsprechend komplexe Architektur erfordern. Bereits bekannte architektonische Anforderungen gehören früh in deine Planung, wenn sie sich später schwer ändern lassen.

Sicherheit und Benutzerfreundlichkeit musst du von Anfang an berücksichtigen. Eine fertige Windows-Forms-Anwendung lässt sich am Projektende nur schwer durch eine:n UX-Expert:in benutzerfreundlich machen. Ebenso müssen erforderliche Sicherheitsmechanismen bereits beim Entwickeln einzelner Funktionen einfließen.

Anforderungen mit dem Fachbereich prüfen

Bevor du ein selbst ausgedachtes Feature programmierst, fragst du den Fachbereich nach seinem Bedarf. Auch Anforderungen aus einem Pflichtenheft verdienen einen prüfenden Blick: Manche Wünsche entstehen, ohne dass jemand die Funktion später braucht.

Als Softwareentwickler:in bringst du dein Fachwissen in diese Gespräche ein. Kund:innen können technische Fragen und deren Folgen teilweise schwer einschätzen.

Unter Featuritis oder Feature Creep versteht man, dass immer weitere Features in die Software gelangen. Zusätzliche Wünsche des Fachbereichs können dazu beitragen, ebenso wie weitere Interfaces oder Factories, die Entwickler:innen einbauen.

Mit TDD bei der Anforderung bleiben

Beim Test Driven Development (TDD) beschreibt ein Test das gewünschte Verhalten deiner Software. Im Zyklus Red, Green, Refactor schreibst du Produktivcode, der einen fehlschlagenden Test erfolgreich macht. Dafür wählst du die einfachste passende Lösung.

So richtest du deine Arbeit auf eine konkrete Anforderung aus. Ein eigenes Framework zur Datenbankabstraktion würde zusätzlichen Aufwand verursachen, wenn der Test bereits mit einer einfachen Lösung erfolgreich läuft.

Voreilig an der Performance arbeiten

Premature Optimization bezeichnet das voreilige Optimieren von Code. Wenn du etwa Schleifen austauschst oder Java-Streams einsetzt, weil du dir davon mehr Geschwindigkeit versprichst, kann der Effekt für die Laufzeit kaum spürbar sein.

Bei Anwendungen mit Schnittstellen kann die Latenz durch Netzwerkzugriffe wesentlich stärker ins Gewicht fallen. Auch die gewählte Schnittstelle beeinflusst die Laufzeit. Änderungen an kleinen Codeabschnitten binden dann Zeit, obwohl das vermutete Problem an anderer Stelle liegt.

Yak Shaving: aufwendige Nebenaufgaben

Mit Yak Shaving sind Arbeiten gemeint, die viel Zeit kosten und das eigentliche Feature kaum voranbringen. Mein Beispiel ist ein selbst entwickelter objektrelationaler Mapper für eine Aufgabe, die sich bereits mit einer sicheren und performanten SQL-Abfrage lösen ließe.

Ein kleines Framework zu bauen kann Spaß machen. Im Projekt kostet es jedoch Zeit, während die benötigte Funktion liegen bleibt.

Meine Literaturempfehlung

Zu YAGNI empfehle ich dir "Extreme Programming Explained" von Kent Beck. Das Buch behandelt auch Test Driven Development und Pair Programming. Den Buchverweis sowie die Links zur genannten Java-Klasse und zum Comic findest du in meinen Shownotes unter anwendungsentwicklerpodcast.de/WH2.

Transkription der gesamten Episode

Automatisch erzeugte Transkription der Episode

[0:00] Herzlich willkommen zu den Wissenshäppchen beim Anwendungsentwickler-Podcast. In dieser

[0:08] Episode geht es um das Jagni-Prinzip. You ain't gonna need it. Viel Spaß.

[0:14] Hallo und herzlich willkommen zur zweiten Episode der Wissenshäppchen beim Anwendungsentwickler-Podcast.

[0:27] Mein Name ist Stefan Macke und heute habe ich nach der ersten Episode, in der es um das DRY-Prinzip,

[0:33] Don't Repeat Yourself, ging, ein zweites wichtiges Prinzip der Softwareentwicklung mitgebracht und

[0:38] zwar Jagni. You ain't gonna need it oder auch wahlweise you aren't gonna need it, je nachdem,

[0:45] wer das gerade schreibt bzw. wer, ja, wie viel Slang in seiner Sprache so unterbringt. Also,

[0:51] you ain't gonna need it, you aren't gonna need it, ganz egal, auf Deutsch heißt es ungefähr,

[0:55] du wirst es nicht brauchen. Und genau darum geht es auch. Wir wollen bei der Softwareentwicklung

[1:00] nichts programmieren, was wir nicht brauchen. Jetzt könnte man auf die Idee kommen, ja,

[1:04] das macht ja wohl keiner, warum sollte ich denn was bauen, was keiner braucht? Aber das passiert

...

SQL-Aufgaben kommen in fast jeder schriftlichen IHK-Abschlussprüfung vor. Daher wird es Zeit, einmal detailliert über eine sinnvolle Vorgehensweise bei ihrer Beantwortung zu sprechen. Genau dieses Thema hat die einhundertsiebzehnte Episode des Anwendungsentwickler-Podcasts.

TL;DR

Aus meiner Erfahrung als Prüfer gebe ich dir Tipps, wie du SQL-Aufgaben in der schriftlichen IHK-Prüfung bearbeitest und Punkte für korrekte Teillösungen bekommst. Lerne die Syntax mit Schwerpunkt auf SELECT, lies das Datenmodell samt Beispieldaten und markiere alle geforderten Bestandteile deiner Abfrage. Mit kurzen Tabellenaliasen und ausdrücklicher JOIN-Syntax schreibst du übersichtlich; bei optionalen Beziehungen und GROUP BY brauchst du besondere Sorgfalt. Schreibe auch bei einer unvollständigen Lösung die geforderten Spalten und zugehörigen Tabellen auf, damit dein:e Prüfer:in deine Kenntnisse bewerten kann.

Kapitelmarken

[00:00:01] Einstieg und Hinweis zur schriftlichen IHK-Prüfung

[00:00:38] SQL-Aufgaben aus Sicht eines Prüfers

[00:03:00] Aufgabenaufbau und SQL als Grundwissen

[00:05:32] Syntax auswendig lernen und Prüfungszeit sparen

[00:08:17] Die SQL-Aufgabe bei der Aufgabenauswahl berücksichtigen

[00:09:45] Tabellenstruktur und Beispieldaten verstehen

[00:11:04] Anforderungen markieren und Abfragen planen

[00:13:58] SELECT und weitere prüfungsrelevante SQL-Bestandteile

[00:17:08] Teilpunkte durch korrekte Bestandteile erhalten

[00:20:16] Mit FROM beginnen und kurze Tabellenaliase vergeben

[00:22:22] Geforderte Spalten einzeln auflisten

[00:25:36] Kürzere Syntax für Wertebereiche mit BETWEEN

[00:26:44] Tabellen ausdrücklich mit JOIN und ON verknüpfen

[00:30:37] Optionale Beziehungen und OUTER JOIN erkennen

[00:32:07] Alle erforderlichen Spalten in GROUP BY aufnehmen

[00:34:12] Alternative Lösungen zu verschachtelten Subselects

[00:37:13] Rückblick auf die Prüfungstipps

[00:38:25] Fragen und Feedback zur Episode

[00:39:09] Newsletter und geplante SQL-Übungsaufgaben

Inhalt

SQL-Aufgaben kommen in der Prüfung für Anwendungsentwickler eigentlich jedes Mal vor (in GA1). Aber auch in GA2 kommen durchaus häufiger SQL-Aufgaben zum Einsatz. Eine detaillierte Vorbereitung ist also für alle IT-Berufe zu empfehlen.

Es gibt keine Ausrede, SQL nicht in- und auswendig zu kennen. Selbst wenn in fast jeder Prüfung ein Beiblatt mit der SQL-Syntax vorhanden ist, dauert das Nachschlagen viel zu lange. Lerne SQL einfach rauf und runter, wie es sich für einen vernünftigen Anwendungsentwickler gehört.

Ich empfehle, die SQL-Aufgaben zu bearbeiten und nicht zu streichen. Im Vergleich gibt es deutlich schwierigere Aufgaben, für die du die "Streich-Option" noch brauchen könntest.

Vorab schau dir kurz die vorgegebene Tabellenstruktur an und versuche, das Datenmodell zu verstehen.

Lies die Aufgaben bitte genau durch und ermittle zuerst, welche Art von Statement und welche Bestandteile (z.B. ORDER BY) du brauchst. Häufig werden triviale Anweisungen wie die Sortierung am Ende vergessen. Das kostet wertvolle Punkte.

Das wichtigste Statement für die Prüfung ist sicherlich SELECT. Aber auch UPDATE, CREATE TABLE usw. wurden schon häufiger abgefragt. Gefühlt wird SELECT allerdings in 90% der Aufgaben erwartet.

Schaue dir trotzdem auch die eher seltenen SQL-Statements an. Es wurde z.B. auch schonUNION oder CASE benutzt.

Lass die SQL-Aufgaben bitte nicht einfach leer, auch wenn du keine Ahnung hast, wie du die konkrete Aufgabe lösen musst. Die Liste der Spalten und Tabellen gibt meist schon den Großteil der Punkte der Aufgaben.

Bei der Beantwortung der Fragen empfehle ich, mit der Auflistung der Tabellen zu beginnen.

Jede Tabelle sollte sofort einen kurzen Alias bekommen, damit die SQL-Abfrage insgesamt nicht so lang wird. Du musst das alles mit der Hand schreiben!

Danach sollten alle Spalten separat aufgeschrieben werden, damit diese Basispunkte nicht verschenkt werden.

Verwende bei Alternativen die kürzere Schreibweise, um Zeit zu sparen und weniger Fehler machen zu können. Beispiel: Statt WHERE plz > 10000 AND plz < 20000 besser `WHERE plz BETWEEN 10000 AND 20000´.

Um Tabellen zu verbinden, empfehle ich dringend den Einsatz der JOIN-Syntax (anstatt WHERE). Sie kann leicht um weitere Tabellen ergänzt werden, aber auch durch Hinzufügen eines einziges Wortes in einen OUTER-Join verändert werden.

Achte bei den Joins darauf, ob du eventuell ein OUTER-Join brauchst. In den Aufgaben findest du normalerweise Hinweise darauf, ob in den Tabellen verknüpfte Datensätze vorhanden sein müssen oder nicht.

Ein Hinweis zum GROUP BY: Alle Spalten, die selektiert werden und keine Aggregatfunktion enthalten, müssen auch hinter dem GROUP BY aufgeführt werden. Beispiel: SELECT m.name, m.vorname, COUNT(m.fehltage) FROM mitarbeiter m GROUP BY m.name, m.vorname

Nicht jede Aufgabe benötigt ein Subselect. Oftmals kannst du die Abfragen, die gefordert sind, auch mit einem simplen JOIN und/oder GROUP BY lösen.

Literaturempfehlungen

Wie so oft ist meine Buchempfehlung zum Einstieg ins Thema Datenbanken das gute alte IT-Handbuch für Fachinformatiker*! :-)

*(direkt beim Rheinwerk-Verlag bestellen*)

Das Kapitel über Datenbanken bespreche ich auch hier im Buchclub: Buchclub: Handbuch für Fachinformatiker (Teil 11: Datenbanken)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

SQL Tutorial bei w3schools.com

SQL - Häufige Fragen im Fachgespräch

orm - What is N+1 SELECT query issue? - Stack Overflow

Weitere Hilfen zur IHK-PrüfungDu suchst noch mehr Tipps rund um die Vorbereitung auf die schriftliche IHK-Prüfung? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die schriftliche IHK-Prüfung.Und kennst du schon meine Übungsaufgaben für die Abschlussprüfung? Unter dieperfekteihkpruefung.de kannst du sie herunterladen.

Zusammenfassung

SQL in der schriftlichen IHK-Prüfung

Bei meinen Korrekturen als Prüfer sehe ich häufig SQL-Aufgaben, bei denen durch fehlende Bestandteile oder leere Antworten Punkte verloren gehen. Für dich als IT-Azubi gehört SQL zum Grundwissen, besonders als angehende:r Fachinformatiker:in Anwendungsentwicklung. Auch beim Arbeiten mit einem objektrelationalen Mapper wie JPA oder Entity Framework brauchst du SQL-Kenntnisse, etwa wenn Funktionen fehlen oder eine Anwendung zu langsam auf die Datenbank zugreift.

In den besprochenen Prüfungen kommen SQL-Aufgaben regelmäßig in GA1 und gelegentlich in GA2 vor. Eine Aufgabe mit 25 Punkten besteht häufig aus mehreren Statements, deren Punkte sich nach dem Umfang richten. Ich empfehle dir, SQL gezielt vorzubereiten und die SQL-Aufgabe zu bearbeiten.

Syntax lernen und praktisch ausprobieren

Lerne die SQL-Syntax auswendig, damit du während der Prüfung deine Zeit für die konkrete Aufgabe hast. Ein Beiblatt mit SQL-Syntax hängt davon ab, welche Inhalte die Prüfungsersteller:innen beilegen. Beim Nachschlagen geht zudem Prüfungszeit verloren.

Beim Lernen setze ich den Schwerpunkt auf SELECT, weil dieses Statement besonders häufig vorkommt. Dazu gehören auch die Bestandteile für komplexere Abfragen:

Mit WHERE schränkst du die ausgewählten Datensätze ein.

Über JOIN verknüpfst du Tabellen und berücksichtigst dabei die verschiedenen Join-Arten.

Für gruppierte Ergebnisse brauchst du GROUP BY, Aggregatfunktionen und gegebenenfalls HAVING.

Die geforderte Reihenfolge der Ausgabe stellst du mit ORDER BY her.

Auch Subselects gehören zu den regelmäßig gefragten Themen.

Beschäftige dich außerdem mit CREATE TABLE und UPDATE. In Prüfungen wurden auch UNION sowie CASE für Fallunterscheidungen erwartet. Probiere die Statements praktisch aus, beispielsweise mit MariaDB oder MySQL und einem passenden Editor. Die Datenbanken und entsprechende Werkzeuge stehen als Open Source bereit.

Datenmodell und Aufgabe durchgehen

Bevor du eine Abfrage schreibst, schau dir die Tabellenstruktur in Ruhe an. Kläre, welche Daten in welcher Tabelle stehen und wie die Tabellen über Fremdschlüssel zusammenhängen. An den Beispieldaten erkennst du, was die einzelnen Spalten bedeuten und welche Ergebnisse erwartet werden.

Lies anschließend den Aufgabentext genau. Markiere die Stellen, aus denen sich das benötigte Statement und seine Bestandteile ergeben. Auf einem Schmierblatt kannst du festhalten, welche Teile deine Abfrage enthalten muss.

Bei einer Aufgabe zu Fehlzeiten von Mitarbeiter:innen im Januar kann beispielsweise zusätzlich verlangt sein, nach dem Vornamen zu sortieren. Für das geforderte ORDER BY gibt es eigene Punkte. Solche Details geraten beim Arbeiten an einem aufwendigen Join schnell aus dem Blick.

Plane deine Abfrage vor dem Schreiben. Dadurch bleibt sie für dich und dein:e Prüfer:in verständlich, auch wenn du sie später kontrollierst. Nachträglich eingefügte Fußnoten und Ergänzungen erschweren es, das vollständige Statement nachzuvollziehen.

Korrekte Teile aufschreiben

Wenn du bei einer Aufgabe festhängst, schreibe die Bestandteile auf, die du beherrschst. Bei einer SELECT-Abfrage lassen sich die geforderten Spalten und ihre Tabellen aus dem Aufgabentext oder der Beispielausgabe ablesen. Gehe die erwarteten Ausgabespalten von links nach rechts durch und ordne sie den Tabellen zu.

Für korrekte Bestandteile gibt es Teilpunkte. Bei einem einfachen Statement mit ausgewählten Spalten, einer Tabelle und einer Sortierung können beispielsweise jeweils Punkte auf diese Teile entfallen. Eine leere Antwort erhält null Punkte. Auch bei UPDATE oder CREATE TABLE liefern korrekt aufgeschriebene Bestandteile etwas, das dein:e Prüfer:in bewerten kann.

Mit Tabellenaliasen arbeiten

Ich beginne beim Entwerfen mit dem FROM-Teil und vergebe sofort kurze Aliase, etwa M für eine Tabelle mit Mitarbeiter:innen oder K für eine Kund:innentabelle. Anschließend schreibe ich die Spalten mit diesen Aliasen auf, beispielsweise M.Vorname.

So musst du lange Tabellennamen beim handschriftlichen Schreiben seltener ausschreiben. Du sparst Platz und verringerst die Gefahr von Schreibfehlern....

In der ersten Episode meiner "Wissenshäppchen" widme ich mich einem der wichtigsten Prinzipien der Softwareentwicklung: Don’t Repeat Yourself (DRY). Doppelter Code ist der Feind jedes Entwicklers! :-)

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. (DontRepeatYourself)

Am Beispiel einer weit verbreiteten Programmierübung zeige ich den Weg von doppeltem zu "trockenem" (DRY) Code.

TL;DR

Am Beispiel FizzBuzz zeige ich dir, wie du das DRY-Prinzip (Don't Repeat Yourself) anwendest: Jede Information soll im System genau eine eindeutige, maßgebliche Stelle haben. Mehrfach vorhandene Logik erschwert spätere Änderungen, weil übersehene Stellen zu widersprüchlichen Ergebnissen führen können. Durch Refactoring lagerst du gemeinsame Logik in Methoden aus oder hältst Werte in Variablen fest, sodass du sie zentral ändern kannst.

Kapitelmarken

[00:00:00] Einstieg ins DRY-Prinzip

[00:00:50] Das Format der Wissenshäppchen

[00:01:43] Gemeinsames Programmieren beim Vorstellungstag

[00:02:47] FizzBuzz und grundlegende Programmierkonzepte

[00:03:48] Definition von Don't Repeat Yourself

[00:05:11] Warum doppelter Code spätere Änderungen erschwert

[00:06:19] Copy-and-Paste und mehrfach vorhandene Logik

[00:07:29] Shotgun Surgery

[00:08:21] Gemeinsamen Code durch Refactoring zentralisieren

[00:08:54] Martin Fowlers Buch und Code Smells

[00:10:38] Das vollständige Codebeispiel in den Shownotes

[00:11:35] Doppelte Stellen in der ersten FizzBuzz-Lösung

[00:13:21] Änderungen an Spielregeln und Ausgabe

[00:14:30] FizzBuzz mit Variablen und Methoden refaktorisieren

[00:17:08] Themenvorschläge für weitere Wissenshäppchen

Inhalt

Doppelter Code ist ein Code Smell.

Er tritt meistens auf, wenn Entwickler Zeit sparen wollen und mit Copy/Paste arbeiten.

Doppelter Code führt zu Inkonsistenzen und damit zu Fehlern im Programm.

Er äußert sich durch Shotgun Surgery, das Anpassen mehrerer Stellen im Code für die Änderung eines einzigen Features.

Es existieren viele Refactorings, die doppelten Code vermeiden sollen.

Die Aufgabe: FizzBuzz

Das hier ist die Beschreibung des zu lösenden Problems:

Print a list of the numbers from 1 to 100 to the console. For numbers that are multiples of 3 print "Fizz" instead. For numbers that are multiples of 5 print "Buzz" instead. For numbers that are both multiples of 3 and 5 print "FizzBuzz" instead. These are the first 15 values the program should print:

1

2

Fizz

4

Buzz

Fizz

7

8

Fizz

Buzz

11

Fizz

13

14

FizzBuzz

Lösung der Azubis

Die Implementierung der Azubis sieht dann meistens so aus:

public static void main(String[] args)

{

for (int i = 1; i <= 100; i++)

{

if (i % 3 == 0 && i % 5 == 0)

{

System.out.println("FizzBuzz");

}

else

if (i % 3 == 0)

{

System.out.println("Fizz");

}

else

if (i % 5 == 0)

{

System.out.println("Buzz");

}

else

{

System.out.println(i);

}

}

}

Diese Implementierung ist recht komplex (drei verschachtelte if-Statements) und enthält auch sehr viel doppelten Code:

Die auszugebenden Strings. Würden wir das Spiel auf Deutsch übersetzen, müssten wir die Strings an mehreren Stellen verändern.

Die Prüfung auf Fizz und Buzz (Modulo-Rechnung). Würden sich die Regeln ändern (z.B. 7 und 11 statt 3 und 5 oder zusätzlich Fizz bei "enthält die Ziffer 3"), müssten sie an mehreren Stellen angepasst werden.

Die Ausgabe auf der Konsole. Soll das Spiel in einer Webanwendung oder einer Windows-Applikation eingesetzt werden, müsste die Ausgabe an mehreren Stellen korrigiert werden.

Refactorings

Um die Komplexität und den doppelten Code zu entfernen, können verschiedene, relativ einfache Refactorings angewendet werden:

Werte in Variablen oder Konstanten auslagern, die nur einmalig definiert werden.

Variable für das Ergebnis einführen und diese nur einmalig ausgeben, anstatt jedes Ergebnis separat.

Ergebnisse der einzelnen Prüfungen verketten, anstatt doppelt zu prüfen.

Schritt 1: Doppelte Werte in Variablen auslagern

Fizz und Buzz sollen als Wert nur noch einmalig vorkommen. So sieht eine mögliche Lösung aus:

public static void main(String[] args)

{

String fizz = "Fizz"; // <--- HIER

String buzz = "Buzz"; // <--- HIER

for (int i = 1; i <= 100; i++)

{

if (i % 3 == 0 && i % 5 == 0)

{

System.out.println(fizz + buzz); // <--- HIER

}

else

if (i % 3 == 0)

{

System.out.println(fizz); // <--- HIER

}

else

if (i % 5 == 0)

{

System.out.println(buzz); // <--- HIER

}

else

{

System.out.println(i);

}

}

}

Schritt 2: Variable für Endergebnis einführen

Anstatt viermal die Ausgabe mit System.out.println() durchzuführen, soll das Ergebnis "gesammelt" und nur einmal ausgegeben werden. Das könnte dann so aussehen:

public static void main(String[] args)

{

String fizz = "Fizz";

String buzz = "Buzz";

for (int i = 1; i <= 100; i++)

{

String ergebnis = ""; // <--- HIER

if (i % 3 == 0 && i % 5 == 0)

{

ergebnis = fizz + buzz; // <--- HIER

}

else

if (i % 3 == 0)

{

ergebnis = fizz; // <--- HIER

}

else

if (i % 5 == 0)

{

ergebnis = buzz; // <--- HIER

}

else

{

ergebnis = "" + i; // <--- HIER

}

System.out.println(ergebnis); // <--- HIER

}

}

Schritt 3: Doppelte Prüfungen entfernen

Die Ergebnisse der beiden Prüfungen können ebenfalls in Variablen gespeichert werden, um sie wiederzuverwenden. Beispiel:

public static void main(String[] args)

{

String fizz = "Fizz";

String buzz = "Buzz";

for (int i = 1; i <= 100; i++)

{

String ergebnis = "";

boolean isFizz = i % 3 == 0; // <--- HIER

boolean isBuzz = i % 5 == 0; // <--- HIER

if (isFizz && isBuzz) // <--- HIER

{

ergebnis = fizz + buzz;

}

else

if (isFizz) // <--- HIER

{

ergebnis = fizz;

}

else

if (isBuzz) // <--- HIER

{

ergebnis = buzz;

}

else

{

ergebnis = "" + i;

}

System.out.println(ergebnis);

}

}

Schritt 4: Komplexität reduzieren

Die Komplexität der geschachtelten if-Statements wird zuletzt aufgehoben. Hierfür gibt es kein einfaches Refactoring, sondern man muss die grundsätzliche Struktur des Codes ändern und ein wenig nachdenken, wie man das erreichen könnte. Wichtig hierbei ist der Fokus darauf, alles Doppelte zu eliminieren. Wenn man sich das vor Augen hält, denkt man automatisch in verschiedene Richtungen und kommt (hoffentlich) auf eine mögliche Lösung.

Zunächst macht man sich deutlich, was eigentlich noch doppelt ist: die Kombination der beiden Prüfungen! Das Zutreffen beider Bedingungen ist eigentlich nur ein Sonderfall der beiden einzelnen Prüfungen. Anstatt nach jeder Prüfung das Endergebnis zu überschreiben, muss es einen Weg geben, die Ergebnisse zu kombinieren. Dem könnte man sich wie folgt annähern:

1) Sonderfall if (isFizz && isBuzz) entfernen und Code kompilierbar machen (überflüssiges else entfernen):

if (isFizz)

{

ergebnis = fizz;

}

if (isBuzz)

{

ergebnis = buzz; // noch falsch

}

if (false) // noch falsch

{

ergebnis = "" + i;

}

2) Anstatt bei isBuzz das Ergebnis zu überschreiben, Buzz anhängen:

if (isFizz)

{

ergebnis = fizz;

}

if (isBuzz)

{

ergebnis += buzz; // <--- HIER

}

if (false) // noch falsch

{

ergebnis = "" + i;

}

3) Die falsche Abfrage beim letzten if korrigieren:

if (isFizz)

{

ergebnis = fizz;

}

if (isBuzz)

{

ergebnis += buzz;

}

if (!isFizz && !isBuzz) // <--- HIER

{

ergebnis = "" + i;

}

4) Wenn jetzt noch die doppelte Verwendung von isFizz und isBuzz vermieden werden soll, kann die letzte Bedingung auf ein anderes Kriterium umgestellt werden:

if (isFizz)

{

ergebnis = fizz;

}

if (isBuzz)

{

ergebnis += buzz;

}

if (ergebnis.isEmpty()) // <--- HIER

{

ergebnis = "" + i;

}

Musterlösung

Meine komplett "Musterlösung" sieht nun so aus:

public class FizzBuzz

{

public static void main(String[] args)

{

final String fizz = "Fizz";

final String buzz = "Buzz";

for (int i = 1; i <= 100; i++)

{

String ergebnis = "";

boolean isFizz = i % 3 == 0;

boolean isBuzz = i % 5 == 0;

if (isFizz)

{

ergebnis += fizz;

}

if (isBuzz)

{

ergebnis += buzz;

}

if (ergebnis.isEmpty())

{

ergebnis += "" + i;

}

System.out.println(ergebnis);

}

}

}

Ein paar Kleinigkeiten wurden noch angepasst. Aus Gründen der besseren Symmetrie wurden alle drei Zuweisungen zu ergebnis auf Konkatenation umgestellt. Außerdem wurden die Strings fizz und buzz als final deklariert, da sich ihre Werte während der Programmausführung nicht ändern werden. Die Prüfungen wurden aus Gründen der besseren Lesbarkeit nicht wieder inline in die if-Statements geschrieben (siehe Inline Temp, sondern die Zwischenvariablen isFizz und isBuzz wurden beibehalten (siehe Extract Variable).

DRY

Damit wurden alle Anforderungen von Don’t Repeat Yourself umgesetzt:

Die Strings können an einer einzigen Stelle "übersetzt" werden,...

Die vernünftige Begrüßung eines neuen Auszubildenden ist ein wichtiger Schritt für einen erfolgreichen Start in die Ausbildung. Ich erzähle ich in der einhundertsechzehnten Episode des Anwendungsentwickler-Podcasts, welche Inhalte unsere ersten Gespräche haben.

TL;DR

Ich begrüße dich als IT-Azubi persönlich und bespreche mit dir, wie deine ersten Wochen im Unternehmen ablaufen. Beim Start in der IT-Abteilung lernst du deine Kolleg:innen kennen und erfährst, welche Regeln im Arbeitsalltag gelten, wie du dein Berichtsheft führst und welche Termine dich begleiten. Eine Checkliste und ein erstes Ticket im Issue-Tracker helfen dir dabei, deine Aufgaben im Blick zu behalten. Dazu gehören passende Lernmaterialien sowie der verantwortungsvolle Umgang mit Admin-Rechten und persönlichen Daten.

Kapitelmarken

[00:00:01] Thema: Neue IT-Azubis begrüßen

[00:02:19] Zwei Starts: Unternehmen und IT-Abteilung

[00:03:33] Persönlich begrüßen und den Ablauf erklären

[00:06:37] Mail-Verteiler und Kontakt zu anderen Azubis

[00:07:01] Berufsschule und Schulungstermine abstimmen

[00:08:47] Datenschutz, Sicherheit und Zugangskarten

[00:11:09] Checkliste für den Start in der Abteilung

[00:11:46] Kolleg:innen kennenlernen und durchs Gebäude gehen

[00:14:01] Arbeitszeiten und Gleitzeit abstimmen

[00:16:22] Pausen und gemeinsames Essen

[00:17:54] Bei Krankheit richtig Bescheid geben

[00:19:48] Urlaub beantragen und planen

[00:20:50] Geburtstage und betriebliche Feiern

[00:22:54] Telefonvertretung und Telefontraining

[00:24:58] Berichtsheft und Fahrtkostennachweise

[00:27:00] Duzen, Siezen und Kleidung

[00:28:31] Kosten für Lernmaterialien klären

[00:29:28] Probezeit und formaler Ablauf einer Kündigung

[00:30:25] Die nächsten Monate der Ausbildung planen

[00:31:55] Regelmäßige Gespräche, Reviews und weitere Termine

[00:34:26] Verschiedene Bereiche der IT kennenlernen

[00:34:54] Lernmedien auswählen und Kopfhörer bereitstellen

[00:37:18] Handbuch für Fachinformatiker:innen anschaffen

[00:38:48] Mit Admin-Rechten verantwortungsvoll umgehen

[00:40:46] Rückblick auf die Themen der ersten Tage

[00:42:11] Checkliste und erstes Ticket im Issue-Tracker

[00:43:20] Weiterführende Links und Feedback

Inhalt

Bei uns starten die EDV-Azubis nicht direkt in der EDV-Abteilung, sondern durchlaufen zunächst eine allgemeine Schulung mit allen anderen Azubis. Daher gibt es am allerersten Tag im Unternehmen nur ein kurzes Gespräch und am ersten Tag in der EDV-Abteilung werden dann die Details durchgesprochen.

Am ersten Tag im Unternehmen

Persönliche Begrüßung

Ablauf der nächsten Tage und Wochen erläutern

Aufnahme in WhatsApp-Gruppen (Kollegen, Azubis)

Termine kommunizieren

Einschulung

Erste Berufsschulwoche

externe und interne Schulungen (z.B. Office, Natural)

Formalien

Datenschutzerklärung unterzeichnen

Einweisung in die Sicherheitsbestimmungen

Aushändigen der Stempelkarte

Am ersten Tag in der EDV-Abteilung

Checkliste aushändigen und Ticket mit Aufgaben zum Einstieg zuweisen

Vorstellung aller Kollegen in der Abteilung und ihrer Aufgabenbereiche

Rundgang durch das Gebäude mit Besichtigung der interessantesten EDV-Bereiche (Serverraum etc.)

Arbeitsweise in der Abteilung klären

Arbeitszeiten

Gibt es Kernarbeitszeiten oder übliche Arbeitszeiten, zu denen der Azubi anwesend sein sollte?

Gibt es Tage (z.B. Freitag), an denen nicht wie üblich gearbeitet wird?

Sollen Azubis evtl. nicht allein in der Abteilung sein?

Pausen

Wie ist die Frühstückspause geregelt?

Gibt es eine (gemeinsame) Mittagspause?

Hinweis auf Ein-/Ausstempeln

Krankheit

Wer (Asubilder, Vorgesetzter) muss wie (Telefon, WhatsApp) informiert werden, wenn der Azubi krank ist?

Was gilt für die Berufsschulphase?

Urlaub

Ab wann kann Urlaub beantragt werden?

Gibt es Kollegen, mit denen der Urlaub abgestimmt werden muss?

Wie läuft die Telefonvertretung, wenn Kollegen nicht im Büro sind?

Soziale Events

z.B. Geburtstagsrunden, gemeinsames Frühstück, jährliche Feiern, Betriebsausflus, Weihnachtsfeier

Formalien

Das Berichtsheft ist immer am Ende des Monats ungefragt abzugeben (siehe Häufige Fragen zum Berichtsheft)

Fahrtkostennachweise

Wer wird geduzt/gesiezt?

Gibt es Vorgaben bzgl. der Kleidung im Büro?

Wer übernimmt die Kosten für anzuschaffende Bücher und Lernmaterialien?

Probezeit, Kündigung, Schulzeit

Groben Ablaufplan für Rest des ersten Jahres aufstellen

Regelmäßige Termine (siehe Maßnahmen für eine erfolgreiche Ausbildung zum Fachinformatiker)

O3s: wöchentliches Feedback zum Verlauf der Ausbildung

Weekly Reviews: interessante Links und "coolen" Code vorstellen

Bi-Weekly-Reviews: Pair Programming und Code Reviews durchführen

Monthly-Reviews: Fachartikel schreiben und Vorträge in der Abteilung halten

EDV-Besprechungen: Protokoll führen und Fragen stellen

Buchclubs: konkrete Kapitel mit anderen Azubis abstimmen

Jour Fixe: regelmäßige Projektbesprechungen

Azubi-Rundlauf durch die Abteilung vorstellen

Lernverhalten besprechen

Eher analoge oder digitale Notizen?

Lesen/Hören/Anschauen? Was funktioniert am besten?

Kopfhörer mitbringen für Podcasts/Videos

Handbuch für Fachinformatiker kaufen

Auf Verantwortung als Benutzer mit erweiterten Rechten hinweisen

Datenschutz, Urheberrecht

Literaturempfehlungen

Hier kommt die gesammelte Liste aller oben verlinkter Podcastepisoden, die den Azubi ins Unternehmen einführen.

Maßnahmen für eine erfolgreiche Ausbildung zum Fachinformatiker

Bewertung von Auszubildenden (Evaluierungsbögen)

Bewertung von Auszubildenden (Teil 2)

Häufige Fragen zum Berichtsheft

Buchclub: Handbuch für Fachinformatiker (Teil 1)

Meine Checkliste für den ersten Tag in der EDV-Abteilung

Hier kannst du dir meine kurze Checkliste für den Start in die Ausbildung herunterladen. Du musst sie natürlich um deine eigenen Inhalte ergänzen bzw. korrigieren. :-)

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Der erste Eindruck – auch für Ausbilder wichtig

Mit motivierten Auszubildenden optimal starten

Tipps zum Ausbildungsbeginn

Zusammenfassung

Deine ersten Tage im Unternehmen

In meinem Unternehmen beginnt deine Ausbildung mit einer gemeinsamen Schulung für Azubis aus allen Ausbildungsberufen. Dabei lernst du das Versicherungsgeschäft kennen und erfährst, wie die Systeme im Alltag funktionieren. Anschließend kommst du in die IT-Abteilung, wo du mit dem Programmieren beginnst. Deshalb begrüße ich dich zu zwei Zeitpunkten: am ersten Tag im Unternehmen und beim Einstieg in die Abteilung.

Für unser erstes Gespräch habe ich meist zehn bis fünfzehn Minuten. Dabei geht es um folgende Punkte:

Persönlich kennenlernen: Ich stelle mich vor und biete dir das Du an. Als dein Ausbilder möchte ich dazu beitragen, dass du dich im Unternehmen willkommen fühlst.

Die nächsten Wochen verstehen: Du erfährst, wie die Schulung abläuft und wann du in die IT-Abteilung kommst. Je nachdem, wann die anderen Azubis Berufsschule haben, verbringst du bereits einzelne Tage bei mir.

Kontakt zum Team bekommen: Du wirst früh in passende Mail-Verteiler aufgenommen. In meinem Unternehmen gibt es außerdem eine informelle WhatsApp-Gruppe für Azubis.

Erste Termine kennen: Wir besprechen, wann du dich an der Berufsschule anmelden musst und wann dein erster Schulblock beginnt. Dazu gehören die Adresse und die erforderlichen Unterlagen. Bei mir wechseln sich eine Woche Berufsschule und zwei Wochen im Unternehmen ab.

Schulungen abstimmen: Bereits geplante interne oder externe Schulungen werden mit dir abgestimmt, damit sich bei Bedarf auch Unterkunft und Zugfahrten organisieren lassen.

Unterlagen und Sicherheit klären: Je nach Unternehmen gehören eine Datenschutzerklärung und Hinweise zu Gefahren am Arbeitsplatz dazu. Du bekommst außerdem die erforderlichen Karten oder Unterlagen. Die Stempelkarte öffnet in meinem Unternehmen auch die Türen.

Beim Einstieg in die IT-Abteilung

Ich gebe dir eine einseitige Checkliste mit wichtigen Punkten und Terminen, die du in den ersten Tagen abhaken kannst. Meine Vorlage steht unter anwendungsentwicklerpodcast.de/116 zum Herunterladen bereit.

Bei einem Rundgang stelle ich dir die Kolleg:innen vor, damit du ihre Aufgabenbereiche kennenlernst und weißt, mit wem du später zusammenarbeitest. Dabei zeige ich dir auch die Räume, die du im Alltag brauchst, etwa Besprechungsräume und die Kaffeeküche. Toiletten und das Restaurant gehören ebenfalls dazu. Je nach Gebäude schauen wir uns außerdem den Serverraum oder andere technische Räume an.

So läuft der Arbeitsalltag

Arbeitszeiten: Du erfährst, welche Zeiten für dich gelten und wie du sie mit mir und den Kolleg:innen abstimmst. Auch bei Gleitzeit brauchen wir gemeinsame Zeiten für Lehrgespräche. Dazu kommen gegebenenfalls Regeln zur Anwesenheit weiterer Mitarbeiter:innen sowie übliche Zeiten für den Feierabend am Freitag.

Pausen: Wir besprechen, wann Frühstücks- und Mittagspausen stattfinden und ob du dafür ausstempeln musst. Ich nehme dich am ersten Tag zum gemeinsamen Essen mit, damit du Anschluss an das Team findest.

Krankheit: Du brauchst Klarheit darüber, wen du bis wann und auf welchem Weg informierst, wenn du krank bist. Das betrifft auch Fehlzeiten während der Berufsschule und die Frage, ab wann ein ärztlicher Nachweis erforderlich ist.

Urlaub: Wir klären, wie du Urlaub beantragst und mit wem du ihn abstimmst. Dazu gehört, welche Regeln während der Probezeit gelten und wie bereits geplante Schulungen berücksichtigt werden.

Feiern und Geburtstage: Du erfährst, welche Gewohnheiten es in der Abteilung gibt, etwa ob zum Geburtstag etwas mitgebracht wird. Für Betriebsausflüge und Weihnachtsfeiern besprechen wir auch, welche Kleidung und welches Verhalten erwartet werden.

Telefonvertretung: Ich zeige dir, wie du mit Anrufen für abwesende Kolleg:innen umgehst. Wenn du Anrufe übernehmen sollst, üben wir die passenden Funktionen am Bürotelefon.

Berichtsheft und weitere Regeln

Mit deinem Berichtsheft beginnst du direkt beim Einstieg. Ich zeige dir,...

Was ich so alles vorbereite, wenn ein neuer Azubi zum Fachinformatiker Anwendungsentwicklung zu uns kommt, erzähle ich in der einhundertfünfzehnten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Für deinen Einstieg als IT-Azubi bereite ich schon vor Ausbildungsbeginn deinen Arbeitsplatz vor und stimme Schulungen mit den Berufsschulzeiten ab. In den ersten Monaten lernst du mit vorbereiteten Tutorials und praktischen Aufgaben Java sowie die Werkzeuge kennen, die du beim Entwickeln brauchst. Dazu kommen weitere IT-Grundlagen und ein eigenes Blog auf deinem Server. Zum Ende der Probezeit besprechen wir ausführlich deinen bisherigen Fortschritt, wobei auch dein Feedback zu meiner Arbeit als Ausbilder zählt.

Kapitelmarken

[00:00:01] Thema: Die ersten Ausbildungswochen planen

[00:00:20] Der Fahrplan aus Sicht eines Ausbilders

[00:02:20] Wann die Vorbereitungen beginnen

[00:03:57] Berufsschulzeiten und Einschulung klären

[00:06:11] Externe Schulungen buchen

[00:06:56] Hardware beschaffen und den Arbeitsplatz vorbereiten

[00:08:31] Der erste Eindruck beim Ausbildungsstart

[00:09:42] Kolleg:innen über den Start informieren

[00:10:43] Rechner und Programme einrichten und testen

[00:12:00] Telefon und ergonomische Eingabegeräte

[00:13:24] Zugänge zu Ticketsystem, Wikis und E-Mail

[00:15:35] Regelmäßige Termine über den Kalender planen

[00:16:33] Das Berichtsheft technisch vorbereiten

[00:18:04] Die Java-Entwicklungsumgebung bereitstellen

[00:19:20] Einstieg in die Support-Hotline

[00:20:36] Schulungen für die ersten Ausbildungsmonate

[00:21:12] Java-Tutorial und englische Fachbegriffe

[00:22:23] Lambdas und Streams mit einem Oracle-Kurs lernen

[00:22:55] Unit-Tests und Mocking vertiefen

[00:24:04] Azubi-Bootcamp mit Hilfsprogrammen und Sicherheitsthemen

[00:25:29] Office-Schulungen für den Arbeitsalltag

[00:27:19] LaTeX anhand von Videos lernen

[00:28:20] Git-Kurs und Fragen zum selbstständigen Erarbeiten

[00:29:46] Eigenen Webserver und Blog aufsetzen

[00:30:59] Netzwerkgrundlagen und sichere Systeme

[00:31:58] Zeitmanagement und Softwareprojekte

[00:32:43] SQL im Selbststudium lernen

[00:34:03] Daten anhand von IHK-Aufgaben modellieren

[00:36:24] Feedbackgespräch zum Ende der Probezeit

[00:38:24] Rückblick und unternehmensspezifische Inhalte

[00:41:05] Feedback, Shownotes und Newsletter

Inhalt

Wie der Einstellungsprozess bei uns abläuft, habe ich bereits in einer früheren Episode beschrieben: Ablauf des Bewerbungsverfahrens für potentielle Azubis. Sobald der Ausbildungsvertrag unterschrieben ist, beginnen dann die Vorbereitungen auf den neuen Azubi. Im Folgenden zeige ich alle Schritte, die ich dabei durchlaufe.

Vor Beginn der Ausbildung

Informationen von der Berufsschule besorgen

Termin für die Einschulung

Schulzeiten/Blockphasenplan (z.B. Blockphasen der BBS Haarentor)

Termine für überbetriebliche Schulungen machen (in unserem Fall Adabas und Natural)

Nötige Hardware/Software beantragen/aufsetzen (falls nicht als erste Aufgabe durch Azubi selbst umzusetzen)

Kollegen über den ersten Tag des Azubis in der Abteilung informieren

Technik/Arbeitsplatz aufsetzen

Die folgende Liste ist nicht vollständig und weicht je nach Unternehmen sicherlich von den gezeigten Punkten ab.

Windows und nötige Programme einrichten (Office etc.)

Telefon einrichten

ergonomische Eingabegeräte bereitstellen

Zugang einrichten/kontrollieren

Ticketsystem

Unternehmenswiki

Azubi-Wiki

Einweisung in Terminplanung im Mailprogramm (erste Einladungen zu Terminen folgen)

Einweisung in das Führen des Berichtshefts (Wiki/LaTeX)

Java-Programmierumgebung aufsetzen

Einweisung in Supportarbeit

Schulungen/Tutorials planen

Auch diese Liste ist sicherlich nicht vollständig. Je nach Unternehmen werden natürlich andere Inhalte geschult. Aber ich denke, meine Sammlung bietet einen guten Überblick über die Grundlagen, die ein Azubi zum Fachinformatiker Anwendungsentwicklung vermittelt bekommen sollte.

Java

Eigenes Tutorial

Einführung in Unit Tests und Mocking

Lambdas und Streams

Azubi-Bootcamp (Shortcuts, Hilfsprogramme, Datenschutz usw.)

Office (Word, Excel, Tod durch PowerPoint)

LaTeX (YouTube-Videos)

Git

Eigenen Linux-Server anschaffen

Weitere Schulungen

Wie funktioniert das Internet?

Sicherheit auf dem Heim-PC

Aufbau einer Personal Brand

Zeitmanagement

Agile Prozessmodelle und Scrum

Anforderungsanalyse in Softwareprojekten

Datenbanken (SQL und Datenbankmodellierung)

Ende der Probezeit

Detailliertes Feedback-Gespräch mit dem Azubi (erste Evaluierung)

Literaturempfehlungen

Hier kommt die gesammelte Liste aller oben verlinkter Podcastepisoden, die den Azubi in seinen ersten Wochen begleiten und die ersten fachlichen Kenntnisse vermitteln.

Bewertung von Auszubildenden (Teil 2)

Podcast-Serie: Lernzielkontrollen

Ergonomie am Arbeitsplatz

Einführung in die Versionsverwaltung mit Git (Teil 1)

Pragmatic Unit Testing in Java 8 with JUnit (Buchclub)

Der eigene Webserver (Teil 1)

SQL - Häufige Fragen im Fachgespräch

Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell)

Das ISO/OSI-Modell (Teil 1)

Das erwähnte Buch zur Einführung in JUnit und Mocking ist Pragmatic Unit Testing in Java 8 with JUnit* von Jeff Langr.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Checkliste ToDos vor dem Start Ihrer Auszubildenden

Zusammenfassung

Vor deinem Ausbildungsbeginn

Bei einem Ausbildungsstart am 1. August beginne ich im Juni oder Juli mit den Vorbereitungen. Mein Fahrplan reicht bis zum Ende der Probezeit; die persönliche Begrüßung am ersten Tag behandle ich gesondert.

Von der Berufsschule besorge ich den Blockphasenplan und erfahre, wann du zur Einschulung kommen musst. In meinem Unternehmen wechseln sich eine Woche Berufsschule und zwei Wochen im Betrieb ab. Die Schulzeiten trage ich in meinen Kalender und das Urlaubssystem ein, damit ich Schulungen passend legen kann. Für dich halte ich die ersten Schultermine mit Datum und Uhrzeit auf einer Liste fest.

Externe Schulungen buche ich frühzeitig, weil Termine verschoben werden können, wenn sich zu wenige Teilnehmer:innen anmelden. In meinem Unternehmen betrifft das beispielsweise Natural und die Datenbank Adabas.

Wenn Hardware bestellt werden muss oder Softwarelizenzen eine Freigabe brauchen, kümmere ich mich vor deinem Start darum. Den Arbeitsplatz richten IT-Azubis aus höheren Ausbildungsjahren ein. Da mein Unternehmen mit Thin Clients arbeitet, besteht der Aufbau hauptsächlich darin, Kabel anzuschließen. Einen eigenen PC kannst du bei Interesse gemeinsam mit mir zusammenbauen.

Die Kolleg:innen erfahren, wann du in die IT-Abteilung kommst. Das kann nach deinem eigentlichen Ausbildungsbeginn liegen, weil du zunächst eine allgemeine Schulung mit IT-Azubis und Azubis anderer Berufe besuchst.

Dein Arbeitsplatz und deine Zugänge

Auf dem Rechner beziehungsweise der virtuellen Windows-Maschine wird dein Benutzerkonto eingerichtet. Netzlaufwerke und Drucker müssen erreichbar sein. Vor deinem Start wird geprüft, ob die Anmeldung funktioniert und die benötigten Programme laufen.

Office und die Entwicklungswerkzeuge stehen mit passenden Lizenzen bereit. Für den Einstieg in Java gehören das JDK und Eclipse dazu, bei Bedarf auch Git und Gradle. Mein Java-Tutorial ist bereits als Projekt in der IDE geöffnet, sodass du mit der ersten Aufgabe anfangen kannst.

Ein eingerichtetes Telefon mit eigener Nummer ermöglicht dir, Kolleg:innen zu erreichen. Ergonomische Tastaturen und Vertikalmäuse stehen zur Verfügung, wenn du damit arbeiten möchtest. Zunächst ist der Arbeitsplatz mit üblichen Eingabegeräten ausgestattet.

Du erhältst Zugriff auf die Systeme, die du für deine Aufgaben brauchst. Dazu gehören das Ticketsystem Redmine und das interne Wiki, außerdem Intranet und E-Mail. Über Redmine verteile ich auch Aufgaben an IT-Azubis. Im Azubi-Wiki hältst du für die Weekly Reviews interessante Codebeispiele und gelesene Artikel fest.

Ein vorbereiteter Arbeitsplatz trägt dazu bei, dass du dich im Unternehmen willkommen fühlst. Deshalb erledige ich vorher, was sich vorher erledigen lässt, und berücksichtige die Zeit, die Berechtigungen und Freigaben brauchen.

Termine und Berichtsheft

Regelmäßige Gespräche und Lernzielkontrollen plane ich über das E-Mail-System. Dazu kommen Reviews und Evaluierungsgespräche. Gleich zu Beginn lernst du, Einladungen anzunehmen oder abzulehnen, damit die Termine im Kalender verlässlich stehen.

Für das Berichtsheft richte ich alle technischen Voraussetzungen ein. Im beschriebenen Ablauf meines Unternehmens schreibst du es im Wiki; anschließend wird es mit einer kleinen Software nach LaTeX übertragen. Monatlich wird es ausgedruckt und unterschrieben. Dafür müssen der Wiki-Zugang und die LaTeX-Umgebung bereitstehen. Ein vollständig digitales Berichtsheft möchte ich mir zum Zeitpunkt der Aufnahme noch ansehen.

Java lernen und Software testen

Mit meinem englischsprachigen Java-Tutorial beginnst du bei den Grundlagen und lernst dabei technische Fachbegriffe. Programmiererfahrung wird vorausgesetzt als mögliche Vorerfahrung berücksichtigt; der Kurs startet bei Variablen und Datentypen und führt bis zu Vererbung und Polymorphie. Interfaces und Tests gehören ebenfalls dazu.

Anschließend arbeitest du einen kostenlosen Oracle-Videokurs mit Übungen zu Lambdas und Streams durch, die mit Java 8 hinzugekommen sind. Damit lernst du auch Ansätze der funktionalen Programmierung kennen.

Schon im Tutorial schreibst du Unit-Tests und löst eine Aufgabe zum Mocking. Nach etwa zwei bis drei Monaten vertiefst du das Testen mit dem Buch Pragmatic Unit Testing in Java 8 with JUnit. Die Inhalte brauchst du später in deinem ersten Projekt.

Im ersten Ausbildungsjahr hilfst du nach einer Einweisung zeitweise in der Support-Hotline aus. Ein Vollzeitkollege übernimmt den First-Level-Support regulär. Durch die Einsätze lernst du Kolleg:innen kennen und kannst schon früh bei konkreten Problemen helfen.

Schulungen für deinen Arbeitsalltag

...

Wie man als Anwendungsentwickler Prüfungsbester wird, erklärt Sebastian Schnieder im Interview in der einhundertvierzehnten Episode des Anwendungsentwickler-Podcasts.

TL;DR

Ich spreche mit Sebastian Schnieder, der 2017 seine Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung mit der Gesamtnote 1 abgeschlossen hat. Sein duales Studium und die frühe Mitarbeit an Kundenprojekten haben ihn auf die Prüfung vorbereitet, während er mit Prüfungsaufgaben gezielt sein Wissen überprüft hat. Für deine eigene Prüfung findest du konkrete Anregungen: Dokumentationen als Beispiele lesen, deine Präsentation vor anderen üben und das Fachgespräch mit einer prüfungserfahrenen Person durchspielen. Sein Android-Abschlussprojekt erreichte 95 Prozent in der Dokumentation und 100 Prozent im Fachgespräch.

Kapitelmarken

[00:00:01] Sebastian Schnieders Weg zur Abschlussnote 1

[00:01:43] Arbeitgeber und duales Studium in Oldenburg

[00:03:13] Technische Inhalte und Programmierprojekte im Studium

[00:06:34] Einstieg über Schulpraktikum und Visual Basic

[00:10:06] Mitarbeit an Kundenprojekten für den ÖPNV

[00:12:43] JavaScript und bevorzugte Entwicklungsumgebungen

[00:15:49] Gesamtnote 1 und IHK-Bestenehrung

[00:18:24] IHK-Vorbereitung im dualen Studium

[00:20:35] Austausch mit örtlichen IHK-Prüfer:innen

[00:22:07] Prüfungsaufgaben und Prüfungstrainer

[00:24:13] Abschlussprojekt: Android-Modul für erhöhtes Beförderungsentgelt

[00:28:00] Präsentation und Fachgespräch zur Probe

[00:31:10] Live-Demo mit Tablet und Belegdruck

[00:32:45] Fragen im Fachgespräch und Programmieren an der Tafel

[00:36:40] Projektdokumentation mit LaTeX

[00:39:28] Herausforderungen und Amortisation aus Kundensicht

[00:42:40] Prüfungsergebnisse und Tipps für IT-Azubis

[00:45:50] Ausbildungsplätze und Entwicklung des Unternehmens

[00:49:35] Betreuung und Einstieg in echte Projekte

[00:53:10] Lernen im Arbeitsalltag und die interne Software Projektura

[00:56:05] Einblicke in weitere Arbeitsbereiche und Messebesuch

[01:00:51] Code-Reviews und Pair-Programming

[01:04:50] Studienabschluss und verkürzte Ausbildungszeit

[01:06:32] Mögliches Bachelorprojekt: Busanzeigen über Bluetooth ansteuern

[01:10:32] Pläne für den Master

[01:11:24] Andere IT-Azubis beim Lernen unterstützen

[01:12:12] Clean Code und Software Engineering

[01:15:06] Einsteigerbücher und Lernen mit Onlinequellen

[01:17:51] Aktuelle Android-Techniken im Developer Blog

[01:18:39] Kontakt zu Sebastian und Abschluss des Interviews

[01:20:32] Shownotes und weitere Links

Inhalt

Allgemeines zur Person

Wo arbeitest du?

Mein Ausbildungsbetrieb ist die AMCON GmbH aus Cloppenburg. Ein Software-Dienstleister für Bus- und Bahnunternehmen.

Ich absolviere aktuell ein duales Studium als Wirtschaftsinformatiker (B.Sc.) an der IBS Oldenburg.

Die IHK-Prüfung habe ich im Rahmen des dualen Studiums absolviert, da diese dort mit integriert ist.

Vor dem dualen Studium habe ich ein ganz normales Abitur absolviert.

Bei der Arbeit befasse ich mich einerseits mit der mobilen Entwicklung für Android und der Entwicklung für Windows mit dem .NET-Framework.

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Visual Basic, Java, Node.js

Was machst du so im Alltag?

Software für den Personenverkehr entwickeen, z.B. für die Ticketbuchung oder die Verwaltung von Ticketabos.

Dafür verwende ich hauptsächlich Java unter Android.

Was ist deine Lieblingsprogrammiersprache und warum?

Java. Ich finde die Arbeit mit der IDE IntelliJ bzw. Android Studio sehr produktiv.

Prüfungsbester 2017

Ausbildung

Wie viele Azubis gibt es in eurem Unternehmen und in welchen Berufen?

Wir bilden Fachinformatiker Anwendungsentwicklung aus.

Aktuell haben wir insg. 8 duale Studenten und 4 normale Azubis.

Insg. haben wir inzwischen 50 Mitarbeiter, aber als ich anfing, lagen wir noch bei 10 Kollegen.

Wir haben mehrere Kollegen, die den Ausbilderschein gemacht haben, und es werden stetig mehr.

Was waren die Ausbildungsinhalte?

Zum Einstieg arbeiten wir erstmal an internen Projekten. Es gibt auch eine große eigene Software, die komplett von Azubis umgesetzt wurde.

Recht bald können wir aber auch in echten Kundenprojekten mitarbeiten, was sehr motivierend für die Azubis ist.

Außerdem helfen sich natürlich die Azubis untereinander.

Durchlauft ihr unterschiedliche Bereiche im Unternehmen?

Nein, man bleibt in der Entwicklung, da viele andere Bereiche wie Rechnungswesen ausgelagert sind.

Ich konnte aber einmal an einer Messe mit unserem Vertriebler teilnehmen und habe auch auf Job-Messen mitgearbeitet.

Helft ihr euch untereinander und wenn ja wie (z.B. Vorträge, Diskussionsrunden)?

Das läuft eher auf Zuruf, es gibt keine regelmäßigen Termine.

Wie hat dich dein/e Ausbilder/in unterstützt?

Mit Übungsaufgaben, Einführungen in die Projekte, Code-Reviews, Pair-Programming.

Ab und an stellen auch Kollegen von sich aus interessanten Code vor.

Abschlussprüfung

Was war das Thema deiner Projektarbeit?

Ich habe eine Software zur Aufnahme eines "erhöhten Beförderungsentgelts" entwickelt (Schwarzfahrer).

Womit hast du deine Projektdokumentation geschrieben?

Mit LaTeX. Dafür hatten wir eine Einführung an der Uni.

Wie hast du dich auf die schriftliche Prüfung vorbereitet?

Es gab einen Vorbereitungskurs an der Uni, der ein halbes Jahr vorher begann.

Die Prüfungsthemen wurden schon in der Vorlesung behandelt.

Es gab auch Feedback von IHK-Prüfern, die in die Vorlesung kamen.

Empfehlen kann ich auch Prüfungsvorbereitung aktuell* von Dirk Hardy.

Wie hast du dich auf die Präsentation und das Fachgespräch vorbereitet?

Unser Geschäftsführer ist IHK-Prüfer. Er hat mir nach einer Probepräsentation Feedback gegeben und Verbesserungsvorschläge gemacht.

Präsentationen haben wir bereit vorher oft in Uni geübt. Es gab sogar ein separates Modul zum Thema Soft Skills.

Wie lief die mündliche Prüfung ab?

Ich habe eine Live-Demo mit eigener Hardware (Tablet) gezeigt und extra das IHK-Logo eingebaut. Das Tablet habe ich auf den Beamer umgeleitet.

Die Prüfer haben ihre Fragen untereinander aufgeteilt. Die Themen waren: Datenbanken, Testen, Android, Klasse/Objekt, Polymorphie.

Ich musste auch eine for-Schleife an die Tafel schreiben.

Was waren die größten Herausforderungen für dich?

Die schriftliche Prüfung war in ihrer Fragestellung ungewohnt für mich als Studenten.

Der Aufwand für die Dokumentation war sehr hoch. Das hatte ich unterschätzt.

Ich habe die Amortisation aus Sicht des Kunden berechnet und nicht aus Sicht meines Unternehmens. Da war ich mir unsicher, ob das so in Ordnung ist.

Welche Tipps hast du für andere Prüflinge?

Jeder muss das Projekt verstehen können. Trotzdem muss man auch fachlich tief einsteigen und zeigen, was man kann.

Ich habe einen Prüfungstrainer* mit Erklärungen zur Vorbereitung verwendet und mir die Antworten hauptsächlich mit Google und Erklärungen auf YouTube erarbeitet.

Ich empfehle auch, sich andere Projektdokumentationen zur Inspiration anzuschauen und insb. aufs Inhaltsverzeichnis zu achten, um zu prüfen, ob man an alle Inhalte gedacht hat.

Um die Projektpräsentation gut rüberzubringen, muss man sich in die Zielgruppe hineinversetzen.

Bestenehrung

Welche Note hast du genau bekommen?

Gesamtnote "sehr gut" (1)

95% gab es für die Projektdokumentation, 100% für Projektpräsentation und Fachgespräch.

Wie lief die Bestenehrung ab?

Es war eine tolle Veranstaltung mit vorherigem Frühstück. Viele Reden und vor allem viele Prüflinge, die geehrt wurden. Es waren ja alle Berufe vertreten und nicht nur die Fachinformatiker.

Zukunft

Was ist der Thema deiner Bachelorarbeit?

Ich habe schon eine Idee rund um den Ticketverkauf. Es geht um die Ablösung einer alten Software mit Anbindung von Displays im Bus über Bluetooth.

Wie geht es jetzt bei dir weiter (z.B. feste Anstellung, Studium)?

Ich werde erstmal das Studium beenden.

Danach würde ich gere noch einen Master anhängen.

Aus- und Weiterbildung

Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie ist das Vorgehen?

Nebenbei helfe ich als normaler Mitarbeiter den Azubis, aber nicht als Ausbilder.

Was ist das letzte Fachbuch mit Bezug zur Programmierung, das du selbst gelesen hast?

Ich nutze eher das Internet, insb. StackOverflow. Aber Clean Code* kann ich sehr empfehlen. Auch Design Patterns* sollte man sich anschauen.

Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?

Clean Code*. Visual Basic habe ich mit dem Buch von Thomas Theis gelernt: Einstieg in Visual Basic*. Für Java habe ich Java ist auch eine Insel* gelesen und speziell für Android Android-Apps entwickeln für Einsteiger*.

Welche Quellen kannst du für die Aus- und Weiterbildung im Bereich Programmierung empfehlen und warum?

YouTube

Android-Blog

Abschluss

Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?

Auf meiner Website: http://www.sebastian-schnieder.de/. Dort findet man verschiedene Kanäle, um mich zu kontaktieren.

Literaturempfehlungen

Prüfungsvorbereitung aktuell - Fachinformatiker Anwendungsentwicklung: Abschlussprüfung* von Dirk Hardy.

*

Prüfungstrainer Fachinformatiker für Anwendungsentwicklung*

*

Robert C. Martin - Clean Code: A Handbook of Agile Software Craftsmanship*

*

Design Patterns - Elements of Reusable Object-Oriented Software*

*

Christian Ullenboom - Java ist auch eine Insel*

*

Einstieg in Visual Basic*

*

Android-Apps entwickeln für Einsteiger*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Sebastians Website

Berufsbeste der IHK Oldenburg

Zusammenfassung

Sebastian Schnieders Weg zur Abschlussnote 1

Ich spreche mit Sebastian Schnieder über seinen Ausbildungsweg und darüber, wie du dich als IT-Azubi auf die Abschlussprüfung vorbereiten kannst. Er hat 2017 seine Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung mit der Gesamtnote 1 abgeschlossen und wurde bei der IHK Oldenburg geehrt....

Einige meiner Maßnahmen für die erfolgreiche Ausbildung zum Fachinformatiker Anwendungsentwicklung stelle ich in der einhundertdreizehnten Episode des Anwendungsentwickler-Podcasts vor.

TL;DR

Ich begleite dich als IT-Azubi mit selbstständigem Lernen und festen Gesprächsterminen durch die Ausbildung. Tutorials und Fachbücher helfen dir beim Einstieg, während du beim gemeinsamen Programmieren und beim Erklären dein Wissen vertiefst. Regelmäßige Fachartikel sowie Vorträge geben dir Gelegenheit, Themen gründlich zu bearbeiten und das Präsentieren zu üben. Mit frühen Lernzielkontrollen und monatlich bearbeiteten IHK-Prüfungen bereite ich dich auf die Abschlussprüfung vor; dein Feedback fließt dabei in meine Arbeit als Ausbilder ein.

Kapitelmarken

[00:00:00] Einstieg: Maßnahmen für eine erfolgreiche IT-Ausbildung

[00:03:27] Eigene Ideen, Feedback und langfristiges Lernen

[00:08:03] Tutorials im eigenen Tempo bearbeiten

[00:11:41] Fachbücher gemeinsam im Buchclub lesen

[00:14:55] Mentoring und Lernen durch Lehren

[00:18:11] Azubi-Rundlauf durch IT und Fachbereiche

[00:21:55] Einen eigenen Webserver aufsetzen

[00:24:21] Regelmäßige Termine im Ausbildungsalltag

[00:24:52] Tägliches Stand-up am Aufgabenboard

[00:28:23] Wöchentliche Gespräche unter vier Augen

[00:29:14] Weekly Review und Link der Woche

[00:31:50] Eigene Codeschnipsel vorstellen

[00:33:24] Podcasts und Blogbeiträge als Lernmaterial

[00:36:15] Wöchentliche Lernzielkontrollen

[00:38:31] Besprechungsprotokolle schreiben und verstehen

[00:40:58] Code-Reviews und Pair-Programming

[00:43:46] Berichtsheft monatlich prüfen

[00:45:08] Fachartikel für den eigenen Blog schreiben

[00:48:58] Fachvorträge vor der IT-Abteilung

[00:50:39] Monatlich IHK-Prüfungen bearbeiten

[00:53:00] Halbjährliche Gespräche mit gegenseitigem Feedback

[00:55:33] Das geplante jährliche Azubi-Bootcamp

[00:59:33] Überblick über die Maßnahmen

[01:01:46] Eigene Vorschläge und Feedback zur Ausbildung

Inhalt

Die hier genannten Maßnahmen setze ich selbst - die meisten schon seit einigen Jahren - in der Ausbildung bei der ALTE OLDENBURGER Krankenversicherung AG ein. Es geht also nicht um Ideen aus der Theorie, sondern um praxiserprobte konkrete Dinge, die man tun kann, um die Ausbildung zu optimieren.

Allgemein

Sehr gut ist, wenn die Azubis selbstständig eigene Maßnahmen erarbeiten oder zumindest zur konkreten Gestaltung beitragen können.

Die einzelnen Maßnahmen können durchaus angepasst werden, wenn sie nicht (mehr) funktionieren.

Einige Maßnahmen entfalten ihre Wirkung erst nach längerer Zeit und sollten daher nicht vorschnell wieder beendet werden.

Unregelmäßig/einmalig

Neue fachliche Inhalte bringen sich die Azubis mehr oder weniger selbstständig bei, in dem entsprechende Tutorials bearbeitet werden. Beispiele: Java, Git, SQL, Datenbanken.

Mit Buchclubs kann die tiefergehende Auseinandersetzung mit einem Thema gefördert werden und der sanfte Druck, bis zu einem gewissen Termin bestimmte Kapitel eines Buches gelesen haben zu müssen, fördert auch die langfristige Auseinandersetzung mit dem Buch.

Azubis aus den höheren Lehrjahren sollten als Mentoren für die neuen Azubis zur Verfügung stehen. Dadurch lernen sie selbst den Stoff noch einmal intensiver, weil sie ihn erklären müssen. Aber auch die neuen Azubis profitieren, da die älteren Azubis näher an ihrem Wissensstand sind als ein langjähriger Ausbilder und die Probleme vielleicht etwas besser im Blick haben.

Beim Azubi-Rundlauf besuchen die Azubis die Teilbereiche unserer IT-Abteilung bzw. auch die Fachbereiche unseres Unternehmens. Zum einen bekommen sie dadurch ein besseres Verständnis von den Aufgaben der Kollegen, sie können aber auch in den Fachbereichen konkrete Probleme oder potentielle Projekte identifizieren, um die Arbeit im Unternehmen zu optimieren.

Jeder Azubi bekommt während der Ausbildung Zeit, um seinen eigenen Webserver aufzusetzen. Der kann dann z.B. für einen Blog, aber auch für ein Git-Repository oder OwnCloud genutzt werden. Dabei lernen die Azubis quasi nebenbei den Umgang mit Linux, die Absicherung eines Internetservers und vielleicht sogar noch eine neue Programmiersprache.

Regelmäßig/wiederholend

Täglich

In einem täglichen Standup-Meeting werden die aktuellen Aufgaben aller Teilnehmer besprochen und eventuell neu priorisiert. Dadurch bekomme ich als Ausbilder einen besseren Überblick über die aktuellen Tätigkeiten und kann Probleme auch frühzeitig erkennen. Hier kann man z.B. die drei Fragen aus dem Daily Scrum beantworten:

Was habe ich seit dem letzten Mal bearbeitet?

Was werde ich bis zum nächsten Mal bearbeiten?

Was waren meine Probleme?

Wöchentlich

Wöchentlich führe ich mit jedem meiner Azubis ein 30-minütiges O3 durch, in dem wir über den aktuellen Stand der Ausbildung aber auch private Inhalte sprechen können.

Zusätzlich gibt es ein Weekly Review mit allen Azubis, in dem jeder Teilnehmer seinen Link der Woche vorstellt, einen Code-Schnipsel, der ihn stolz macht, und die Inhalte meiner Website (Podcast oder Fachartikel) besprochen werden.

Gerade zu Beginn der Ausbildung führe ich auch wöchentlich Lernzielkontrollen mit den Azubis durch, um von Anfang an zielgerichtet auf die Abschlussprüfung hinzuarbeiten.

Zweiwöchentlich

Alle zwei Wochen findet unsere Teambesprechung statt, zu der die Azubis die Besprechungsprotokolle anfertigen. Dabei sollen sie sich mit den verwendeten Fachbegriffen auseinandersetzen und so ganz nebenbei die Inhalte des Berufs und des eigenen Unternehmens lernen.

Im Bi-Weekly Review sprechen wir über durchgeführte Code Reviews und Pair Programmings. Jeder Azubi hat die Möglichkeit, eigenen Code Review zu lassen, aber auch sich Code eines anderen anzuschauen. Und darüber hinaus sollen sie noch Pair Programmings mit anderen Kollegen durchführen.

Monatlich

Einmal im Monat wird das Berichtsheft kontrolliert. Dieser wichtige Ausbildungsinhalt, der auch wichtig für die Zulassung zur Prüfung ist, soll von den Azubis eigenständig einmal im Monat erstellt werden und wird dann von mir als Ausbilder korrigiert und abgezeichnet.

Jeder Azubi soll einmal im Monat einen längeren Fachartikel schreiben, der potentiell auch auf dem eigenen Blog veröffentlicht werden kann. Ich korrigiere den Artikel und gebe Feedback zum Inhalt.

Alle drei Monate soll jeder Azubi einen kurzen Fachvortrag vor der IT-Abteilung halten. Dies dient der Vorbereitung auf die spätere Projektpräsentation, aber auch wieder der Vertiefung bestimmter fachlicher Inhalte.

Ab dem zweiten Lehrjahr gehe ich mit den Azubis einmal im Monat eine komplette IHK-Prüfung durch, damit das große Themenspektrum langfristig erarbeitet werden kann und auch die Fragestellung der IHK klar wird.

Halbjährlich

In halbjährlichen Evaluierungsgesprächen wird langfristig die Ausbildung geplant und ein detailliertes Feedback zur Arbeit des Azubis, aber auch des Ausbilders eingeholt.

Jährlich

Einmal im Jahr führen die IT-Azubis für die neuen Azubis ein Bootcamp durch, bei dem technische Inhalte wie z.B. Shortcut in häufig benutzten Programmen oder kleine Tools, um die Arbeit zu erleichtern, vorgestellt werden. Dies trainiert die Azubis für Schulungen und beim Sprechen vor großen Gruppen.

Literaturempfehlungen

Das hier sind die Bücher aus dem erwähnten Buchclub.

*(direkt beim Rheinwerk-Verlag bestellen*)

Sandi Metz - 99 Bottles of OOP

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Bewertung von Auszubildenden (Evaluierungsbögen)

Bewertung von Auszubildenden (Teil 2)

Podcast-Serie: Lernzielkontrollen

Häufige Fragen zum Berichtsheft

Vorbereitung auf die schriftliche Abschlussprüfung

Der eigene Webserver (Teil 1)

Azubi-Blogs: Jonas und Vincent

Zusammenfassung

Wie ich die Ausbildung gestalte

In meiner Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung verbinde ich eigenständiges Lernen mit regelmäßigem Austausch. Die beschriebenen Ansätze lassen sich auch auf andere IT-Berufe übertragen. Fast alle meine bisherigen Azubis haben mit einer Eins abgeschlossen.

Als IT-Azubi kannst du eigene Ideen einbringen und mit deinem/deiner Ausbilder:in besprechen, welche Termine oder Lernformen dir helfen. Bei meinen Angeboten ist dein Feedback ausdrücklich erwünscht, auch wenn Termine ausfallen oder etwas im Alltag schlecht funktioniert.

Einige Lernformen entfalten ihre Wirkung über mehrere Monate. Deshalb beginne ich früh mit festen Terminen und passe sie an den jeweiligen Lernstand sowie die Aufgaben im Betrieb an. Die meisten beschriebenen Angebote gehören seit Jahren zu meiner Praxis; das tägliche Stand-up ist erst seit wenigen Wochen dabei. Das jährliche Bootcamp steht zum Zeitpunkt der Aufnahme noch bevor.

Im eigenen Tempo lernen

Tutorials zu konkreten Technologien

Zum Ausbildungsbeginn bearbeitest du bei mir ein Java-Tutorial selbstständig. Java ist im Betrieb verbreitet und deckt objektorientierte Inhalte für die Abschlussprüfung ab. Der englisch kommentierte Code hilft dir zugleich, Fachbegriffe kennenzulernen.

Wie lange du dafür brauchst, hängt von deinen Vorkenntnissen und deinem Lerntempo ab. Eine feste Zeitvorgabe gibt es dafür nicht. Du probierst den Code aus und programmierst selbst, bevor du mit Projekten beginnst. Bei Fragen stehen dir neben mir auch erfahrenere IT-Azubis zur Seite.

Im weiteren Verlauf kommen Tutorials zu Git hinzu; SQL und Datenmodellierung bearbeitest du ebenfalls auf diesem Weg. Ich erstelle die Materialien selbst oder prüfe geeignete Angebote, bevor ich sie dir gebe.

Fachbücher gemeinsam lesen

Im Buchclub vereinbare ich mit dir, welche Kapitel du bis zum nächsten Gespräch liest. Die festen Termine helfen dabei, regelmäßig Zeit zum Lesen einzuplanen. Anschließend bespreche ich mit dir die Inhalte und offene Fragen.

Zu meinen Büchern gehören das IT-Handbuch für Fachinformatiker:innen und 99 Bottles of Object Oriented Programming. Letzteres behandelt unter anderem Refactoring und testgetriebenes Entwickeln sowie lesbaren Code....

Ein Interview zu den IHK-Prüfungen mit Dr. Ingo Strauch - Prüfer für Anwendungsentwickler in Hamburg - gibt es in der einhundertzwölften Episode des Anwendungsentwickler-Podcasts.

TL;DR

Ich spreche mit Dr. Ingo Strauch, der seit 2010 angehende Fachinformatiker:innen für Anwendungsentwicklung an der Handelskammer Hamburg prüft. Für deine IHK-Prüfung helfen dir ein verständlicher Projektantrag, eine sorgfältig geprüfte Dokumentation und eine geübte Präsentation mit gesicherten Dateien. Im Fachgespräch werden Fragen zu deinem Projekt gestellt, aus denen sich Themen wie Objektorientierung oder IT-Sicherheit ergeben. Die besprochenen Vorgaben zu Seitenumfang, Projektzeit und Zielgruppe hängen von der jeweiligen Kammer ab; zum Berufsalltag gehören außerdem verständliche Bugreports, Tests und die Zusammenarbeit mit anderen Menschen.

Kapitelmarken

[00:00:00] Einführung ins Interview über IHK-Prüfungen

[00:01:13] Dr. Ingo Strauch und sein Arbeitgeber

[00:03:30] Von der Physik zur Softwareentwicklung

[00:08:00] Programmiersprachen in Forschung und Beruf

[00:11:08] Einstieg als ehrenamtlicher IHK-Prüfer

[00:14:47] Prüfungstage und Zeit pro IT-Azubi

[00:16:33] Freistellung und Aufwand für Projektdokumentationen

[00:18:18] Dokumentationen lesen und Ausschüsse organisieren

[00:20:50] Ein Testmodul für Drohnenabwehrsoftware

[00:22:32] Einblicke in Unternehmen und wiederkehrende Projekte

[00:25:37] Seitenvorgaben und Umfang der Abschlussprojekte

[00:28:32] Prüfungen überarbeiten und mündliche Prüfungszeiten

[00:31:05] Fragen im Fachgespräch und IT-Sicherheit

[00:34:34] Fehlende Unterstützung und vermeidbare Fehler

[00:38:43] Projektzeit und Projektdokumentation

[00:42:08] Einen verständlichen Projektantrag schreiben

[00:44:12] Eigenleistung und Programmcode dokumentieren

[00:46:42] Einheiten, Schreibfehler und unvollständige Kapitel

[00:50:01] Auftreten und technische Vorbereitung

[00:52:56] Antworten im Fachgespräch bewerten

[00:56:32] Wohlwollen gegenüber IT-Azubis

[00:57:35] Die Zielgruppe der Präsentation wählen

[00:59:32] Was gute Prüfer:innen ausmacht

[01:01:41] Screencast und Live-Demo im Prüfungsraum

[01:04:43] Bücher für Softwareentwicklung und Teamarbeit

[01:09:57] Deployment, Bugreports und Kommunikation im Beruf

[01:12:05] Kontakt zu Ingo Strauch und Verabschiedung

[01:13:11] Rückblick auf das Interview und Shownotes

Inhalt

Über folgende Fragen haben wir im Verlauf des Interviews gesprochen.

Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Ich heiße Ingo Strauch und arbeite bei der Eurofins Information Systems GmbH in Hamburg

Wenn mir die schamlose Eigenwerbung erlaubt ist: wir sind bei der Great Place To Work "Deutschlands beste Arbeitgeber 2017" Mitarbeiterumfrage unter die ersten 100 von über 700 teilnehmenden Firmen gekommen

Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Alles angefangen hat mit dem Commodore 128, wo ich neben den ganzen Spielen irgendwann mit Basic und Assembler im Selbststudium angefangen habe zu programmieren

In der Schule hatte ich seit der 9. Klasse Informatik Grundkurs, in dem wir dann Pascal und Assembler programmiert haben (in der 13. Klasse nur noch zu Dritt plus Lehrer)

Nach einer Pause während des Physik-Studiums wurde mein Interesse dann wieder geweckt, als ich über das Uni-Rechenzentrum mit Unix/Linux in Berührung kam

Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?

Gar keins, denn ich habe wie gesagt Physik studiert

Aber bei der Diplomarbeit war neben der Datenanalyse ein Schwerpunkt die Software-Entwicklung. Damals sollte das Analyse-Framework für die Kollegen neu geschrieben und ich war fast von Anfang an dabei und durfte oder musste mein eigenes Erzeugnis dann auch für die eigene Diplom- und später Doktorarbeit benutzen

Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Das ist im Moment hauptsächlich C#

Was ist deine Lieblingsprogrammiersprache und warum?

Auch hier: C#. Man kann viel kompakteren Code schreiben als z.B. mit C++

IHK-Prüfungen

An welcher IHK prüfst du?

Das ist die Handelskammer in Hamburg

Welchen Beruf prüfst du?

Fachinformatiker Anwendungsentwicklung

Wie bist du Prüfer geworden?

Das war 2010. In der damaligen Firma sollte wieder ausgebildet werden. Dazu gab es eine Info-Veranstaltung von der Personalabteilung

Selbst ausbilden wollte ich damals nicht. Der Personalchef hat aber im Auftrag der Handelskammer für die Prüfertätigkeit geworben, weil der Bedarf dort immer hoch ist

Wenige Monate später saß ich dann als vollwertiges Mitglied in meinem Prüfungsausschuss, weil dort jemand ausgeschieden war

Warum bist du Prüfer geworden?

Es klang ganz interessant. Ich war neugierig, womit sich andere Unternehmen so herumschlagen.

Und weil ich damals auch an Software für den Bildungssektor gearbeitet habe, fand ich das ganz naheliegend. Außerdem ist es eine schöne Tätigkeit, um etwas an die Gesellschaft zurückzugeben.

Was waren die Voraussetzungen, um Prüfer zu werden, und wie lief das ab?

Weil ich selbst gar nicht den Beruf gelernt habe, den ich nun prüfen wollte, lief es darüber, dass ich das Anderthalbfache der Ausbildungsdauer in dem Beruf gearbeitet habe, also mindestens 4,5 Jahre.

Ansonsten gab es so wenig Fomalitäten zu erledigen, dass ich mich nicht mal mehr erinnere, wie das genau lief.

Jetzt gibt es halt alle 5 Jahre eine neue Berufungsurkunde und zum 15. Jubiläum bekomme ich dann eine Alsterrundfahrt spendiert.

Wirst du für deine Prüfungstätigkeit auf der Arbeit freigestellt?

Ja, für die Prüfungstage werde ich von meinem Arbeitgeber freigestellt

Die Korrektur der vorab eingereichten Projektdokumentationen mache ich in meiner Freizeit nach Feierabend oder am Wochenende

Was macht dir an der Prüfertätigkeit Spaß?

Ich finde es super interessant, dadurch mitzubekommen, wie vielfältig die Software-Entwicklungs-Szene in Hamburg ist. Wie unterschiedlich die Firmen sind und ihre Projekte/Branchen. Aber auch wie ähnlich. Allein schon, wer alles schon programmiert hat, Task-Boards mit Bugtrackern oder Zeiterfassungssystemen zu koppeln...

Außerdem finde ich es leichter, Dinge zu verstehen, wenn ich sie konkret vor mir sehe, statt nur Artikel darüber zu lesen. Und im eigenen Job kann man nun mal nicht alles selbst ausprobieren.

Nicht zuletzt macht der Austausch mit meinem Mitprüfern viel Spaß.

Was nervt dich an der Prüfertätigkeit?

Wenn's die Azubis unnötigerweise versemmeln. Aber noch mehr, wenn der Ausbildungs- oder Umschulungs-Betrieb das zulässt.

Leider kommt es immer wieder dazu, dass wir als Prüfer den Eindruck haben, dass niemand anderes sich ernsthaft die Projektdoku oder die Präsentation angeguckt hat

Was würdest du an den IHK-Prüfungen verändern, wenn du es könntest?

Wir prüfen sehr wenige Frauen, aber das lässt sich eher weniger über die Prüfungsausgestaltung beeinflussen

Was zeichnet deiner Meinung nach einen guten Prüfer aus?

Erst einmal die Bereitschaft, über den Tellerrand zu gucken, da man die meiste Zeit mit Projekten/Technologien konfrontiert wird, die man in der Form selbst so noch gar nicht hatte

Ein gewisses Wohlwollen den Prüflingen gegenüber, damit man sie nicht noch nervöser macht, als sie oft schon sind. Und damit man ggf. das Thema wechselt, wenn man merkt, der Prüfling weiß darüber wirklich nichts mehr.

Gibt es häufige Fragen, die ihr immer wieder im Fachgespräch stellt?

Neben konkreten Fragen, die sich aus dem Projekt und der Präsentation ergeben, gerne Grundsätzliches zur Objektorientierung (z.B. Polymorphismus), Datenbanken (z.B. SQL Injections, Prepared Statements), aber zu viel sollte ich wohl nicht verraten :-)

Reine Wissensfragen stellen wir eher wenig, mehr Detailfragen dazu, wie und warum etwas im Abschlussprojekt gemacht wurde. Oder wir lassen uns grob skizzieren, wie eine Erweiterung programmiert werden würde, z.B. wie eine mobile App in die Architektur passen würde

Welche Tipps hast du für angehende Prüflinge (schriftlich, Antrag, Doku, Fachgespräch)?

Den Antrag bitte nicht zu knapp formulieren. Und insbesondere drauf achten, dass jemand völlig Fremdes das lesen und verstehen muss. Oft müssen wir die erste Fassung ablehnen, weil das nur ein Firmeninterner verstehen kann. Im schlimmsten Fall kennt keiner der Prüfer die verwendete Programmiersprache, die Tools oder Bibliotheken!

Bei der Doku lege ich schon einigen Wert darauf, dass man erkennt, was der Azubi selbst gemacht hat. Daher missfallen mir so Formulierungen wie "es wurde XY gemacht". Da weiß ich im Zweifel nicht, ob das nicht auch jemand anderes war.

Und leider finde ich auch die Kapitel zur eigentlichen Durchführung in nicht wenigen Fällen sehr allgemein, so dass ich mich frage, ob das jetzt nur ein Fachkonzept war oder ob wirklich etwas programmiert wurde. Von daher möchte ich eigentlich immer auch Code sehen, wo "etwas passiert", d.h. keine reinen DTOs. Meine Mitprüfer sehen das aber weniger streng.

Und natürlich: Schreib- oder Rechenfehler in Doku und Präsentation hinterlassen keinen guten Eindruck.

Als Physiker rollen sich mir auch gerne mal die Zehennägel hoch, wenn bei Berechnungen die Einheiten nicht stimmen. Am Ende steht da dann z.B. bei der Kostenrechnung die richtige Zahl plus Währungssymbol, aber mathematisch korrekt geschrieben sind die Gleichungen nicht.

Was sind No-Gos für Prüflinge bei den Prüfungen?

Schlechte Vorbereitung. Es gab tatsächlich mal einen Prüfling, der hatte seine Präsentation nur auf genau einem USB Stick und der ging just vor der Prüfung kaputt.

Wenn die Prüflinge niemanden über die Doku oder Präsentation drüber schauen lassen und sie letztere offenbar nie zur Probe gehalten haben. Wobei man da nicht ausschließen kann, dass es an schlechter Betreuung lag und der Betrieb das zu verantworten hat.

Und sehr schwer wird es für die Prüfer, wenn sie den Prüflingen alles sehr zäh aus der Nase ziehen müssen.

Was waren deine witzigsten/überraschendsten Prüfungssituationen?

...

Ein spannendes Interview über das Leben als Consultant mit Nina Sauermann gibt es in der einhundertelften Episode des Anwendungsentwickler-Podcasts.

TL;DR

Mit SAP-Beraterin Nina Sauermann spreche ich darüber, wie du nach der Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung ins Consulting einsteigen kannst. Je nach Projekt gehört dazu viel ABAP-Code, während du in anderen Projekten vor allem Anforderungen klärst und mit Kund:innen sprichst. Dafür brauchst du fachliches Wissen und die Fähigkeit, technische Fragen verständlich zu vermitteln. Wechselnde Projekte bringen neue Erfahrungen mit sich; zum Arbeitsalltag gehören auch kurzfristige Überstunden und Dienstreisen, die dein Privatleben belasten können.

Kapitelmarken

[00:00:00] Einführung ins Interview über Consulting

[00:01:15] Nina Sauermann und ihr Weg zur Anwendungsentwicklung

[00:05:07] SAP HCM und Erfahrungen mit der Zeitwirtschaft

[00:08:37] Fachliche Regeln am Beispiel eines Bonussystems

[00:11:17] ABAP und weitere Technologien im SAP-Umfeld

[00:13:10] Systemzugriff und Rechte beim Entwickeln

[00:14:45] Transaktionen und Programmnamen

[00:17:11] SAP und kundenspezifischer Code

[00:18:30] Einstieg in den Beruf als SAP-Beraterin

[00:21:03] Anforderungen klären und Aufwand vermitteln

[00:25:01] Schulung zu Kommunikation und Auftreten

[00:27:44] Wie viel Programmieren zum Consulting gehört

[00:28:53] Projekte vorbereiten und technische Begriffe klären

[00:32:58] SAP-Standard an betriebliche Abläufe anpassen

[00:35:55] SAP ohne eigene Entwickler:innen betreiben

[00:38:01] Daten finden und mit der SAP-Hilfe arbeiten

[00:40:15] Zeit zum Einarbeiten und Module wechseln

[00:43:35] Fachwissen und der Einstieg als Junior-Berater:in

[00:46:25] Aufgaben und Betreuung während der Ausbildung

[00:47:23] Dienstreisen und Remote-Arbeit

[00:50:43] Warum Unternehmen externe Berater:innen beauftragen

[00:53:22] Widerstand gegen zusätzliche Freigaben

[00:55:50] Systeme zum Testen und Transportaufträge

[00:58:42] Nachwuchs für SAP und ABAP finden

[01:03:06] Selbstsicher auftreten und Vertrauen gewinnen

[01:07:04] Neue Aufgaben und unregelmäßige Arbeitszeiten

[01:09:02] Wie Kund:innen die Arbeit kontrollieren

[01:10:22] Dienstreisen und ihre Folgen fürs Privatleben

[01:13:32] Zeit für Städte und gemeinsame Unternehmungen

[01:14:50] Gespräche führen und Small Talk üben

[01:18:48] Lieblingsprogrammiersprache und Kontakt zu Nina

[01:20:39] Shownotes und Feedback

Inhalt

Folgende Fragen haben wir u.a. im Verlauf des Gesprächs geklärt.

Consulting

Was ist eigentlich ein Consultant?

Was macht ein Consultant den ganzen Tag?

In welchem Bereich bist du als Consultant unterwegs?

Wie bist du zum Consultant geworden?

Welche Skills sollte man mitbringen, wenn man Consultant werden möchte?

Welche Rolle spielen Soft Skills in deinem Arbeitsalltag?

Erwarten Kunden von dir, dass du die Technik komplett beherrschst oder darfst du auch mal etwas nachfragen?

Wie laufen Consulting-Projekte ab?

Warum engagieren deine Kunden dich, anstatt einen eigenen Mitarbeiter einzustellen?

Bist du ständig auf Reisen oder hast du auch mal einen "normalen" Alltag?

Besteht dein Alltag nur aus Meetings oder setzt du auch etwas um?

Welchen Teil deiner Arbeitszeit musst/darfst du in Weiterbildung investieren?

Wie bildest du dich weiter, um die bestmöglichen Lösungen für deine Kunden zu finden?

Was gefällt dir an deinem Job als Consultant?

Was magst du nicht an deinem Job als Consultant?

Hast du Literaturempfehlungen für den Bereich Consulting?

Literaturempfehlungen

Im Nachgang hat Nina mir noch diese Buchempfehlung geschickt für alle, die in die Programmierung mit ABAP einsteigen möchten: Schrödinger programmiert ABAP*.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Nina bei fachinformatiker.de

Nina bei XING

Zusammenfassung

Ninas Weg ins SAP-Consulting

Für einen Einblick in den Beruf habe ich Nina Sauermann interviewt, die seit 2013 als SAP-Beraterin arbeitet. Sie hat zuvor eine Ausbildung zur Fachinformatikerin Anwendungsentwicklung bei der Hypovereinsbank abgeschlossen.

Ursprünglich hatte Nina sich für die Fachrichtung Systemintegration beworben. Nach einem Tag in der Entwicklungsabteilung und einer persönlichen Pro-und-Contra-Liste entschied sie sich für Anwendungsentwicklung, weil sie dort mehr Neues lernen konnte. Ihr erster Kontakt mit SAP war durch die vielen Informationen anstrengend.

In der Ausbildung arbeitete sie mit dem Personalmodul HCM, ausgeschrieben Human Capital Management. Dort beschäftigte sie sich unter anderem mit Arbeitszeiten und Lohnabrechnungen. Ihre Ausbilderin wählte passende Aufgaben aus und besprach mit ihr, wie sie diese umsetzen konnte. Direkten Kontakt zum Fachbereich hatte Nina vor allem bei ihrem Abschlussprojekt.

Fachliche Regeln verstehen und in Code abbilden

Wenn ein nächtlicher Job für die Zeitwirtschaft ausfiel, fehlten am nächsten Morgen die gebuchten Arbeitszeiten. Dadurch entstanden viele Tickets. Manche Mitarbeiter:innen trugen ihre Zeiten selbst nach, wodurch nach dem nächsten erfolgreichen Job doppelte Buchungen entstanden.

Bei einem späteren Projekt sollte Nina ein Bonussystem überarbeiten, das auf manuell ausgefüllten Excel-Listen beruhte. Dabei waren Boni an Personen ausgezahlt worden, die laut Vertrag keinen Anspruch hatten. Auch verstorbene Mitarbeiter:innen erschienen noch in den Vorschlägen.

Mit dem Fachbereich besprach Nina ausführlich, unter welchen Bedingungen jemand einen Bonus erhalten durfte. Der Code musste diese Regeln vollständig abbilden, damit berechtigte Personen ihren Bonus bekamen und unzulässige Zahlungen ausgeschlossen wurden. Solche Aufgaben verlangen, dass du die fachlichen Zusammenhänge verstehst.

Mit ABAP im SAP-System entwickeln

Nina programmiert beruflich ausschließlich mit ABAP. In ihrer Ausbildung lernte sie außerdem Java und erhielt eine Schulung zu COBOL. Je nach SAP-System und Modul kommen auch Java-Komponenten vor. UI5 und Fiori werden im Gespräch als Technologien für neuere Oberflächen und Apps genannt; damit arbeitete Nina zum Zeitpunkt des Interviews selbst noch nicht.

Für ihre Arbeit braucht sie Zugriff auf das jeweilige SAP-System. Die Entwicklungsumgebung ist darin integriert. Nina arbeitet in der Transaktion SE80, in der sie Programme schreiben und direkt ausführen kann.

Eine Transaktion kann auch als Aufruf für ein Programm dienen. Anwender:innen geben dann den Transaktionsnamen ein und starten darüber das Programm, ohne es in der Entwicklungsumgebung suchen zu müssen.

Zu den beschriebenen Rahmenbedingungen gehören:

Viele Kund:innen betreiben für HCM ein eigenes System. Der Zugriff hängt davon ab, welches System freigegeben ist.

Quellcode konnte Nina in ihren Projekten meist einsehen. Zum Ändern brauchte sie einen zusätzlichen, bei SAP registrierten Schlüssel, der mit Lizenzkosten verbunden war.

Eigene Programme beginnen mit Y oder Z. Kund:innen können auch einen eigenen Namensraum kaufen.

Nina beschreibt, dass SAP kundenspezifischen Code unter den vereinbarten Bedingungen in den Standard übernehmen kann.

Im Gespräch zeigt sich außerdem, wie unterschiedliche Begriffe technische Gespräche erschweren können. ABAP- und Java-Entwickler:innen diskutierten längere Zeit über denselben Sachverhalt, bis Nina zwischen ihnen vermittelte. Als Beispiel nennt sie Wahrheitswerte, die in ihrem ABAP-Alltag häufig durch ein Zeichenfeld mit X beziehungsweise einem leeren Inhalt dargestellt werden.

Was du im Consulting machst

Ninas Einstieg führte sie früh zu Kund:innen. Die angekündigte längere Phase mit Schulungen wurde verkürzt, sodass sie zunächst kleinere Programmieraufgaben übernahm und kurz darauf an umfangreichen Projektgesprächen teilnahm.

Als Berater:in klärst du mit Kund:innen, was ein Programm leisten soll und welchen Aufwand das verursacht. Häufig sprichst du dabei mit Personen, die ihre fachlichen Ziele kennen und wenig technisches Wissen mitbringen. Du musst nachvollziehbar vermitteln, warum eine Aufgabe beispielsweise zehn Tage dauert und welcher Aufwand hinter einem gewünschten Ergebnis steckt.

Wie viel Zeit du mit Code verbringst, hängt vom Projekt ab. Nina schätzte ihren Anteil zum Zeitpunkt des Interviews auf etwa 80 Prozent. In anderen Projekten hatte sie viele Besprechungen und Telefonate, gegen Projektende teilweise zwei einstündige Telefonkonferenzen pro Tag.

Vor einem Termin sind der grobe Umfang und erste Konzepte meist bekannt. Mitarbeiter:innen im Vertrieb klären vorab Wünsche und fragen nach, wie viel Zeit die Arbeit erfordert. Im Termin werden anschließend Details und Termine besprochen. Nina erlebte auch kurzfristige Einsätze, bei denen sie erst vor Ort erfahren sollte, was zu tun war.

Mit Kund:innen sprechen und auftreten

Eine einwöchige Schulung behandelte, wie Nina E-Mails formuliert und Fehler bei Kund:innen diplomatisch anspricht. Auch Kleidung und Verhaltensregeln wurden geübt. Beim ersten Besuch erschien sie grundsätzlich formell gekleidet; bei weiteren Terminen orientierte sie sich am jeweiligen Umfeld. Gerade bei Banken und Versicherungen gehörte entsprechende Kleidung dazu.

Präsentationen müssen zu den teilnehmenden Personen passen. Für eine Geschäftsführung bereitest du Inhalte anders auf als für Entwickler:innen.

Nina betont außerdem, wie wichtig es ist, sicher aufzutreten und für die eigene Arbeit einzustehen. Als junge Beraterin wurde sie teilweise zunächst wenig ernst genommen. In einem Projekt schrieb ein Kunde trotz ihrer Antworten weiterhin ausschließlich ihrem erfahrenen Kollegen. Nachdem Nina die Fragen über zwei Wochen hinweg bearbeitet hatte, wandte er sich direkt an sie.

SAP an betriebliche Abläufe anpassen

SAP bietet Standardprozesse, während Betriebe eigene Anforderungen mitbringen. Diese werden durch Customizing oder zusätzlichen Code abgebildet.

Ein Beispiel aus Ninas Ausbildung betrifft das Spenden der Cent-Beträge des Nettogehalts. Ihr Ausbildungsbetrieb wollte das Geld selbst sammeln und um denselben Betrag ergänzen....