Was ich diese Woche gelernt habe (Woche 50/2013)

Jede Woche schreibe ich einen Blogbeitrag, der beschreibt, was ich in dieser Woche gelernt habe. Ich schreibe diese Blogbeiträge aus zwei Gründen.

Zuerst , ich möchte meine persönliche Entwicklung im Auge behalten, und das Schreiben regelmäßiger Blogbeiträge ist eine großartige Möglichkeit, dies zu tun.

Zweiter , ich möchte meine Erkenntnisse mit Ihnen teilen. Ich hoffe, dass Sie einige davon in Ihrer täglichen Arbeit verwenden können.

Fangen wir an und finden heraus, was ich in Woche 50 gelernt habe.

Was ich in Woche 50 gelernt habe

Zuerst , Sprechen Sie die Sprache Ihrer Kunden.

Vor zwei Wochen habe ich argumentiert, dass wir "Dinge" mit domänenspezifischer Sprache benennen sollten. Diese Woche habe ich gelernt, dass wir hier nicht aufhören sollten. Wir sollten in unserer Kommunikation auch eine domänenspezifische Sprache verwenden.

Diese Woche fragte mich mein Kunde, ob es möglich wäre, die Validierungslogik eines Formulars X zu ändern. Das Formular X hat ein Pflichtfeld namens Bankkontonummer. Mein Kunde wollte dieses Feld optional machen, da es nicht in allen Anwendungsfällen erforderlich ist.

Mein erster Versuch, die Situation zu erklären, war folgender:

Wir können das Feld Bankkontonummer nicht in allen Anwendungsfällen optional machen, da es in Anwendungsfall X nicht null oder leer sein kann

Ich dachte, ich hätte die Situation ziemlich klar erklärt, aber mein Klient verstand mich nicht. Es war an der Zeit, einen besseren Weg zu finden, um die Situation zu erklären. Am Ende habe ich diese Erklärung verwendet:

Die Bankkontonummer ist in Anwendungsfall X erforderlich, da Sie die Zahlungsinformationen benötigen, damit Sie an den Inhaber des Bankkontos zahlen können.

Das hat es geschafft! Am Ende haben wir die folgenden Änderungen an der Validierung vorgenommen:

• Die Bankkontonummer ist im Anwendungsfall X weiterhin obligatorisch.
• Die Back-Account-Nummer ist optional, wenn der Anwendungsfall dies nicht erfordert.

Lektion: Verwenden Sie keinen Fachjargon, wenn Sie mit Ihren Kunden kommunizieren.

Zweiter , Wenn die Scheiße auf den Ventilator trifft, eliminiere alle Ablenkungen.

Wenn ein schwerwiegendes Problem in einer Produktionsumgebung gefunden wird, folgen die Ereignisse normalerweise dieser Reihenfolge:

1. Ich bekomme eine E-Mail oder einen Anruf und finde heraus, dass es ein Problem gibt, das meine Aufmerksamkeit erfordert.
2. Ich fange an, das Problem zu lösen.
3. Nach einer Weile erhalte ich möglicherweise einen Anruf, bei dem ich das Problem besprechen und versuchen muss, herauszufinden, was falsch ist.

Können Sie herausfinden, was das Problem ist?

Genau.

Wenn ich das Problem nicht gelöst habe, bevor ich den in Schritt drei erwähnten Anruf erhalte, hat der Anruf zwei Konsequenzen:

• Ich "verliere" meinen Fokus und muss ihn nach Ende des Telefongesprächs wiederfinden. Das bedeutet, dass ich das Problem nicht so schnell wie möglich lösen kann.
• Telefonieren ist Zeitverschwendung. Wenn mein Kunde beispielsweise 20 Personen hat, die das System aufgrund des Problems nicht nutzen können, und das Telefonat 15 Minuten dauert, verliert mein Kunde 300 Minuten Arbeitszeit (fünf Stunden!).

Deshalb stelle ich mein Telefon stumm, nachdem ich die erste Meldung über das Problem erhalten und meinen Kunden darüber informiert habe, dass ich dieses Problem löse. Das hilft mir, das Problem schnellstmöglich zu lösen und den Schaden zu minimieren.

Dritter , Jede Verbesserung zählt!

Ich arbeite jetzt seit über zwei Jahren an demselben Projekt. Während dieser Zeit habe ich viele neue Dinge gelernt und mehrere neue Spring-Versionen wurden veröffentlicht (das Projekt ist eine Spring-Webanwendung).

Die Herausforderung jedes langen Projekts besteht darin, den Code zu verbessern, wenn Sie neue Fähigkeiten erlernen und neue Versionen der verwendeten Frameworks und Bibliotheken veröffentlicht werden. Einige Leute argumentieren, dass aus Gründen der Konsistenz die gesamte Codebasis die gleiche Vorgehensweise verwenden sollte.

