Mohamed Gamal: Die Kunst, Strategien für zukunftssichere Technologien zu entwickeln

00:08 - 00:21
Mein Name ist Matt, und ich werde mit Mohammed Gamal über architektonische Entscheidungen und den Wandel von Unternehmenskulturen sprechen. Hallo, Mohammed. Guten Morgen. Gut, das zu haben

00:21 - 00:23
du hier. Hey, guten Tag.

00:23 - 00:25
Freut mich auch, dich zu haben.

00:25 - 00:28
Guten Tag. Du hast recht. Du hast recht. Es ist 14 Uhr.

00:28 - 00:32
Wir sind in Europa und es ist Freitag, also ist es fast ein Wochenende.

00:32 - 00:37
Es ist also ein guter Zeitpunkt, um das Wochenende oder das Interview zu beginnen. Stimmt.

00:38 - 00:43
Und, Mohammed, ich bin, ich bin nicht besonders begeistert von dem Interesse.

00:43 - 00:47
Ich denke, die Leute kennen dich, sie werden dich anhand der Beschreibung kennen.

00:48 - 00:54
Aber was ist interessant, und ich würde gerne gleich mit der Frage beginnen, du

00:54 - 00:58
Ich habe vor Kurzem für eine Zusammenfassung gearbeitet, ziemlich erfolgreiches Fintech.

00:59 - 01:08
Sie haben eine ziemlich große Runde, also hoffe ich, dass Sie in Ihrer Abteilung viel Geld für Technologie ausgeben können. Jeder hält durch

01:08 - 01:09
so. Ja.

01:11 - 01:18
Und so haben wir uns kürzlich unterhalten, es war wirklich interessant, in welcher Wohnung du arbeitest, weil du

01:18 - 01:20
arbeite auf einer Plattform in dieser Abteilung.

01:20 - 01:22
Könntest du vielleicht ein paar Worte darüber sagen, und was machst du

01:22 - 01:25
mache ich da? Ja. Ja, natürlich.

01:26 - 01:30
Das Plattformteam ist also von Natur aus eher ein Gründungsteam.

01:30 - 01:38
Wenn du also in einer tribalisierten Welt arbeitest, was das Spotify-Modell ist, können wir das später durchgehen.

01:39 - 01:45
Wenn das Team viel größer wird, brauchst du am Ende ein Team, das für die Architektur verantwortlich ist,

01:45 - 01:52
die Architekturvision, die architektonische oder technische Richtung, die Sie einschlagen werden.

01:52 - 01:59
Es sollte also gewissermaßen alle Produkte und deren Zusammenspiel überwachen und im Mittelpunkt stehen.

01:59 - 02:03
Das Plattformteam besitzt also von Natur aus kein eigenes Feature.

02:04 - 02:11
Das Unternehmen, das das Plattformteam besitzt Werkzeuge und Dienstleistungen, um Ingenieuren zu helfen, bessere Produkte zu liefern,

02:11 - 02:19
stabilere Produkte, Observability zum Beispiel, um immer den Überblick über die Daten zu haben, über die Abstürze, alles.

02:19 - 02:27
Es ist also eher ein Gewinn für das Gründungsteam, das einfach eine Architekturvision hat und Tools bereitstellt.

02:27 - 02:32
an Ingenieure, um ihnen bei ihrem Konstruktionsprozess, der Codierung usw. zu helfen und sie zu unterstützen.

02:33 - 02:35
Also, ja, in wenigen Worten, ist es das, was es bedeutet?

02:35 - 02:39
Und der Plattformstamm ist immer noch ein Stamm wie jede andere Abteilung.

02:39 - 02:41
Es hat verschiedene Teams.

02:42 - 02:45
Das Team, für das ich arbeite, heißt also die mobile Plattform.

02:45 - 02:50
Wir sind also engagierter oder nur engagierter, speziell für das Handy.

02:50 - 02:57
Wir besitzen keine Funktionen, die du als Nutzer letztlich sehen kannst, aber uns gehört wieder das Fundament,

02:57 - 03:04
wie die Produkte zusammenarbeiten, wie die Dinge aufeinander abgestimmt sein sollten, wie man eine neue Bibliothek hinzufügt, neue Abhängigkeiten,

03:04 - 03:11
wie sich das auf die anderen Abhängigkeiten auswirken wird, Bibliotheken zu haben, um Ingenieuren Bibliotheken zur Beobachtbarkeit zur Verfügung zu stellen.

03:11 - 03:16
Zum Beispiel, wie ich bereits erwähnt habe, auch das DevOps für das Handy.

03:16 - 03:23
Wir besitzen also das CI und die CD und all diese Prozesse, das Release-Management, mit dem Play Store

03:23 - 03:25
und Apple, Store und so weiter.

03:25 - 03:30
Also mehr oder weniger, das ist es, was wir tun, es hängt natürlich von der Rolle jedes Einzelnen ab, aber am Ende

03:30 - 03:36
sind sozusagen, ich würde sagen, das Schmiermittel zwischen den Stämmen. Also ja.

03:38 - 03:40
Nun, danke, danke dafür.

03:40 - 03:46
Ich denke, es ist eine clevere Lösung, aber ich frage mich nur, welche Art von Herausforderungen, welche

03:46 - 03:49
Haben Sie typische Herausforderungen oder Schmerzpunkte?

03:49 - 03:52
Zum Beispiel, weil Sie einen großen Einfluss auf die gesamte Organisation haben, auf

03:52 - 03:58
die gesamte Anwendung, aber was sind die typischen Herausforderungen und Schmerzpunkte? Ja.

03:59 - 04:06
Normalerweise besteht die Herausforderung darin, dass die Leute mit der Zeit das Gefühl haben, dass ich für jedes Plattformteam meine, ich nicht

