Saheeda

Pseudocode. Im Code schreiben bin ich geübt, das geht mir einfach von der Hand (wenn die grobe Idee erstmal steht). Bei PAP oder Struktogramm muss ich überlegen, wie genau die "Syntax" dafür ist, um mir nicht dadurch Fehlerquellen einzubauen.

Hi, wie gut ist dein Englisch? Du wirst vermutlich jeden Tag zumindest schriftlich damit zu tun haben. Ansonsten: Frag doch mal deinen Mann. Wenn er bei derselben Behörde arbeitet, kann er ja ungefähr einschätzen, wo deine Schwächen liegen (in Bezug auf den Tätigkeitsbereich der FISIs in dieser Behörde= und auf welchem Stand du im Vergleich zu anderen Azubis bist. Mit Microsoft Office wirst du vermutlich wenn überhaupt dann nur peripher zu tun haben, zu viel Zeit würde ich darin nicht versenken. Stress dich nicht. Eine Ausbildung ist zum Lernen da. Ich wünsche dir ganz viel Erfolg.

@Julian-B90 Die Vorgaben "meiner" IHK (Dresden) waren ähnlich denen deiner. Da hier im Forum oft die Punkte Ist-Analyse und Soll-Konzept mit aufgeführt werden, hatte ich dies mit aufgenommen und mein Antrag wurde auch im ersten Anlauf akzeptiert. Irgendwo ist es auch logisch: Du musst in deinem Antrag irgendwie darlegen/plausibel machen, warum und mit welchem Ziel das Projekt durchgeführt wird. Ob du das jetzt explizit "Ist-Analyse" nennst oder anderweitig im Text beschreibst, macht ja inhaltlich keinen großen Unterschied. (Wenn die jeweilige IHK so einen Punkt explizit fordert ist es natürlich schlau, das auch dort aufzuführen!).

Hm, also ich würde hier glaube nur noch ein paar Sachen ändern: das hier umformulieren das hier streichen, Bezug zur Firma einbauen und Rechtschreibung/Grammatik prüfen lassen. Ansonsten weiß ich nicht, wo hier zu viel Pathos sein soll. Ich lese Motivation, Begeisterung und Liebe zur Technik - genau das ist doch die Grundvoraussetzung für eine Anstellung, egal ob Azubi oder Facharbeiter. Bei einem angehenden Azubi würde ich ehrlich gesagt auch darüber hinweg sehen, dass das Berufsbild vielleicht noch nicht zu 100% zur Realität passt. Darüber informieren ja - aber die konkrete Praxis sieht doch am Ende eh anders aus. Ich denke, bei uns würdest du ne Einladung zum Vorstellungsgespräch erhalten.

Inhaltlich finde ich den Punkt gar nicht so schlecht, nur an der Formulierung müsste man arbeiten. Was ich daraus lese: Der TO hat gemerkt, dass die Ausbildung die falsche Entscheidung war. Statt jetzt aber mittendrin abzubrechen hat er (oder sie) sich gesagt "Arschbacken zusammenkneifen und durch". Genau das ist doch die Skepsis bei krummen Lebensläufen: "Wird derjenige es diesmal durchziehen?", "Wird sich die Investition in die Ausbildung rentieren?". Ich stimme Maniska aber insofern zu: Weniger Mimimi. Erzähl, was du gemacht hast, womit du dich beschäftigst, was dich begeistert. Wenn du n Mini-ITX zusammengeschraubt hast, erzähl das. Wenns dir Spaß macht, an irgendwelchen technischen/logischen Problemen zu schrauben, erzähl das. Wenn du dir (rudimentäre) Skript-Kenntnisse angeeignet hast, erzähl das. Von Excel würde ich glaube erst anfangen, wenn mir sonst nichts Besseres einfällt.

Ich hatte damals keine. Mein Chef grinste mich bei der Frage an und meinte nur "Wir hatten 3 Jahre Zeit, uns kennen zu lernen, ich denke, das passt."

Im 1. Lehrjahr haben wir vor allem Übungsaufgaben gemacht, um das erkennen/analysieren von Problemen und deren Zerteilung zu üben. Die Programmieraufgaben gingen mehr in Richtung "Entwirf einen Algorithmus für Problem xy" oder "Implementiere Algorithmus xy". Gegen Ende des 1. Lehrjahrs wurden wir in die firmeneigenen Frameworks eingearbeitet. Das fing bei "Bau ne einfache Bücherverwaltung" an und wurde mit der Zeit immer komplexer (Vernünftiges Fehlerhandling, externe APIs/Urls abfragen, Benachrichtigungen erzeugen, etc.) Im 2. Lehrjahr wurden wir stückchenweise in reale Projekte integriert (aufgrund der Projektgrößen waren dies nur Teilmodule). Die Aufgaben waren quer beet: XLS auslesen und importieren, Datenbankmigration, GUI nach Vorgaben umsetzen. Im 3. hatte ich die erste eigene (kleine) Anwendung (von Datenbank bis hin zu GUI und Kommunikation mit nem anderen System war da fast alles drin). Mein Ausbilder stand mir währenddessen noch bei der Konzeption/größeren technischen Problemen zur Seite. Gelernt habe ich primär Java und n bisschen JavaScript.

Ich geh noch n Schritt weiter: Wer den Code schreibt, muss ihn (bzw die Anwendung) auch dokumentieren. Wenn ich von unseren Projekten ausgehe, steckt im Code oft viel implizites Wissen. Doku ist nicht nur "was" macht der Code (das sehe ich), sondern vor allem "warum". Es geht um den größeren Zusammenhang, Querverweise auf ähnliche Konstruktionen (und den Unterschied dazu), Querverweise aufs Konzept oder andere Quellen, Hinweise zur Benutzung, etc.

@Crash2001 Ich gebe dir Recht, dass man das bloße Aufsetzen einer VM (und bisschen damit rumspielen) auch gut allein zuhause machen kann. Was aber finde ich schwer umsetzbar ist, sind Best-Practices und diverse Tipps und Tricks, die man erst mit der Erfahrung (durch ältere Kollegen) lernt. Beispiel (ich bin AE, deswegen fällt mir so ein Beispiel einfacher): Reines Java oder JEE kann ich daheim lernen. Was ich aber durch meinen Ausbilder bzw. das Arbeiten damit in der Firma gelernt habe, war die praktische Anwendung von z.B. Design Patterns. Oder z.B. eigene Frameworks zu bauen, die stabil sind und nicht bei der ersten komischen Eingabe abrauchen (Und auch benutzbar sind). Nicht zu vergessen der ganze Bereich Clean-Code. Ich glaube, solche Dinge sind nur sehr schwer daheim im eigenen Kämmerchen erlernbar. Da ist das Wissen und die Erfahrung älterer Kollegen einfach unglaublich hilfreich und wertvoll.

Ich hab damals auch den kompletten Zeitraum angegeben. Zur Zeitpunkt der Einreichung konnte ich ja noch nicht wissen, wann ich effektiv dafür eingeplant werde. Im 3. Lehrjahr sind ja die meisten bereits fest ins Tagesgeschäft eingebunden, ergo entscheiden da noch andere Faktoren mit, wann man wie viel Zeit in die Projektarbeit investieren kann.

Für mich klingt das nach einem der Hauptprobleme für miesen Code. Wenn man immer nur "schnell-schnell" arbeiten soll und damit alles nur oberflächlich versteht, ist es fast schon vorprogrammiert, dass die eigene Lösung nur Gefrickel ist oder beim nächsten Husten ganz schnell andere Teile des Systems ins Wanken bringt. Ich halte es für unmöglich, ein fremdes System in 15 Minuten soweit zu verstehen, dass man eine stabile Lösung einbauen kann.

Also ich sehe es als Teil der Professionalität, zu wissen, wie man sich bei offiziellen Anlässen kleidet. Ich verkaufe in dem Moment nicht nur mich/meine Leistung, sondern repräsentiere auch meinen Arbeitgeber. Bei Kunden kann ich auch nicht in Jogginghose auftreten. Dafür Punkte abzuziehen finde ich zwar auch etwas übertrieben, aber das liegt halt im Ermessen der IHK und wenn mans weiß, kann man sich entsprechend vorbereiten.

War bei mir (als FIAE) ähnlich. Hast du denn die Möglichkeit, dir auf Arbeit ne Art Laborumgebung aufzubauen? Dann könntest du dich mit euren Programmen und Systemen vertraut machen, ohne Angst zu haben, was reales kaputt zu machen.

Ich hatte so gut wie keine Ahnung vom Programmieren und habe vor meiner Ausbildung n Praktikum absolviert. Ich hab in der Zeit vor allem Aufgaben bekommen, die meine Selbstständigkeit und mein logisches Denken prüfen sollten (und nebenbei hab ich eben auch sehr viel übers Programmieren gelernt). Keine Vorkenntnisse zu haben ist vollkommen ok (und manchen Ausbildern sogar lieber, da dir weniger Mist abgewöhnt werden muss), solange du das "gewisse Etwas" hast. Dinge wie Selbstständigkeit, eine schnelle Auffassungsgabe, logisches Denken und grundlegende Anstandsregeln sind viel wichtiger.

IMHO klingt die dritte Person (also "Der Entwickler hat... gemacht") hier total falsch. Was spricht denn gegen das vollkommen neutrale "Es wurde xy gemacht"?