Whiz-zarD

Eben. Ich sehe da auch keine Probleme. Schlechter Code kommt doch nur dadurch zustande, weil man es nicht besser weiß. Probleme bestehen doch nur, wenn der Azubi beratungsresistent ist. Ich kenne es selber. In der Firma, wo ich arbeite, schule ich inzwischen Senior Entwickler, obwohl ich erst vor knapp 5 Jahren dort als Junior Entwickler angefangen habe. Wir haben dort auch ein paar Spezies, die weiterhin Spaghetticode schreiben, weil sie der Meinung sind, sie seien die besten Entwickler der Welt und lassen sich eh nichts von einem etwas sagen, der ca. 20 Jahre jünger ist, als sie selbst. Die meisten Entwickler nehmen aber die Tipps, die ich denen gebe, zu Herzen. Sicherlich, viele von denen waren auch erst skeptisch, weil sie den Begriff "SOLID" zum ersten Mal gehört haben (obwohl sie schon seit über 20 Jahren als Entwickler tätig sind) und fassten es als neumodischen Schnick-Schnack auf und waren der Meinung, dass unsere Anwendung eh viel zu kompliziert sei und die Prinzipien hier nicht greifen können aber als ich denen ein paar Beispiele gezeigt hatte, wie man unsere Anwendung hätte besser strukturieren können, war denen auch klar, dass sie ihren Programmierstil radikal ändern müssen und da klappt es auch. Sicherlich, sie fallen manchmal in alte Muster zurück aber das liegt auch daran, dass sie mit den Prinzipien noch nicht so ganz vertraut sind aber das wird einem blutigen Anfänger auch so ergehen.

Für dich gibt es also nur zwei Arten von Azubis: Jemand, der keine Ahnung hat, aber lernwillig ist Jemand, der Vorkenntnisse hat aber beratungsresistent ist Gutes Schubladendenken...  Ich sehe das also anders. Als Azubi muss man nicht alles kennen oder können, aber er sollte schon vor der Ausbildung wissen, auf was er sich dort einlässt. Ich habe es selbst bei meiner Assistentenausbildung gemerkt, dass viele mit falschen Vorstellungen die Ausbildung anfangen. Da sitzen echt ein Haufen Leute, die meinen, dass sie nach der Ausbildung Facebook, Apple oder Microsoft hacken können. Ein Kommilitone dachte, Objektorientierung sei sowas, was man sonst in Hollywood-Filmen sieht: Programmierung mit grafischen "Objekten", die man per Drag'n'Drop durch die Gegend schiebt. Ja, er dachte, sowas wie die Programmiersprache Scratch sei professionelle Softwareentwicklung. Er hatte bis Dato nicht mal eine Zeile Code geschrieben oder gesehen. Die meisten meiner damaligen Kommilitonen haben schon nach dem zweiten Semester das Handtuch geworfen. Wir waren ca. 80 Schüler und ganze 6 (ich war einer davon) haben später auch den Abschluss gemacht. Diejenigen, die den Abschluss gemacht hatten, hatten auch schon Vorkenntnisse. Der Rest hatte sich im Vorwege keine Gedanken drum gemacht, was es heißt, Software zu entwickeln. Sie wollten halt "irgendwas mit Computern" machen. Ich finde es schon wichtig, dass der Azubi weiß, was er will und dass Softwareentwicklung nicht heißt, dass man nur ein paar Klicks macht und schon wäre man der nächste Steve Jobs oder Bill Gates oder hätte das nächste Call of Duty entwickelt. Ich programmiere schon, seit ich 7 oder 8 Jahre alt war. Damals angefangen auf einem C64 und mir hat es auch nicht geschadet. Im Gegenteil. Vorkenntnisse können helfen, die Dinge besser zu verstehen. Mein Code sah vor der Ausbildung auch nicht besonders toll aus. Ich habe aber jeden Tipp und Hinweis von den Dozenten dankend angenommen und auch versucht, ihn sofort umzusetzen, während die anderen Kommilitonen mit den Tipps nichts anfangen konnten, weil sie noch mit ihren "if-Schleifen" beschäftigt waren und nach dem zweiten Semester immer noch Spaghetticode schrieben. Denen hat man auch schon geraten, die Ausbildung abzubrechen, weil sie mit dem Stoff nicht hinterherkommen würden. Darum unterstütze ich auch solche Projekte, wie z.B. Jugend Hackt. Dort haben Jugendliche die Möglichkeit, Tipps, Anregungen und Erfahrungen von Softwareentwicklern, Dozenten und auch von anderen Jugendlichen zu erhalten und da kommen teilweise sehr witzige Projekte bei raus. Sicherlich, der produzierte Code ist nicht erste Sahne und die Projekte sind auch nicht bis ins letzte Detail durchdacht aber das erwarte ich eigentlich auch an einem Wochenende nicht. Vielmehr haben die Projekte den Charakter eines Prototypen aber who cares? Die Jugendlichen hatten Spaß und konnten dabei auch was lernen.