04:06 - 04:11
Ich meine in meinem Fall notwendig, aber mit der Zeit haben die Leute vielleicht das Gefühl, nicht wirklich die volle Verantwortung zu tragen

04:12 - 04:16
oder die Verantwortung dafür, was sie versenden und wie sich das auf andere Dinge auswirkt.

04:16 - 04:21
Denn bei Teams konzentrieren sie sich normalerweise auf ihr eigenes Produkt, um ihr eigenes Produkt zu liefern

04:21 - 04:24
der beste Weg, aber sie sehen nicht, wie sich das auf die anderen auswirkt.

04:25 - 04:31
Das Plattformteam hilft auch dabei, denn Sie wissen immer noch, wenn ich etwas kaputt gemacht habe, die Plattform

04:31 - 04:34
Das Team wird davon erfahren, also werden sie sich darum kümmern.

04:34 - 04:39
Ich denke, dadurch wird die Verantwortung, das Gesamtbild zu sehen, ein wenig minimiert.

04:39 - 04:44
Das ist also die größte Herausforderung für uns, das nicht zu tun.

04:44 - 04:46
Also wollen wir Dinge lösen.

04:46 - 04:50
Wir wollen, dass alles gut integriert ist.

04:50 - 04:56
Aber auf der anderen Seite wollen wir, dass sich auch die Teams für das, was sie tun, verantwortlich fühlen und das große Ganze sehen.

04:56 - 05:02
Ich würde also sagen, meiner Meinung nach ist das die größte Herausforderung, die Sie haben, darin, dass Sie beides zusammen machen müssen.

05:04 - 05:10
Und wer ist Ihr Partner, wenn es darum geht, mit wem Sie normalerweise arbeiten und wo Sie Ihre Entscheidungen lösen können?

05:11 - 05:16
Ja. Das ist eine sehr schwierige Frage, sagte ich. In Ordnung.

05:17 - 05:24
Im Grunde ist unser Team wirklich, wirklich eigenverantwortlich, sodass wir zum Beispiel niemals individuelle Entscheidungen treffen. Alles wird durch Dokumente abgewickelt.

05:25 - 05:26
Wir fordern uns gegenseitig sehr heraus.

05:26 - 05:28
Wir sind sehr, sehr ehrlich zusammen.

05:28 - 05:32
Wir haben kein politisches Ding wie, ja, okay.

05:32 - 05:33
Und dann ändern wir Dinge.

05:33 - 05:35
Nein, wir sind sehr herausfordernde Leute.

05:36 - 05:43
Also ich würde sagen alles, aber natürlich das, was am nächsten kommt, weil ich mehr auf Android stehe. Das gibt es, Tiago.

05:43 - 05:45
Jetzt ist er technischer Leiter unseres Teams.

05:46 - 05:48
Also arbeiten wir die ganze Zeit zusammen.

05:48 - 05:54
Außerdem, weil wir viel mit Feuergefechten kämpfen, passiert bei der Veröffentlichung etwas und so weiter.

05:54 - 05:57
Wir gehen vorbei, wir gehen weiter, die Dinge gehen sehr frei miteinander um.

05:57 - 06:02
Also würde ich sagen, ja, wenn es ein krimineller Partner ist, dann ist er es.

06:02 - 06:05
Also und aus diesem Grund kämpfen wir wirklich viel.

06:07 - 06:10
Und warum schussest du viel? Warum ist es so?

06:10 - 06:15
Ja, denn auch hier überwachen wir, wie alles zusammenarbeitet.

06:15 - 06:20
Bei der Brandbekämpfung geht es also nicht unbedingt um die Leistung der App in der Produktion.

06:21 - 06:28
Das passiert selten, aber es geht eher darum, wie die Dinge integriert werden und in welche Richtung sich die Teams bewegen.

06:28 - 06:35
Wenn wir zum Beispiel nur über das Android-Team sprechen, sind es mehr als 40, 45 Ingenieure. Das Gleiche gilt für iOS.

06:36 - 06:44
All diese Ingenieure wissen also nicht, dass andere vielleicht an derselben Sache arbeiten oder vielleicht an etwas, das zu Konflikten führen wird.

06:44 - 06:50
Also, wenn man Ratschläge einholt, muss man manchmal, ja, sehr geduldig sein.

06:52 - 06:58
Versuche wirklich, den Leuten beizubringen, dass sie lernen müssen, wie alles zusammenhängt und zusammenarbeitet.

06:58 - 07:06
Das nenne ich immer noch Brandbekämpfung, denn wenn Sie Ihrem Projekt zum Beispiel eine neue Abhängigkeit hinzufügen, kann das alles kaputt machen.

07:06 - 07:11
Aber das weißt du nicht, weil du deinen Sinn formen willst, du testest, es funktioniert, aber du nicht

07:11 - 07:12
sehen Sie, was hinter den Kulissen passiert.

07:13 - 07:15
Und das, ja, das passiert oft.

07:15 - 07:21
Also, wenn wir das beaufsichtigen, ja, wir müssen Probleme aneinander weitergeben und ja.

07:21 - 07:23
Okay, Thiago, du gehst das an. Okay. Nein.

07:23 - 07:25
Ich nehme das jetzt in Angriff und so weiter.

07:25 - 07:27
Also, ja, deswegen wähle ich.

07:28 - 07:34
Und du hast die Stämme erwähnt, Stämme sind Squads, also quasi in einer Art Spotify-Art.

07:34 - 07:38
Könntest du mir mehr darüber erzählen?

07:38 - 07:39
Wie funktioniert das bei dir?

