Als die erste russische Ausgabe des bekannten Buches „How to Graze Cats“ veröffentlicht wurde, das sich dem schwierigen Thema des unberechenbaren Managements durch Naturprofis und nicht sehr Softwareentwickler widmet, bemerkte mein erfahrener Kollege, der Projektmanager: „Es wäre richtiger, es„ How to Graze Cattle “zu nennen.“ . Der Satz wurde in Erinnerung behalten, und wie die Erfahrung, die seitdem im Umgang mit Programmierern gesammelt wurde, zeigt, hatte ein Kollege Recht.
Wie Nena- Programmierer ihre Kollegen sehen
Es gibt eine ganze Reihe von Artikeln über Habré, die sich mit Softwareentwicklungsmethoden, Kommunikation und Interaktion im Projektteam, Auswahl und Einstellung von Programmierern befassen. Ohne Übertreibung sammelt jeder dieser Artikel viele verärgerte Kommentare von Programmierern, in denen sie „Piemas“, Tester, Mitarbeiter der Personalabteilung, Analysten und Kunden beschuldigen - für alle, die sich einfach nicht für Mängel in einer bestimmten Methodik oder für Fehler in Projekten lieben. In Artikeln und in Kommentaren zu ihnen ist die vorherrschende Meinung, dass der Entwickler immer Recht hat. Die Verbreitung dieser Meinung ist unter anderem darauf zurückzuführen, dass Programmierer den größten Teil des Publikums in Habr ausmachen. Gleichzeitig arbeiten Spezialisten, die keine Programmierer sind, in Organisationen und Projektteams. Dieser Artikel drückt privat genau den Standpunkt der einen oder anderen Seite aus, die auf der anderen Seite der „Barrikaden“ gebildet wurde.
Heute, mein junger Freund, werde ich Ihnen die Welt mit den Augen Ihrer Kollegen beschreiben und Ihnen erzählen, wie Sie, der Softwareentwickler, der große und immer richtige Programmierer, ihnen in dieser Welt erscheinen. Sind Sie sicher, dass Sie wie Ihre Katze das Zentrum des Universums sind und dass jeder Ihnen vor dem Ende des Projekts einen
Sarg schuldet? Dies wird Ihrer Meinung unter anderem durch die quantitative Überlegenheit Ihrer Kohorte im Projektteam gestützt, aber tatsächlich in einer guten Hälfte der Projekte, in denen Sie, ein junger oder bereits grauer, aber immer noch nicht genügend geisteskranker Freund, der Rest des Teams ruhig ist hasst deine Allwissenheit und übermäßige Selbstgefälligkeit. Ihr Snobismus wird nur durch den exorbitanten und übermäßig aufgeblasenen Snobismus des Architekten blockiert, aber Sie werden ein anderes Mal über diese
Kaste sprechen.
Ein Business Analyst hasst Sie für die zeitaufwändigsten Teile von Spezifikationen, die angeblich aufgrund von Versehen nicht realisiert wurden.
Tester hassen Sie dafür, dass Sie den endgültigen Build 5 Minuten vor Ende des Arbeitstages mit Korrekturen ausrollen und ruhig nach Hause gehen. Sie müssen noch einige Überstunden am Abend damit verbringen, fünfzig Korrekturen und Regressionstests zu überprüfen, bevor sie morgen veröffentlicht werden.
Der Projektmanager hasst Sie dafür, dass Sie vom höchsten Glockenturm auf ihn gespuckt haben, denn Ihre Zukunft sowie Ihr Gehalt im Unternehmen hängen nicht von seiner Meinung und seinem Feedback ab, sondern nur von Ihrem direkten Chef, der fast immer einen Weg findet um dich vor deinem Versagen zu schützen. Natürlich hasst er Sie noch mehr als Tester, denn nachdem sie ihre Tests abgeschlossen und die Freigabe für die Veröffentlichung des endgültigen Builds erteilt haben, muss er um 11 Uhr abends noch die Erstellung der endgültigen Veröffentlichungsberichte für abschließen Bereitstellungs- und Wartungsteams für den Kunden.
Der Support-Service hasst Sie für den "selbstdokumentierten" Code und für die ständige Umgehung von Antworten auf ihre Fragen, auch wenn die Stunden für die Unterstützung des entfremdeten Codes in Ihrem Zeitplan in dem neuen Projekt, dem Sie zugewiesen sind, speziell zugewiesen sind.
Das Wichtigste zuerst.
Lebensweg eines gewöhnlichen Programmierers
Irgendwie habe ich nach einem
erfolgreichen Projekt mit Zustimmung des Leiters der Entwicklungsabteilung eine Präsentation für die Programmiergruppe vorbereitet, die unter anderem eine „Grafik“ enthielt, die den Lebensweg des Programmierers von Anfang an darstellt und im Schulalter im Notizblock codiert durch die Entwicklung integrierter Entwicklungsumgebungen (20 Jahre), das Fehlermanagement (25 Jahre) und die Interaktion mit anderen Gruppen von Spezialisten und externen Auftragnehmern (30 Jahre), bevor die Praxis der kontinuierlichen Integration und automatischen Entwicklung angewendet wird yvaniya Releases erreichte das
Aussehen von grauen Haaren 35 Jahren (Alter Meilensteine, natürlich bedingt, und dient nur der Weg des Lebens zu illustrieren gemittelt). Ein Programmierer ist wie kein anderer in der modernen Welt gezwungen, ständig technisch und beruflich zu lernen und sich zu verbessern, und sehr viele schaffen dies sehr. Gleichzeitig beginnen die meisten, die ihr erstes
Whistle-Fraud- Programm „Hello, World“ schreiben und einen Lebenslauf auf hh.ru / monster.com veröffentlichen, sofort, ihre Finger bei den Interviews zu spreizen und nennen sich stolz „ein echter Profi“. - das sind in der Tat nicht.
In diesem Projekt konnte ein Entwickler vergessen, den aktualisierten Code in ein gemeinsames Repository zu stellen, und zwei seiner Kollegen versuchten einen halben Tag im Extremmodus festzustellen, warum die Funktion nicht wie angegeben funktioniert. Ein anderer Entwickler hat einen Fehler im Bereitstellungsskript gemacht, und wenn der Projektmanager (!) Dies nicht bemerkt hätte, würde sich die Implementierung der Ergebnisse der Teamzusammenarbeit für die gesamte Iteration bis zum nächsten Zyklus der Codefreigabe in der Produktumgebung verzögern, d. H. für 2 Wochen.
Beide Spezialisten hatten mehr als ein Jahr Arbeit hinter sich, sie waren Profis in der Softwareentwicklung, d.h. Erhielt eine finanzielle Entschädigung für ihre Arbeit, codierte jedoch nicht "für sich selbst" oder in einem kostenlosen Open-Source-Projekt. Trotzdem haben sie Fehler gemacht, die "kindisch" sind, egal was sie sehen. Es ist eine bekannte Sache, jeder hat Fehler, nur wer nichts tut, mäht nicht. Aus diesem Grund wollte ich diese Präsentation für Entwickler erstellen, um auf der Grundlage meiner Erfahrung mit der Beratung verschiedener Projektteams zu zeigen, welche Problembereiche fast jeder Programmierer hat und was sie nicht im Bereich des Wissens über eine bestimmte Programmiertechnologie liegen, sondern in Verwandte Bereiche, in denen MUD, Designer und Zerstörer so beliebt sind und Fähigkeiten beginnen, mit Anforderungen, Werkzeugen, Fehlern, Planung usw. zu arbeiten. Wenn Sie sich also beim Lesen eines Artikels in einem der oben genannten Beispiele versehentlich wiedererkennen und nach dem Lesen entsprechende Schlussfolgerungen ziehen und es schaffen, „über sich selbst zu wachsen“, werden andere Sie zu Recht als Fachmann auf ihrem Gebiet sehen und sich darüber freuen die mit Ihnen im selben Projekt und Team arbeiten.
Interaktion mit Nicht-Programmierern
Lassen Sie sich wissen, mein geschickter Freund, dass andere Spezialisten, mit denen Sie im Projektteam zusammenarbeiten, wie Tester, Analysten, technische Redakteure, Designer und andere, nicht weniger für den Erfolg des Projekts verantwortlich sind als Sie
, oh Wunder des Universums . Und all diese Nichtmenschen spielen eine nicht geringere Rolle und in einigen Projekten sogar eine größere Rolle als Ihre Rolle als Encoder. Daher ist eine kompetente und wohlwollende Interaktion mit ihnen ein wesentlicher und wichtiger Bestandteil Ihrer Arbeit, für die Sie zweimal im Monat eine Menge Geld von einem Geldautomaten erhalten (bis mit einem Wort - das Geld ist
viel größer als all diese Leute am selben Geldautomaten). Sie betrachten sie und ihre Designanforderungen oft von oben oder durch Ihre Finger, ohne die Aufmerksamkeit, die sie zu Recht verlangen. Und sie haben Bedürfnisse und berufliche Erwartungen und verschiedene, abhängig von ihren Rollen.
Der Analyst erwartet beispielsweise, dass Sie nicht nur über und ohne jeden Buchstaben in den Spezifikationen streiten, sondern diese auch gewissenhaft in Programmcode übersetzen. Und dass Sie keine Schutzbrille tragen, wenn Sie beim Testen gefragt werden, warum Sie die Schlüsselfunktion, die in der morgigen Version enthalten und in den Anforderungen festgelegt war, nicht implementiert haben, bevor Sie vor einem Jahr in das Projektteam berufen wurden, immer da und seitdem hat sich kein einziger Buchstabe geändert.
Der Tester hat das Recht, von Ihnen ein fehlerfreies Qualitätsergebnis Ihrer Arbeit zu erwarten. Als sie eingestellt wurde, wurde ihr versprochen und sie erwartet daher, dass sie nicht Teil der TDD-Entwicklungsmethode sein wird, nach der Sie, MUD, das unfertige Produkt in Tests „werfen“ und gemäß den Ergebnissen die fehlenden Funktionen fertigstellen und offensichtliche Mängel beheben. Und die Testerin erwartet mit Sicherheit, dass Sie keine Fäulnis verbreiten, weil sie nicht weiß, wie sie das Produkt anders als manuell testen kann, oder dass ihre Fähigkeiten im Umgang mit der Datenbankabfragesprache viel geringer sind als Ihre. Vergessen Sie am Ende nicht, dass sie für manuelle Tests um ein Vielfaches weniger bezahlt wird als Sie für das Programmieren, und dass sie, wenn sie SQL so gut kennt wie Sie, auf Ihrem Stuhl vor Ihrem Monitor sitzt und nicht Sie, denn bei gleichen Qualifikationen zwischen Ihnen würde sie es vorziehen, sie im Team und in der Organisation zu belassen, denn im Gegensatz zu Ihnen wird sie, nachdem sie den schwierigen Weg eines Testers durchlaufen hat, niemals so viel Fäulnis auf ihre Kollegen übertragen wie Sie.
Technische Kenntnisse der Technologie
Haben Sie das
Kindergarteninstitut bereits abgeschlossen und erklären in den Interviews erfolgreich, wie sich der Designer vom Destruktor unterscheidet? Ich werde Ihnen ein Geheimnis verraten, dass die Berufswelt beim Erstellen von Software nicht auf dieses Wissen beschränkt ist. Wenn Sie weiterhin der Meinung sind, dass geschriebener und irgendwie ausführbarer Code als Ergebnis Ihrer Arbeit ausreicht, um
vom Projektmanager / Kunden nicht zweimal im Monat sn
zu erhalten, sind Sie dabei In Ihrer zukünftigen Karriere werden Sie viel mehr Probleme auf Ihrem eigenen Kopf haben, und vor allem werden Sie eine Quelle anhaltender Kopfschmerzen für alle sein, die nicht das Glück haben, in Ihrer Nähe zu arbeiten.
"Versionierung? Code auskommentieren? Einhaltung von Kodierungs- und Namensstandards? Nein, ich habe es nicht gehört! " Sagen Sie also Ihre Kollegen hier und hier in einer Vielzahl von Projektteams und Organisationen. Junger Freund, Sie jammern über alles, was nicht direkt mit „Code Jabbering“ zusammenhängt: die Notwendigkeit, Kommentare hinzuzufügen, den Code mit Blocktests gemäß den im Unternehmen oder in der Abteilung festgelegten Standards abzudecken, Repository-Zweige zusammenzuführen ... Was können wir dazu sagen? komplexere Dinge, die fortgeschrittene oder wirklich hochqualifizierte erfordern: Testautomatisierung, Implementierung und Unterstützung für die kontinuierliche Integration, Einrichtung von Bamboo-Cucumber-Maven-Puppet-Bundles und viele Stunden Suche in Systemprotokollen bei der Suche x Hinweise auf Softwarefehler - all dies ist für Sie Langeweile und Rückstände, die es Ihnen nicht ermöglichen, Ihre Codierungsfähigkeiten direkt zu verbessern, und die Ihre FAQ herabsetzen. Wenn Sie sich weigern, bestimmte Hardware zu verwenden, verbergen Sie als professioneller Softwareentwickler häufig einfach Ihre Unfähigkeit, diese zu verwenden. Ich erinnere mich an die Reaktion und das Gesicht eines Programmierers, der als Versuch, einen schwer zu findenden "schwebenden" Defekt zu erkennen, die Verwendung des in die IDE integrierten Profilers vorschlug: Mir wurde gesagt, dass dies nicht die Aufgabe des Projektmanagers sei, zu beraten, welche Tools der Programmierer für seine Arbeit verwenden sollte.
Werkzeugfertigkeiten
Wie automatisiert ist Ihre Arbeit auf Ihrer Workstation? Haben Sie Ihre Fähigkeiten in der Arbeit mit regulären Ausdrücken, der Erstellung und Ausführung von Batch-Dateien verbessert? Können Sie auf Wunsch eines Kollegen, Testers, Analysten oder Kunden in 3 Minuten ein paar hunderttausend Protokollzeilen auf einem Remote-Server analysieren, den erforderlichen Eintrag für den Schlüsselparameter finden, die Ausgabe packen, an die angegebene Adresse weiterleiten und zur unterbrochenen Aufgabe zurückkehren? Wie schnell, MUD, wissen Sie, wie man Routineoperationen ausführt, die eine wiederholte Wiederholung während des Arbeitstages erfordern?
Wie Sie wissen, können Sie die Kompilierung in modernen Entwicklungsumgebungen starten, indem Sie F5 (oder F6? Oder F13?) Drücken. Warum muss ich als Projektmanager am Ende solche Dinge wissen? Sie wissen nicht, MUD, wie schnell, in ein paar Minuten Entladen Sie es von Jira, formatieren Sie es ordnungsgemäß in Excel und senden Sie dem Kunden eine E-Mail über den
Fehlerbericht mit
Blackjet- und Huren- Diagrammen und -Trends weiß, wie sich der Destruktor vom Konstruktor unterscheidet). Aber für eine ziemlich lange Karriere habe ich nicht so viele Programmierer getroffen, die Tastaturkürzel auf der Tastatur verwenden, um bestimmte Standardaktionen aufzurufen - die meisten von ihnen verwenden den langsameren "Maus" -Manipulator. Bedingt "Tab - 1000 - Tab - 1 - Tab - 0 - Tab - Rücktaste - 2 - Strg + S - Strg-F6 - Eingabe, Alt-Tab, F5" in 6 Sekunden ermöglicht es einem echten Profi, das zu tun, indem er mit der Maus schnippt und stochert Mit Zeigefingern auf der Tastatur macht ein langsamer fünf lange Minuten. Und wenn solche Vorgänge hunderte Male am Tag ausgeführt werden, möchte ein anderer Projektmanager im Kontext einer sich nähernden Frist manchmal einen solchen „Fachmann“ von der Tastatur entfernen und Änderungen vornehmen / den ausführbaren Code kompilieren / auslegen und der Testgruppe den Startschuss geben Der Neubau ist endlich fertig.
Seien Sie daher nicht faul und verbringen Sie Zeit damit, den blinden Zehn-Finger-Druck und die Methoden des effektiven Arbeitens mit Werkzeugen zu beherrschen, und glauben Sie erfahreneren Menschen, auch wenn einige von ihnen von Ihren Projektmanagern so ungeliebt sind - diesmal zahlt sich dies aus. In der Zwischenzeit haben Sie, junger ungeschickter Mann, noch nicht die Perfektion erreicht. Gehen Sie, vergraben Sie sich auf dem Monitor und schreiben Sie den Code, Bl ..!
Arbeitsbewertung
Sie können es nicht ertragen, wenn der Projektmanager in den heiligen Prozess des "Schreibens von Code" eingreift. Gleichzeitig werden Sie sich jedoch niemals das Vergnügen verweigern, einen ätzenden Kommentar zu „unrealistischen“ Fristen, „undichten“ Anforderungen, vorzeitigen Änderungswünschen und inkompetenten Projektmanagern abzugeben. Wenn sie sich im Rahmen einer bestimmten Methodik an Sie wenden, um eine Expertenmeinung zur Bewertung der Arbeitskosten für die nächste Iteration oder für das gesamte Projekt zu erhalten, machen Sie ein überraschtes Gesicht und beginnen, „Ausreden“ über unverständliche oder unvollständige Spezifikationen, unbekannte Technologien und das überhaupt nicht Ihre Sache zu machen Um zu planen, haben Sie keine Zeit für "Bullshit" und sollten lieber das Richtige tun - Code schreiben. „Schätzung der Arbeitskosten nach der Methode der Funktionspunkte? In Analogie zu früheren Ergebnissen? Basierend auf der Anzahl der Bildschirmformulare und Datenbank-E / A-Anforderungen? Nein, ich habe es nicht gehört! "
Daher, ein junger Freund, schweigen Sie entweder in einem Lappen, wenn es nicht Ihre Aufgabe ist, die Arbeit im Projekt zu planen, oder verbessern Sie Ihre eigenen Fähigkeiten, um wirklich Expertenbewertungen abzugeben, und nicht mit dem Finger am Himmel. Und bis du das letzte
gemeistert hast -
IPKB !!!
Hindu-Code
Eine Ihrer Lieblingsbeschäftigungen ist es, von indischen Entwicklern erstellten Softwarecode zu kritisieren. Füttere dich nicht mit Brot, sondern lass uns uns über den "Pasta" -Programmierstil lustig machen. Sie diskutieren nicht nur über den „Hindu“ -Code, sondern unterhalten sich auch gerne über Technologie (siehe unten). Und das alles trotz der Tatsache, dass Sie selbst Methoden den stolzen Namen kolbasa () nennen, kopieren Sie unvergesslich Codeteile an verschiedene Stellen im Programm und erstellen Sie Klassen mit der Größe von einem Dutzend oder zwei Bildschirmen.
Aufgrund der Bedeutungslosigkeit Ihrer eigenen Berufserfahrung, MUD, ist Ihnen nicht bewusst, dass die
Scheiße, die Sie selbst schreiben, oft nicht besser und manchmal schlechter ist als der Code, den Ihre südlichen Kollegen erstellen. In jedem Land gibt es traurige Programmierer, "urteilen Sie nicht, lassen Sie uns nicht beurteilen", und echte Profis, ich werde Ihnen ein Geheimnis verraten, MJD, gehen Sie nicht auf nationaler Ebene dem Vorwurf ihrer Kollegen nach und verbessern Sie langsam ihre eigenen Qualifikationen und ihre eigene Zeit. Sie sind für die Erstellung eines Softwareprodukts vorgesehen und geben direkt für die Programmierung aus und nicht für die Suche nach
Strohhalmen in den Augen anderer, wenn ein Fehler im Code eines anderen vorliegt.
Endlose Technologiediskussion
Sie diskutieren endlos mit anderen Programmierern, was Java ++ C ## überlegen ist oder welche Versionsnummer einhundertneunundzwanzig Bruchteil fünfzehn einer Javascript-Bibliothek besser ist als Version einhundertneunundzwanzig Bruchteil dreizehn. Solche Diskussionen werden Ihnen selbst in den Tagen, in denen 2-3 Tage oder Wochen vor dem Ende einer Iteration oder eines mehrmonatigen Projekts verbleiben und die Anzahl der Ihnen zugewiesenen nicht korrigierten schwerwiegenden Fehler mehr als fünfzig beträgt, nie leid tun.
Sie tun dies ohne Gewissensbisse während der Arbeitszeit und nicht freitagabends oder am Wochenende für ein Glas Bier. Sie sind in ein solches Geschwätz verwickelt, obwohl die Frage der Auswahl und Verwendung der einen oder anderen Technologie in einem Produkt außerhalb Ihres Kompetenzbereichs liegt (weil die Größe Ihrer Kompetenz, MJD, einfach noch nicht erwachsen ist), aber Sie verbringen immer noch Zeit mit Ihrem Arbeitgeber und Projekt auf unproduktiven Trepot.
Jammern über "unnötige" Rallyes
Als ich, nachdem Sie gerade
Ihre Zeit mit Reden
verbracht hatten , 2 Stunden lang in der Küche / im Raucherzimmer mit einem halben Dutzend der gleichen Scheißcodierer über das neueste Framework / die neueste Pressekonferenz von Google-Microsoft-Apple-Linus Torvalds sprach, stahl ich dann ein paar Leute. Tage der Entwicklung erklären Sie plötzlich bei der Analyse der abgeschlossenen Iteration, dass zu viele unnötige Besprechungen im Projekt stattfinden und Sie diese verkürzen müssen - als Reaktion darauf möchten Sie nur eines schreien:
Halt die Klappe und
IPKB !!!
Russisch lesen und schreiben
Nun, am Ende, wie sie sagen, das letzte, aber alles andere als unwichtigste. , , , C## — - ( - , XXI ). , , , -
— , ..! ,
_ — , .
tsya.ru , «» — , "
" «» — , «
», ..!!111
Nachwort
, , , , , . ! , , , - ,
.
Ergänzung
: ? , , , .
, , , . , - 10 . 3 , , , , , “” 3 .
: 1 3 3 1. , . , “
” ( “”). , , , , , .
“
” , , , “”, , . , , , , “, , , , , XYZ , , ( / / )!”.
, “”, “
”, , : , , , , ( ), “”.
.