Fünf beängstigende Trends des modernen Designs

Gewohnheit ist eine schreckliche Kraft. Es lässt Sie Veränderungen widerstehen, es behindert die Entwicklung. Aber in der IT lieben wir es, an der Spitze der Technologie zu stehen, wir lieben Herausforderungen, wir lieben es, das umzusetzen, was sich in nur wenigen Jahren auf andere Bereiche ausbreiten wird.

Wir sind bereit für das Neue und dürfen nicht warten, bis die Zukunft kommt, und wir müssen uns darauf einstellen. Wir können vorwärts gehen, nur um zu wissen, in welche Richtung.

Egor Bugaenko weiß, was jetzt zu tun ist, um in 5 bis 10 Jahren ein gefragter Programmierer zu bleiben. Seine Ideen mögen wie immer kontrovers erscheinen. Sie müssen ihnen nicht unbedingt zustimmen, aber wenn Sie beispielsweise über das Haustierprojekt nachdenken, wird dies nicht noch einmal schaden. Und die Tatsache, dass der Programmierer Englisch braucht, kann kaum unterschiedliche Meinungen geben. In den verbleibenden Punkten wird es jedoch interessant sein, die Meinung der Community in den Kommentaren zu kennen.



Als nächstes folgt die Textversion von Egors Bericht über AppsConf , aber er bezieht sich nicht nur und nicht so sehr auf die mobile Entwicklung, sondern auf die gesamte Branche. Egor Bugaenko, Gründer von Zerocracy, Entwickler von Cactoos, Takes Framework, JCabi und anderen Open Source-Projekten. Er schrieb eine Reihe von Büchern mit dem Titel „Elegante Objekte“, unterhält einen provokanten Blog und gibt zum Nachdenken anregende Berichte wie diesen.



Ich beginne mit einer Geschichte darüber, wie ich mich vor nicht allzu langer Zeit entschlossen habe, Software für mobile Geräte zu entwickeln, und schnell kollidierte, dass ich nicht wusste, wie ich das machen soll. Aus diesem Grund habe ich mich entschlossen, jemanden um Hilfe zu bitten, der mir erklärt, wie ich eine Anwendung in vollständig gepackter Form erstellen kann. Erstellen Sie also eine Anwendung, die im Apple Store verfügbar sein wird.

Ich habe mich gefragt, wie ich die Anwendung in einem Paket zusammenstellen kann, dh nicht nur einige Schaltflächen auf dem Bildschirm zeichnen, sondern eine gesamte Anwendung erstellen kann . Offensichtlich sind der Code zum Beispiel bei Swift und das Produkt auf dem Mobiltelefon zwei völlig verschiedene Dinge: Der erste ist sehr klein und der zweite ist sehr groß und enthält solche Fragen:

• Unit-Tests
• statische Analyse;
• Kontinuierliche Integration
• Abhängigkeitsmanagement;
• Kontinuierliche Lieferung;
• Staging-Umgebung;
• App-Genehmigungsprozess im Apple Store
• Prozess der Montage von Fehlern aus der Produktion usw.

Das Anordnen der Schaltflächen auf dem Bildschirm ist im Internet leicht zu lesen. Ich brauchte einen Spezialisten, einen Experten, der mir beim Aufbau der gesamten Pipeline helfen würde. Für mich als Programmierer ist dies wichtiger als das Anordnen der Schaltflächen auf dem Bildschirm.

Ich habe einen solchen Spezialisten gefunden, aber er sagte mir: „Warum denkst du darüber nach? Zeichnen Sie zuerst die Anwendung. Was ist kontinuierliche Integration? Warten Sie, bis mit Unit-Tests - es funktioniert. Was ist eine Lieferpipeline? Warum TestFlight - benutze einen Simulator. "

Sicher ist er ein guter Programmierer, aber in seinem Kopf ist meiner Meinung nach alles auf den Kopf gestellt . Er hält den Code für wichtig und der Rest der Verpackung ist zweitrangig. Meiner Meinung nach ist dies ein großes Problem, und ich möchte darüber sprechen.