07:40 - 07:43
Gibt es irgendwelche Schattenseiten eines solchen Ansatzes?

07:43 - 07:45
Weil dies ein sehr beliebtes Modell ist. Richtig?

07:45 - 07:53
Ist es. Ich meine, ich würde nicht verstehen, dass ein Unternehmen mit einer Größe von 100 Mitarbeitern so etwas anwendet

07:53 - 07:56
ehrlich, weil es keinen Sinn ergibt.

07:56 - 08:01
Also ich arbeite auch in verschiedenen Stilen, ich würde sagen, nicht nur im Spotify-Modell.

08:02 - 08:10
Aber wenn ein Unternehmen wie SumUp, denke ich, dass wir mehr als 3,5 000 Mitarbeiter haben, macht das mehr Sinn.

08:10 - 08:17
Was genau es macht, ist, dass es dir eine gute Teamstruktur bietet, es hat einen autonomen Ansatz,

08:17 - 08:20
wie man Agile skaliert und so weiter.

08:20 - 08:25
Im Grunde haben Sie also einen Stamm, jeder Stamm ist für seine Domäne verantwortlich.

08:25 - 08:29
In großen Unternehmen kann es sich bei dieser Domain um ein kleines Unternehmen innerhalb des Unternehmens handeln. Ja.

08:30 - 08:33
Und dann hat dieser Stamm seine eigenen Teams.

08:33 - 08:39
Also, auch die Verantwortung wird von den Teams geteilt und die Schönheit der Spotify-Modelle ist das.

08:39 - 08:42
zwingt nicht alle Teams, mit derselben Methodik zu arbeiten.

08:43 - 08:44
Jedes Team ist also autonom.

08:44 - 08:48
Sie können arbeiten, wie sie wollen. Am Ende tragen sie zur großen Vision bei.

08:49 - 08:52
Aber auf ihre eigene Art, also wird es nicht erzwungen.

08:53 - 09:00
Und dann, weil auch all diese Teams quasi funktionsübergreifende Teams sind.

09:00 - 09:03
Sie müssen also auch eine Art von Kapiteln haben.

09:03 - 09:08
Jedes Team hat also Backend-Ingenieure, Frontend-Ingenieure, Mobilgeräte, bla bla bla.

09:08 - 09:10
Dann haben Sie Kapitel für diese Domains.

09:10 - 09:12
Sie haben zum Beispiel ein Kapitel für Mobilgeräte.

09:12 - 09:15
Darin befindet sich ein Android-Kapitel, ein iOS-Kapitel usw.

09:15 - 09:21
Du bringst also immer auch alle zusammen, um Wissen auszutauschen, Wissen zu teilen und so weiter.

09:22 - 09:23
Und es hat viele andere Details.

09:23 - 09:27
Lass uns nicht glauben, dass es viele Leute gibt, die besser darüber sprechen können als ich.

09:29 - 09:40
Der Nachteil ist meiner Meinung nach also die Priorisierung, denn am Ende ist jede Entität, nämlich Stamm

09:40 - 09:42
hat in diesem Fall seine eigenen Prioritäten.

09:43 - 09:46
So wird die Ausrichtung manchmal zu einem Problem.

09:46 - 09:50
Man muss immer an einem Strang ziehen und es ist, glaube ich, die schwierigste Mission aller Zeiten.

09:50 - 09:57
Um auf die Vision ausgerichtet zu sein, um die Prioritäten Ihres Teams mit den Prioritäten anderer Teams in Einklang zu bringen.

09:57 - 10:00
Also ich denke, das ist die größte Herausforderung.

10:00 - 10:06
Du musst also immer daran arbeiten, weil ich denke, das ist meiner Meinung nach das größte Geschäft.

10:08 - 10:14
Also, ja, ich denke, auch die Aufrechterhaltung einer gemeinsamen Vision ist irgendwie problematisch, weil, nochmal,

10:14 - 10:19
In verschiedenen Bereichen ist es sehr schwierig, eine gemeinsame Vision für alle zusammen zu entwickeln.

10:20 - 10:23
Das ist also auch ein bisschen herausfordernd, würde ich sagen.

10:25 - 10:32
Auch die Rekrutierung ist zum Beispiel eine Herausforderung, denn wenn es um diesen und jeden Stamm geht

10:32 - 10:41
ist sehr groß, groß genug, sie haben ihre eigenen, sagen wir mal Einstellungs-, Prozess- oder Standards.

10:42 - 10:48
Sie müssen also auch an dieser Art der Standardisierung des Einstellungsprozesses für alle Stämme arbeiten,

10:48 - 10:52
nicht nur, jeder Stamm kann tun, was er will.

10:52 - 10:54
Weil dir am Ende die Qualität wichtig ist.

10:54 - 10:59
Alle Ingenieure oder alle Mitarbeiter werden die gleiche Qualität haben und in allen Stämmen dieselben Titel tragen.

10:59 - 11:01
Das ist also auch eine Herausforderung.

11:02 - 11:09
Das Letzte ist meiner Meinung nach die Ressourcenallokation oder Talentverteilung, was ich meine.

11:10 - 11:11
Manche Stämme sind also überfüllt.

11:12 - 11:14
Sie haben genug Leute, andere Stämme nicht.

11:14 - 11:19
Und aber mit diesem Stamm ist es sehr schwer, die Ressourcen dieser tribalisierten Welt zu teilen.

11:20 - 11:25
Weil das Teilen der Ressourcen die Entität, für die Sie arbeiten, irgendwie verändert.

11:25 - 11:30
Es ist nicht so einfach, dass du gerade in deinem Stamm einen Mobiltechniker brauchst, ein anderer Stamm hat vielleicht

