Gefühlt nicht viel gelernt - was tun?

[Gurki]

Hallo,

ich bin nun seit einem halben Jahr in meiner Firma und lerne den Beruf des FIAE. Ich wollte den Beruf auch immer machen und mir macht er auch soweit Spaß (mitunter bisschen langweilig), aber mir kommt jetzt nach nem halben Jahr das ganze so vor, als ob ich noch nicht wirklich viel gelernt habe.

Ich habe seit beginn der Ausbildung ein kleines Projekt wo ich auch meistens dran arbeite, lese zwischendurch ein Buch und jetzt das Openbook C# - das umfassende Handbuch. (Demzufolge ist mein Projekt in C# geschrieben [vorher in VB.Net])

Nun fühle ich mich aber irgendwie so leer und so als ob ich bisweilen nichts wirkliches gelernt habe. Zwar verstehe ich meinen Code soweit es geht (manche passagen eher nicht so wirklich, diese sind dann aus dem Netz und einwenig angepasst worden von mir), ich kann auch meine Arbeitskollegen fragen wenn ich fragen habe, aber selbst wenn sie mir etwas erklären, fehlt mir irgendwie mit unter die Verständnis zu dem gerade besprochenem.

Ich weiß nicht ob das "normal" ist, dass man einwenig erschlagen wird von der komplexen IT und der extreme vielfältigen Abkürzungen und das das ganze Verständnis zum Programmieren noch kommt.

Vorallem habe ich etwas Angst, dass ich es nie lerne in den 2,5 Jahren ein guter Programmierer zu werden - der sein "Handwerk" gut beherrscht um im Berufsleben voll einsteigen zu können. Denn später kann ich ja schelcht meine Arbeitskollegen fragen was das und das im Code bedeutet...

Kurz es ist bzw. es kommt mir doch schwerer vor als gedacht und ich weiß nicht weiter, vielleicht bin ich auch einfach zu ungeduldig (das bin ich generell)?

Ich weiß nur - ich komme aus dem Handwerk und da wurde einem etwas vorgemacht und man hats nach gemacht, wenns nicht saß, wurde es mit der Zeit besser und perfektioniert. Hier in der IT ist das halt doch etwas anders....

Hat jemand Rat für mich? :old

Bearbeitet 9. August 2011 von Gurki

[Pixie]

.....

[lupo49]

Hallo,

Ich weiß nur - ich komme aus dem Handwerk und da wurde einem etwas vorgemacht und man hats nach gemacht, wenns nicht saß, wurde es mit der Zeit besser und perfektioniert. Hier in der IT ist das halt doch etwas anders....

So ist es in der Regel nicht im Gebiet der IT. Es wird viel Wert darauf gelegt, dass die Auszubildenden sich selber motivieren können. Gerade beim Programmieren ist schlichtweg nicht möglich, dass dir dein Ausbilder/Kollege immer wieder bestimmte Sachen vormachen. Die Denkweisen beim Programmieren wirst nur du dir beibringen können. Es ist klar, dass es nach einem halben Jahr noch recht holprig ist, wenn du bei Null angefangen hast. Das sollte dich zu diesem Zeitpunkt aber nicht entmutigen. Hast du die Situation auch mal mit deinen Kollegen besprochen und die um eine Einschätzung gefragt?

[Nikomania]

...ich kann auch meine Arbeitskollegen fragen wenn ich fragen habe, aber selbst wenn sie mir etwas erklären, fehlt mir irgendwie mit unter die Verständnis zu dem gerade besprochenem...

Und wissen deine Kollegen das?

Wenn ich Auszubildenden oder Praktikanten etwas beibringe und die nie nachfragen nervt mich das immer total, weil ich meist genau weiß, dass Sie nicht alles verstanden haben. Wie soll der "Lehrer" denn ohne Frage das Niveau rausfinden auf dem erklärt werden sollte? Manche Azubis/Praktikanten sind halt schneller als andere.

Und lupo hat natürlich auch damit recht, dass man in der IT in der Lage sein muss die Probleme selbst zu lösen und somit eine recht hohe Motivation braucht ABER du bist ein Azubi und wenn es um grundsätzliches geht solltest du keine Hemmungen haben Fragen zu stellen und auch nachzuhaken, wenn du es nicht verstanden hast. Zumindest ist das meine Meinung.

[Gurki]

.....