Viele Firmen unterziehen sich derzeit einen Wandel, da sie gemerkt haben, dass sie mit ihren alten Firmenkulturen nicht mehr weiterkommen. Gehe mal auf Konferenzen oder oder besuche mal User groups (z.B. auf meetup) und unterhalte dich mal dort mit den Entwicklern. Entweder hast du Entwickler, die auf ein ganzes Arsenal an Technologien setzen oder Entwickler, die noch einen Monolithen mit Legacy Code schreiben aber davon weg wollen. Die klassischen Desktop-Anwendungen geraten auch immer mehr in den Hintergrund. Selbst bei der klassischen Webentwicklung mit PHP bröckelt es gerade, da sog. Single-Page-Applikationen immer mehr in den Vordergrund rutschen. Darum wird verstärkt nach Entwicklern gesucht, die eben halt schon einen gewissen Wissensstand haben. Man darf auch nicht vergessen, dass frische Studiumabsolventen sich ebenfalls auf die Junior Entwickler-Stellen bewerben und darum halte ich die Chancen für nicht allzu hoch, dass ein FISI ein Job als Junior Entwickler findet. In den Stellenangeboten steht zwar häufig "Sie haben ein Studium der Informatik oder eines vergleichbaren Studiengangs bzw. eine IT-Ausbildung absolviert." aber ein Studiumabsolvent mit Kenntnissen in der Entwicklung wird wohl eher genommen, als jemand bei dem man quasi von Null anfangen müsste. Wie gesagt, ich habe schon einige Firmen gesehen, wo man beim Vorstellungsgespräch dem Chef der Entwicklungsabteilung gegenübersitzt und dann erst mal technische Fragen beantworten muss und ich hatte mich damals auch nur als Junior-Entwickler beworben. Er kann sich ja ruhig darauf bewerben und ich wünsche ihm auch viel Glück aber große Chancen sehe ich halt nicht. Es wird zwar immer gejammert, dass die Firmen keine Leute finden aber offenbar können die Firmen es sich leisten zu warten, bis sich mal der richtige bewirbt.