11:30 - 11:32
2 mehr als sie brauchen.

11:32 - 11:34
Nein, das kannst du nicht einfach teilen.

11:34 - 11:36
Das ist also auch etwas, woran man arbeiten muss.

11:36 - 11:40
Aber sobald du dich um diese Dinge gekümmert hast, wenn du die Schattenseiten bereits kennst und daran arbeitest

11:40 - 11:48
sie, ich denke, es ist meiner Meinung nach das perfekte Setup. Danke dafür. Das ist wirklich interessant.

11:48 - 11:49
Ich habe nicht so für die

11:49 - 11:53
Beim ersten Mal höre ich die Schattenseiten der Arbeit in Stämmen.

11:53 - 11:59
Ich habe eine Menge Vorteile gehört, aber ich habe noch nie davon gehört, was den Einstellungsprozess angeht, und

11:59 - 12:02
wie, du weißt schon, Leute von einer Seite an ein anderes Ende zu bringen.

12:02 - 12:06
Dass das so schwierig ist, ich denke, das ist eine unschätzbare Erkenntnis.

12:07 - 12:12
Und vor Kurzem, als wir uns unterhalten haben, haben wir über ein paar technische Konzepte gesprochen.

12:12 - 12:20
Also, und die, die mir im Gedächtnis blieb, war die Diskussion über Polyrepo versus Monorepo. Jep.

12:20 - 12:27
Wenn Sie sich also erinnern, ob Sie sich noch an unser Gespräch erinnern, können Sie das vielleicht näher erläutern, denn das war ja.

12:29 - 12:36
Wenn wir also zum Beispiel über das Backend sprechen, ist der größte Architekturtrend derzeit eher Microservices. Ja.

12:36 - 12:38
Jeder Dienst ist also eigenständig.

12:39 - 12:42
Es ist immer noch irgendwie verbunden, aber eigenständig.

12:42 - 12:44
Bei Handys ist das also anders.

12:44 - 12:49
Sie können das nicht wirklich anwenden, da Sie am Ende 1 App versenden.

12:49 - 12:53
Es ist ein Produkt, das du versendest und das du in den Play Store hochlädst. Alles zusammen.

12:53 - 12:55
Es kann nicht in Stücke geschnitten werden.

12:56 - 12:59
Architektonisch ja, aber was die Lieferung angeht, nein.

13:00 - 13:06
Der größte Teil der mobilen Entwicklung durchläuft also das Mono-Repo-Muster, in dem alles enthalten ist

13:06 - 13:09
ein Ort, alles in einem, GitHub-Repo.

13:09 - 13:15
Jeder trägt zum gleichen Teil bei, und am Ende wird alles zusammen versendet.

13:15 - 13:16
Das Poly Repo ist ein bisschen anders.

13:16 - 13:21
Es ist eher wie Microservices, aber für mehr meine ich, es ist eher wie Microservices.

13:21 - 13:26
So kannst du zum Beispiel kürzen, du hast eine Domain, eine App, zum Beispiel. Es hat eine Bankdomain.

13:26 - 13:29
Es hat eine Checkout-Domain, es hat große Domains.

13:30 - 13:36
Sie können diese Domains in SDKs unterteilen, und jedes SDK ist ein separates Repository und hat seine eigene Version.

13:36 - 13:39
und am Ende fügen sich diese Dinge zusammen.

13:39 - 13:46
Am Ende funktionieren beide meiner Meinung nach sehr gut, aber beide haben viele Nachteile.

13:47 - 13:53
Also das Monorepo, es gibt den Ingenieuren die Möglichkeit, alles zu sehen, weil sie

13:53 - 13:58
Öffnen Sie beispielsweise Pull-Requests für jede Änderung des Codes, und alles an einem Ort.

13:58 - 14:00
Also das ist eine sehr gute Sache.

14:00 - 14:04
Aber der Nachteil ist, dass es auch überwältigend wird.

14:04 - 14:09
Es erhöht sich, die Bauzeit um ein Vielfaches, denn das ist die schmerzhafteste Sache, die du machen wirst.

14:09 - 14:12
höre von jedem mobilen Entwickler, insbesondere von Android-Entwicklern.

14:12 - 14:16
Vor allem in großen Unternehmen, die Build-Zeit, und ich brauche ewig, um den Code zu erstellen.

14:17 - 14:22
Das ist also auch einer der Nachteile des Monorepo, weil Sie alles zusammen bauen müssen.

14:23 - 14:28
Das Polyurepo ist etwas anspruchsvoll, da Sie auch die Versionen aneinander ausrichten müssen.

14:28 - 14:31
Die Version, in der all diese SDKs zusammenarbeiten.

14:31 - 14:35
Das ist also der herausfordernde Teil, der herausfordernde Teil, aber am Ende geht es viel schneller.

14:35 - 14:38
Es steht Ihnen frei, in Ihrem Repo zu tun, was Sie wollen.

14:38 - 14:40
Es steht Ihnen frei, so zu testen, wie Sie möchten.

14:40 - 14:50
Es steht Ihnen frei, alles zu tun, und dann versenden Sie eine neue Version, vielleicht wöchentlich, und Sie fügen sie in die App ein, integriert, fertig. Cool. Es hat einen Nachteil.

14:50 - 14:53
Auch hier ist das Testen ein weiterer Nachteil.

14:53 - 14:56
Das liegt daran, dass Sie die Integration nicht ständig testen.

14:56 - 14:58
Also, ich meine, beide sind gut.

14:58 - 15:04
Meine persönliche Meinung ist, Polyurepo zu verwenden und zu versuchen, die Nebenwirkungen zu minimieren.

15:04 - 15:08
Es gibt viele Möglichkeiten, das zu tun, so sehe ich das.