Aus irgendeinem Grund glauben viele Entwickler, dass der Code selbst wichtig ist, und die Montage ist das, was der DevOps- Ingenieur oder jemand anderes tut. Wenn Sie zu einem Team kommen, ist dies normalerweise bereits erledigt und konfiguriert. Sie befinden sich in einem Projekt, in dem Sie Code schreiben, ohne zu wissen, wie alles in der Produktion endet. Ich glaube, dass die Tatsache, dass Programmierer nicht den gesamten Montagezyklus sehen und nicht wissen, wie es funktioniert, ein Problem ist.

Zuerst bereitstellen, dann codieren

Ich schreibe Bücher über Programmierung und ich weiß selbst, dass ein Buch gut funktioniert, wenn Sie es zuerst schön gestalten . Das heißt, ich entwerfe das Buch, bevor ich schreibe. Zuerst erstelle ich ein Makefile, das direkt über die Kommandozeile das gesamte Buch aus Dateien auf LaTeX sammelt, Texte, Bilder und Cover-Art vorbereitet. Ich verbringe viel Zeit und mache es so, dass mit einem Befehl das gesamte Buch in einer PDF-Datei gesammelt wird. Ich achte sehr darauf, wie es aussehen wird, wo die Einrückungen sind, welche Textblöcke und der Abstand zwischen ihnen, wie die Seiten nummeriert werden. Wenn mir das alles gefällt, sehe ich, dass alles wunderschön zusammengesetzt und alles in diesem Produkt vollständig ist, auch wenn bisher nur eine Seite geschrieben wurde. Erst dann beginne ich ein Buch zu schreiben, und erst dann macht es mir Freude.

Meistens machen Programmierer das Gegenteil: Sie schreiben, laufen auf dem Simulator, überprüfen die Arbeit. Ich glaube, dass es richtiger ist , zuerst zu implementieren, dann Code .

Ich werde noch ein Beispiel geben. Ein unerfahrener Entwickler hat sich freiwillig bereit erklärt, ein Open-Source-Projekt mit uns durchzuführen. Er entschied sich für Flutter, machte die erste Iteration, startete sie, sagte, dass alles cool und cool sei, und bot an, nachzuschauen. Wir fragen: „Wie probiere ich etwas aus? Hier ist das iPhone - wohin soll man schieben? " Was er zu erklären begann, wohin er gehen sollte, was er herunterladen sollte, war ein langer Prozess.

Dies schien uns unangenehm und am Ende stimmte er zu, dass die Anwendung wirklich auf TestFlight hochgeladen werden muss. Nach einiger Zeit zeigte er die Anwendung auf TestFlight. Ich drückte die Knöpfe und bemerkte einige Mängel. Ich habe nicht mit Flutter gearbeitet und wollte es nicht wirklich, aber ich wollte schnell beheben, was mir aufgefallen ist. Ich fragte, wie das geht, wohin und wie man eine Pull-Anfrage sendet. Ich öffne das Repository, Readme-Datei: "Dies ist eine coole Anwendung ... klicken Sie auf Download ...".

Die Anweisungen waren kompliziert und unverständlich. Ich fragte erneut, wie ich all dies auf meinem Computer bereitstellen sollte. Ich wollte nur den Code einer anderen Person mit einem einfachen Klick auf einige Schaltflächen auf meinem Computer ändern, den Simulator starten und eine Pull-Anfrage senden. Dieser Typ hat alles beschrieben und ist nie zurückgekommen.

Diese Situation zeigt, dass seine Qualitäten als Programmierer gut sind - er konnte die Anwendung ausführen. Aber seine Qualitäten als Person, die das ganze Projekt sieht, lassen zu wünschen übrig. Infolgedessen verlor das Projekt nicht nur mich als Mitwirkenden, sondern auch viele andere. Dieser Programmierer erhielt keine Rückgaben von anderen, er arbeitete wie ein Einzelgänger.

Meiner Meinung nach ist es momentan falsch, einsam zu sein . Der Markt bewegt sich in Richtung größerer Teams: Es werden mehr Leute in ihnen sein, sie werden öfter kommen und gehen.

