Sinnlose Meetings, unerklärliche Beförderungen, miserable Einarbeitung,
Feindseligkeiten gegenüber Leistungsträgern: Welcher Technologiefreund
kennt das nicht aus seinem Berufsalltag?
Bullshit-Jobs, deren Inhalt einzig und allein aus der Produktion von
mehr und mehr Papier besteht. Überbordender Verwaltungswahnsinn,
einfachste Entscheidungen, die stets von nicht weniger als fünf
Entscheidern abgenickt werden müssen. Und natürlich "Eskalationspfade",
bei denen bestimmt jede Meldung auf dem Weg durch die Hierachie verloren
geht.
Das OSS (Vorgängerorganisation der CIA) hat in den 40ern das "Simple
Sabotage Field Manual" herausgegeben, mit zahlreichen Ratschlägen zur
Sabotage von Nazi Deutschland:
https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf
Vergleicht mal die Punkte unter "General Interference with Organizations
and Production" ab Seite 18 mit dem was hier im Forum teilweise
berichtet wird. Insbesondere die Konzerndrohnen unter euch: Erkennt ihr
darin nicht auch euren Alltag wieder?
Ja, das kenne ich nur all zu gut. Das Problem ist, dass besonders
hochqualifizierte Mitarbeiter in einem geschlossenen Sozialgefüge
dauernd Erregungen und Befindlichkeiten haben, die für sie unangenehm
sind. Besonders wenn ein Chef aufgrund von falscher Beförderungen nicht
auf seinen Posten gehört wegen fehlender Qualitäten, dann entstehen
solche "Bauchschmerzen" bei allen Beteiligten, nicht nur beim "Chef".
Um die abzubauen, sabotieren viele auch unterbewusst den Arbeitgeber,
aber nur im dem Maße, dass dieser spitz auf Knopf überlebt.
Es würde einen enormen Produktivitätsschub in den Firmen geben, wenn die
Reibungsverluste aufgrund vom Abbau der persönlichen Befindlichkeiten
minimiert würden.
Vielleicht sind die neuen amerikanischen Tech-Giganten und Tesla so
erfolgreich, weil von Anfang an diese retortenmäßig so designt wurden,
dass diese Reibungsverluste nicht da sind.
Zurück zum Thema:
https://www.automobilwoche.de/article/20181106/NACHRICHTEN/181109965/1334/-programmierer-fuer-vw-in-portugal-vw-konzern-gruendet-software-lab-in-lissabon
Zitat:
"Dienstbeginn in den Labs ist immer um 8 Uhr. Dann wird gemeinsam
gefrühstückt und um 8:30 gibt es ein erstes „Stand-up“, eine 15-Minütige
Konferenz, bei der besprochen wird, was an dem Tag ansteht. Danach gehen
die einzelnen Teams in ein ebenfalls 15 Minütiges „Stand-up“. Um 9 Uhr
geht es dann los. Die Entwickler arbeiten immer im Tandem, also zu zweit
auf einem Arbeitsplatz und an einem Projekt. Einer von beiden
programmiert, der zweite hinterfragt permanent, was der erste
programmiert. „Das hilft uns, fast fehlerfreie Software zu produzieren“,
sagt Hofmann. Dienstschluss ist um 17 Uhr. „Danach ist man nicht mehr
produktiv“, sagt Hofmann.
Der durchstrukturierte Tag bedeutet aber auch: "Keine Gleitzeit, keine
Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr
stattdessen: Reine Konzentration auf die Arbeit, so der CIO. "
SO geht Software!
Diggi schrieb:> Der durchstrukturierte Tag bedeutet aber auch: "Keine Gleitzeit, keine> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. ">> SO geht Software!
Sie haben wohl die Redewendung "Code-Monkeys" viel zu ernst genommen,
anders kann man so eine entwürdigende Behandlung von Entwicklern nicht
vorstellen.
HBich schrieb:> Diggi schrieb:>> Der durchstrukturierte Tag bedeutet aber auch: "Keine Gleitzeit, keine>> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr>> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. ">>>> SO geht Software!>> Sie haben wohl die Redewendung "Code-Monkeys" viel zu ernst genommen,> anders kann man so eine entwürdigende Behandlung von Entwicklern nicht> vorstellen.
Software Factory. ;)
Diggi schrieb:> Der durchstrukturierte Tag bedeutet aber auch: "Keine Gleitzeit, keine> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. "
Was fürn Scheißladen. Kenne keinen Betriebsrat der ein pauschales
Handyverbot am Arbeitsplatz dulden würde. Also: Kein Betriebsrat.
Diggi schrieb:> Einer von beiden programmiert, der zweite hinterfragt permanent, was der erste> programmiert. „Das hilft uns, fast fehlerfreie Software zu produzieren“,
Und beide zusammen bekommen das Gehalt, was ein guter Softwerker alleine
bekommen müsste?
Es gibt sicherlich Pfeifen, bei denen ein ständiges Review notwendig
ist, aber der Regelfall ist das ja wohl nicht.
Manfred schrieb:> Diggi schrieb:>> Einer von beiden programmiert, der zweite hinterfragt permanent, was der erste>> programmiert. „Das hilft uns, fast fehlerfreie Software zu produzieren“,>> Und beide zusammen bekommen das Gehalt, was ein guter Softwerker alleine> bekommen müsste?>> Es gibt sicherlich Pfeifen, bei denen ein ständiges Review notwendig> ist, aber der Regelfall ist das ja wohl nicht.
Um fair zu bleiben: Das Vorgehen hat sich bewährt, um beste
Softwarequalität zu gewährleisten. Unter anderem bei Microsoft:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/esem-begel-2008.pdf
Klar man bekommt mehr Softwarequalität, dafür braucht man eben zwei
Entwickler, die gut miteinander können, ungefähr auf dem gleichen Level
sind und in ihren Ansichten auch übereinstimmen.
Es gibt unter Entwicklern so gewaltige Unterschiede. Da kann einer
durchaus um den einen großen Faktor besser sein als der andere. Insofern
funktioniert das bei sehr motivierten MA, aber nicht beim 0815
Konzernbeamten oder Klitschenfriggler.
Wann lesen sich die zum Beispiel in neue Themen ein? Geht das auch alles
zu zweit? Oder sind die Aufgaben so simpel, dass Lektüre oder gar die
Erstellung von technischen Dokumenten gar nicht erst erforderlich ist?
Manfred schrieb:> Es gibt sicherlich Pfeifen, bei denen ein ständiges Review notwendig> ist, aber der Regelfall ist das ja wohl nicht.
Jeder profitiert von Code Reviews. Deshalb sind die auch in jeder
anständigen Firma üblich. Niemand ist perfekt, besonders nicht die Leute
die glauben sie wären es. Ein gutes Code Review führt immer dazu, dass
man etwas dabei lernt.
Das "Pair Programming" bei dem 2 Leute an einem Stück Code arbeiten ist
leider selten, hat sich aber bereits seit dem "360" Projekt von IBM als
sinnvoll herausgestellt. Ein großer Vorteil dabei ist, dass man im Laufe
der Zeit die Fähigkeiten neuer Mitarbeiter breiter im Unternehmen
streuen kann.
Es gibt da einen schönen Vortrag von Felix von Leitner.
https://media.ccc.de/v/34c3-9095-antipatterns_und_missverstandnisse_in_der_softwareentwicklung
Diggi schrieb:> Wann lesen sich die zum Beispiel in neue Themen ein? Geht das auch> alles> zu zweit? Oder sind die Aufgaben so simpel, dass Lektüre oder gar die> Erstellung von technischen Dokumenten gar nicht erst erforderlich ist?
Natürlich macht man das in der Freizeit. Ich arbeite auch in so einem
Internationalen Unternehmen. Als Entwickler hat man bei einer 42h Woche,
22 Meetings. Dann geht praktisch alles für Ops drauf, da Devons und das
OPS praktisch nicht mehr existent respektive überfordert.
Der Rest geht dann noch an die Scrum/Kanban Meetings. Am Ende bekommt
man eine schlechte Quali weil man sein Task nicht abgearbeitet hat und
sich zu wenig einbringt. Ich habe es am Freitag. Was da raus kommt kann
ich singen!
Entwickler zu sein, heute, lasst es! Just my 2 Cents.
Grüsse,
René
Diggi schrieb:> Wann lesen sich die zum Beispiel in neue Themen ein? Geht das auch alles> zu zweit?
Naja, das teilt man auf, und der eine erklärt das dann dem anderen.
Dadurch haben das im Optimalfall beide verstanden.
> Oder sind die Aufgaben so simpel, dass Lektüre oder gar die> Erstellung von technischen Dokumenten gar nicht erst erforderlich ist?
99% der Softwareentwicklung sind extrem simple Dinge, bei denen die
Hauptschwierigkeit die Benutzung irgendwelcher kaputter APIs sind. So
wirklich neue Dinge werden nur sehr selten gebaut, und dann auch meist
nur von Einzelpersonen.
Die Dokumentation zum Code wird natürlich mit dem Code erstellt. Der
Code selbst ist ja auch nichts anderes als ein technisches Dokument
welches dann vom Compiler in Maschinensprache übersetzt wird. Code
schreibt man so, dass Menschen den Lesen können, denn jede Codestelle
wird viel häufiger gelesen als sie geändert wird.
Omg.
Gehört derjenige, welcher diesen Thread eropened hat, und diejenigen,
welche kluge Ratschläge diesbezüglich auszudünsten zu glauben gemeint
gehabt zu haben, etwa zu dem Geraffel, welches uns vorschreiben wird,
wie unsere Zukunft in technologischer Sicht auszusehen hat?
Na dann mal prost!
Christian B. schrieb:> Das "Pair Programming" bei dem 2 Leute an einem Stück Code arbeiten ist> leider selten, hat sich aber bereits seit dem "360" Projekt von IBM als> sinnvoll herausgestellt. Ein großer Vorteil dabei ist, dass man im Laufe> der Zeit die Fähigkeiten neuer Mitarbeiter breiter im Unternehmen> streuen kann.>> Es gibt da einen schönen Vortrag von Felix von Leitner.>> https://media.ccc.de/v/34c3-9095-antipatterns_und_missverstandnisse_in_der_softwareentwicklung
Fefe ist das Paradebeispiel für einen brillianten Überfachmann ohne
jegliches "Corporate Fit". Solche Leute will kein Konzern einstellen:
Intelligent. Gewissenhaft. Idealisten. Machen nur Ärger. Als Berater ist
ihr Wissen dann aber schon gefragt (lässt er sich auch ordentlich
vergüten), zumindest in begrenztem Umfang. Was nicht ins Bild passt wird
dann einfach ignoriert.
Inscheniör undercover schrieb:> Sinnlose Meetings, unerklärliche Beförderungen, miserable Einarbeitung,> Feindseligkeiten gegenüber Leistungsträgern: Welcher Technologiefreund> kennt das nicht aus seinem Berufsalltag?
Ich.
Wechsle den Betrieb. Man muss nicht bei solchen Verwaltungsapparaten
arbeiten. Man kann auch entwickeln. Man muss dabei aber bei der
Bewerbung die Augen auf machen und die richtigen Fragen fragen.
Auch ich habe mich mal auf so eine recht interessante Anzeige für einen
"Entwickler" bei so einem KFZ-Betrieb beworben. Beim Bewerbungsgespräch
stellte sich dann raus, dass die keinen "Entwickler", sondern einen
"Spezifikateur", "Koordinator" und "Kontrolleur" suchten, aber offenbar
das richtige Wort nicht gefunden hatten. Das war eines der kürzesten
Vorstellungsgespräche überhaupt. Ich habe mir dann noch das Städtchen
angeschaut und einen Kaffee getrunken, vor ich nach Hause bin. War eine
schöne Zeit dort.
René H. schrieb:> Ich arbeite auch in so einem Internationalen Unternehmen. Als Entwickler> hat man bei einer 42h Woche, 22 Meetings.
Das habe ich auch erlebt. Im Praxissemester bei einem internationalen
Unternehmenskonglomerat, die aus dem "Jäger 90" letztlich den
"Eurofighter" gemacht haben. Wenn man das erlebt hat, dann wundert es
keinen, dass die Jahreszahl dieses Flugzeugs einige Male angepasst
wurde.
Das einzige abteilungsübergreifende "Entwicklungsobjekt", das wirklich
voranging, war die Modelleisenbahn im Keller des Unternehmens. Die
"Meetings" dazu (die müssen sein, kennt man ja von der Arbeit auch)
fanden beim Mittagessen in der Kantine statt... ;-)
Rainer Z. schrieb:> Also: Kein Betriebsrat.
Richtig erraten, steht aber im Bericht: "Portugal ... „So eine Art der
Zusammenarbeit wäre in Wolfsburg nicht denkbar“, so Hofmann."
Rainer Z. schrieb:> Solche Leute will kein Konzern einstellen:> Intelligent. Gewissenhaft.
Nein, glaube ich nicht. Solche Leute werden schon auch von Konzernen
eingestellt, und die Konzerne versuchen auch die zu halten (z.Bsp in dem
in den Abteilungen Meetings reduziert werden und Bürokratie von der
Team-Assistenz erledigt wird), nur meistens kommen da die Bewerber
nicht, oder hauen schnell wieder ab.
Wenn man heute als Ingenieur irgendwas auch nur halbwegs kann, ist man
quasi unkündbar. Es gibt nur leider sehr viele Leute die nichts können
und trotzdem ihren Abschluss geschafft haben.
Albert schrieb im Beitrag #5612783:
> Selten so einen Unsinn gelesen. SO geht Software eben nicht. Man muss> sich auch alleine konzentrieren können. Glaubst du ernsthaft da hilft es> wenn jemand immer von der Seite kritisiert.
Du hast Pair Programming nicht verstanden. Da wirst Du nicht kritisiert,
sondern jemand arbeitet Dir zu. Sprich der andere denkt mit, und
beantwortet Dir die Fragen die Du hast, bevor Du sie stellst. Sprich
solche Fragen wie "Wie hieß diese Funktion noch mal". Die Frage was denn
überhaupt programmiert werden soll ist ja zu diesem Zeitpunkt schon
beantwortet.
Lothar M. schrieb:> Wenn man das erlebt hat, dann wundert es> keinen, dass die Jahreszahl dieses Flugzeugs einige Male angepasst> wurde.
Naja, es gibt ja auch Pazifisten. :)
Diggi schrieb:> Zurück zum Thema:>> https://www.automobilwoche.de/article/20181106/NACHRICHTEN/181109965/1334/-programmierer-fuer-vw-in-portugal-vw-konzern-gruendet-software-lab-in-lissabon
VW, da muss jeder selber wissen ob er für diese kriminelle Organisation
arbeiten möchte. Es sei aber darauf hingewiesen, dass es zur Zeit nicht
mehr die kostenlosen Nutten für die Führung gibt. Bzw. man redet
momentan nicht drüber.
> Zitat:>> "Dienstbeginn in den Labs ist immer um 8 Uhr. Dann wird gemeinsam> gefrühstückt
Lass mich kurz mal kotzen, ja. Das mag für den ansonsten bindungslosen,
unfähig sich selber ein Frühstück zu machen, digital naiven
Millenial-Hipster ganz toll sein.
Wir Erwachsenen ziehen es vor das Frühstück zu Hause mit der Familie zu
verbringen, nicht mit den Hackfressen von Kollegen. Firma != Familie.
> und um 8:30 gibt es ein erstes „Stand-up“, eine 15-Minütige> Konferenz, bei der besprochen wird, was an dem Tag ansteht.
Antreten vor der Kompanie, der Hauptmann gibt den Tagesbefehl aus.
> Danach gehen> die einzelnen Teams in ein ebenfalls 15 Minütiges „Stand-up“.
Antreten vor dem Gerät, der Uffz stottert einzelne Anweisungen hervor.
Wer so etwas mag, da habe ich einen heißen Tipp:
https://bewerbung.bundeswehr-karriere.de/> Um 9 Uhr> geht es dann los. Die Entwickler arbeiten immer im Tandem, also zu zweit> auf einem Arbeitsplatz und an einem Projekt.
Selber denken ist nicht mehr in Mode, selber als Ingenieur Verantwortung
für seine Tätigkeit übernehmen auch nicht. Halt, sind ja Programmierer,
na dann.
> Einer von beiden> programmiert, der zweite hinterfragt permanent, was der erste> programmiert.
Da kann man nur hoffen, dass der Kamerad nicht wöchentlich Berichte an
den Führungsoffizier sendet.
> „Das hilft uns, fast fehlerfreie Software zu produzieren“,> sagt Hofmann.
Nachdem Bosch keine Betrugssoftware mehr liefert muss man die fast
fehlerfreie (= schwer zu entdeckende) Betrugssoftware selber machen.
Hartes Los.
> Dienstschluss ist um 17 Uhr. „Danach ist man nicht mehr> produktiv“, sagt Hofmann.
Wenn einem um 17 Uhr der Kamerad/Aufpasser von der Pelle rückt könnte
man das erste Mal am Tag in Ruhe arbeiten und was geschafft bekommen.
> Der durchstrukturierte Tag
Für verzogene Hipster, die ohne Mamis ordnende Hand keine eigene
Struktur in ihren Tag bekommen und denen es nicht gelingt ihre Arbeit
selbstständig zu organisieren. Für Typen, die mit Anfang 20 noch von
Muttis Brust entwöhnen werden müssen.
> bedeutet aber auch: "Keine Gleitzeit, keine> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. "
Bindungslos, jung, keine Verantwortung haben und damit kein Bedarf für
Außenkontakt. Keine Termine bei Behörden, Ärzten, Firmen, etc. haben.
Arbeit, Arbeit, Arbeit. Dann mit 30 auf die Millenial-Müllhalde geworfen
werden. Wer's mag für den ist es das Höchste.
> SO geht Software!
So geht moderne Ausbeutung in einer kriminellen Organisation.
Hannoveraner schrieb:> G. Ast schrieb:>> So ist also die "Abgasoptimierungssoftware" bei VW programmiert>> worden...>> Die ist bei Bosch programmiert worden
Die Software wurde von Bosch programmiert, der Parametersatz von VW.
Somit kann jede Seite das irgendwie abstreiten daran Schuld zu sein.
Hannes J. schrieb:>> bedeutet aber auch: "Keine Gleitzeit, keine>> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr>> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. ">> Bindungslos, jung, keine Verantwortung haben und damit kein Bedarf für> Außenkontakt. Keine Termine bei Behörden, Ärzten, Firmen, etc. haben.> Arbeit, Arbeit, Arbeit
Ja... Wie soll man es überhaupt schaffen sich 8h am Stück zu
konzentrieren, selbst ohne Ablenkung? Muss man Raucher werden, um eine
Ausrede zu bekommen stündlich das Büro zu verlassen?
Wenn ich ein wirklich kompliziertes Problem habe, gucke ich auch mal ne
halbe Stunde aus dem Fenster (Postkarten-Aussicht hier) und überlege.
Hilft mir mein Pair-Programming-Partner dann beim Gucken?
Ihr habt keine Ahnung, wie das in manchen Klitschen in Deutschland
abläuft.
Für Frühstück haben wir eh keine Zeit, müssen ja beide arbeiten um uns
irgendwie die Immobilie leisten zu können. Und dann fahren wir auch noch
so früh wie möglich los, sonst fährt man ja gleich wieder über eine
Stunde.
Pair Programming wäre schon ganz nett, aber hier hat man natürlich auch
allein ausgezeichnete Qualität zu liefern, obwohl man mindestens alle
halbe Stunde mit einem Supportticket und/oder Anruf gestört wird. So aus
der Sales Abteilung die Anfrage ob die Auswertung, die man vor einer
halben Stunde angefordert hat, denn bald fertig ist.
Wenn man dann doch einen Bug drin hat, der durchgerutscht ist, weil ja
für Reviews keine Zeit mehr ist und wir ja auch ganz hipp sind und
Continuous Deployment machen, also 2 mal die Woche ausrollen, ohne dass
es groß getestet wurde. Dann geht noch ein bisschen Freizeit des
Entwicklers drauf, denn die Systeme dürfen ja nur nach 18 Uhr und vor 7
Uhr eingeschränkt verfügbar sein.
Planbarer Feierabend, Fehlanzeige. Da ist es auch nicht besser, dass ich
die Telko abends um 18 Uhr von zu Hause machen kann, denn ich hab
trotzdem morgens um 6 Uhr angefangen und bis um 17 schnell nach Hause
gefahren um rechtzeitig zu der Telko wieder am Rechner zu sitzen.
Da hört sich das bei VW nicht so schlecht an.
Dr. Sommer schrieb:> Wenn ich ein wirklich kompliziertes Problem habe, gucke ich auch mal ne> halbe Stunde aus dem Fenster (Postkarten-Aussicht hier) und überlege.> Hilft mir mein Pair-Programming-Partner dann beim Gucken?
Der schreibt in der Zeit Dein übles Gefrickel um ;-)
Ernsthaft:
Das Vier-Augen-Prinzip ist schon sehr sinnvoll, aber kaum rund um die
Uhr wie weiter oben beschrieben.
Wir handhaben das hier so, dass erstmal grundsätzlich nach jedem Projekt
der Programmierende mit dem anderen zusammen alles nochmal durchgeht und
seinen Code erklärt. Bei kniffligeren Sachen sitzt man aber auch
durchaus mal zusammen am Rechner, aber nicht den gesamten Tag.
Eventuell ist es ein Ziel dieses Prinzips, die zwangsläufig
zwischendurch auftretenden Konzentrationsschwächen durch den jeweils
anderen abzufangen.
Andererseits fühlen sich eventuell beide genötigt, länger zu coden, als
es ihre Konzentrationsfähigkeit eigentlich zuliesse und sie verkneifen
sich eine Pause oder zögern sie hinaus. Das könnte zu mehr Stress
führen.
Und wenn man Pech hat, dann fallen beide zur selben Zeit in ein Loch
(bspw. nach dem Mittagessen).
Außerdem müssen sich die beiden schon gut verstehen - irgendwelche
atmosphärischen Störungen dürften dem Ganzen sehr abträglich sein.
Meine Einschätzung: manchmal ist das Prinzip durchaus sinnvoll, aber
permanent kaum.
Dr. Sommer schrieb:> Hilft mir mein Pair-Programming-Partner dann beim Gucken?
So lange du nichts schreibst, kann er dich nicht korrigieren und
hinterfragen.
Mich würde auch mal interessieren, wie das in der Realität zugeht. Ich
kenne diese "Paararbeit" noch aus dem Studium, wo wir zu zweit
irgendwelche Aufgaben lösen mussten. Ich habe dann gedacht und mein
Kommilitone hat das in Windeseile in den Rechner getippt. Wir waren ein
Traumpaar, ratzfatz fertig.
Aber wehe wenn wir hätten die Rollen tauschen müssen. Er war nicht der
flinkeste Denker und ich kein guter Tipper... ;-)
Lothar M. schrieb:> So lange du nichts schreibst, kann er dich nicht korrigieren und> hinterfragen.
Wenn ich jeden Gedankengang hinschreibe hab ich zur Deadline einen
riesigen Haufen wirres Geschreibsel über verworfene Ansätze und kein
Ergebnis...
Erinnert mich an die Schule, wo angenommen wird dass man ohne
Hinschreiben nicht denken kann und man sich die Finger verkrampft jeden
Pups auszuformulieren.
Lothar M. schrieb:> Mich würde auch mal interessieren, wie das in der Realität zugeht.
Ein konkretes Beispiel:
Bei neuen Features sitzen zwei vorm Rechner, überlegen sich nützliche
TestCases und sprechen über Interfaces und klopfen die rein. Danach
setzt sich jeder an seinen Rechner, der eine implementiert die Tests aus
und der andere den Produktcode. Der Produktcode wird geshelved und an
den Testcoder gegeben. Dann kommt der Produktcoder wieder an den Rechner
des Testcoders, überprüfen ob die Tests grün laufen und machen
gegenseitig Code Review. Laufen die Tests rot, guckt man gemeinsam wos
hakt, fehlerhafte Testimplementierung oder fehlerhafte
Produktimplementierung. Nach grünen Tests und Review wird dann
eingecheckt. Hinterher haben zwei Leute ein tieferes Verständnis des
Features und der zugehörigen Test-Suite.
So versuchen wir es wenn möglich zu handhaben, ja, es klappt nicht immer
optimal, wies halt in der Realität so ist, aber man kann es so gut wie
möglich anstreben.
Aber wenn einer alles macht an einem Feature, von der Entwicklung hin
zum Test führt das zwangsläufig irgendwann zu Problemen hinterher.
Trennung von Produkt und Test auf zwei Personen hat sich schon
desöfteren bewährt und führt meistens zu höherer Qualität, weil man sich
deutlich intensiver mit den Schnittstellen beschäftigt.
Die Pair-Programmierung wurde wahrscheinlich auch von den gleichen
Leuten ausgedacht, die GIT erfunden haben.
In der Theorie phänomenal, bis es zur Anwendung kommt.
Die Leute brauchen Prozesse, die auf die Produktentwicklung abgestimmt
sind und nicht umgekehrt die Arbeit auf die Prozesse angepasst wird.
Die Produkt ist wichtiger als der Prozess.
Bei sicherheitskritischen Systemen ist der Prozess wichtig, damit die
Verantwortung verteilt wird und Fehler systematisch herausgetrieben
werden.
Bei einer Neuentwicklung, die keine Standard-Software sein soll oder
wenn ich einen hochperfomanten Regel-Algorithmus implementiere, will ich
am Besten überhaupt gar keine Stimmen auch von der Ferne nicht hören.
> Der durchstrukturierte Tag bedeutet aber auch: Keine Gleitzeit, keine> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr –> stattdessen: Reine Konzentration auf die Arbeit, so der CIO.
LOL. Klingt nach kambodschanischer Näherei. Wer aufs Klo muss fliegt
gleich raus.
Scheinbar gibt's nach der Wirtschaftskrise in Portugal mehr Verzweifelte
als in D die sowas mit sich machen lassen.
Albert schrieb im Beitrag #5613074:
> Halte ich für nicht zielführen, da Wertvolle Human Resources> verschwendet werden, wenn man zu zweit an der Aufgabe sitzt ohne einen> vernünftigen Prozess zu haben.
Was du für zielführend hältst ist irrelevant. Es zählt was in der Praxis
termingerecht Ergebnisse in ausreichender Qualität liefert. Ein Prozess
hilft bei unfähigen Leuten genausowenig gute Ergebnisse abzuliefern, wie
kein Prozess.
Es hat schon einen Grund, warum Pair-Programming aus den USA kommt.
Da sind die Rahmenbedingungen ganz andere, die Zeiten, die ein
Entwickler bei derselben Firma ist, sind dramatisch kürzer als in
Deutschland, die Ausbildung des Durchschnittsentwicklers ist erheblich
unter dem Nievau aus Deutschland. Man muss jederzeit damit rechnen, dass
ein Entwickler innerhalb von Stunden die Papiere abholt und weg ist.
Da ist es durchaus sinnvoll und gibt auch sicherlich deutlich bessere
Ergbnisse, als wenn man solche Leute alleine frickeln lässt.
Ob das in Deutschland sinnvoll ist, mag man bezweifeln.
Gruß
Axel
Ja der deutsche Übermen... entwickler und der amerikanische
Unterentwickler, ist schon klar, nen noch gröberen Allgemeinplatz haste
nicht gefunden?
Wo derzeit die Musik spielt ist dir scheinbar entgangen? Software ist
die Zukunft. Deutschland darf sich dann auf seinen Status als
Hardwarezulieferer für USA / China einen schrubben.
Abradolf L. schrieb:> Albert schrieb:>> Halte ich für nicht zielführen, da Wertvolle Human Resources>> verschwendet werden, wenn man zu zweit an der Aufgabe sitzt ohne einen>> vernünftigen Prozess zu haben.>> Was du für zielführend hältst ist irrelevant. Es zählt was in der Praxis> termingerecht Ergebnisse in ausreichender Qualität liefert. Ein Prozess> hilft bei unfähigen Leuten genausowenig gute Ergebnisse abzuliefern, wie> kein Prozess.
Wird bei Waymo und Tesla genauso gearbeitet?
Albert schrieb im Beitrag #5613158:
> Du hast einfach keine Ahnung.
Wenn du meinst. Versucht da etwa wieder ein theoretischer Bedenkenträger
den Leuten die es tagtäglich in der Praxis erfolgreich umsetzen die Welt
zu erklären?
Sieh es einfach ein, du hasts einfach nicht drauf, egal mit welcher
Methode.
Naja, Hardware wird ja in der Regel auch besser, wenn man schon bei der
Konzeptionierung wenigstens das Ergebnis (bzw. die geplante Umsetzung)
mal im Team bespricht und sich die Überlegungen des Einzelnen der Kritik
der Anderen stellen müssen.
Wenn man einen einzelnen Kellerfrickler ans CAD setzt kommt meistens
kein Konzept und irgendein Schaltplanwust, durch den keiner durchsehen
will. (Weswegen dann auch das Review ausbleibt und derselbe Frickler
auch das Layout macht.)
Der oben geschilderte strikte Arbeitsablauf wäre mir wahrscheinlich auch
zu rigide (alleine schon daß die Gleitzeit damit wegfällt). Aber wie gut
kann ein Entwickler sein, der sich nicht traut sein Arbeitsergebnis
herzuzeigen oder stetige Korrektur fürchtet?
Wühlhase schrieb:> Aber wie gut> kann ein Entwickler sein, der sich nicht traut sein Arbeitsergebnis> herzuzeigen oder stetige Korrektur fürchtet?
Full Ack.
Inscheniör undercover schrieb:> Sinnlose Meetings, unerklärliche Beförderungen, miserable Einarbeitung,> Feindseligkeiten gegenüber Leistungsträgern: Welcher Technologiefreund> kennt das nicht aus seinem Berufsalltag?
Ich kenne das nicht aus meinem Berufsalltag.
Albert schrieb im Beitrag #5613179:
> Hab ich nicht nötig mich vor dir zu beweisen.
Offensichtlich schon, sonst hättest du das Thema ja nicht ins Spiel
gebracht. Wo der Zusammenhang zwischen der Güte eines Entwicklers und
einem Bankkontostand ist, bleibt wohl dein Geheimnis.
Dass du offensichtlich wenig Wertschätzung für deine Arbeit erhalten
hast und nun anderweitig suchst - ob zu recht oder zu unrecht kann ich
nicht beurteilen - zeigst du ja ganz offen dadurch:
Albert schrieb im Beitrag #5613179:
> Wenn du heute nacht> schlafen gehst wirst du kurz daran denken wie schön es ist finanziell> komplett ausgesorgt zu haben und dann kommt der Neid.
Bemitleidenswert.
Schon interessant, wie wenige sich wirklich was unter
Pair Programming vorstellen können und hier sinnfreie
Kommentare absondern ;)
https://de.wikipedia.org/wiki/Paarprogrammierung
Ja, ist nicht für jede Situation was. Ja, die beiden
Entwickler sollten miteinander können. Ja, es hat auch
Nachteile.
merciless
Rainer Z. schrieb:> Diggi schrieb:>> Der durchstrukturierte Tag bedeutet aber auch: "Keine Gleitzeit, keine>> Handys am Arbeitsplatz, eingeschränkte Browser, kein Mailverkehr>> stattdessen: Reine Konzentration auf die Arbeit, so der CIO. ">> Was fürn Scheißladen. Kenne keinen Betriebsrat der ein pauschales> Handyverbot am Arbeitsplatz dulden würde. Also: Kein Betriebsrat.
Vielleicht ein bisschen übertrieben, aber mehr Fokus und Zielstrebigkeit
würde gerade den Endwigglern in den Mid-Life-Jahren gut zu Gesicht
stehen. Die haben nur noch die die Familie und den Karrierausklang vor
Augen und die jungen Wilden nur Gehaltssteigerungen bei geringstem
Aufwand. Deshalb tun sich die Autohersteller auch so schwer mit
Software, wenn sie inhouse entwickeln müssen. Lange und sehr, sehr teure
Entwicklung, trotzdem Software clumsy, buggy bis hin zu dysfunktional.
Da muss mehr Struktur, Fleiß und Routine rein.
Drillmaster schrieb:> Deshalb tun sich die Autohersteller auch so schwer mit> Software, wenn sie inhouse entwickeln müssen. Lange und sehr, sehr teure> Entwicklung, trotzdem Software clumsy, buggy bis hin zu dysfunktional.> Da muss mehr Struktur, Fleiß und Routine rein.
Einfach mal eine Gruppe erfahrener SW-Entwickler und Freelancer mit 20
Jahre Berufserfahrung dauerhaft einbinden und gut bezahlen (80€/h), die
Anforderungen sauber formulieren, Architektur und Schnittstellen
definieren und genehmigen und einfach mal machen lassen.
Bei VW fehlt es einfach nur an Führuns- und Managementkompetenzen,
sobald es nicht mehr um Maschinenbau und Produktion geht.
Der Fisch stinkt vom Kopf her. Sie haben bis heute nicht herausfinden
wollen, wer denn nun die initiale Idee hat mit dem Abgastuning als
Softwarelösung.
Special Agent Meyer schrieb:> Verlauf des Threads:> CIA - Nazi Dtl - Volkswagen - Software - Pair Programming - Hipster
Nutten. Du hast Nutten vergessen. Wer Volkswagen sagt muss auch Nutten
sagen. Man sollte auch nicht Peter Hartz vergessen. Der Ehrenmann, dem
wir Hartz IV zu verdanken haben und der in 44 Anklagepunkten schuldig
gesprochen wurde, u.a. weil er das Geld für die Nutten abgesegnet hat.
Bei VW ist, um mal zum Betreff zurück zu kommen, so etwas der übliche
Wahnsinn im Alltag.
Hannes J. schrieb:> Special Agent Meyer schrieb:>> Verlauf des Threads:>> CIA - Nazi Dtl - Volkswagen - Software - Pair Programming - Hipster>> Nutten. Du hast Nutten vergessen. Wer Volkswagen sagt muss auch Nutten> sagen. Man sollte auch nicht Peter Hartz vergessen. Der Ehrenmann, dem> wir Hartz IV zu verdanken haben und der in 44 Anklagepunkten schuldig> gesprochen wurde, u.a. weil er das Geld für die Nutten abgesegnet hat.>> Bei VW ist, um mal zum Betreff zurück zu kommen, so etwas der übliche> Wahnsinn im Alltag.
Nutten haben wir im Betrieb nicht.
Abradolf L. schrieb:> Ingenier 4.0 schrieb:>> Nutten haben wir im Betrieb nicht.>> Keine Aufsteiger-Führungskräftinnen im Betrieb?
Wußte gar nicht, daß ihr so merkwürdige Sitten bei euch im Konzern habt.
Inscheniör undercover schrieb:> Insbesondere die Konzerndrohnen unter euch: Erkennt ihr> darin nicht auch euren Alltag wieder?
Einfache Antwort: Nein.
Dennis schrieb im Beitrag #5613845:
> Sag mal gehts noch. Du willst professionell sein aber so einen Unsinn> von dir geben.
Mach dich mal locker, willst du etwa bestreiten, dass es Arschkriechen
bzw. das Pendant sich hochschlafen in der Realität gibt? Da wird eine
kleine Überspitzung schon niemanden weh tun oder gehörst zur Generation
Snowflake?
Abradolf L. schrieb:> Ingenier 4.0 schrieb:> Nutten haben wir im Betrieb nicht.>> Keine Aufsteiger-Führungskräftinnen im Betrieb?
Heißt das nicht BWL-Bitch?
Dennis schrieb im Beitrag #5614014:
> Du bist hier auch so ein Problemkind.
Ich finde es erfrischend wenn jemand offensichtliche Tatsachen
ausspricht und sich nicht hinter falsch verstandener Korrektheit
versteckt.
Ein Safespace ist nur solange schön bis er mit der Realität kollidiert.
Und dass es Menschen, sowohl Frauen als auch Männer gibt die sich
hocharschkriechen oder hochschlafen willst du doch wohl nicht
bestreiten, oder?
Le X. schrieb:> hocharschkriechen oder hochschlafen
Wie macht man das eigentlich, gibt es da Coachings für? Ist das das, was
man immer unter "Soft Skills" oder "Networking" versteht?
Dr. Sommer schrieb:> Wie macht man das eigentlich, gibt es da Coachings für? Ist das das, was> man immer unter "Soft Skills" oder "Networking" versteht?
Tja das wird für emotionale Krüppel immer ein Buch mit sieben Siegeln
bleiben, wie man mit Mitmenschen und Nichtrobotern sympathisieren kann.
Ärgere deine Chefin und sieh dir an wie eine Furietransformation
praktisch aussieht.
Dr. Sommer schrieb:> Wie macht man das eigentlich, gibt es da Coachings für? Ist das das, was> man immer unter "Soft Skills" oder "Networking" versteht?
Nicht zwangsläufig.
Man kann auch networken und mit anderen Menschen gut auskommen, ja, sich
sogar gut mit Arbeitskollegen und Vorgesetzten verstehen ohne gleich ein
Arschkriecher zu sein.
Das nennt sich dann "normaler zwischenmenschlicher Umgang".
Diggi schrieb:> G. Ast schrieb:>> So ist also die "Abgasoptimierungssoftware" bei VW programmiert>> worden...>> https://karriere.audi.de/sap/bc/bsp/sap/z_hcmx_ui_ext/?jobId=CE6634AF2C031EE8AAD35C68B9C21723>> Bei Audi kannst du auch gleich als "Spezialist/-in> Gesetzesinterpretation" anheuern.> LOL. Da fehlt übrigens noch ein "d" für das neutrale Geschlecht.
Sehr schön :-) Man sollte meinen der Fachbegriff dafür wäre Jurist, aber
nein:
- Sie haben ein erfolgreich abgeschlossenes Studium der Fahrzeugtechnik,
des Maschinenbaus oder eines vergleichbaren Studienganges
Abradolf L. schrieb:> Sehr schön :-) Man sollte meinen der Fachbegriff dafür wäre Jurist, aber> nein:>> - Sie haben ein erfolgreich abgeschlossenes Studium der Fahrzeugtechnik,> des Maschinenbaus oder eines vergleichbaren Studienganges
Wenn Du Dir die Aufgabe ansiehst, wird klar, dass sich das Angebot an
normpopelnde Sesselfurzer richtet, die sich beim TÜV unterfordert
fühlen.
Für Juristen sind möglicherweise die Stellen im Bereich Compliance. Wer
sich früher immer freiwillig zum Tafeldienst gemeldet hat, könnte sich
da wohlfühlen ...
Percy N. schrieb:> Wenn Du Dir die Aufgabe ansiehst, wird klar, dass sich das Angebot an> normpopelnde Sesselfurzer richtet, die sich beim TÜV unterfordert> fühlen.
Ja schon klar, aus dem Grund habe ich mich ja nur auf den Titel
gestützt, so nach dem Motto "Wir haben 100 Leute gefragt: welches
Studium vermuten sie hinter einem Spezialisten für
Gesetztesinterpretation?"
