Was ich diese Woche gelernt habe (Woche 33/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 33 gelernt habe.

Was ich in Woche 33 gelernt habe

Zuerst , Ich habe von Mob Programming gehört, das wie Paarprogrammierung mit Steroiden aussieht. Anfangs war ich etwas skeptisch, aber dann hat mich Woody Zuill davon überzeugt, dass ich etwas daraus lernen kann.

Ich finde es toll, dass das Ziel der „Mob Programming Bewegung“ nicht darin besteht, Mob Programming zu empfehlen. Sie teilen einfach mit, was für sie funktioniert und was ihnen hilft, die Teamarbeit zu verbessern. Ich denke, dass dies ein würdiges Ziel ist.

Wenn Sie daran interessiert sind, können Sie weitere Informationen über die Mob-Programmierung erhalten, indem Sie die Grundlagen der Mob-Programmierung lesen.

Zweiter , Branding ist wichtig. Ich habe diese Woche Brilliant Marketing von Richard Hall gelesen und festgestellt, dass Entwickler (einschließlich mir) oft nicht sehr gut darin sind, ihre persönlichen Marken aufzubauen. Die meisten von ihnen wissen wahrscheinlich nicht einmal, warum dies für sie von Vorteil wäre. Früher dachte ich auch so, aber das Lesen von Brilliant Marketing hat mir die Augen geöffnet.

Mir wurde klar, dass jeder Softwareentwickler eine persönliche Marke hat (dies gilt auch für andere Berufe). Diese Marke bestimmt, wie er von seinen Kollegen, Kunden und potenziellen Arbeitgebern wahrgenommen wird.

Siehst du meinen Punkt?

Wenn Sie Ihre persönliche Marke nicht aufbauen, werden diese Personen Sie nur als Softwareentwickler sehen. Es gibt viele Entwickler da draußen und Sie werden als einer von ihnen angesehen. Sie haben vielleicht den Ruf eines soliden Entwicklers, aber Sie sind im Grunde nur ein austauschbares Rädchen .

Wenn Sie andererseits Ihre Marke aufbauen, können Sie entscheiden, wie diese Personen Sie sehen. Sie können sich einen Ruf als Experte für etwas aufbauen und sich von der grauen Masse abheben . Denken Sie an Adam Bien. Er hat sich als Java-EE-Experte gebrandmarkt und sieht verdammt beeindruckend aus.

Wenn Sie sich zwischen Adam Bien und einem zufälligen Java EE-Entwickler entscheiden müssten, welchen würden Sie gerne in Ihrem Team haben?

Exakt. Deshalb ist Personal Branding so wichtig.

Dritter , Wenn Sie das Eigentum an gemeinsam genutztem Code fördern, sollten Sie erwägen, Autoreninformationen aus dem Quellcode zu entfernen. Stellen wir uns eine Situation vor, in der unser Team aus drei Entwicklern besteht:

• Jill ist eine Guru, die alles über Programmieren weiß, was man wissen muss. Sie ist eine Rockstar-Entwicklerin.
• Joe ist ein normaler Softwareentwickler. Er ist kein Guru, aber er kann definitiv soliden Code schreiben.
• Jim ist das „schwächste“ Glied unseres Teams. Er bemüht sich sehr, aber oft schadet er mehr als er nützt.

Was passiert, wenn ein neuer Typ namens Jack unserem Team beitritt und anfängt, Änderungen am Quellcode vorzunehmen?

Da Jack die Fähigkeiten der anderen Teammitglieder kennt, ist es wahrscheinlich, dass er Annahmen über die Qualität des Codes trifft, indem er die Autoreninformationen verwendet. Mit anderen Worten, wenn Jack bemerkt, dass der Code von Jim geschrieben wurde, nimmt er automatisch an, dass der Code beschissen sein muss (und so weiter).

Das ist gefährlich, weil alle Entwickler schlechte Tage haben können und alle Entwickler beschissenen Code schreiben können.

Jack hat wahrscheinlich keine Probleme, den von Jim oder Joe geschriebenen Code zu reparieren. Schließlich ist Jim ein Idiot und Joe ein durchschnittlicher Entwickler wie er selbst.

Was passiert, wenn er seltsame Dinge in dem von Jill geschriebenen Code bemerkt? Fühlt er sich wohl damit, es zu reparieren, oder nimmt er an, dass es einen Grund dafür geben muss, weil Jill es geschrieben hat? Ich würde mein Geld auf letztere Option setzen.

Das Entfernen der Autoreninformationen ist eine einfache Möglichkeit, dieses Problem zu lösen. Wenn Sie wirklich wissen müssen, wer einen bestimmten Code geschrieben hat, können Sie diese Informationen aus dem Versionskontrollsystem abrufen. Richtig?

Vierter , Manchmal ist etwas, was zu gut klingt, um wahr zu sein, wahr. Sich beruhigen. Ich spreche nicht von Ponzi-Systemen oder Multi-Level-Marketing. Ich spreche von Hazelcast. Wenn Sie noch nichts davon gehört haben, empfehle ich Ihnen, herauszufinden, was es ist.

Es sieht sehr interessant und einfach zu bedienen aus und hat auch sehr gute Erfahrungsberichte. Es wäre sehr interessant, Hazelcast in einem realen Softwareprojekt zu verwenden. Ich hoffe, dass ich dazu bald Gelegenheit bekomme.

Wenn Sie ein Spring-Entwickler sind, können Sie Hazelcast auch als Implementierung der Cache-Abstraktion von Spring 3.1 verwenden.

Fünfter , Wenn Sie keine Lust zum Programmieren haben, hilft Ihnen das Lesen von HackerNews nicht, die Arbeit zu erledigen. Die Chancen stehen gut, dass Sie, nachdem Sie alle interessanten Geschichten gelesen haben, zu DZone wechseln werden. Das kann zwar Spaß machen, ist aber nicht sehr produktiv.

Wenn Sie sich das nächste Mal so fühlen, befolgen Sie diese Schritte:

1. Unterteilen Sie die Aufgabe in kleinere Aufgaben und schreiben Sie sie auf.
2. Beende die erste Aufgabe auf deiner Liste.
3. Entfernen Sie die Aufgabe aus Ihrer Liste und gehen Sie zurück zu Schritt 2.

Mir ist aufgefallen, dass wenn ich keine Lust zum Programmieren habe, das Problem darin besteht, dass ich mich nicht auf eine "große" Aufgabe konzentrieren kann . Da ich mich nicht konzentrieren kann, ist es wirklich schwer anzufangen .

Wenn ich diese Aufgabe in kleinere umsetzbare Elemente aufteile, kann ich mich jeweils auf eine kleine Aufgabe konzentrieren , und ich weiß genau, was ich tun soll .

Außerdem liebe ich den Moment, in dem ich eine Aufgabe von meiner Liste entfernen kann. Das Beste an dieser Methode ist, dass die Aufgaben klein sind. Das bedeutet, dass ich ständig Punkte von meiner To-Do-Liste entferne!

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.