Ja, und daraus entsteht Legacy Code. Die Firmen sollten schon aus wirtschaftlichen Interesse daran interessiert sein, weitestgehend idealen Code zu schreiben. Zumindest so die Theorie... Es ist auch ein Irrglaube, wenn man denkt, dass schnellgeschriebener Code günstiger sei. Die Kosten kommen dann später im Test aber Tests werden vernachlässigt, weil sie zu teuer wären und der Kunde davon nichts hat ... Also liefert man lieber Bananen-Software aus. Ich arbeite selber in so einer Firma. Unsere Software ist auch so um die 15 Jahren am Markt und inzwischen hat sie den Status "unwartbar" erreicht, weil man eben nicht darauf geachtet hat, den Code sauber zu halten. Nächstes Jahr wird angefangen, sie komplett neuzuschreiben. Die Kunden meckern inzwischen auch schon über die schlechte Softwarequalität. Eigentlich kann die Firma sich nur glücklich schätzen, dass sie in einer Nische agiert, wo es keine Konkurrenz gibt. Für die Neuentwicklung wurden 4 Jahre eingeplant. Das sind Unsummen an Geld, die man hier verpulvert, nur weil man einfach nicht sauber arbeitet. Wir haben einen gigantischen Monolithen mit zig Millonen Lines of Code und Klassen im fünfstelligen Bereich, die teilweise sogar Lines of Code im fünfstelligen Bereich haben. Bei einer Klasse muss man sogar ReSharper (ist eine .Net-Anwendung) abschalten, wenn man die Klasse anschauen möchte, weil es sonst zu Abstürzen von Visual Studio kommen kann. Unittests gibt es auch keine. Es gibt nur ein paar Integrationstests, die zwar jede Nacht laufen aber, die schlagen zu 95% fehl, weil nur einer was einchecken muss und schon stimmen die Ergebnisse nicht mehr. Obwohl ich erst seit knapp 5 Jahren als Softwareentwickler arbeite, schule ich inzwischen im Unternehmen Entwickler, die schon seit über 20 Jahren tätig sind. Das ist doch einfach falsch. Davor habe ich in einigen anderen Unternehmen als Praktikant gearbeitet und dort sah es ähnlich aus, wie in der jetzigen Firma und da frage ich mich schon, was FIAEler eigentlich lernen? Ich habe auch das Gefühl, dass man in Berufsschulen falsche Prioritäten setzt. Es ist jetzt schon ein paar Jahre her, aber in einer Firma, wo ich als Praktikant gearbeitet habe, sagte ein FIAE-Azubi, dass in seiner Berufsschule die While-Schleife weggelassen wird, weil sie zu kompliziert sei. Was ist das denn für ein Unterricht? Da ist schon die Syntax einer Sprache für die Azubis zu kompliziert und dann lässt man es einfach weg? Wie kann man denn ein guter Entwickler werden, wenn man schon essentielle Probleme mit der Syntax hat? Als Junior Entwickler hat man zwar noch nicht so viel Erfahrung aber ein gewisses Grundwissen sollte schon vorhanden sein, denn ansonsten wäre eine Ausbildung witzlos, wenn man bei einem Junior Entwickler eh von Null anfangen müsste und ihm erklären muss, was eine While-Schleife ist. Nach einer dreijährigen Ausbildung sollte man schon sein Handwerk verstehen. Zwar nicht perfekt (das erreicht man sowieso nicht) aber wenigstens in einem ausbaufähigen Stadium.

Dann läuft doch irgendwas nicht richtig. Die Fragen, die ich stellte, sind Dinge, die ich in den ersten 3 Semestern in meiner Assistentenausbildung gelernt habe. Gut, SOLID wurde explizit so nicht genannt, aber die Dozenten haben uns es so beigebracht, quasi nach SOLID zu arbeiten. Zumindest erwarte ich von einem Junior Entwickler, dass er den Unterschied zwischen Array, ArrayList und einer LinkedList kennt. Das zeigt, dass er gewisse Kenntnisse über Zeiger hat. Auch ein Junior Entwickler sollte sein Handwerk verstehen und die Interna einer Programmiersprache in Grundzügen kennen. Ich erwarte ja nicht, dass er weiß, wie ein Garbage Collector arbeitet oder wie man einen Rot-Schwarz-Baum implementiert. Zumindest vom Garbage Collector sollte er mal was gehört haben. Er sollte aber einige Design Patterns, wie z.B. Factory Methods oder Singletons kennen und nein, das sind keine hohen Anforderungen. Das sind auch Anforderungen, die viele Firmen an einen Junior Entwickler stellen. Als ich mit meiner Assistentenausbildung fertig war und Berwerbungen schrieb, wurde ich von einigen Firmen getestet, wie mein Kenntnissstand ist. Da kamen diese Fragen auf, die ich stellte. Weitere Fragen waren z.B. wieso die Klasse String in Java und C# vor Vererbung schützt sei und warum man Strings nicht konkatenieren sollte. Auch wurden einige Fragen zu Datenbanken gestellt. Wie z.B. was eine Transaktion sei oder was Indizes seien.

Naja, wenn ich ein Arbeitgeber wäre und einen Anwendungsentwickler suche, würde ich doch schon stutzig werden, wenn ein FISI sich auf die Stelle bewirbt. NIchts für ungut aber ein FISI ist doch was anderes als ein FIAE. Mag sein, dass einige es so geschafft haben aber es macht ein Unterschied, ob man nur die Syntax einer Sprache kennt und irgendwas zusammenhacken kann oder wirklich was von Softwareentwicklung versteht. Wie sieht es denn mit deinen Kenntnissen aus? Wo liegt Unterschied zwischen einem Array, ArrayList und einer LinkedList? Welche Vor- und Nachteile haben diese Datenstrukturen? Kennst du gängige Design Patterns? Was ist SOLID? Mit Welcher Sprache würdest du denn entwickeln wollen?