Ich bin keiner von ihnen!

Ich glaube, dass wir den Code sofort umschreiben und umgestalten sollten, wenn er ungeschickt aussieht oder wir wissen, dass es einen besseren Weg gibt, dasselbe zu tun. Dieser Ansatz hat zwei Hauptvorteile:

• Es wird uns motivieren. Nichts ist frustrierender, als einer uralten Best Practice zu folgen, wenn wir wissen, dass dies nicht die beste Vorgehensweise ist.
• Es verhindert, dass unsere Codebasis zu nicht wartbarem "Legacy-Code" wird. Wenn wir unsere Codebasis vernachlässigen und ihre Probleme nicht beheben, wenn wir sie identifizieren, wird unsere Codebasis schneller verrotten, als wir uns vorstellen können.

Lassen Sie Ihre Codebasis nicht verrotten . Wenn Sie Ihren Code häufig verbessern, wird der Entwickler, der ihn nach Ihnen pflegen muss, Ihnen dafür danken.

Vierter , Die Wahl einer "sicheren" Technologie ist nicht immer die beste Wahl.

Wenn wir eine Technologie für ein neues Projekt auswählen, haben wir manchmal zwei Möglichkeiten:

1. Die "sichere" Technologie. Die "sichere" Technologie ist sehr ausgereift und wir kennen sie sehr gut.
2. Die "riskante" Technologie. Wir haben festgestellt, dass diese Technologie in Blogs und in der Entwickler-Community im Allgemeinen viel Anklang findet, haben aber nicht viel Erfahrung damit.

Unternehmensentwickler entscheiden sich oft für die erste Option, und die Hipster entscheiden sich eher für die zweite.

Ich bin ein bisschen konservativ, wenn es um die Auswahl von Technologien geht, aber in letzter Zeit habe ich begonnen, meine Einstellung zu hinterfragen. Ich begann zu zweifeln, als ich die Gründe identifizierte, warum ich dazu neige, die "sichere" Technologie zu wählen. Diese Gründe sind:

• Ich kenne die "sichere" Technologie sehr gut und weiß, dass sie viele Nachteile haben kann. Allerdings kann ich diese Einschränkungen umgehen und weiß, dass ich keine Fehler mache.
• Ich befürchte, dass die „riskante“ Technologie noch nicht serienreif ist, da ich ihre Stärken und Schwächen nicht genau kenne. Mit anderen Worten, ich habe Angst, dass ich es vermasseln könnte, wenn ich mich entscheide, diese Technologie zu verwenden.

Es scheint, dass der Hauptgrund, warum ich auf Nummer sicher gehe, die Angst vor dem Unbekannten ist. Ist das wirklich ein guter Grund?

Nein. Das ist es nicht!

Wenn wir nicht genug Erfahrung mit einer bestimmten Technologie haben, sollten wir sie nicht aufgeben. Stattdessen sollten wir die Antworten auf unsere Fragen finden und eine fundierte Entscheidung treffen.

Fünfter , Nichts geht über die persönliche Kommunikation.

Ich habe an vielen Meetings teilgenommen, die eine totale Zeitverschwendung waren, und ich bin kein großer Fan von „traditionellen“ Meetings. Das heißt aber nicht, dass ich die persönliche Kommunikation für nutzlos halten würde.

Ich denke, dass Face-to-Face-Kommunikation ein sehr mächtiges Werkzeug sein kann, wenn es richtig eingesetzt wird. Denken Sie an die folgenden Situationen:

• Kodieren (oder Debuggen) in Paaren statt versuchen, Ihr Problem alleine zu lösen.
• Eine schnelle Demo für den Product Owner, der neben Ihnen sitzt, anstatt die Demo auf einem Remote-Server bereitzustellen und den Product Owner zu bitten, sich das anzusehen.
• Brainstorming mit einer anderen Person im Vergleich zu dem Versuch, alleine auf großartige Ideen (oder irgendeine Idee!) zu kommen.

Sehen Sie das Muster hier?

Ich behaupte, dass Sie viel von der persönlichen Kommunikation profitieren können, solange Sie es vermeiden, ein traditionelles Meeting zu organisieren.

Es gab viel Aufhebens um alternative Kommunikationsmethoden wie IM und Social-Media-Plattformen. Obwohl ich der Meinung bin, dass dies wertvolle Werkzeuge sind, um mit meinen Freunden und Verwandten in Kontakt zu bleiben, besteht ihr größter Nachteil darin, dass sie nicht garantieren, dass beide Gesprächspartner ihr tatsächlich Aufmerksamkeit schenken!

Deshalb schätze ich altmodische Diskussionen. Denn wenn der andere nicht darauf achtet, merke ich das sofort und kann entsprechend handeln.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.