Die Dynamik der Humanressourcen bewegt sich in Richtung eines höheren Umsatzes, daher muss jede Person, die erneut zum Projekt kommt, es in seiner Gesamtheit sehen - nicht nur den Code, der auf den Simulatoren ausgeführt wird.

Ein Neuling sollte in eine Umgebung gelangen, die aus Sicht der Montage für ihn freundlich ist - er muss eine Readme-Datei öffnen und in wenigen Minuten verstehen, wie alles auf dem Simulator startet. Was Sie anklicken müssen, um zu überprüfen, ob alles über die Befehlszeile erstellt wurde - nicht über komplexe IDEs, die mehrere Stunden lang konfiguriert werden müssen. Es sollte möglich sein, make / build / etc in die Kommandozeile zu schreiben. Danach wird alles gesammelt und eine grüne Linie gedruckt - alles ist fertig - und dann die Anfrage ziehen. Dies ist der erste Gedanke, den ich heute teilen möchte.

Natürlich werden Sie sagen, dass Sie nicht alleine arbeiten, nicht als alleinige Gründer von Projekten, nicht als CTO. Sie arbeiten in Teams und können nicht einfach sagen, dass Sie sich jetzt mit der Bereitstellung TestFlight befassen und CI dringend verstehen müssen. Dies ist nicht Ihre Aufgabe, Sie erhalten keine Zeit dafür usw.

Daher empfehle ich Ihnen, Ihre eigenen Haustierprojekte durchzuführen - Projekte, die Sie zu Ihrem eigenen Vergnügen durchführen -, um alles in seiner Gesamtheit zu verstehen.

Nur 20-30% der Programmierer haben ihre eigene veröffentlichte Anwendung, und jeder sollte sie haben. Wenn Sie sich selbst in Betracht ziehen und ein gefragter Programmierer sein möchten, würde ich empfehlen, Ihre mobile Anwendung zu erstellen und den gesamten Zyklus ihres Markteintritts zu durchlaufen: Überprüfungen im Apple Store, CI, Verpackung und allem anderen. Machen Sie es Open Source, damit die Leute dazu beitragen und Ihnen zeigen können, wie sie versagen.

Sehen Sie, wie Sie mit dem Markt arbeiten, und versuchen Sie zu verstehen, welche Art von Programmierern Sie sind. Ich denke, dass ein Programmierer, der keine Haustierprojekte hat, schlecht ist.

Entweder interessiert er sich nicht für seinen Beruf oder es ist ihm egal, er kann es nicht oder er hat Angst. Es ist eine Angst, den gesamten Zyklus zu sehen. Wir haben Angst, das Projekt als ein Produkt zu betrachten, das für den Kunden bereit ist. Und der Client für uns ist in vielen Fällen ein anderer Entwickler, da ich in meinem Beispiel ein Client-Entwickler bei Flutter war.

Die zweite Angst ist meiner Meinung nach Geld.

Wie viel Code werden Sie für 100 US-Dollar schreiben?

Ich arbeite mit vielen Programmierern auf der Zerocracy-Plattform zusammen und habe festgestellt, dass sie sehr oft Angst vor Geld haben. Sie sind es gewohnt, am Ende des Monats zu zahlen, und sie sind ziemlich schmerzhaft, wenn sie in Geld bewertet werden. Viele können die einfache Frage nicht beantworten: "Wissen Sie, wie viel Sie Code für 100 Dollar machen können?"

Sicher wissen Sie, wie viel Sie pro Monat verdienen möchten. Stellen Sie sich vor, wie viel ein voller Monat Ihres Lebens kostet: eine Wohnung, ein Auto, regelmäßige Zahlungen, das übliche Maß an Komfort und Unterhaltung.

Vollzeit-Entwickler mit fester Bezahlung haben keine Zeit mehr.

Ich denke, wir werden immer mehr in vorübergehend versammelten Teams arbeiten, in denen Leute kommen, während sie gebraucht werden, und danach weiter gehen. Die Ära der Entwickler, die an einem Ort sitzen, geht zu Ende, weil das Unternehmen sie vor vielen Jahren eingestellt hat. Sie lieben dieses Unternehmen einfach und sind deshalb dabei - es spielt keine Rolle, welche Technologie das Unternehmen verwendet.