gelöscht

Es kommt drauf an, in welche Entgeldgruppe du eingestuft wirst. Frisch ausgelernte fangen oft in Gruppe 5 an. Das wären laut derzeitigen Stand ohne Zulage 13,41 € pro Stunde. Bei 151,67 Stunden pro Monat (35 Stunden/Woche) sind das 2.033, 89 € Brutto pro Monat und 24.406,76 € Brutto pro Jahr. Wenn jetzt eine Zeitarbeitsfirma meint, dass man in Gruppe 4 anfängt, was derzeit 11,88 € pro Stunde (ohne Zulage) wären es 21.622,07 € Brutto pro Jahr. Laut Tarifvertrag wäre es sogar denkbar, dass ein frisch ausgebildeter mit Gruppe 3 anfängt, dann wären wir bei 20.439,04 € Brutto pro Jahr aber das macht eigentlich keine Zeitarbeitsfirma, da sie genau wissen, dass andere Zeitarbeitsfirmen eine höhere Gruppe anbieten.

Wenn du aber in den Code verstehen möchtest, dann bleibt dir nichts übrig. Trau dich ruhig. Du bist ein Azubi und das wissen deine Kollegen auch. Daher werden sie dir wohl nicht den Hals umdrehen, wenn du Fragen stellst. Aller Anfang ist nun mal schwer. Auch für jemanden, der schon seit Jahren in diesem Beruf arbeitet und dann in einer neuen Firma anfängt. In der Firma, wo ich arbeite, bekommen neue Entwickler auch erstmal mehrere interne Schulungen, um die Software zu verstehen. Da geht es auch um technische Dinge, wie z.B. wie das intern entwickelte Framework funktioniert. Bei mir hat das auch ca. ein halbes Jahr gedauert, bis ich die Software weitestgehend durchdrungen habe. Außerdem hat dein Chef ja auch schon erkannt, dass du Defizite hast. Also weiß er auch, worauf er sich da einlässt. Wie gesagt, trau dich einfach, nachzufragen, wenn du nicht weiterkommst.

Es wird doch hier immer argumentiert, dass der Fachinformatiker ein halber Kaufmann wäre, weil er Kosten, Risiken, etc. abschätzen können muss aber genau das musst du in allen anderen Berufen auch und das würde ja bedeuten, dass jeder Beruf ein halber Kaufmann wäre und deshalb sage ich, dass der Fachinformatiker kein Kaufmann ist, da er auch nur über das selbe Grundwissen wie jeder andere verfügt. Ich denke, dass einigen hier die Weitsicht fehlt und nicht über ihren eigenen Tellerrand hinausschauen. Dann würden sie auch merken, dass ihr Wissen über BWL gar nicht so groß ist, wie sie wohl vermuten. Mag sein, dass im Ausbildungsrahmenplan drinnen steht, dass der Fachinformatiker über gewisse Kaufmännische Erfahrung besitzen muss aber ich kenne keine duale Ausbildung, wo in der Berufsschule nicht das BWL-Grundwissen beigebracht wird, denn wie gesagt, das benötigt jeder Beruf, denn überall geht es um die Wirtschaftlichkeit.

Das lernst du in jedem x-beliebigen Beruf auch... Das würde ja dann bedeuten, dass der Mechatroniker auch ein kaufmännischer Beruf wäre, denn er muss ja Ahnung von Lieferzeiten, Marktpreisen, Kostenschätzung und Risiken haben ... Das kannst du jetzt mit jedem Beruf fortfahren.

Ich habe Links rausgesucht. Selbst die offizielle Beschreibung zu diesem Beruf verrät nichts über kaufmännische Fähigkeiten ... Komischerweise ist das Forum die einzige Quelle, die ich finde, wo dies wie ein Berseker behauptet wird, ohne offiziellen Quellen zu nennen. Wenn das nur darauf hinausläuft, dass man irgendwelche Kosten zusammenrechnen muss, dann ist jeder Beruf ein kaufmännischer Beruf ... Ja und? Ich habe damals als Mechatroniker als Zeitarbeiter gearbeitet und musste auch Angebote einholen, Preise vergleichen und musste Aufwände einschätzen. Ist der Mechatroniker nun plötzlich auch ein kaufmännischer Beruf? Das gehört nun mal zu einem Job dazu.