?? Wenn Du was zu sagen hast, spucks aus...

So ist es in der Regel nicht im Gebiet der IT. Es wird viel Wert darauf gelegt, dass die Auszubildenden sich selber motivieren können. Gerade beim Programmieren ist schlichtweg nicht möglich, dass dir dein Ausbilder/Kollege immer wieder bestimmte Sachen vormachen.

Natürlich nicht, das verlange ich ja auch nicht (ich bins nur halt "gewohnt"), aber vielleicht mal den Code mit anschauen und Tipps und Tricks verraten (was gestern mal geschah). Kommt halt zu wenig von.

Die Denkweisen beim Programmieren wirst nur du dir beibringen können.

Ja genau, deshalb lese ich ja auch in vielen Büchern, aber vieles davon sind halt doch noch Böhmische Dörfer. Gerade weil es so extrem komplex ist und es auch so viele Abkürzungen gibt.

Es ist klar, dass es nach einem halben Jahr noch recht holprig ist, wenn du bei Null angefangen hast. Das sollte dich zu diesem Zeitpunkt aber nicht entmutigen.

Das wollte ich ja auch wissen, ob es "normal" ist das es noch holperig ist bzw. ich mich noch etwas schwer mit dem ganzen tue.

Hast du die Situation auch mal mit deinen Kollegen besprochen und die um eine Einschätzung gefragt?

Habe ich gestern und es gibt demnächst ein Feedbackgespräch um deren Einschätzung über meinen Lernerfolg preis zu geben.

[lilith2k3]

Also. Es gibt solche und solche Betriebe.

Idealerweise sollten Jungprogrammierer eine Art Mentor haben, sprich jemanden festes an Hand, den Sie zu diesem und jenem löchern können. Der auch mal mit drüber guckt, Dir Anleitung gibt, wie man Bugs vermeidet, etc. pp.

Die Realität sieht erschreckend anders aus. Im Prinzip läuft das nach dem SB-Markt-Prinzip. Bedien Dich aller Ressourcen, derer Du habhaft werden kannst, aber verlang bitte keine Beratung.

Was mir geholfen hat, waren so Sachen wie:

Viddler.com - Øredev 2008 - Agile - Clean Code III: Functions - Uploaded by oredev

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

Mi

Fabulous Adventures In Coding - Site Home - MSDN Blogs

Jon Skeet: Coding Blog

.NET Design Patterns in C# and VB.NET - Gang of Four (GOF) - DoFactory

Inversion of Control Containers and the Dependency Injection pattern

Mocks Aren't Stubs

Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin: Amazon.de: Robert C. Martin: Englische Bücher

Test Driven Development. By Example Addison-Wesley Signature: Amazon.de: Kent Beck: Englische Bücher

Refactoring: Improving the Design of Existing Code Object Technology Series: Amazon.de: Martin Fowler, Kent Beck, John Brant, William Opdyke: Englische Bücher

Design Patterns. Elements of Reusable Object-Oriented Software.: Amazon.de: Erich Gamma, Richard Helm, Ralph E. Johnson: Englische Bücher

Head First Object-Oriented Analysis and Design: Amazon.de: Brett McLaughlin, Gary Pollice, David West: Englische Bücher

Head First Design Patterns: Amazon.de: Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra, Mike Loukides: Englische Bücher

http://www.amazon.de/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1313088700&sr=1-1

Professionell entwickeln mit Visual C# 2010: Das Praxisbuch Galileo Computing: Amazon.de: Matthias Geirhos: Bücher

Professional Enterprise .NET (Wrox Programmer to Programmer) eBook: Scott Millett, Jon Arking: Amazon.de: Kindle-Shop

C# in Depth: Amazon.de: Jon Skeet: Englische Bücher

Anfangen würde ich mit Robert C Martins Videos/Büchern zum Thema Clean Code. Da lernst Du was für's Programmierer (Über-)Leben :]

Es gibt jede Menge Sachen, mit denen Du Deine Freizeit verbringen kannst - und als angehender Programmierer auch solltest.

Das was Dir für den Alltag wirklich was bringt musst Du Dir (leider) selbst beibringen.

[lilith2k3]

Also. Es gibt solche und solche Betriebe.

Idealerweise sollten Jungprogrammierer eine Art Mentor haben, sprich jemanden festes an Hand, den Sie zu diesem und jenem löchern können. Der auch mal mit drüber guckt, Dir Anleitung gibt, wie man Bugs vermeidet, etc. pp.