Ich kenne Beispiele für solche Projekte, die viele Jahre in C ++ geschrieben wurden und dann erkannten, dass sie in Java schreiben mussten. Und die gleichen Leute, im gleichen Büro, für den gleichen Geldwechsel für Investoren, trainieren ein halbes Jahr lang neu und fangen an, wackelig zu werden und in Java zu rollen. Dies ist ein Ansatz aus der Vergangenheit. Meiner Meinung nach werden solche Ansätze in Zukunft nicht mehr existieren, weil sie keinen Sinn ergeben.

Der Markt wird global , der Fernzugriff auf den Arbeitsmarkt wird immer einfacher. Ein in Moskau ansässiges Unternehmen wird uninteressant und unrentabel sein, um Menschen beispielsweise von iOS auf Android oder von C ++ auf Java umzuschulen. Es ist einfacher, neue Spezialisten einzustellen, die als Freiberufler kommen, die Aufgabe erledigen und gehen.

Ich denke, dieses Format von Projekten wird beliebt sein: temporäre Projekte, bei denen sich Freiberufler treffen, ihre Aufgaben ausarbeiten - ein Experte in diesem Bereich, ein anderer Experte in diesem Bereich und verlassen das Projekt.

Von Programmierern erwartet diese neue Zeit:

• Die Fähigkeit zu verstehen, wie viel Sie wert sind. Geben Sie also eine Schätzung an, wie viel Ihre Arbeitsstunde wert ist und wie viel Wert Sie dafür schaffen werden.
• Fähigkeit, unter vorübergehenden Bedingungen zu arbeiten.
• Fähigkeiten, sich selbst zu verkaufen, richtig präsent. Ein freiberuflicher Entwickler auf dem Weltmarkt muss einen „Handelsvorteil“ und einen Preis haben.

Viele Menschen haben Angst, Lebensläufe zu erstellen, Angst, sich selbst zu verkaufen. Wie gesagt, ich denke, dass die Zusammenfassung definitiv das Haustierprojektelement enthalten sollte.

Eigene Projekte sind der erste Wertindikator auf dem Markt und nicht dort, wo Sie Software entwickelt haben, die Sie 5 Jahre hintereinander geerbt haben. Sie erstellen ein Pet-Projekt von Grund auf neu und es spielt keine Rolle, worum es geht, wie kompliziert es ist oder wie viele Downloads es im Apple Store hat. Lassen Sie es 0 Likes und 2 Downloads sein, aber dies ist ein integrales Projekt, das Sie selbst erstellt haben.

Für mich als Arbeitgeber sind solche Menschen wertvoller als diejenigen, die seit vielen Jahren im Büro sind und einen Lebenslauf bei einem oder zwei Arbeitgebern haben. Es fällt mir schwer zu verstehen, was ich mit dieser Person machen soll und wie ich sie bewerten soll. Ich weiß, dass er möchte, dass ich es den ganzen Monat nehme und mit ihm befreundet bin, unabhängig vom Ergebnis. Für mich ist dieses Format jetzt inakzeptabel, für eine große Anzahl von Arbeitgebern wird es in Zukunft auch unangenehm sein.

Daher wird empfohlen, Geld zu zählen und an Verträgen zu arbeiten . Vielleicht passt das nicht ganz zu Ihren Arbeitgebern, aber versuchen Sie, Vollzeit zu arbeiten und im Büro zu sitzen und gleichzeitig nach Mikroprojekten für einen Teilzeitjob zu suchen. Nicht um des Geldes willen, sondern um zu verstehen, ob der Markt Sie als Freiberufler braucht oder nicht, ob Sie ihn als Experten brauchen oder nicht. Oder Sie brauchen nur Ihren Chef, der Angst hat, Sie zu verlieren, weil nur Sie wissen, wie der Projektcode funktioniert.