15:09 - 15:13
Aber am Ende arbeiten beide am wichtigsten, was es zu pflegen gilt, und das ist

15:13 - 15:15
größter Deal in der Softwareentwicklung im Allgemeinen.

15:15 - 15:21
Denn egal, was du tust, ist ein Vermächtnis, es wird sehr bald ein Vermächtnis sein, also musst du

15:21 - 15:26
es ist ein schönes Erbe, nicht das Erbe, das die Menschen in 5 Jahren hier erleiden werden.

15:28 - 15:34
Und Sie gehen die Trends in der Softwareentwicklung an, wie die Microservices. Richtig? Jeder geht in diese Richtung.

15:34 - 15:39
Und noch eine Frage, die ich dir stellen wollte, um dir einen kleinen Hintergrund zu geben, also das war

15:39 - 15:44
Womit, mit etwas, mit dem ich vorher zu kämpfen hatte, wie zum Beispiel das Unternehmen zu leiten.

15:44 - 15:49
Also, meine Firma, die ich leite, der Brain Hub, wir sind quasi der JavaScript-Entwicklershop. Richtig?

15:49 - 15:55
Und als wir damit angefangen haben, ich glaube, es ist ungefähr 8 oder 9 Jahre her, da wuchs das JavaScript wie verrückt.

15:55 - 16:00
Also, jede Woche, jeden Tag, hast du quasi ein neues Framework, eine neue Bibliothek und die Entwickler

16:00 - 16:03
vor allem die Entwickler haben ihre Studie gezeigt.

16:03 - 16:05
Dies ist ihr erster Job oder sie studieren gerade.

16:05 - 16:07
Sie sind nicht so erfahren.

16:07 - 16:13
Sie fahren einfach, weißt du, mit dir herum, mit all den Bibliotheken, Frameworks, mit denen wir diesen Weg gehen sollten.

16:13 - 16:17
Wir sollten diesen Weg gehen, diesen Weg, und du hast quasi jede Menge davon.

16:17 - 16:25
Also frage ich mich nur, wie Sie es angehen, Nein zu neuen Dingen zu sagen und Entwickler bei Laune zu halten, Entwickler

16:25 - 16:26
glücklich zur gleichen Zeit?

16:26 - 16:29
Ja. Ich würde sagen, es ist ein Muskel, den du trainierst.

16:32 - 16:38
Weil ja. Am Anfang, besonders als ich der Plattform beitrat, weil das die Teams sind

16:38 - 16:41
die normalerweise nein sagen, aber immer aus einem bestimmten Grund.

16:41 - 16:45
Hoffentlich verstehen die Leute, dass es einen Grund hat.

16:45 - 16:51
Also, ja, am Anfang habe ich immer gesagt, okay, vielleicht funktioniert das nicht. Okay?

16:52 - 16:54
Aber vielleicht ohne genug Kontext zu geben.

16:56 - 17:04
Danach erfährst du von Zeit zu Zeit, wie sich die Leute mehr dafür interessieren würden oder wie sie deine Idee annehmen.

17:05 - 17:08
Wenn du den Kontext teilst, wenn du teilst, ja. Weißt du was?

17:08 - 17:10
Das, das, das, sie funktionieren nicht zusammen.

17:10 - 17:16
Es fühlt sich sehr trivial an, die Bibliotheksversion zu aktualisieren, nicht einmal eine neue Bibliothek hinzuzufügen, hinzuzufügen

17:16 - 17:18
Ich aktualisiere nur die Abhängigkeitsversion.

17:18 - 17:24
Es könnte jeden Zyklus leicht durchbrechen, denn am Ende gibt es transitive Abhängigkeiten,

17:24 - 17:28
und wenn jede Abhängigkeit andere Abhängigkeiten mit unterschiedlichen Versionen hat, wenn Sie aktualisieren

17:28 - 17:30
eine Version, es könnte alles kaputt machen.

17:31 - 17:35
Ich denke, mit der Zeit verstehen das auch die meisten Ingenieure.

17:36 - 17:42
Um ehrlich zu sein, ist es nicht schwer, nein zu sagen, denn manchmal sogar bevor ich gehe und sage

17:42 - 17:45
nein, ich sehe, andere Leute haben das schon getan und sie verstehen es bereits.

17:45 - 17:51
Und um ehrlich zu sein, das ist das Beste hier ist, dass ich denke, die Leute von früher

17:51 - 17:57
sogar wenn ich hierher gekommen bin, haben sie diese Kultur entwickelt, die die Leute jetzt verstehen und irgendwie haben

17:57 - 18:02
geteiltes Wissen über die App oder über unsere Produkte, diese Produkte versenden wir.

18:03 - 18:09
Außerdem gibt es etwas, das die Dinge einfacher macht, nämlich dass man immer etwas hat, das heißt

18:09 - 18:12
Abhängigkeitsbäume, die alle Versionen und alles zusammen erwähnen.

18:12 - 18:18
Also, wann immer du einen Pull-Request für einige Änderungen öffnest, siehst du, was all die Versionen

18:18 - 18:24
ändere es, und es ist sehr einfach für dich, sehr sichtbar, die Auswirkungen dessen, was du getan hast, zu verstehen.

18:24 - 18:30
Das Problem tritt nur auf, wenn vielleicht neue Ingenieure hinzukommen, also sollte es Teil des Onboardings sein

18:30 - 18:34
dass sie verstehen müssen, dass, was auch immer sie tun, die Wirkung sehr hoch ist.

18:35 - 18:40
Aber am Ende akzeptieren sie es wirklich sehr, sehr freundlich, und es ist sehr gut.