Die Realität sieht erschreckend anders aus. Im Prinzip läuft das nach dem SB-Markt-Prinzip. Bedien Dich aller Ressourcen, derer Du habhaft werden kannst, aber verlang bitte keine Beratung.

Was mir geholfen hat, waren so Sachen wie:

Viddler.com - Øredev 2008 - Agile - Clean Code III: Functions - Uploaded by oredev

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

Mi

Fabulous Adventures In Coding - Site Home - MSDN Blogs

Jon Skeet: Coding Blog

.NET Design Patterns in C# and VB.NET - Gang of Four (GOF) - DoFactory

Inversion of Control Containers and the Dependency Injection pattern

Mocks Aren't Stubs

Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin: Amazon.de: Robert C. Martin: Englische Bücher

Test Driven Development. By Example Addison-Wesley Signature: Amazon.de: Kent Beck: Englische Bücher

Refactoring: Improving the Design of Existing Code Object Technology Series: Amazon.de: Martin Fowler, Kent Beck, John Brant, William Opdyke: Englische Bücher

Design Patterns. Elements of Reusable Object-Oriented Software.: Amazon.de: Erich Gamma, Richard Helm, Ralph E. Johnson: Englische Bücher

Head First Object-Oriented Analysis and Design: Amazon.de: Brett McLaughlin, Gary Pollice, David West: Englische Bücher

Head First Design Patterns: Amazon.de: Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra, Mike Loukides: Englische Bücher

http://www.amazon.de/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1313088700&sr=1-1

Professionell entwickeln mit Visual C# 2010: Das Praxisbuch Galileo Computing: Amazon.de: Matthias Geirhos: Bücher

Professional Enterprise .NET (Wrox Programmer to Programmer) eBook: Scott Millett, Jon Arking: Amazon.de: Kindle-Shop

C# in Depth: Amazon.de: Jon Skeet: Englische Bücher

Anfangen würde ich mit Robert C Martins Videos/Büchern zum Thema Clean Code. Da lernst Du was für's Programmierer (Über-)Leben :]

Es gibt jede Menge Sachen, mit denen Du Deine Freizeit verbringen kannst - und als angehender Programmierer auch solltest.

Das was Dir für den Alltag wirklich was bringt musst Du Dir (leider) selbst beibringen.

[Gurki]

Vielen Dank für die vielen vielen Links!!! Ich werde mir das mal in Ruhe anschauen und durchlesen / durch hören. Ja so wirklich jemanden festes als Anprechpartner habe ich nicht so wirklich, man ist eher auf sich selsbt gestellt. Sicher kann man wie schon im ersten Beitrag erwähnt, jemanden Fragen und man bekommt dann auch eine Antwort, die Frage ist aber ob man mit der Antwort was anfangen kann oder das nur so Schnippsel sind die einen auch nicht wirklich weiter bringen.

Aber ok, dann werde ich das mal durchackern.

[Anyanca]

Hast du dir schon mal Code von deinen Kollegen angeschaut? Ich fand das am Anfang hilfreich, die verschiedenen Stile meiner Kollegen zu vergleichen und habe versucht mir von jedem das "Beste" rauszupicken

Habt ihr Programmierrichtlinien im Betrieb? Sowas find ich auch ganz hilfreich, bei mir war da nur das Problem, dass es die nirgends schriftlich gab, sondern die hat man mir nur auf nachfragen gesagt (wobei die auch jeder so ein bisschen nach seinem Geschmack abwandelt^^).

Ansonsten kann ich dir nur raten, dich nicht so schnell demotivieren zu lassen. Du kannst ja auch mal mit deinen Klassenkameraden reden, wies bei denen so läuft.

[IT-Fraggle]

Vorallem habe ich etwas Angst, dass ich es nie lerne in den 2,5 Jahren ein guter Programmierer zu werden - der sein "Handwerk" gut beherrscht um im Berufsleben voll einsteigen zu können.

Moin Gurki,

habe keine Angst, noch kein Meister is vom Himmel gefallen.Entscheidend ist, dass du rechtzeitig vor deiner Prüfung etwas veränderst, und nicht erst 1 Woche vor der Prüfung anfängst zu jammern wie manch einer hier.