Nach Alternativen suchen, sehen, versuchen, verkaufen . Zuerst werden Sie nicht gekauft, es wird Probleme geben - viele Probleme! Wenn Sie diese Probleme lösen, werden Sie zu einem gefragten Programmierer auf einer höheren Ebene.

Leider können nicht nur Programmierer selbst den Arbeitspreis bestimmen, sondern auch Kunden. Manchmal schlagen sie vor, dass ich bestimmte Aufgaben als Experte ausführe. Und oft versteht der Kunde, der mir einen Job anbietet, nicht, wie er mich bewerten soll. Meistens wollen die Leute nur billiger, wie 50 Dollar, nicht 100 Dollar pro Stunde. Ich verstehe, dass eine Person mit diesem Ansatz immer noch nicht versteht, wie viel ich in dieser Stunde in Echtzeit schreibe. Dann stimme ich zu und multipliziere einfach die Anzahl der Stunden mit 2. Als Ergebnis bekomme ich so viel, wie ich ursprünglich wollte.

Ich kenne meinen wahren Wert und meine Geschwindigkeit. Kunden sind nicht bereit für Beträge von 100 bis 500 US-Dollar pro Stunde, für sie sind 20 bereits eine Menge, da sie im Laufe der Zeit an das Vollzeitbeschäftigungsformat gewöhnt sind. Das heißt, wenn eine Person Geld für die Zeit erhält, die sie angeblich für die Entwicklung ausgibt.

Ich weiß nichts über dich, aber ich kann nicht 8 Stunden lang Code schreiben. Ich bin sicher, dass jeder von Ihnen bestätigen wird, dass Sie von 8 Arbeitsstunden, die Sie im Büro oder am Computer verbringen, tatsächlich viel weniger Code schreiben. Und sie zahlen für diese 8 Stunden, und der Kunde glaubt, dass es 8 Stunden Arbeit sind. Dies ist ein System der doppelten Täuschung: Sie sind froh, getäuscht zu werden, und wir täuschen sie. Daher verwende ich den Multiplikationsfaktor. Ich werde mindestens 20 arbeiten, aber dann mache ich 3 Wochen, was ich wirklich in 2 Stunden tun kann.

Bringen Sie Ihren Kunden bei und lernen Sie, wie Sie selbst Geld zählen.

Gute Programmierer schreiben Code, die besten - Tickets

Sowohl Kunden als auch Programmierer sind an informelle Kommunikation gewöhnt.

Informelle Kommunikation in Form von Chats, Telefonanrufen, Kundgebungen und E-Mails ist eine Form der Kommunikation, die das Projekt zerstört und den Kunden und den Programmierer nur noch schlimmer macht.

Informelle Kommunikation bleibt in der Luft, sie wird nicht in der Dokumentation aufgezeichnet, wird nicht überwacht, dann ist es schwierig, dorthin zurückzukehren, und es macht es schwierig, das Projekt aufrechtzuerhalten. Wenn sich ein Team ändert und wie ich bereits sagte, muss sich das Team ändern und wird sich intensiver ändern. Es wird sehr wichtig, wie verständlich die früheren Kommunikationen im Projekt sind.

Wenn ich zu einem Entwicklungsprojekt komme, möchte ich verstehen, was im letzten Jahr getan wurde, nicht nur in Form von Code, sondern auch eine Erklärung für diesen Code haben: Warum ein solches Framework oder ein solcher Algorithmus gewählt wurde, der bereits seine Meinung zu diesem Algorithmus geäußert hat und ich stimmte nicht zu. Ich möchte das alles sehen und nicht im Büro suchen oder nach jemandem chatten, der mir alles erklärt. Ich brauche die Möglichkeit, dies direkt im Repository oder im Ticketsystem zu lesen.

Leider folgen Programmierer meistens dem Beispiel der Kunden. Natürlich im Interesse des Kunden die Möglichkeit einer informellen Kommunikation mit dem Entwickler zu haben. Und wir sind schwach genug und folgen ihrem Beispiel, hören am Telefon zu, was zu tun ist, antworten, hören, antworten ... und dann machen wir es.

