Berichtsheft

[Aika]

Hallo,

seit 2 Jahren schreibe ich nun schon meist die gleichen Dinge in meine Wochenberichte. Ich arbeite in keinem Softwareunternehmen, sondern bei einem Metallbauunternehmen und wir bearbeiten eben Aufgaben der It im Unternehmen. Also schreibe ich z.B.

Montag: PC repariert

Dienstag: Drucker insatlliert

Mittwoch: auf Helpline mitgearbeitet - Aufträge verteilt an entsp. Mitarbeiter

Donnerstag: Fachzeitschriften gelesen

Freitag: Arbeitsplatz gesäubert

oder...Lagerbestand überprüft und aufgeräumt, Monitor und Drucker in bestehendes PC-System aufgebaut, Server überprüft.....

Was schreibt ihr den so, ich hab echt keine Ideen mehr und kann ja nicht immer nur das gleiche schreiben auch wenn es in der Realität meist so aussieht - Kaffee trinken, Halle fegen, mit Kollegen gequatscht....

[SaintsRow]

Moin,

Sind das denn nach zwei Jahren immer noch die Aufgaben, die man Dir da so gibt? Fachzeitschriften lesen als tagesfüllende Tätigkeit? Drucker installieren? EIN Drucker auf den ganzen Dienstag? Da sagt bisher niemand was dazu?

Im eigenen Interesse solltest Du versuchen, mehr und anspruchsvollere Aufgaben zu bekommen. Falls Du nicht übernommen wirst oder freiwillig den Arbeitgeber wechseln willst (nach bestandener Prüfung), wird es schwer mit diesen "Referenzen" etwas zu finden.

Gar nichts gegen Dich, aber solche Aufgaben sind eines FI Azubis (ich nehme an Systemintegration?) im Zweiten Jahr, oder sogar schon weiter, unwürdig.

[pr0gg3r]

Ich würde mir in erster Linie weniger Sorgen um das Berichtsheft machen, sondern eher um deine Ausbildung! Mit diesen Tätigkeiten kommst du, wie SaintsRow bereits geschrieben hat, leider nicht weit.

Es gibt deshalb einen Ausbildungsrahmenplan. Darin steht, was dir begebracht werden muss(!). Setz dich mit deinem Ausbilder zusammen und gehe diesen Rahmenplan durch, damit du entsprechende Aufgaben bekommst. Der Ausbilder ist verpflichtet das zu tun!

Wenn du dann andere (anspruchsvollere) Aufgaben bekommst, ist das "Problem" mit dem Berichtsheft von ganz alleine gelöst

[Aika]

Ja eben das meine ich ja, aber viel andere Aufgaben gibt es hier nicht. Könnt ihr konkreter mal ein paar Beispiele geben was ihr unter anspruchsvolleren Aufgaben versteht?? Dann kann ich damit zu meinem Ausbilder gehen und ihm genau sagen was ich eidentlich tun sollte....

[Wuwu]

Was schreibt ihr den so, ich hab echt keine Ideen mehr und kann ja nicht immer nur das gleiche schreiben auch wenn es in der Realität meist so aussieht - Kaffee trinken, Halle fegen, mit Kollegen gequatscht....

Warum kannst Du das nicht? Mit Selbstbelügen schadest Du Dir im Endeffekt nur...

Dann kann ich damit zu meinem Ausbilder gehen und ihm genau sagen was ich eidentlich tun sollte....

Google kannst Du bedienen? Dann such mal nach Deinem Ausbildungsberuf und dem Stichwort "Rahmenlehrplan".

[Cometcola]

Moin,

also wenn dir Langweilig wird, dann such dir einfach eigene Projekte. Wenn es keinen stört, dass du nur rumsitzt, dann stört es auch keinen, wenn du eigenständig was lernen willst. Wenn genügen Hardware vorhanden ist, dann bau dir einfach mal nen kleines Netzwerk auf, nen Server, paar Clients und dann experementiere einfach drauf los. Steck dir Ziele und dann arbeite darauf hin. Als Tipp kann ich dir noch geben, alles sorgfälltig zu notieren und festzuhalten. Kann dann schon als Vorbereitung für dein Abschlussprojekt dienen (übe auch das (wissenschaftliche) Schreiben! Ist schwieriger als viele denken und es ist ein Unterschied, ob man vom letzten Urlaub schreibt oder man versucht technische Abläufe festzuhalten).

