Ralf hat geschrieben:DeathAndPain hat geschrieben:Soweit die Theorie. Menschliche Psyche funktioniert aber anders.
Mit der Einstellung könntest du die gesamte Wissenschaft und Forschung auf der Welt zumachen.
Wieso das denn?!? Die Wissenschaftler der Welt arbeiten doch nicht alle in demselben Labor! Wenn Du allerdings als WM (wissenschaftlicher Mitarbeiter) die Arbeitsmethoden Deines Profs oder anderer WMs, die am Nebentisch arbeiten, offen kritisierst, dann kannst Du durchaus ähnliche Effekte erleben, ja.
Ralf hat geschrieben:DeathAndPain hat geschrieben:Das ist ein Lehrer, der hat eine pädagogische Ausbildun
Das macht jeder andere, der einen Vortrag hält, auch.
Eine pädagogische Ausbildung haben? Das halte ich für ein Gerücht.
Ralf hat geschrieben:DeathAndPain hat geschrieben:Etwas anderes ist es, wenn ein Schüler zum Lehrer geht und ihm im Auditor-Stil sagt, dass er seine Unterrichtsmethoden nicht in Ordnung findet und dass er der Meinung ist, der Lehrer solle seinen Unterrichtsstil in dieser und jener Richtung umstellen.
Hab ich gemacht, 9. Klasse. Und mir damit nicht den Lehrer zum Feind gemacht, sondern die anderen Schüler.
Das sind zwei verschiedene Paar Schuhe, die sich freilich nicht ausschließen. Du wirst wohl irgendwas gefordert haben, was für die Schüler Mehrarbeit bedeutet hat, was diese Dir übel genommen haben.
Wie der Lehrer darüber gedacht hat, wissen wir nicht. Das muss er Dir ja nicht erzählt haben (bzw. er hat Dir nur den politisch korrekten, also den nicht mimosenhaften Teil davon erzählt). Selbst wenn Du Deine Kritik nur in Form von Empfehlungen vorgebracht haben solltest (das, worüber wir in dem Thread hier diskutieren, ist sogar noch einen Zacken schärfer), gilt doch die Regel, dass Ratschläge auch Schläge sind, bzw. das Sprichwort:
"Gib nie einen Rat. Der Weise braucht ihn nicht, und der Narr verwirft ihn. Aber beide nehmen ihn übel."
Ralf hat geschrieben:Abgesehen davon, dass einem Schüler der Auditor-Stil nicht zusteht, weil er kein Auditor ist. Bei einem Auditor weiß ich: Was der sagt, ist erstmal Gesetz!
Bei einem formalen Audit schon. Aber so, wie ich diesen Thread bislang verstanden habe, reden wir nicht von einem formalen Audit (bei dem der Auditor in aller Regel ein Externer ist), sondern von einer Nutzung des ATC-Tools für ein Vier-Augen-Prinzip beim Programmieren: Mitarbeiter A kontrolliert den Code von Mitarbeiter B und umgekehrt (z.B. weil sie die beiden einzigen Entwickler im Hause sind). Mitarbeiter A hat bestimmte Schwerpunkte, die er wichtig findet, Mitarbeiter B andere. Du kannst zwar versuchen, Regeln aufzustellen, was kritikwürdig ist und was nicht, aber wenn das so einfach wäre, dann bräuchte man das zweite Augenpaar nicht, sondern könnte den ATC vollautomatisch den Code kontrollieren lassen (Code Inspector-style).
Glaub mir: Auch wenn man sich bei Kritikpunkten zusammensetzt und sich im Gespräch auf Lösungen einigt (wozu man am Arbeitsplatz ja letztlich gezwungen ist), bleibt doch rein emotional beim Codeurheber in aller Regel das negative Gefühl des Kritisiertwordenseins zurück. Und an Emotionen erinnert man sich weit länger als an Sachfakten; das ist eine meines Wissens biologisch begründete Tatsache.
ich würde das gerne mal sehen, wie Du Daniels Code auditierst und umgekehrt, jeder dem anderen die Umsetzung seiner Kritikpunkte aufzwingt und ihr anschließend produktiv weiter zusammenarbeitet.
DeathAndPain hat geschrieben:Aber es entsteht keine Liebe zum UnterDRÜCKer.
Wenn ich von meiner Frau und meinen Kindern geliebt werde, reicht mir das. Kollegen und Kunden sollen mich respektieren, nicht lieben.
Die Möglichkeit zu dieser Einstellung ist ein Freelancern vorbehaltener Luxus.
Ralf hat geschrieben:DeathAndPain hat geschrieben:Das mache ich auch zuweilen. Ob es Zeit spart, bin ich mir aber nicht sicher, denn manchmal kommt die Lösung (so wie in Deinem Fall), in vielen Fällen guckt der aber auch nur drauf, lässt sich den Sachverhalt erklären, rätselt und kapituliert am Ende
Ah, weil die Wahrscheinlichkeit besteht, dass es schiefgeht, versuchst du es erst gar nicht?
Nein. Wie von mir beschrieben, versuche ich es durchaus gelegentlich. Ich habe nur dargelegt, dass ich mir nicht sicher bin, ob es sich in der Bilanz lohnt. In aller Regel findet man die Antwort ja auch alleine, wenn man genug Zeit und Energie reinsteckt. Wenn nun in 30% der Fällen der andere einem helfen kann und man diese Zeit einspart, in 70% der Fälle der andere es aber nicht schafft und man durch die initiale Erklärung, das folgende gemeinsame Grübeln und fruchtlose Diskussionen nochmal die gleiche Zeit oben drauflegt, dann lässt sich festhalten, dass sich das Fragen im statistischen Mittel nicht lohnt und daher im Einzelfall auch nicht anzuraten ist (negativer Erwartungswert im Glücksspiel). Ich bin nicht sicher, ob es tatsächlich so schlecht aussieht. Rein gefühlsmäßig will ich das aber nicht ausschließen.
Wir reden dabei von Problemen, die komplex genug sind, dass sie nicht mit einem raschen Zuruf über den Tisch beantwortet werden können. Und wenn man einen Kollegen fragt, dann will man auch nicht unhöflich sein. Ich habe das schon häufig erlebt, dass ich schon in der ersten Minute nach Fragestellung sagen konnte, der weiß es auch nicht, da habe ich ja noch mehr Durchblick, da kommt nix bei raus. Dann ist man aber schon im Gespräch gefangen und kann den anderen mit seinen Vorschlägen
(die man alle längst durchdacht hat oder die von mangelndem Verständnis des Sachverhalts zeugen) nicht rasch abwürgen, sondern muss zumindest so lange diskutieren, bis er selber merkt, dass er nicht wird helfen können. Erst dann hat man wieder einen sozial verträglichen Bailout Point. Damit kann man eine ganze Menge Zeit verbrennen!
Es ist also nicht so, dass man im Zweifel immer fragen sollte. Es lohnt durchaus, seine Chancen vorher ein bisschen abzuwägen.
Ralf hat geschrieben:DeathAndPain hat geschrieben:Du weißt aber nicht, was sie im stillen Kämmerlein über Dich gedacht oder in der Pause über Dich geredet haben. Und wie Dein Arbeitsklima sich entwickelt hätte, wenn Du als ihr Kollege in dem Laden Deinen Arbeitsalltag der nächsten Jahre hättest verbringen müssen.
Ach, weißt du.. Ich war Stotterer auf einer Ruhrgebietshauptschule, Hauptschüler in einer Familie von lauter hochbegabten Akademikern, die ganze Stadt wusste dass mein Stiefvater meine Mutter im Suff verprügelt hat. Und ich beschränke mich explizit auf den nicht so schlimmen Teil meiner Lebensgeschichte. Wenn du SO eine Lebensgeschichte hast, ist dir Getuschel egal.
Ich war als Schüler auch Außenseiter und habe gelernt damit umzugehen. Das heißt aber nicht, dass das erstrebenswert wäre oder dass ich nicht zu schätzen wüsste, dass es jetzt anders ist und ich mich einer positiven Teamathmosphäre erfreue.
Davon abgesehen haben Mitschüler kaum Einfluss auf Deine weitere Laufbahn. Versaust Du es Dir hingegen mit Kollegen, dann ist das Team belastet, und das kann früher oder später personelle Konsequenzen haben. Wirst Du als Brennpunkt der Teambelastung identifiziert, dann bist Du mit Deinem Arbeitsplatz auch naheliegender Ansatzpunkt zur Lösung des Problems für den Chef.
Ich habe mir mal eine Mir-doch-egal-Haltung erlaubt, als ich mich geweigert habe, in die Gewerkschaft einzutreten und jeden Monat 1% meines Gehalts zum Machterhalt des (typischerweise auch in der Gewerkschaft aktiven) Betriebsrats beizusteuern. Dabei habe ich eben jene Macht gewaltig unterschätzt. Trotz größter Anstrengungen meines Vorgesetzten, mich zu halten, hat mich das nach einigen Jahren den Job gekostet.
Ralf hat geschrieben:DeathAndPain hat geschrieben:So läuft das in der Realität.
Aber nur in der Software-Entwicklung. Kein Mensch würde die QM bei einer Schraube in Frage stellen, nur weil kein Geld dafür da ist.
Wenn Du wüsstest, was ich schon für Schrauben gesehen habe... mitnichten haben die alle eine hochwertige Qualitätssicherung.
Ralf hat geschrieben:Es liegt an uns, den Leuten klarzumachen, dass wir keine Script-Kiddies sind.
Die Haltung kannst Du gegenüber Endanwendern und deren wissensgleichen Vorgesetzten vertreten. Bei Deinesgleichen aber hast Du nicht von vornherein den Nimbus des fachlich Überlegenen.
Ralf hat geschrieben:Schon der Quatsch, dass Klassen mit CL und Interfaces mit IF anfangen, zeigt, dass die, die sich das ausgedacht haben, nicht viel von Softwareentwicklung verstehen. Das ist in anderen Sprachen (soweit ich das überblicken kann) "sehr unüblich", um das mal vorsichtig formulieren.
Interfaces sind so ziemlich das einzige OO-Element in ABAP, das ich nie so richtig begriffen habe. Von der Theorie her schon: Man definiert einen Parametersatz, auf den man sich dann in Klassen etc. beziehen kann. Aber oft genug sehe ich im Code, wie Interfaces gerufen werden und grübele, welche der vielen Implementierungen dann gezogen wird - und woher das System weiß, welche davon es ziehen soll. Trotz mehrerer Anläufe habe ich noch keine Erklärung von Interface-Nutzung in ABAP gesehen, die ich so weit verstanden hätte, dass es bis in die Praxis hineinreicht.
Ralf hat geschrieben:Sorry, aber solange ein Artikel im SPIEGEL oder in einem Buch vom Layout her anders aussieht als dein Quelltext, kannst du hier nicht mit "menschlichem Lesefluss" argumentieren.
Beim SPIEGEL wäre die richtige Argumentation "für Propagandazwecke", aber das steht auf einem anderen Blatt.
Ralf hat geschrieben:Gerade bei technischen Texten liegt Lesbarkeit sehr wohl im Auge des Betrachters. Darum finde ich zum Beispiel Leerzeilen zwischen Anweisungen der Lesbarkeit förderlich (weil viele Anweisungen mehrzeilig sind und ich so sofort sehe, wo die Anweisung anfängt und endet), bei einem Kunden wurde ich aufgefordert, alle unnötigen Leerzeilen zu vermeiden, weil das den Quelltext verlängert - was er unübersichtlich findet. Er will soviel Quelltext auf einen Blick sehen wie möglich.
In diese Richtung tendiere ich auch, allerdings nur, solange es nicht zu Lasten der Lesbarkeit geht. Leerzeilen können Codeblöcke gut strukturieren und sind von daher hilfreich. Was mich am PP nervt, sind verschenkte Zeilen, die nicht der Lesbarkeit dienen. Ein typisches Beispiel sind CALL FUNCTION-Aufrufe. Da finde ich es optisch optimal, wenn der erste EXPORTING-Parameter rechts neben dem Schlüsselwort EXPORTING steht und die übrigen dann bündig darunter. Die übrigen Blöcke (IMPORTING, TABLES, EXCEPTIONS) ebenso. Das Schlüsselwort in eine eigene Zeile zu stellen, wie der PP es macht, dient Null der Lesbarkeit, ganz im Gegenteil. Der Code wird länger
UND schlechter lesbar.
Zum Glück ist der PP konfigurierbar. Ich nutze ihn viel - aber nur, um meinen Gesamtcode in Großschreibung zu setzen 3.1i-style.
Ein Graus für Kollegen, aber jedem das Seine.
ewx hat geschrieben:Der prettyprinter ist ein fester Bestandteil der ABAP-Programmierung.
"Fest" stimmt nur bedingt. Wie schon erwähnt ist der PP konfigurierbar. Man kann in gewissem Umfang einstellen, was er tun soll und was nicht. Wenn Daniel mit Großschreibung klarkommt (
), dann würde ihn mein PP nicht stören.
ewx hat geschrieben:Ein quelltext, bei dem durch Anwenden des PP die Verständlichkeit „zerstört“ wird, ist definitiv nicht gut.
Wie sieht so ein Quelltext denn aus?
ewx hat geschrieben:Es ist also wichtig, zu erkennen, „wer in dem Kapitel ermordet wird“. Die Formatierung des quelltextes hilft dabei. Eine „extravagante“ Formatierung ist eher hinderlich.
Warum? "Extravagant" muss ja nicht "schlecht lesbar" bedeuten. Im Gegenteil kann es bedeuten, dass die Lesbarkeit trickreich heraufgesetzt worden ist.
Ralf hat geschrieben:Der Funktionsbaustein zerschneidet mir nicht das Coding, ich kann die Methode direkt an einer funktionalen Operandenposition einsetzen (quasi wie ein CONV). In meinen Augen ist das lesbarer, in seinen schon deshalb Quatsch, weil es in einer Methode steht.
Ja, das ist etwas, was ich auch bedaure, dass Funktionsbausteinaufrufe nicht funktional gestaltet werden können. Dafür braucht man für eine Methode halt jede Menge zeitraubenden Overhead, bevor man überhaupt damit anfangen kann, den eigentlichen Nutzcode zu schreiben. Das lohnt sich nur, wenn es genug Aufrufe gibt, die von der funktionalen Darstellung profitieren.