Dann vergehen 2-3 Wochen und wir erinnern uns nicht mehr daran, worauf wir uns geeinigt haben. Der Kunde sagt, dass er dies nicht wollte. Wir versuchen zu beweisen, dass dies das ist, was er angefordert hat. Wir suchen nach einer Erwähnung im Chat - der Flohfang beginnt.

Ich denke, der Grund ist die Angst vor Ticketsystemen. Viele Programmierer, mit denen wir zusammenarbeiten (das betrifft Sie natürlich auch), wissen nicht, wie, mögen nicht, wollen keine Aufgaben in Form eines Tickets formulieren - klar und prägnant.

Es fällt den Leuten leichter zu sagen: "Lass uns reden!" Wir werden eine Kundgebung abhalten, uns zusammensetzen und alles entscheiden. In 3 Stunden werden wir uns verstehen und dann werde ich es codieren. Ich werde mich daran erinnern, worauf wir uns geeinigt haben, und alles programmieren. “ Vergiss nichts, triff dich wieder. Und so werden wir uns irgendwie von Rallye zu Rallye erstrecken.

Das ist nicht richtig. Wir als Programmierer müssen jede informelle Kommunikation in Tickets umwandeln. Wir haben mit dem Kunden (Kunde, Product-Owner, einem anderen Programmierer) gesprochen und herausgefunden, was geändert werden muss. Wir wandeln jede Kommunikation in ein Ticket um, das durch das Framework unseres Systems (Jira, GitHub usw.) begrenzt ist. Dort schreiben wir auf: Was funktioniert nicht, wie Sie müssen es reparieren, warum Sie es reparieren müssen, welche Motivation, und dann arbeiten wir an diesem Ticket.

Die Unfähigkeit eines Programmierers, die Arbeit in Tickets zu strukturieren, kann auf seine geringen Qualifikationen hinweisen. Ich glaube, dass es zwei Arten der Entwicklung gibt:

• Kontinuierliche Entwicklung - Programmierung von 9 bis 17 Uhr: Ich bin angekommen, habe den Computer eingeschaltet, dann habe ich etwas gemacht, dort, Mittagessen, ich habe auch codiert, das Ende des Tages - nun, morgen werde ich weitermachen. Das heißt, wir programmieren, solange Energie, Zeit und Kraft vorhanden sind.
• Inkrementelle Entwicklung ist anders: Es gibt Aufgabe Nummer 13, ich werde es bis zum Ende tun und dann sehen, welche Aufgabe als nächstes kommt. In diesem Formular wird die Aufgabe (Ticket) immer erledigt. Wenn jedoch kein Ticket vorhanden ist, keine formulierte dokumentierte Aufgabe vorhanden ist, wird das Projekt nicht verschoben - der Code wird nicht geschrieben und die Pull-Anforderung wird nicht angezeigt.

Ich arbeite oft im ersten Szenario. Ich programmiere gerne, morgens schalte ich den Computer ein - und fahre los. Dann bremse ich - hör auf, lass es uns in Aufgaben aufteilen und bestimmen, zu welcher Aufgabe wir gehen werden.

In der zweiten Version endet jedes Ticket mit einer Pull-Anfrage: Hier ist das Problem, seine Beschreibung, Diskussion im Bereich dieses Problems, eine Änderung des Codes. Pull-Anfrage gesendet, verifiziert, akzeptiert - Ticket geschlossen, Sie können mit dem nächsten fortfahren.

Normalerweise arbeiten die Leute in beide Richtungen. Aber aus irgendeinem Grund ist eines der Hauptprobleme, mit denen wir konfrontiert sind: Die Leute wissen einfach nicht, wie sie die Aufgabe in kleinere aufteilen sollen.

Einige Leute glauben fälschlicherweise, dass eine inkrementelle Entwicklung notwendigerweise eine zweiwöchige Aufgabe bedeutet und dass das Ticket mit einer Pull-Anfrage von 5.000 geänderten Zeilen enden sollte. Dies ist keine inkrementelle Entwicklung. Inkrementell ist eine Aufgabe für 0,5 bis 2 Stunden und am Ende einer Pull-Anforderung von 50 bis 100 Codezeilen. Kontinuierlich im Gegenteil - Sie arbeiten lange (Tage, Wochen) und produzieren wenig.