Du wirst deinen Weg schon gehen, bleib am Ball, beherzige die Ratschläge der "Kollegen" hier, dann wirst du das Schiff schon schaukeln.

In diesem Sinne ein schönes Wochenende :-)

[IT-Fraggle]

Also. Es gibt solche und solche Betriebe.

Idealerweise sollten Jungprogrammierer eine Art Mentor haben, sprich jemanden festes an Hand, den Sie zu diesem und jenem löchern können. Der auch mal mit drüber guckt, Dir Anleitung gibt, wie man Bugs vermeidet, etc. pp.

Die Realität sieht erschreckend anders aus. Im Prinzip läuft das nach dem SB-Markt-Prinzip. Bedien Dich aller Ressourcen, derer Du habhaft werden kannst, aber verlang bitte keine Beratung.

Was mir geholfen hat, waren so Sachen wie:

Viddler.com - Øredev 2008 - Agile - Clean Code III: Functions - Uploaded by oredev

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

dnrTV

Mi

Fabulous Adventures In Coding - Site Home - MSDN Blogs

Jon Skeet: Coding Blog

.NET Design Patterns in C# and VB.NET - Gang of Four (GOF) - DoFactory

Inversion of Control Containers and the Dependency Injection pattern

Mocks Aren't Stubs

Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin: Amazon.de: Robert C. Martin: Englische Bücher

Test Driven Development. By Example Addison-Wesley Signature: Amazon.de: Kent Beck: Englische Bücher

Refactoring: Improving the Design of Existing Code Object Technology Series: Amazon.de: Martin Fowler, Kent Beck, John Brant, William Opdyke: Englische Bücher

Design Patterns. Elements of Reusable Object-Oriented Software.: Amazon.de: Erich Gamma, Richard Helm, Ralph E. Johnson: Englische Bücher

Head First Object-Oriented Analysis and Design: Amazon.de: Brett McLaughlin, Gary Pollice, David West: Englische Bücher

Head First Design Patterns: Amazon.de: Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra, Mike Loukides: Englische Bücher

Patterns of Enterprise Application Architecture: Amazon.de: Martin Fowler: Englische Bücher

Professionell entwickeln mit Visual C# 2010: Das Praxisbuch Galileo Computing: Amazon.de: Matthias Geirhos: Bücher

Professional Enterprise .NET (Wrox Programmer to Programmer) eBook: Scott Millett, Jon Arking: Amazon.de: Kindle-Shop

C# in Depth: Amazon.de: Jon Skeet: Englische Bücher

Anfangen würde ich mit Robert C Martins Videos/Büchern zum Thema Clean Code. Da lernst Du was für's Programmierer (Über-)Leben :]

Es gibt jede Menge Sachen, mit denen Du Deine Freizeit verbringen kannst - und als angehender Programmierer auch solltest.

Das was Dir für den Alltag wirklich was bringt musst Du Dir (leider) selbst beibringen.

Finde ich klasse, dass du dir die Arbeit machst und soviel "Wissen" zur Verfügung stellst.:-)

[lilith2k3]

*LOL*

Naja, ich habe es ja nur aggregiert, nicht die Vorträge selbst gehalten

Und das ist nur das, was mir auf die Schnelle eingefallen ist.

Ich habe vor einem ähnlichen Problem wie der TO gestanden, mit dem zusätzlichen Hindernis, dass bei unserer Firma (mit meinem jetzigen Wissen), die Codequalität eher unterdurchschnittlich ist - mir also der Code von Kollegen so gut wie nichts gebracht hat.

Ich hatte/habe zwar einen (festen) Ansprechpartner, der ein gutes Überblickswissen besitzt, mehr aber auch leider nicht.

Weil ich nicht versauern wollte, habe ich mich im Netz umgesehen, und mir die Rosinen, soweit möglich, herausgepickt.

Und die Videos haben mir eine erste gute Hilfestellung gegeben. Dann bin ich auf die Suche nach guten Büchern gegangen.

Das für mich wichtigste Buch ist "Clean Code". Deshalb empfehle ich das auch gleich zu Beginn zu lesen (ich habe es leider selbst erst vor "Kurzem" gelesen).

Jetzt habe ich das Problem, dass unser Berufsschullehrer meinen Code nicht mehr "begreift", weil er moderne Codetechniken wie "favour composition over inheritance" nicht versteht

Bearbeitet 12. August 2011 von lilith2k3