Eine tolle Antwort. Im Klartext: Dir fehlen die Argumente ...

Dann zeige mir doch mal, wo es steht ... Nirgends steht das. Selbst nicht mal Fachinformatiker, die schon seit über 10 Jahren in diesem Beruf arbeiten, die ich kenne, sehen es so ...

Selbst die Arbeitsagentur erwähnt beim Fachinformatiker nicht, dass er kaufmännische Fähigkeiten benötigt. Wie gesagt, dafür gibt es den Informatikkaufmann: https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7795 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7856 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7847 Auch die Unicum-Unternehmensgruppe weist daraufhin, dass es nicht nur den technischen Fachinformatiker gibt, sondern auch den Informatikkaufman: http://karriere.unicum.de/berufsorientierung/berufsbilder/ausbildung-der-it-branche Ich habe damals die Zeit miterlebt, als diese Berufe entstanden, weil das damals die Zeit war, wo ich mich auf einen Ausbildungsplatz beworben habe und niemand hat damals den Fachinformatiker als einen teils kaufmännischen Beruf angesehen, sondern immer als einen technischen Beruf.

Er ist im dritten Lehrjahr. Also fast ausgebildet. Da sollte man schon die Basics kennen.

Das ist schlichtweg falsch. In jedem Beruf lernt man etwas über BWL. Das habe ich damals in meiner Mechatroniker-Ausbildung und in meiner Ausbildung als Informatik-Assistent auch getan. Also stell es bitte nicht so hin, als sei der Fachinformatiker ein halber Kaufmann, denn das stimmt einfach nicht! Der Fachinformatiker wurde als praktizierender Facharbeiter ins Leben gerufen und zwar zur Anfangszeit der damaligen Dotcom-Blase (1997), als solche Facharbeiter noch rar waren. Der Fachinformatiker sollte genau den Missstand, dass eben viele Entwickler eigentlich nur Informatikkaufmänner waren, beheben. 1997 hatte man mehrere IT-Berufsfelder gebildet, die da waren: Fachinformatiker, Informatikkaufmann, IT-Systemkaufmann und IT-Systemelektroniker. Also Techniker und Kaufmänner hatte man von Anfang an getrennt.

Du solltest erst mal ehrlich zu dir selbst sein und dich wirklich fragen, ob der Beruf etwas für dich ist. Daheim hobbymäßig etwas vor sich hinwerkelt ist was anderes, als dies hauptberuflich zu tun. Ich spreche da aus Erfahrung, da ich schon eine Depression aus diesen Gründen hinter mir habe. Was hättest du denn erwartet? Ich habe bis jetzt noch keine Softwarefirma gesehen, die wie im Bilderbuch ihre Software pflegte. Ich habe bis jetzt noch keine Firma gesehen, die ihren Code kommentierte und dokumentierte. Überall hieß es: "Der Code sei historisch gewachsen." Also mit anderen Worten: Uns war es wichtiger, dass der Code schnell zurecht gefrickelt wird. Sowas wirst du immer wieder erleben aber warum ein großes Projekt mit vielen Klassen schlecht sein soll, ist mir irgendwie nicht so klar und wieso man nach technischen Problem nicht suchen kann, ist mir auch nicht klar. Sicherlich, Google wird dir kaum sagen, wie man z.B. einen Zins- und Tilgungsplan implementiert (wie in meinem Fall) aber vielleicht sind deine Arbeitspakete noch zu groß, um gezielt nach Antworten suchen zu können. Das ist vielleicht wie bei der Antwort der Frage "nach dem Leben, dem Universum und dem ganzen Rest". Das soll jetzt nicht heißen, dass es überhaupt keine Firmen gibt, die ihren Code sauber halten aber ich habe die Erfahrung gemacht, dass dies doch eher Ausnahmen sind und wie gesagt, bis jetzt habe ich noch keine Firma gesehen, die das gemacht hat und ich habe inzwischen einige Firmen sehen dürfen. Von Startup-Firmen bis hin zu Firmen, die schon seit 20 Jahren Software entwickeln. Mag ja alles sein, dass deine jetzige Firma nicht ganz so rosig ist aber wenn ich lese, dass du doch schnell das Handtuch wirfst, wenn es Probleme gibt, habe ich doch so meine Zweifel, dass der Beruf was für dich ist. Jeder hat mal Hochs- und Tiefs aber ich habe das Gefühl, dass du die Probleme eher in der Firma suchst, anstatt bei dir selbst. Vielleicht sehe ich es auch falsch aber so kommt es mir derzeit rüber.