Daher sage ich, dass gute Programmierer Code schreiben, aber die besten Tickets schreiben. Das Schreiben von Code ist einfacher als ein gutes Ticket - dies ist eine gute Erklärung dafür, warum dieser Code ausgeführt werden muss. Wenn Sie Ihr Niveau entwickeln und verbessern möchten, konzentrieren Sie sich daher auf die Fähigkeit, einem anderen Programmierer zu erklären, was zu tun ist, und auf die Fähigkeit, einem Kunden oder Kunden zuzuhören und seine Gedanken in Tickets umzusetzen.

Ich werde ein Beispiel aus dem Leben geben. Kürzlich hatten wir einen Kunden, der wie viele andere das Wesentliche des Projekts telefonisch erklären wollte. Er hat mehrmals mit einem unserer Architekten telefoniert. Nach einer Woche stellte ich fest, dass trotz der laufenden Diskussion möglicherweise sogar eine Art Code geschrieben wird und nur ein Ticket im System vorhanden ist. Dies ist ein Fehler eines Architekten, der einen Informationsstrom erhalten und nicht strukturiert hat. Wenn es dann Probleme im Projekt gibt, haben wir dem unzufriedenen Kunden nichts zu antworten. Wir werden die Protokolle von Telefongesprächen nicht erstellen.

Dies ist nur ein Fehler des Architekten. Der Client muss dies nicht wissen. Der Kunde ist eine chaotische, undisziplinierte Kreatur, die während des Entwicklungsprozesses wenig versteht. Er sollte so sein. Aber unsere Aufgabe ist es, disziplinierter zu sein , also Tickets schreiben, strukturieren.

Welche Programmiersprache soll man zuerst lernen? Englisch!

Das nächste Problem, auf das ich oft stoße und auf das ich achten möchte, ist die englische Sprache. Viele russischsprachige Entwickler ignorieren die englische Sprache, betrachten sie als zweitrangig und wollen nicht lernen, oder es fällt ihnen schwer, sie zu geben. Im IT-Bereich gibt es eine russischsprachige Gemeinschaft, mit der wir meines Erachtens mit aller Kraft kämpfen müssen. Habr, als Pionier dieser Gemeinschaft, leistet einen schlechten Dienst.

Natürlich ist die russische Sprache unsere Muttersprache, und es besteht keine Notwendigkeit, sie abzulehnen. Aber im Bereich der gleichen Tickets, Codes, Konferenzen und Bücher, die Sie gelesen haben, sollten wir meines Erachtens auf das Format nur Englisch umsteigen .

Wie gesagt, die Entwicklungswelt wird global, es wird immer weniger Programmierer aus Moskau geben - es wird nur Programmierer geben, zum Beispiel auf Swift, und es wird nur wenige Menschen geben, die sich aus Moskau um Sie kümmern. Programmierer verkaufen sich weltweit über das Internet und nicht über Bürointerviews. Auf die eine oder andere Weise wird dieser Markt auch nach 5-10-15 Jahren kommen, und Sie könnten einfach ausgelassen werden.

Sie denken, dass es einfacher ist, mit einem Landsmann auf Russisch zu kommunizieren. Telegram-, , . — , . , , .

, . , .

, .

. , , .

. . , -, . , , , . — . . , , , .

. , , , . , .

— . Twitter, , Telegram- . , . .

, , , , . , , , , , — .

5-10 . 2 , , .

, . — . , , .

GitHub —

, open source , 10–15 open source, (NASA ).

, .

open source . , — . : , pull requests , , GitHub, .

open source- . open source-, , , .

, , . — open source, ? , , , — .

, — , . , , . open source- . open source community: , -, , pulll request, .

open source-, : , , — - . 2 300 followers GitHub — , 6 .

— , . -, , . , .

, . , . , , , , . — , 25 , , community .

, . , . , full-time, . , .

— , . , 20 Twitter 2 GitHub, . open source-, , . .

— .

2000 , 2019. 2029 . , , followers, , .

, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .

— . .