Als Anregung: Windows Server aufsetzen, verschiedene Dienste ausprobieren (FileServer, Email,Servergespeicherte Profile, etc.) Erst wenn man sowas mal gemacht hat, dann sieht man ein, dass Windows nicht nur Klickibünti ist, sondern man auch Fachwissen benötigt.

Ansonsten sind dir ja erstmal keine Grenzen gesetzt. Wenn du Anregungen brauchst, dann melde dich einfach.

[afo]

Montag: PC repariert

Dienstag: Drucker insatlliert

Mittwoch: auf Helpline mitgearbeitet - Aufträge verteilt an entsp. Mitarbeiter

Donnerstag: Fachzeitschriften gelesen

Freitag: Arbeitsplatz gesäubert

Habt ihr kein Netzwerk?

Keine Server?

[Wuwu]

Wenn genügen Hardware vorhanden ist, dann bau dir einfach mal nen kleines Netzwerk auf, nen Server, paar Clients und dann experementiere einfach drauf los.

Einer der schlimmsten Ansätze überhaupt... und leider immer mehr verbreitet auch in der Enterprise IT, frickeln bis es funktioniert.

[Cometcola]

@Wuwu: Ehrlich gesagt, verstehe ich deinen Beitrag nicht. Frickeln bis es funktioniert hat mit meinem Beitrag exakt gar nichts zu tun. Vielleicht hast du auch eine andere Definition von "experimentieren".

[SaJu]

Manchmal bleibt einem Azubi leider nichts anderes übrig, Wuwu. Es gibt nicht nur Spitzen-Ausbildungsbetriebe mit Enterprise-IT!

Eigenes Netzwerk aufbauen, installieren, alles ausprobieren bis es funktioniert und das dann schriftlich festhalten...

Ich war während meiner Ausbildung in einer ähnlichen Situation und wurde, nachdem die IHK einschritt, kurz vor der Zwischenprüfung von den "Müll"- und Deppen-Arbeiten befreit. Diese Zeit, wo ich zum "rumsitzen und nichts tun" verdonnert war, habe ich zum ausprobieren und selbstständigen lernen genutzt. Dafür habe ich mir Ziele gesteckt und alles mögliche ausprobiert.

Ohne dieses Wissen aus den Experimenten + Messen-/ Konferenz-Besuche während der Freizeit, würde ich heute auf der Straße stehen.

Mein Chef konnte nicht einmal Skripte schreiben... Was soll man dort beigebracht bekommen?

Mit dem selbstständigen Lernen (+ Motivation) habe ich es nach der Ausbildung in die Enterprise-IT geschafft.

Das ist in solchen Fällen der richtige Weg!

[Aika]

Ok und danke für eure Anregungen werde mal schauen dass sich in meiner Firma etwas ändert. Aber da es eben nur eine kleine IT-Abtl. ist gibt es nicht allzu viele Möglichkeiten. Privat lernen und ausprobieren mache ich natürlich - habe z.B. meinen Rechner komplett selbst zusammen,-gestellt und gebaut... Habe zu Hause auch ein kleines Heimnetzwerk und virtuelle Server usw... nur für meine Berichte hilft mir das nicht weiter. Programmiert wird bei uns z.B. gar nicht außer die Techniker die Maschinen, das hat aber mit meiner Ausbildung als FiSI nichts zu tun. Citrix, Linux auch nicht vorhanden...Mal sehen, was ich da tun kann.

[SaJu]

Hast Du schon einmal vom Scripting gehört? Auch in kleinen IT-Abteilungen müssen Server gewartet und dafür Skripte erstellt werden.

Das ist ein wichtiger Ausbildungsteil.

[Wuwu]

@Wuwu: Ehrlich gesagt, verstehe ich deinen Beitrag nicht. Frickeln bis es funktioniert hat mit meinem Beitrag exakt gar nichts zu tun. Vielleicht hast du auch eine andere Definition von "experimentieren".

Der einfach draug los ansatz bis etwas funktioniert, kann klappen, bei leuten die talent haben und technische zusammenhaenge direkt beim ersten mal begreifen, kann aber auch fuerchterlich in die hose gehen... Getreu dem motto "just because you could does not mean you should".

Selber aufbauen und installieren, ja, experementieren und googlen bis es kappt, eher nein. Gerade fuer die grundlage gibt es extrem gute fachliteratur anhand derer man strukturierte vorgehensweise fuer aufbau und konfiguration nachvollziehen kann. Wenn diese basics sitzen kann auch gerne der spieltrieb und die neugier einsetzen.