Als Text soll ein &-Zeichen vorkommen? Dann muss der Text mit als CDATA-Abschnitt definiert werden. Beispiel: <Tag><![CDATA[Clever & Smart]]></Tag> Oder man nimmt gleich ein Framework, was eine XML-Datei generieren kann und spart sich die Mühe, dies selbst zu implementieren.

Was genau soll denn gespeichert werden? Was soll denn in HEX umgewandelt werden? Für mich ist nicht ganz klar, was du eigentlich erreichen möchtest. Darüber hinaus sieht die Zeile var cols = rows; nicht richtig aus. Das müsste wohl var cols = rows[i]; heißen. Ich bin zwar kein JavaScript-Experte aber in JavaScript gibt es doch mit Sicherheit eine Foreach-Schleife. Dann brauchst du auch nicht mit den ganzen indexierten Kram rumhantieren. Außerdem ist mir nicht klar, was die Variablen: var cardID = rows[0]["ID"]; var name = rows[1]["Name"]; var accountnumber = rows[2]["Accountnumber"]; var amount = rows[3]["Amount"]; var datum = rows[4]["CreateDate"]; var transaktionsID = rows[5]["TransactionID"]; var ort = rows[6]["Location"]; bringen sollen. Du gehst die Tabelle nun quasi Diagonal durch und wenn du weniger als sechs Zeilen hast, erhält du eine "Array Out of Bounds"-Exception.

Warum eine Codegenerierung? Verstoßen die generierten Klassen gegen das DRY (Don't Repeat yourself)-Prinzip? Wenn Ja, wieso nicht die Vermeidung von Code-Doubletten durch Vererbung und Generics?

Ich kann es mir nur so vorstellen, dass du die Bits nun zeichnerisch darstellen sollst. Die 25 Bits entsprechen ja die 25 dpi. dpi steht ja für "Dots per Inch" und wird häufig als Synonym für ppi "Pixel per Inch" genommen.

Wenn das für DICH wichtig ist, dann komme aber nicht mit solchen Sprüchen: Ob der Join sinnvoll ist, oder nicht lässt sich auch mit der Aufgabenstellung nicht eindeutig sagen. Es kommt dann auf die eigenen Präferenzen an. Entweder man macht hier ein Join und definiert eine Gruppierung, weil im Select Aggregatsfunktionen aufgerufen worden sind oder man erstellt im Select Subselects. Die Join-Variante hat nun das Problem, dass wenn weitere Spalten im Select ausgewiesen werden sollen, müssen diese Spalten auch noch zusätzlich in die Gruppierung eingepflegt werden. Man hat also einen doppelten Pflegeaufwand. Bei den Subselects kann man einfach weitere Spalten hinzufügen. Darüber kann man sich gerne unterhalten. Alles andere hat hier aber nichts zu suchen.

Die Anforderungen waren doch klar ... Er hat die offizielle Lösung gleich mitgeliefert. Es ging doch nur darum, um zu schauen, ob seine Lösung das gleiche macht, wie die offizielle Lösung. Wozu man dann noch tausend Mal nach der Aufgabe fragen muss und wieso man mit "Ein Where ist ein Join" kommt, ist mir ein Rätsel, denn das war gar nicht das Problem ... Die Offizielle Lösung war jetzt auch nicht so schwer zu verstehen, sodass man als Anhaltspunkt noch die Aufgabe hätte benötigen müssen. Also komm mal wieder auf den Teppich ...

Wenn man mal den ganzen Bullshit löschen wurde, der von den anderen geschrieben wurde, würde man erkennen, dass ich der einzige war, der ihm bei seinen Fragen tatsächlich geholfen hat ...