Ulfmann

Ernsthaft? You have it away?

Moin.
Ich finde ja, selbst die Orakel-Krake Paul hätte bessere Entscheidungen treffen können als Trump. Oder eine Katze. Eine Katze wäre super. "Mr. President, was sollen wir gegen die terroristische Bedrohung des IS tun?"
*Starrt einfach lange stumm zurück*
Was Katzen machen, kann nicht falsch sein.

Mir fallen auf Anhieb hunderte Dinge ein, die das auch sind  Aber zu Kokosnuss am Strand essen könnte man mich jetzt auch überreden.

Ihr müsst bei der Arbeit mal die Schlag-den-Raab-Musik von den Konzentrationsspielen hören. Effekte, die ich bei mir feststelle:
- Ich arbeite behutsamer
- Ich fluche mehr, wenn etwas nicht gleich klappt
- Ich überlege viel länger
- Ich sage einfach nichts, wenn ich etwas nicht weiß
Das gibt der kleinsten Aufgabe gleich mehr Dramatik!  

Sehr schöner Beitrag, @pr0gg3r! Der sollte vielleicht irgendwo verlinkt / angepinnt werden, da sich ja so ziemlich jeder, der neu in der Anwendungsentwicklung ist, mit dieser Situation rumschlägt.

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

WODKA-MELO... oh. 

Ich finde, du gehst das zu speziell an. Ich würde das eher so sehen, dass du wissen solltest, wie Daten aus der Datenbank in eine GUI kommen. Wie man Oberflächen baut, ist ein anderes Thema. Wenn mir jemand sagt "Hey, ich hab zwar keine Ahnung, welche Datenstruktur diese Anwendung hat, aber ich kann prima GUIs bauen" ist das für mich kein Pluspunkt.
Ja wäre übertrieben und nein wäre gelogen. Man beginnt in der BS im Urschleim und man bekommt von allem was mit. Man lernt Datentypen kennen, Kontrollstrukturen, hier bisschen SQL, da bisschen HTML und oben drauf auch gern OOP. Aber das reicht nie im Leben aus, den wesentlichen Teil lernst du in der Firma.  
Naja ganz so einfach ist das natürlich auch nicht. Manchmal tritt das gleiche Problem an einem ganz anderen Anwendungsfall auf, da muss man Lösungen und Vorschläge durchaus verstehen und auf den eigenen Kontext anwenden.

Wir hatten jemanden in der BS Klasse, der war im Prinzip schon ein top Programmierer. Bei jeder Aufgabe, die wir umsetzen mussten, war der Typ als Erstes fertig und hatte oft die cleversten und elegantesten Lösungen. Manche aus der Klasse haben nichtmal seinen Code kapiert so unterschiedlich war der Kenntnisstand. Der Junge hat im Programmierunterricht eigentlich nichts mehr wirklich gelernt (bestenfalls einige Rand-Themen mitgenommen).
Das andere Extrem gab es natürlich auch. Leute haben sich im 2. Lehrjahr verabschiedet - aufgrund mangelnden Interesses oder zu schlechten Ergebnissen. Da hätte man das Lerntempo auch nochmal runterfahren können, es hätte nichts geändert. Also ich behaupte mal, solange du ausreichend fleißig bist und dein Ausbilder im Blick hat und einschätzen kann, dass du auf Kurs bist, brauchst du dir da keine Sorgen machen.

Ja auch ich kann da nur lauter Fragezeichen dran schreiben. Wie schnell wofür? Was für ein Anwendungsniveau? Warum eine Sprache? Usw.
Mein damaliger Mentor (als ich noch Trainee war) hat mal gesagt, für ihn sind bei einem guten Programmierer 2 Dinge wichtig: 1. Wieviel muss er googlen und 2. Wie lange braucht er, bis er die Lösung hat.
Soll heißen: Irgendwann arbeitest du mit den Elementen einer Programmiersprache routiniert, man kennt Dinge auswendig, weil man alles schon 100x gemacht hat, man weiß (zumindest in etwa) wie man bestimmte Probleme löst und dieser Erfahrungsschatz wird mit der Zeit immer größer. So wie bei einer richtigen Sprache. Wenn man etwas nicht (oder noch nicht) weiß, muss man eben nachschauen. Und das Nachschauen bzw. wissen wo man nachschaut ist ein ganz wesentlicher Skill, weil man auch da Routinen entwickeln muss, um schnell das zu finden, was man wissen will. Und das ist auch völlig okay, solange man eben nicht 1 Stunde braucht weil man nach den falschen Dingen sucht oder so.
Wie auch immer, ich hoffe, meine Antwort ging zumindest in die Richtung von dem, wonach du gesucht hast.  

Ich versteh die Frage überhaupt nicht. Du hast eine neue Kollegin, die (noch) nicht so ganz fit in der Materie ist und weil du jetzt mit ihr zusammen arbeiten sollst, hast du Angst, dass du einen schlechten Ruf bekommst? Entschuldige mal, aber was ist das denn für ein Kindergarten?
Wenn ich mit jemandem zusammen arbeite, der offensichtlich weniger routiniert und sachkundig ist, dann helfe ich dem so viel wie ich kann. Und wenn dann Kollegen allen Ernstes anfangen zu lästern oder schlimmeres, würde ich sie fragen ob sie keine anderen Sorgen haben. Ggf. erfährt das dann auch gleich der Teamleiter.
Mit anderen Worten: Mach deine Sache mal gut, sei ein cooler Kollege und k*** dir nicht ein, dass das deinem Ruf schadet. Da schimmert nämlich leicht Arroganz durch.