[127.0.0.1]

also wuwu, ich bin ja in 90% der fälle deiner meinung, nur hier nicht.

wer genug motivation hat und sich ein altes blech schnappt, dort xyz installiert und sich dann mit google, youtube usw. selbst etwas beibring macht mit sicherheit weniger falsch, als derjenige, der dienstags einen drucker anschließt und donnerstags die c't liest. nur was man selbst (falsch) gemacht hat hat man auch verstanden. da hilft alle literatur nicht. wir haben im betrieb zig scripting-bücher: in keinem einzigen stand drin, dass man sich mit einem BOM das komplette script zerschießen kann... diese fehler bzw "effekte" kommen nur in freier wildbahn vor und nicht in büchern.

genau so kann man auch wunderbar mit nem alten switch spielen und die auswirkungen von verschiedenen konfigurationen testen. da lernt man 1000 mal mehr als aus der technischen referenz.

[Wuwu]

genau so kann man auch wunderbar mit nem alten switch spielen und die auswirkungen von verschiedenen konfigurationen testen. da lernt man 1000 mal mehr als aus der technischen referenz.

Aber bitte nachdem man ihn einmal mit Referenz aufgesetzt hat, damit man weiss, wie eine korrekte Installation ausschaut und sich verhält

Was mir grad bei KMUs auffällt ist, dass Handbücher als nettes Extra gesehn werden statt als Pflichtlektüre vor einer Installation und hinterher jedes mal aufs neue das Gejammer losgeht, weil etwas nicht funktioniert wie vorgestellt.

[flashpixx]

@Wuwu & localhost: Ich denke, dass es wichtig ist beides zu können Theorie & Praxis. Ich sehe aber auch, dass heute in vielen Bereich lieber schnell durch Trial & Error gefrickelt wird, bis es funktioniert und 2 Wochen später niemand weiß, warum es funktioniert. Natürlich braucht man Basiswissen und das kann man definitiv in der Literatur finden, praktische Kenntnis bekommt man durch Übung. Der eine lernt etwas, in dem er zuerst die Literatur / Manual durcharbeitet und sich dann hinsetzt und es praktisch ausprobiert, der andere lernt es eben dadurch, dass er ausprobiert und währenddessen das Manual liest.

Ich finde dieses Verhalten sieht man sehr schön bei Programmieranfängern, denn zu Beginn müssen die meisten fast jeden Befehl / Datentyp nachschlagen und haben immer das Buch neben der Tastatur liegen, wenn dann die Kenntnis kommt, dass die Sprache ein System hat, dann wird das Buch nur noch verwendet, wenn man eben komplexere Sachzusammenhänge nachschlagen muss.

Für den OP ist es wichtig, dass er raus bekommt, was für ein "Lerntyp" er ist, d.h. kann er z.B. aus der Literatur alles nachvollziehen und dann praktisch umsetzen oder lernt er eher durch praktische Arbeit. Wichtig ist aber, dass man ggf die Schritte, die zu Lösung eines Problems führen, notiert werden z.B. mittels Wiki oder eben analog mit Stift & Papier, wichtig ist aber auch, dass man Fehlschläge notiert und wenn man diese dann Lösung auch vermerkt, warum sie aufgetreten sind bzw. wie man sie gelöst hat.

Ich denke, dass einseitige Herangehensweise nicht sinnvoll ist, wenn ich theoretisch einen Algorithmus entwerfen kann, aber ich nicht verstehe, wie man ihn dann praktisch implementiert, dann entsteht Software die sehr ineffizient ist, denn Praxis vermittelt mir einen Eindruck über reale Laufzeiten & Speicherbedarf. Fummel ich mal schnell etwas Code für einen Algorithmus zusammen, dann mag dieser zwar laufen, aber meist ist er dann nicht abstrakt genug und lässt sich nur schwer pflegen. Zusätzlich werde ich kaum an Dead- / Whitelocks denken. Ohne Theorie wird die Praxis nicht funktionieren und die Theorie lässt sich nun mal ohne Praxis auch nicht verwenden.

Wichtig ist die Vernetzung von beiden Punkten, ich kann lediglich etwas den Schwerpunkt verschieben, so dass ich den für mich besten Ansatz verwenden kann. Im Sinne des Threads, muss der OP herausfinden, wie er am besten an Dinge herangeht.