18:41 - 18:46
Also fordern auch wir uns immer wieder gegenseitig heraus, okay, vielleicht wird es zu einer Verhandlung oder einer Art

18:46 - 18:51
von, okay, ich möchte auf Version 5 updaten, aber ja, wir haben Version 3. In Ordnung.

18:51 - 18:53
Was ist mit dem Update auf Version 4? Würde es funktionieren?

18:53 - 18:58
Weißt du, es ist wie Handel. Ja.

18:58 - 19:00
Das ist genau das, was ich meine.

19:00 - 19:02
Es ist ein Muskel, den du trainierst. Also.

19:04 - 19:08
Und lassen Sie uns ein bisschen mehr über die technischen Aspekte sprechen.

19:08 - 19:14
Ich habe einmal vom CTO gehört, dass von einem CTO, den Sie erwähnt haben, dass Architekturentscheidungen

19:14 - 19:17
sollte der letzte sein, der es so spät wie möglich macht. Richtig?

19:17 - 19:21
Weil es eine große Wirkung hat und länger bei dir bleibt.

19:21 - 19:26
Also ich frage mich in Ihrem Fall nur, weil Sie bereits erwähnt haben, das Erbe. Richtig?

19:26 - 19:28
Irgendwann wird alles ein Vermächtnis sein.

19:29 - 19:34
Aber hast du irgendwelche umsetzbaren Tipps, wie man die Architektur richtig plant?

19:35 - 19:43
Zum Beispiel, wie man es vor anderen Führungskräften macht, was sollten sie vielleicht vermeiden, oder was sind die häufigsten Fehler in diesem Bereich? Ja.

19:45 - 19:50
Um fair zu sein, es ist unmöglich, wie Sie sagten, es ist unmöglich, ein Vermächtnis zu vermeiden. Das wird passieren.

19:50 - 19:53
Das ist in der Vergangenheit passiert und passiert heute. Das wird passieren.

19:53 - 19:56
Wir entwickeln Legacy-Code für die Zukunft.

19:57 - 20:05
Ich denke also, das Wort Vermächtnis wird irgendwie missbraucht, weil Vermächtnis an sich keine schlechte Sache ist. Es ist in Ordnung.

20:05 - 20:08
Wenn es perfekt funktioniert, ist es in Ordnung.

20:08 - 20:14
Es gibt neue Trends, die die Arbeit erleichtern, aber das heißt nicht, dass die alten nicht schlecht waren.

20:14 - 20:18
Deshalb halte ich Legacy World immer nicht für eine schlechte Sache.

20:19 - 20:25
Aber Sie müssen die negativen Auswirkungen des Vermächtnisses in Zukunft reduzieren.

20:25 - 20:28
Um ehrlich zu sein, sollte es damit einfach sein.

20:28 - 20:34
Jeder, der Softwaretechnik studiert, sollte einfach sein, aber es ist nicht so einfach, wie es sich anhört

20:34 - 20:36
denn am Ende musst du Dinge versenden.

20:36 - 20:37
Und das ist das Hauptziel.

20:37 - 20:39
Wir sind ein Produktunternehmen.

20:39 - 20:42
Die meisten Unternehmen sind Produktfirmen, und Sie müssen versenden.

20:42 - 20:46
Normalerweise treffen Sie Ihre Entscheidungen auf der Grundlage des Zeitplans, den Sie haben, und so weiter.

20:46 - 20:50
Es gibt immer einen lustigen Witz, dass, okay, ich werde das später korrigieren.

20:50 - 20:52
Ich werde das einfach liefern und das später beheben.

20:52 - 20:55
Dieses Update würde später niemals passieren.

20:55 - 20:59
Also sagt er einfach, ja, okay, ich liefere falsch und wir werden optimieren.

21:00 - 21:06
Ich habe noch nie jemanden gesehen, der die Codes, die er nur zur Optimierung erstellt hat, noch einmal überprüft hat.

21:06 - 21:07
Ich dachte, das passiert nicht.

21:08 - 21:15
Meiner Meinung nach sind sie alle, auch ich, eine Erinnerung an mich selbst.

21:15 - 21:19
Folgen Sie einfach den soliden, den grundlegenden soliden Prinzipien.

21:19 - 21:23
Wenn du Prinzipien folgst, wenn du einer sauberen Architektur folgst, wenn du das im Hinterkopf behältst

21:23 - 21:30
Die ganze Zeit wirst du keinen schlechten Einfluss auf das haben, was du jetzt schreibst, weil es immer offen für Veränderungen ist.

21:30 - 21:33
Es ist nur, es ist immer skalierbar und so weiter.

21:33 - 21:37
Also, wenn man das im Hinterkopf behält, denke ich, dass es funktioniert und das ist genug.

21:37 - 21:41 UHR
Also so nehme ich es auf.

21:42 - 21:45
Sie müssen auch lernen, wie man die Architektur plant.

21:45 - 21:50
Natürlich ist die Architektur, wie Sie sagen, nicht das Erste, woran Sie denken.

21:50 - 21:56
Sie müssen also etwas über das Geschäft lernen, wie das Geschäft in 2 bis 3 Jahren geprägt sein wird. Es wird sich immer ändern.

21:56 - 21:58
Du kannst darüber lernen, dann wird sich das morgen natürlich ändern.

21:59 - 22:05
Aber Sie erstellen die Architektur auf der Grundlage der Geschäftsanforderungen, weil Sie es vielleicht am Ende nicht tun

22:05 - 22:07
muss ein ausgefallenes Setup haben.

22:07 - 22:10
Vielleicht funktioniert das einfache Setup besser für dich.

22:11 - 22:18
Denn immer wenn du auch versuchst, ausgefallene Dinge zu bauen, die komplizierter sind als nötig,