Sowohl als auch. Das Buch umfasst so ziemlich alle Ausbildungsinhalte und geht auch darüber hinaus, wenn ich mich richtig erinnere. Da kannst du entweder durch die Themen blättern, die dich interessieren oder auch einfach alles durchrattern. Es kommt in der Berufsschule aber ggf. noch einmal dran.

Der Buchtipp, @KeeperOfCoffee, ist toll, aber hier glaube ich etwas too much. Es geht hier erstmal um die ersten Schritte. Clean Code ist an sich ein Thema für Level 2, in meinen Augen verkompliziert das den Einstieg und das Verständnis für Abläufe enorm.
@ganjabenni Welcome. Um deine Frage vernünftig zu beantworten, musst du mehr Infos rausrücken. Vorbildung? Welche Technologien werden im Betrieb eingesetzt? Wenn du, wie du sagst, ein solides Grundverständnis für Informatik mitbringst, ist das schon mal viel wert. In der Berufsschule fängt man meistens im Urschleim an und arbeitet sich durch Logikschaltungen, Programmiergrundlagen und einfache IT-Systeme. Der "Rest" sollte alles schon mal in der Schullaufbahn aufgetaucht sein.

Ja. Dieses Handbuch ist eigentlich immer eine ganz gute Basis.

Mein Bruder hat grad für uns beide Karten für AC/DC in Leipzig gekauft. Oh. Mein. Gott. Bin ich grad hibbelig.

Mein Bruder hat grad für uns beide Karten für AC/DC in Leipzig gekauft. Oh. Mein. Gott. Bin ich grad hibbelig.

Gewöhn dich dran
 

Ich muss bei Polka immer an Steve Urkel denken.

Ich muss bei Polka immer an Steve Urkel denken.

Kenn ich auch. Und ich hab auch sofort den Geschmack auf den Lippen... Das erinnert mich an Kindergarten-/Schulkantine Mittagsessen. War da schon ein Klassiker.

Jägerschnitzel der alten Bundesländer: Normales paniertes Schweinefleischschnitzel mit Pilzrahmsoße (glaube ich)
Jägerschnitzel der "neuen" Bundesländer: Eine panierte dicke Scheibe Jagdwurst mit Tomaten oder Rahmsoße

Die führte wohl zu direkten "Nachwendezeiten" zu einigen Verwirrungen bei Kneipenbesuchen

Und selbst, wenn ich nichts davon habe, wenn ich 1000 Headhunter arglos und bequem "adde" und nie wieder was von ihnen höre oder ihr Angebot mich langweilt, kommt entweder irgendwann einer wieder mit genau dem was man sucht oder (wie Goulasz und Crash sagen) man stellt sein Profil irgendwann wieder auf "Auf der Suche" und bekommt gratis potentiell passende Angebote. Praktischer geht's doch gar nicht und ich sehe Xing jetzt auch nicht als ein Social Network an, das über die berufliche Ebene hinausgeht, insofern ist es für mich kein Problem, etliche "fremde" Headhunter als Kontakte zu haben.

Das liest sich ja spannend hier. Ich bin ja seit Jahren auf der Suche nach der optimalen Sport-Nahrungs-Ratio die dann auch einen sorglosen Bierkonsum erlaubt  

Ich glaub, das sind beides keine sehr häufig auftretenden Fälle. Durcheinander geratene Zitate können oder sollten dir auch beim nochmaligen Durchlesen auffallen, bestenfalls vor dem Abschicken. Der andere Fall, dass jemand Tage und Wochen später seinen Ausgangspost bearbeiten möchte, um vielleicht die treffende Antwort zu verlinken oder eine Auflistung zu ergänzen macht hingegen schon Sinn, ist aber auch wirklich die Ausnahme.
 Viel häufiger wird eine unbegrenzte Editierzeit dazu führen, dass die Leute ihren Startpost löschen oder durch ein 'Hat sich erledigt" ersetzen, im Nachhinein irgendwelche (dummen) Statements wieder entfernen und damit Diskussionen kaputt machen.
Edit: Ok, robotto war schneller  

Ich glaub, das sind beides keine sehr häufig auftretenden Fälle. Durcheinander geratene Zitate können oder sollten dir auch beim nochmaligen Durchlesen auffallen, bestenfalls vor dem Abschicken. Der andere Fall, dass jemand Tage und Wochen später seinen Ausgangspost bearbeiten möchte, um vielleicht die treffende Antwort zu verlinken oder eine Auflistung zu ergänzen macht hingegen schon Sinn, ist aber auch wirklich die Ausnahme.
 Viel häufiger wird eine unbegrenzte Editierzeit dazu führen, dass die Leute ihren Startpost löschen oder durch ein 'Hat sich erledigt" ersetzen, im Nachhinein irgendwelche (dummen) Statements wieder entfernen und damit Diskussionen kaputt machen.
Edit: Ok, robotto war schneller