22:18 - 22:20
wird mit einem schlechten Erbe enden.

22:20 - 22:23
Denn später warum das alles und wir brauchen es nicht.

22:23 - 22:24
Wissen Sie, was ich meine?

22:24 - 22:32
Also, ja, zusammenfassend denke ich nicht, dass Vermächtnis schlecht ist, aber wir müssen sicherstellen, dass so viel wie

22:32 - 22:34
wir können, dass es nicht schlimm wird.

22:34 - 22:36
Es wird ein Vermächtnis sein. Ja. Das wird es sein.

22:36 - 22:41
Ich weiß also nicht, ob das deine Frage beantwortet hat, also korrigiere mich bitte.

22:41 - 22:42
Mehr oder weniger kann ich nicht korrigieren.

22:42 - 22:46
Ich bin nicht gut, weißt du, gebildet genug in diesem Bereich. Also

22:50 - 22:55
Nein. Ich glaube, das ist, dass ich glaube, das ist nein. Das ist eine gute Antwort.

22:56 - 23:03
Und, Mohammed, ich wollte dir eine schwierige Frage stellen, weil quasi jeder von jedem

23:03 - 23:07
Von uns lernen wir aus wirklich schwierigen Dingen bei der Arbeit.

23:07 - 23:13
Ich frage mich also nur, was die schwierigste Sache oder Situation war, die Sie in Ihrem Leben erlebt haben

23:13 - 23:16
Auswirkungen auf Ihre Karriere, und was haben Sie daraus gelernt?

23:19 - 23:27
Ich denke, der größte Schritt, der schwierigste für mich, und es hat viel Zeit gekostet, mich anzupassen, ist der Übergang von

23:28 - 23:36
die Kultur und Umgebung des Softwarehauses und, ja, für die Produktfirma.

23:36 - 23:39
Das Softwarehaus ist also ganz anders mit einer ganz anderen Mentalität.

23:40 - 23:44
Sie brauchen Sie, Sie interessieren sich nicht sehr für die Zukunft dieses Produkts.

23:44 - 23:46
Am Ende ist es nicht dein Produkt.

23:46 - 23:51
Ich habe 5, 6 Jahre lang bei einem Softwareunternehmen gearbeitet.

23:52 - 23:59
In diesen 5, 6 Jahren habe ich an 9 verschiedenen Projekten gearbeitet. Es ist eine ganz andere Mentalität. Es ist eine ganz andere Mentalität.

23:59 - 24:02
Alles, was Sie wollen, ist versenden.

24:02 - 24:07
Alles, was Sie möchten, ist ohne Abstürze zu versenden, da dies ein Problem für den Kunden ist.

24:08 - 24:12
Außerdem müssen Sie sich mit dem Kunden auseinandersetzen, Sie müssen die Anforderungen verstehen und so weiter.

24:12 - 24:14
Du bist am Ende, am Ende machst du alles.

24:15 - 24:17
Ich habe viel von dort gelernt.

24:18 - 24:21
Aber wenn wir zum Produkt übergehen, das ist eine völlig andere Welt.

24:22 - 24:23
Die Dinge sind nicht die gleichen.

24:23 - 24:27
Sie müssen sehr gut verstehen, was das Produkt ist, weil es Ihr Produkt ist.

24:27 - 24:32
Sie interessieren sich wirklich für das Produkt, weil Sie am Ende derjenige sind, der dafür verantwortlich ist.

24:32 - 24:35
Sie sind derjenige, der dafür verantwortlich ist, es zu testen.

24:35 - 24:37
Sie sind derjenige, der für das Feedback verantwortlich ist.

24:37 - 24:45
Im Softwarehaus ist das Gegenteil der Fall, da der Kunde am Ende testet und mit dem Feedback zu Ihnen kommt. Es ist eine ganz andere Denkweise.

24:45 - 24:48
Also habe ich eine Weile gebraucht, um mich an die neue Denkweise anzupassen.

24:49 - 24:50
Es hat wirklich eine Weile gedauert.

24:51 - 24:54
Aber am Ende, ja, nachdem ich es nicht weiß, jetzt 4 Jahre. Ja.

24:54 - 24:58
Vielleicht 4, ein bisschen mehr als 4 Jahre, die nur für Produktunternehmen arbeiten.

24:59 - 25:02
Ich denke jetzt macht alles zusammen Sinn, aber erst nach 4 Jahren.

25:02 - 25:04
Jetzt ist es natürlich einfach.

25:04 - 25:09
Jetzt habe ich irgendwie eine Verbindung hergestellt, okay, damals war der Kunde für mich der echte Kunde.

25:09 - 25:11
Jetzt ist der Kunde für mich der Stakeholder.

25:12 - 25:16
Aber wir haben beide die gleiche Vision, weil wir beide an demselben Produkt arbeiten.

25:16 - 25:18
Wir kümmern uns beide um dasselbe.

25:18 - 25:22
Das ist jetzt der einzige Unterschied für mich, aber damals war es natürlich schrecklich. Es war sehr schwer.

25:24 - 25:27
Nun, was sind Ihre größten Herausforderungen im Jahr 2024?

25:32 - 25:35
In Ordnung. Technisch gesehen,

25:38 - 25:46
vielleicht die Vereinheitlichung unserer Produkte, weil, ja, wir haben mehrere Produkte, und jetzt gibt es

25:46 - 25:53
sind einige Fusionen oder ein Produkt benötigt einige, Funktionen aus dem anderen und so weiter.

25:53 - 25:58
Diese Sache mit der Vereinigung und dem Teilen ist also eine große Sache.

25:58 - 25:59
Es ist wirklich ein großes.

26:00 - 26:07
Auch KMP, wenn Sie wissen, ist Kotlin Multiplatform neu.

26:07 - 26:09
Es ist ein neuer guter Trend.

26:09 - 26:10
Es ist nicht nur ein neuer Trend.

26:10 - 26:11
Meiner Meinung nach ist es ein neuer guter Trend.

26:12 - 26:19
Es ist also auch eine große Herausforderung für uns, es einzuführen, sich anzumelden und uns darauf zu verlassen, wenn es um große Funktionen geht.

26:20 - 26:25
Und es gibt immer eine große Herausforderung, die wir jedes Jahr haben, also vielleicht, wenn du mich in 5 Jahren fragst,

26:25 - 26:26
Ich werde immer dasselbe sagen.

26:26 - 26:28
Es geht um den Bauprozess des Projekts.

26:29 - 26:31
Also, wie das Projekt gebaut wird und so weiter.

26:31 - 26:35
Wir versuchen immer, dies zu verbessern, aber wir werden immer auch versuchen, dies zu verbessern. Es wird niemals aufhören.

26:35 - 26:36
Es wird immer Probleme geben.

26:36 - 26:40
Das sind also, glaube ich, die drei wichtigsten Dinge.

26:41 - 26:48
Danke fürs Teilen. Und die letzte Frage, die ich allen meinen Gästen stellen wollte, frage ich mich,

26:49 - 26:56
Können Sie Bücher, Ressourcen, Konferenzen, Podcasts oder einige Studien empfehlen, die besonders

26:56 - 27:00
hilfreich für dich als ein bestimmtes, das dir geholfen hat und dich prägen kann.

27:01 - 27:04
Ja. Ja, natürlich. Also würde ich zuerst mit Podcasts beginnen.

27:04 - 27:07
Es gibt eine sehr nette namens Better Tech Leadership.

27:10 - 27:12
Jedenfalls bist du Danke dafür.

27:12 - 27:13
Ich werde es auf einer Website verwenden.

27:13 - 27:15
Ich werde es auf einer Website verwenden.

27:17 - 27:24
Ansonsten, für ja. Für andere Podcasts gibt es, die Primetime ist natürlich auch gut.

27:26 - 27:29
Um ehrlich zu sein, höre ich mir nicht viele Podcasts an.

27:29 - 27:34
Ich weiß von deinem, bevor wir uns kontaktiert haben, seit Januar.

27:35 - 27:37
Deshalb habe ich mich dafür interessiert. Das wollte ich hören.

27:37 - 27:41
Ich mag den Vortrag und so weiter, also wollte ich mir mehr Interviews anhören.

27:41 - 27:44
Die Primetime ist auch toll, aber das sind die einzigen 2.

27:45 - 27:54
Für Box, ich meine, für eine umfassendere Vision über Softwareentwicklung und Unternehmen und, wie man baut

27:54 - 28:00
Lean Software und DevOps und so weiter. Ich mag das Accelerate-Buch. Es ist sehr, sehr zu empfehlen.

28:00 - 28:04
Es heißt Accelerate, das Zeichen von Lean Software und DevOps.

28:06 - 28:12
Es gibt ein Buch, von dem ich denke, dass es eines der besten ist, das ich je gelesen habe, 5 Dysfunctions of a Team.

28:13 - 28:14
Ich liebe dieses Buch wirklich so sehr.

28:14 - 28:16
Ich liebe ich liebe es. Ich liebe die Geschichte.

28:16 - 28:17
Ich liebe es, wie es geschrieben ist.

28:19 - 28:23
Meiner Meinung nach ist es wirklich sehr inspirierend, weil man diese immer fühlt,

28:26 - 28:32
Werte, aber Sie wissen nicht, dass es in allen Teams eine gemeinsame Sache ist.

28:33 - 28:39
Es ist nett, es ist meiner Meinung nach sehr, sehr wichtig, gelesen zu werden, für jeden, der treten will

28:39 - 28:43
hoch, um mehr über das Team zu erfahren und wie Teams funktionieren und wie man ein besseres Team zusammenstellt.

28:44 - 28:47
Leider gibt es nicht viele Boxen für Personaltechnik.

28:47 - 28:50
Es gibt viele Boxen für den Management-Track für das technische Management.

28:51 - 28:56
Deshalb heißt das Staff Engineer Book The Staff Engineers Path, weil ich sage, es ist

28:56 - 29:03
einer der ersten, und der andere wird daher Staff Engineer genannt. So einfach ist das also.

29:04 - 29:11
Diese waren auch wichtig, um aus anderen Aspekten zu lernen, wie Mitarbeiter Ingenieur oder Mitarbeiter plus,

29:11 - 29:12
Personalleiter und so weiter.

29:13 - 29:17
Wie es in anderen Unternehmen, in großen Unternehmen usw. funktioniert. Was heißt das?

29:17 - 29:22
Was sind die Tracks, verschiedene Arten, Mitarbeiter zu sein, verschiedene Arten, Mitarbeiter zu sein, und so weiter?

29:22 - 29:24
Also, es war sehr, sehr hilfreich für mich.

29:25 - 29:28
Also, ja, ich glaube, die habe ich im Kopf.

29:29 - 29:34
Großartig. Vielen Dank, Mohammed, und das war meine letzte Frage.

29:34 - 29:37
Du hast Amara eine tolle Antwort gegeben, also danke dafür.

29:39 - 29:45
Und ich schätze deine Zeit wirklich und wünsche dir ein schönes Wochenende. Du auch. Genieß es. Danke.

29:47 - 29:52
Folgen Sie Matt auf LinkedIn und abonnieren Sie den Better Tech Leadership-Newsletter.

‍