Connect with us

Entwicklung & Code

Die beste Konferenz meines Lebens, und was sie anders gemacht hat


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Konferenzen kosten mehr, als auf dem Ticket steht. Zum Eintrittspreis kommen Anreise, Übernachtungs- und Verpflegungskosten, und dazu meistens noch zwei oder drei Arbeitstage, die sich nicht abrechnen lassen. Rechnet man das für alle Teilnehmerinnen und Teilnehmer zusammen und bedenkt man die Menge an Kerosin, Benzin und Strom, die für die Anreise benötigt wird, dann ergibt sich eine Bilanz, die ökonomisch wie ökologisch fragwürdig ausfällt. Der offensichtliche Gegenwert dafür ist das Programm.

Weiterlesen nach der Anzeige

Nur trägt das Programm diese Rechnung oftmals nicht. Die Vorträge stehen anschließend ohnehin online, und selbst dort, wo das nicht der Fall ist, findet sich zu praktisch jedem Thema genügend adäquater und frei zugänglicher Ersatz im Netz, völlig unabhängig von der Konferenz. Es gibt kaum einen Vortrag, für den man tatsächlich reisen und vor Ort sein müsste. Ich stelle mir deshalb seit Jahren die Frage, ob es sich noch lohnt, auf Konferenzen zu fahren, und ich muss zugeben: Wegen der Vorträge allein wäre die Antwort ernüchternd.

Im Juli 2026 war ich dann jedoch auf einer Veranstaltung, bei der die Rechnung vollkommen anders aufgegangen ist. Es war eine der besten, wenn nicht gar die beste Konferenz, auf der ich jemals war.

Wer Konferenzen verteidigt, verweist üblicherweise auf das Networking. Die Vorträge seien nur der Anlass, das Eigentliche passiere in den Pausen, beim Essen, am Abend. Dieses Argument halte ich im Kern für richtig. Nur löst es sich zumindest für mich persönlich selten ein.

Den typischen Ablauf kennen Sie vermutlich: Die Kaffeepause beginnt, es bilden sich Grüppchen aus Menschen, die einander bereits kennen, und wer allein steht, steht weiterhin allein. Nach zwanzig Minuten ertönt das Signal, dass es weitergeht, und alle begeben sich wieder in die Räume und setzen sich. Der Teil, der als das Eigentliche gilt, bekommt am Ende die Zeit, die das Programm übrig lässt.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Selbstverständlich habe ich meinen Anteil daran. Ich bin in solchen Situationen schüchtern und zurückhaltend, und es fällt mir schwer, ein Gespräch zu beginnen. Nicht, weil ich mich ungern unterhalte, im Gegenteil. Aber Smalltalk liegt mir nicht, und ohne Smalltalk fehlt mir der Einstieg. Ich laufe seit über zwanzig Jahren durch diese Branche und habe immer noch das Gefühl, kein Networking zu können.

Weiterlesen nach der Anzeige

Hinzu kommt eine Beobachtung, die ich nicht als Vorwurf verstanden wissen möchte, sondern als nüchterne Feststellung: Auch als Referent wird man erstaunlich selten angesprochen. Ich bekomme durchaus mit, dass Leute in der Nähe stehen, dass sie schauen, dass sie überlegen, aber mich dann nicht ansprechen. Beide Seiten warten also darauf, dass die jeweils andere anfängt, und niemand macht es.

Das heißt ausdrücklich nicht, dass große Fachkonferenzen sich nicht lohnen würden. Sie leisten etwas, das ich zu Hause nicht bekomme: einen Überblick über ein ganzes Feld in zwei Tagen, den Blick in Nachbardisziplinen, nach denen ich von mir aus nie gesucht hätte, und ein Gefühl dafür, worüber eine Branche gerade spricht. Deshalb fahre ich weiterhin hin. Nur ist das ein anderer Wert als der, den das Versprechen vom Networking in Aussicht stellt.

Eine Ausnahme habe ich lange mit mir herumgetragen. Am 24. September 2011 fand in Brescia die erste italienische Konferenz zu Node.js statt, und ich war damals dort. Rund 250 Menschen aus ganz Europa waren angereist, für eine Technologie, die damals kaum jemand kannte und mit der sich noch kein Geld verdienen ließ. Für Heise habe ich seinerzeit darüber geschrieben.

Was diese Konferenz auszeichnete, war nicht das Programm, sondern die Energie im Raum. Man hatte den Eindruck, an etwas teilzunehmen, das später einmal wichtig sein würde, und dieser Eindruck war offenkundig nicht meiner allein. Es wurde bis nachts diskutiert, ohne dass irgendjemand dazu aufgefordert werden musste.

Im Rückblick war der Grund dafür simpel: Dort saßen ausschließlich Menschen, die für das Thema brannten. Node.js war 2011 keine Karriereoption und kein Pflichtprogramm. Wer hinfuhr, tat das aus Überzeugung. Diese Voraussetzung lässt sich nicht dadurch herstellen, dass man mehr Tickets verkauft.

Fünfzehn Jahre lang ist mir nichts Vergleichbares mehr begegnet. Bis Juli.

Am 13. und 14. Juli 2026 fand in Berlin der IT Business Summit statt, veranstaltet von IT Business Growth. Die Zielgruppe waren IT-Freelancerinnen und -Freelancer sowie Unternehmerinnen und Unternehmer, die Themen waren Positionierung, Akquise und Preisgestaltung. Etwa achtzig bis hundert Menschen waren vor Ort. Ich war als Sprecher eingeladen und habe darüber gesprochen, wie ich vom Entwickler zum Unternehmer wurde, und warum die verbreitete Erklärung, das sei vor allem Glück gewesen, zu kurz greift. Glück braucht es tatsächlich – aber es nützt wenig, wenn die Vorbereitung fehlt und Chancen unerkannt vorbeiziehen.

Ich spreche sonst auf Tech-Konferenzen und war im Vorfeld entsprechend unsicher. Meine Sorge galt nicht dem Thema, sondern dem Publikum. Im Kopf hatte ich das Bild, das die Coaching-Szene der vergangenen Jahre auf YouTube geprägt hat: Menschen, die keinen Satz zustande bringen, ohne „KPIs“, „Challenges“, „Mindset“ und „tackeln“ unterzubringen. Ich fürchtete weniger, dass mein Vortrag nicht zünden würde, als schlicht, keinen Anschluss zu finden.

Es kam vollkommen anders. Dort liefen ganz normale IT-Leute herum, so wie ich, die entweder freiberuflich arbeiten, ein Unternehmen führen oder sich selbständig machen wollen. Und es beschäftigen sie dieselben Fragen wie alle, die eigenständig unterwegs sind: Wie komme ich an Aufträge? Wofür stehe ich? Was ist meine Arbeit wert?

Angefangen hat es bereits am Vorabend, bei einem gemeinsamen Abendessen. Es hat mich einige Überwindung gekostet, überhaupt hinzugehen, und das lag ausschließlich an mir, weil ich unsicher war und nicht wusste, was auf mich zukommen würde. Und: Ich saß dann an einem Tisch mit lauter Menschen, die ich alle nicht kannte.

Statt das irgendwie zu überspielen, habe ich offen gesagt, wie es mir damit geht: dass ich solche Situationen schwierig finde, dass ich nie genau weiß, worüber ich reden soll, und dass mir der Einstieg fehlt. Das war kein Kalkül, eher eine Kapitulation.

Die Reaktion hat mich überrascht. Den anderen am Tisch ging es genauso, und eine Person merkte an, sie fände das eine ungewöhnlich offene und ehrliche Art, ein Gespräch zu beginnen, und eigentlich sei das doch bereits der perfekte Einstieg. Genau das war es dann auch. Wir haben den ganzen Abend geredet, lange und intensiv, und es ging kaum um Geschäftliches, sondern um Persönliches. Ich bin danach mit einem Gefühl auf mein Zimmer gegangen, das ich von Konferenzabenden schlicht nicht kenne.

An diesem Tisch hat sich entschieden, wie ich die restlichen Tage erlebt habe. Was ich jahrelang für ein Defizit gehalten hatte, erwies sich als der bessere Gesprächseinstieg. Nicht, weil Ehrlichkeit eine Technik wäre, sondern weil sie jedem Einstieg überlegen ist, den ich mir vorher hätte zurechtlegen können.

Am nächsten Tag hielt Sandra Löhning von exali einen Vortrag über ebendieses Thema. Ihre Kernthese lautete, Networking werde meist als Frage der Menge verstanden, also möglichst viele Leute zu kennen. Das allein bringe jedoch nichts. Tragfähig werde es erst, wenn echte Verbindungen entstehen. Es gehe nicht um Quantität, sondern um Qualität, quasi „Deep-Networking“.

Die Pointe daran ist, dass ich mich mit ihr am Abend zuvor lange über Introversion, Schüchternheit und die Schwierigkeit unterhalten hatte, ein Gespräch zu beginnen. Der Vortrag war insofern die Fortsetzung von etwas, das längst lief.

Wie ernst es der Veranstaltung mit diesem Gedanken war, habe ich beim Mittagessen gemerkt. Ich kam mit zwei anderen Teilnehmern darüber ins Gespräch, wie Verkaufsgespräche ablaufen. Daraus wurde ein kleines Rollenspiel am Tisch, und anschließend hat sich einer der beiden hingesetzt und mir ein paar Anzeigen für LinkedIn entworfen, einfach um zu zeigen, wie er das Thema angehen würde. Davon hatte er nichts, es hat ihn seine Zeit gekostet, aber er hat sich die Mühe für mich gemacht. Einfach so.

Und das war kein Einzelfall, sondern das Klima der Veranstaltung. Wer mitbekam, dass jemand an einer Stelle nicht weiterkam, bot Hilfe an. Ähnlich verlief das Gespräch mit Philipp Göhner, der über die steuerliche Seite von Unternehmensvermögen gesprochen hatte und sich danach die Zeit nahm, das Thema mit mir in Ruhe durchzugehen.

Auch ich habe anderen Teilnehmern etwas zurückgeben können, indem ich ihre Fragen zum Aufbau meines Unternehmens und YouTube-Kanals beantwortet habe. So viel Gemeinschaft habe ich seit Jahren nicht mehr erlebt, und erst dort ist mir aufgefallen, wie sehr sie mir gefehlt hat.

Ich habe selbst schon Konferenzen mitorganisiert und weiß daher ungefähr, wie viel Arbeit in so etwas steckt und an wie vielen Stellen es schiefgehen kann. Umso genauer habe ich hingesehen, warum das Miteinander dort funktionierte, und umso beeindruckter bin ich zurückgefahren. Meine Antwort: Es war kein Zufall, sondern das Ergebnis vieler kleiner Entscheidungen.

Die erste betrifft die Größe. Achtzig bis hundert Teilnehmende sind wenig genug, dass man in zweieinhalb Tagen mit fast allen einmal ins Gespräch kommen kann. Man begegnet sich mehrfach, erkennt sich am nächsten Morgen wieder und knüpft an das an, was am Vortag besprochen wurde. Bei hunderten oder gar über tausend Menschen ist jede Begegnung eine Erstbegegnung.

Die zweite betrifft den Ablauf. Die Tische beim Abendessen waren vorab zusammengestellt, sodass niemand mit dem Teller in der Hand nach einem Platz suchen musste. Der Konferenzmorgen wurde nicht von den Veranstaltern eröffnet, sondern von einem Zauberer. Das hätte leicht in Richtung Kindergeburtstag kippen können, aber er hat den Bogen zum Thema geschlagen und das Publikum gleich dazu gebracht, mit den Sitznachbarinnen und Sitznachbarn zu interagieren. Nebenbei sorgte er auf diese Weise dafür, dass die beiden Veranstalter danach auf die Bühne in einem Saal kamen, der bereits wach war – es herrschte eine ganz andere und aufgeheizte Atmosphäre, als ich das von anderen Konferenzen kenne.

Die dritte betrifft die Bühne selbst. Eine Moderatorin führte durch das Programm, souverän und schlagfertig, und trug damit erheblich zur Stimmung bei. Die Sprecherinnen und Sprecher wurden vorher abgeholt und im Hintergrund verkabelt und dann angekündigt, sodass sie durch das Publikum auf die Bühne liefen, statt zuvor unbeteiligt auf der Bühne stehen zu müssen. Das ist eine Kleinigkeit, aber sie verändert die Energie im Raum massiv, und ich werde sie auf anderen Veranstaltungen vermissen.

Die vierte betrifft den Abend. Auf den Konferenztag folgte ein Abendprogramm, das ebenso ernst genommen wurde wie das Bühnenprogramm, bis hin zur Aftershow auf dem Dach. Unterm Strich war das eine Mischung aus Konferenz, Networking und Party, wie ich sie zuvor nicht erlebt habe, und das sage ich als jemand, der Partys eher meidet. Das klingt nach Beiwerk, ist aber genau der Teil, in dem aus einer Gruppe einander unbekannter Menschen eine Gemeinschaft geworden ist.

Bemerkenswert fand ich schließlich, was nicht passiert ist. Die Veranstalter verkaufen selbst Programme für ihre Zielgruppe, und es hätte nahegelegen, die zweieinhalb Tage dafür zu nutzen. Wer wollte, konnte darüber sprechen, wer nicht wollte, wurde in Ruhe gelassen. Zwischen einem Angebot und dem Bearbeiten von Menschen, bis sie zustimmen, verläuft ein schmaler Grat, und dieser Grat wurde nicht überschritten.

Natürlich fällt dort, wo Licht ist, auch Schatten. Konkret hätte ich mir vor allem zwei Dinge anders gewünscht.

Zum einen war es beim Abendessen am Vortag zu laut. Die Akustik des Raums schaukelte sich hoch, bis ein Gespräch mit mehreren Personen nur noch schwer möglich war. Ausgerechnet an der Stelle, an der die Veranstaltung ihre Stärke hatte, arbeitete der Raum gegen sie. Später auf dem Dach war es besser, aber da war die Runde bereits nicht mehr vollständig.

Der zweite Punkt betrifft den dritten Tag. Nach zwei außergewöhnlich dichten Tagen sackte die Energie am dritten Tag spürbar ab, und das Programm wirkte konventioneller als zuvor. Bis zu einem gewissen Grad ist das unvermeidlich, denn niemand hält dieses Niveau beliebig lange. Der Kontrast fiel trotzdem auf.

Beides ist Kritik auf hohem Niveau, und das ist bereits das eigentliche Urteil: Wenn nach zweieinhalb Tagen die Raumakustik als größter Kritikpunkt übrig bleibt, ist sehr vieles anderes offensichtlich richtig gelaufen.

Mit der Node.js-Konferenz in Brescia lässt sich der Summit inhaltlich nicht vergleichen, dafür liegen die beiden Themenwelten zu weit auseinander. Atmosphärisch aber hat Berlin den Maßstab übertroffen, an dem ich fünfzehn Jahre lang alles andere gemessen habe. Damit hatte ich nicht im Entferntesten gerechnet, und ich werde noch lange daran zurückdenken. Anders als 2011 lag es nämlich nicht am Zeitgeist, sondern an Gestaltung.

Ein Patentrezept lässt sich daraus nicht ableiten, wohl aber ein Muster.

Der wichtigste Faktor ist, wer im Raum sitzt. Es funktioniert dann, wenn Menschen zusammenkommen, die für ein Thema intrinsisch brennen. Davon gibt es zu keinem Thema Tausende, und deshalb ist es auf großen Konferenzen ungleich schwerer. Wo es dort gelingt, geschieht es meist in einem einzelnen Track oder in einer Community innerhalb der Veranstaltung, also faktisch in einer kleinen Konferenz in der großen. Kleinere Formate haben es leichter, weil sie persönlicher sind und weil man einander wiedererkennt.

Klein zu sein genügt allerdings nicht. Der Rahmen muss bewusst gestaltet werden. Die Inhalte müssen selbstverständlich stimmen, aber sie sind nicht der Hebel. Der Hebel ist alles, was Menschen in die Lage versetzt, offen miteinander zu sprechen und sich aus ihrer Komfortzone zu bewegen. Das ist Arbeit, und einer Veranstaltung sieht man an, ob diese Arbeit geleistet wurde.

Für Konferenzen gilt damit dasselbe, was Sandra Löhning über das Networking gesagt hat: Qualität statt Quantität. Für Teilnehmende heißt das, weniger Veranstaltungen zu besuchen und bei jeder einzelnen zu wissen, weshalb und mit welchem Ziel man hinfährt. Für Veranstalter heißt es, sich zu fragen, was die eigene Veranstaltung von ihrer Aufzeichnung unterscheidet.

Damit zurück zur Ausgangsfrage. Der Aufwand, den eine Konferenz verursacht, rechtfertigt sich nicht durch ihr Programm, denn das Programm bekommt man auch von zu Hause aus. Er rechtfertigt sich durch das, was zwischen den Programmpunkten passiert. Genau dieser Teil bekommt in der Planung erfahrungsgemäß die geringste Aufmerksamkeit, weil er sich schlechter planen lässt als ein Zeitraster. Ich bin nach Berlin gefahren, ohne zu wissen, ob es sich lohnen würde, und bin auf eine Weise begeistert zurückgekommen, die mich selbst überrascht hat. Konferenzen können sich sehr wohl lohnen. Sie müssen nur entsprechend gebaut sein.

Transparenzhinweis: Ich war beim IT Business Summit als Sprecher eingeladen. Ein Honorar habe ich nicht erhalten, die Reisekosten habe ich selbst getragen, die Hotelkosten hat der Veranstalter übernommen. Eine geschäftliche Verbindung zu IT Business Growth besteht nicht. Im Vorfeld sind zwei gemeinsame Videos mit Pierre Wilken entstanden, Vom Techie zum Unternehmer und KI, Code und die Zukunft der Softwareentwicklung.


(mro)



Source link

Entwicklung & Code

Kritisieren oder schweigen? Diskussionskultur in IT-Projekten


In IT-Projekten gibt es eine ganze Menge Dinge, die niemand hören möchte. Zum Beispiel, dass das Webformular eine Sicherheitslücke aufweist, das automatische Backup seit einer Woche nicht mehr funktioniert oder das bereits beworbene Feature ohne größeren Codeumbau nicht machbar ist.

Weiterlesen nach der Anzeige

Oft genug sieht sich der Überbringer der schlechten Nachricht selbst Kritik ausgesetzt. Kein Wunder also, dass viele genau überlegen, wie offen sie ihre Meinung in einem IT-Projekt äußern.




Alex Kirsch ist IT-Beraterin, Coach und freie Wissenschaftlerin. Mit ihrem Hintergrund in Künstlicher Intelligenz, User Experience Design und Entscheidungsfindung macht sie Software- und Entwicklungsteams fit für die harte Realität.

Ob jemand Mängel anspricht oder sich Kritik verkneift, hat viel mit Erziehung, Kultur und Erfahrung zu tun. Was für eine Person ein technisches Argument ist, empfindet die nächste als Egotrip. Die unterdrückte Antwort: Diplomatie oder Heuchelei? Über persönliche Moralvorstellungen und Einzelfälle lässt es sich trefflich diskutieren. Der springende Punkt sind vielmehr die Auswirkungen auf das Projekt.

Ein ungeklärtes Problem ist wie ein unerkanntes Krebsgeschwür. Es kann wachsen, bis es sich irgendwann nicht mehr ignorieren lässt. Ein Beispiel dafür ist eine größere Aktualisierung einer Library. Die dafür notwendigen Änderungen im Code mitsamt Testen würden vielleicht eine Woche Zeit kosten. Niemand hat eine Woche Zeit übrig, also passiert nichts. Für die nächste größere Änderung der Library haben Entwicklerinnen und Entwickler natürlich noch weniger Zeit übrig. Irgendwann schlagen die Auswirkungen der veralteten Library im eigenen Code durch. Sie ist zu allem inkompatibel, moderne Funktionen sind unerreichbar. Das Problem: Statt eines Updates braucht es jetzt eine Neuimplementierung der betroffenen Stellen. Aus einem alltäglichen Stolperstein ist ein unüberwindbarer Wall geworden.

Manchmal bleiben Probleme einfach unerkannt. Das ist Pech. Oder Entwicklerinnen und Entwickler erkennen sie und entscheiden sich bewusst dafür, sie zu ignorieren. Das ist eine Ermessensfrage. Aber wenn Teammitglieder Probleme verschweigen, dann ist das eine verpasste Chance. Insofern wäre es in IT-Teams folgerichtig, das Ansprechen von Problemen aktiv zu fördern.

Weiterlesen nach der Anzeige

Doch die Realität sieht anders aus; nicht nur, weil Diskussionskultur nicht zum Lehrinhalt eines Informatikstudiengangs zählt, sondern vor allem, weil IT-Projekte von Zeitdruck, überzogenen Erwartungen und mangelnder Management-Unterstützung geprägt sind.

Ein kaputtes Projekt macht alle kaputt. Die letzten drei Deadlines gerissen, Fachbereich oder Marketingabteilung sind sauer und machen Druck, im Team schiebt man sich gegenseitig die Schuld zu. Entdeckt ein Teammitglied jetzt ein neues Problem, wird es je nach Naturell entweder noch weniger bereit sein, es anzusprechen (wozu auch, es hat ja niemand Zeit, das Problem zu beheben) oder es besonders laut und aggressiv zur Sprache bringen (es ist fünf vor zwölf, jetzt muss endlich etwas passieren!). Das Problem bleibt bestehen und verkommt zum Streitfall, der das Projekt noch weiter verzögert und gefährdet.

Schade, dass es oft so weit kommt. Denn eigentlich wollen alle das gleiche: funktionierende Software, die jemandem das Leben in irgendeiner Form erleichtert und worauf Entwicklerinnen oder Entwickler stolz sein können. Und das wird umso unwahrscheinlicher, je weniger das Team Probleme offen ausdiskutiert.

Das einzelne Teammitglied könnte jetzt die IT-Welt verfluchen und Dienst nach Vorschrift erledigen – oder sich der Realität stellen und die Situation als persönliche Herausforderung annehmen. Die Rahmenbedingungen eines Projektes kann es üblicherweise nicht ändern und hat auch die Stimmung im Team nicht direkt in der Hand. Teammitglieder können jedoch Strategien entwickeln, um den eigenen Argumenten mehr Gehör zu verschaffen.

Fragen sind ein didaktisches Instrument und helfen oft weiter als die Demonstration von Fachkompetenz. Wer ein Problem selbst erkennt, macht niemanden anderes dafür zum Sündenbock. „Dein Code ist Schrott!“, greift persönlich an und erzeugt schlechte Stimmung. „Dein Code könnte eine kleine Überarbeitung gebrauchen“, ist noch schlimmer, denn die angesprochene Person wird oft nicht einmal verstehen, dass es ein Problem gibt. Probieren wir es konstruktiv: „Dieser Code ist ineffizient, weil er innerhalb der Schleife dieselbe Berechnung mehrfach durchführt. Wir sollten diese aus der Schleife herausziehen“, oder „Diesen Code finde ich schlecht lesbar, weil ich die Aufteilung in Funktionen nicht nachvollziehen kann.“ Bei diesen Aussagen geht es um den Code, nicht um die Fähigkeiten der Person, die ihn produziert hat. Das Problem wird direkt benannt und lässt sich beheben.

„Das geht nicht!“, kann die Adressatin oder der Adressat der Kritik leicht als inkompetent oder bockig auslegen. Was genau geht denn nicht? Die notwendige Technik ist noch nicht erfunden? Also versuchen wir eine Lösung zu finden: Warum wird diese Funktion gebraucht? Welche Effekte wie Kosteneinsparung oder Fehlerreduzierung sollen dadurch entstehen? Mit ein paar Fragen macht man entweder die Sinnlosigkeit offensichtlich oder findet gemeinsam eine Lösung.

Oder ist das „geht nicht“ eine Zeitfrage? Dann vielleicht „Ich/Wir als Team arbeite/n gerade an Feature X, Test Y und Dokumentation Z. Wie sollen wir diese neue Anforderung priorisieren? Welche der anderen Aufgaben, die aktuell geplant sind, sollen wir hinten anstellen?“.

Jeder Mensch pflegt eine andere Diskussionskultur, vielleicht sogar unterschiedliche je nach Kontext. Es lohnt sich, die eigene Antenne für Befindlichkeiten gut zu kalibrieren.

Im alltäglichen Umgang mit Teammitgliedern ergeben sich viele Gelegenheiten zur Beobachtung. Ist der Mensch ein Morgenmuffel? Dann die heiklen Themen erst nach der Mittagspause auftischen. Geht es mit rationaler Begründung voran oder hilft es, auf den Angst- oder Belohnungs-Knopf zu drücken? Wie bringt das Teammitglied selbst Argumente vor? Ein schöner Zeitvertreib in langweiligen Meetings ist, sich vorzustellen, was die einzelnen Leute gerade denken oder warum sie überhaupt zu diesem Termin erschienen sind.

In einem gut eingespielten Team muss man nicht jedes Wort auf die Goldwaage legen. Zum Beispiel kommt die Chirurgin mit einem einfachen „Skalpell!“ durch, ohne zeitraubende Höflichkeiten wie „Würden Sie mir bitte das Skalpell reichen?“ Deshalb lohnt es sich, gegenseitiges Vertrauen aufzubauen und auch eigene Grenzen klarzumachen.

Kritiker können auch selbst zur Zielscheibe von Kritik werden. Sei es durch eine andere Meinung zur abgelieferten Arbeit, ein Gegenargument in einer Diskussion oder durch einen offenen persönlichen Angriff. Wie geht man am besten damit um? – Erst einmal einen Schritt zurücktreten, tief durchatmen und analysieren. Worum geht es und warum fühle ich mich angegriffen?

Gibt es eine unterschiedliche Sichtweise der Situation? Ist die Sicherheitslücke in der Library ein Grund zur Panik oder ein theoretisches Angriffsszenario, das im Kontext gar nicht relevant werden kann? Entwicklerinnen und Entwickler müssen die Meinung des anderen nicht übernehmen, sondern sich nur bemühen, die andere Sichtweise nachzuvollziehen. Vielleicht kennt der andere nicht alle Fakten, hat weniger Erfahrung oder ein höheres Sicherheitsbedürfnis.

Oder will jemand nur Dampf ablassen und ein Sündenbock war gerade greifbar? Manchmal haben Motive für Kritik und Diskussionen gar nichts mit der Sache zu tun oder machen eine Kleinigkeit zur Staatsaffäre. Dann sollte man ruhig bleiben, Gegenfragen stellen und versuchen, auf eine sachliche Ebene zu kommen oder auch das Gespräch vertagen.

Selbst wenn ein Argument sachlich und korrekt ist, mag es uns nicht gefallen. Oft beschleicht einen das unangenehme Gefühl, etwas falsch gemacht zu haben. Dabei sollten wir nicht vergessen, dass auch das größte Genie mal daneben liegt. Gut vorgebrachte Kritik ist ein Zeichen dafür, dass das Team funktioniert. Immerhin macht sich jemand die Mühe, uns darauf hinzuweisen.

In vielen Fällen stört uns auch einfach die Konsequenz des Gesagten, wenn daraus weitere Arbeit folgt. Fertig geglaubter Code muss geändert werden oder nicht eingeplante Aufgaben verzögern den Zeitplan. Darüber freut sich niemand. Trotzdem sollten wir uns hüten, die Meinungsäußerungen anderer zu ignorieren, als irrelevant abzutun oder den eigenen Unmut am Nachrichtenüberbringer auszulassen. Wer selbst den Respekt fordert, gehört zu werden, sollte ihn auch anderen zuteilwerden lassen.



Source link

Weiterlesen

Entwicklung & Code

Developer-Häppchen – CUDA für ARM, Node-Sicherheit und Rust-Umfrage



Aufmacher ALC-Konferenz

Aufmacher ALC-Konferenz

(Bild: decorwithme/123rf.com)

Multi-Krisen, Transformationen, KI – die Herausforderungen für agile Führungskräfte sind klar und mannigfaltig. Die Online-Konferenz Agile Leadership Day (ALC) gibt am 1. und 2. Dezember 2026 Antworten darauf. Vormittags laufen Vorträge, nachmittags kommen die Teilnehmerinnen und Teilnehmer in praktischen Kurz-Workshops zusammen.



Source link

Weiterlesen

Entwicklung & Code

Herdr: Terminal-Multiplexer sortiert Flotten von Coding-Agenten


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Wer mehrere Coding-Agenten parallel an verschiedenen Projekten arbeiten lässt, muss auf deren Ausgaben warten und vor allem den Überblick behalten: Welcher Agent rechnet noch, welcher ist fertig, und wo blockiert eine Rückfrage den nächsten Schritt? Genau an dieser Stelle setzt Herdr an. Der freie Terminal-Multiplexer hält Sitzungen am Leben, ordnet sie nach Projekten und fasst den Zustand von Agenten in einer Seitenleiste zusammen.

Weiterlesen nach der Anzeige

Das im März 2026 veröffentlichte Projekt hat inzwischen auch institutionellen Rückhalt erhalten. Gründer Can Celik kündigte Anfang August die Aufnahme in den Herbstjahrgang 2026 des US-Gründerprogramms Y Combinator an. Y Combinator führt Herdr als Ein-Personen-Unternehmen mit Sitz in Ankara. Y Combinators Standard Deal investiert in jedes aufgenommene Start-up 500.000 US-Dollar. Eine weitere, individuelle Finanzierungsrunde nennt Herdrs Ankündigung nicht.

Herdr liefert kein Sprachmodell und ersetzt keine Agenten wie Claude Code, Codex oder OpenCode. Als auf Coding-Agenten zugeschnittener Konkurrent zu tmux führt Herdr gewöhnliche Terminal-Prozesse aus, ergänzt deren Darstellung aber um die Zustände working, blocked, done,idle und unknown. Die aktuelle stabile Ausgabe ist 0.9. Das in Rust entwickelte Programm steht unter der Apache-2.0-Lizenz. Binärpakete gibt es für Linux und macOS auf x86-64 und ARM64 sowie für Windows auf x86-64. Hinzu kommen unter anderem Homebrew, Nix und mise. Einzelne Funktionen bleiben unter Windows eingeschränkt.

Die Herdr-Architektur folgt dem Client-Server-Modell klassischer Terminal-Multiplexer. Ein Server stellt die Terminal-Instanzen bereit, unter Unix als Pseudoterminals (PTYs) und unter Windows per ConPTY-Konsolen. Der Client stellt diese nur dar, sodass Shells, Entwicklungsserver und Agenten weiterlaufen, sollte er getrennt werden. Herdr organisiert Terminals in Workspaces, Tabs und Panes, sodass der Nutzer sie entsprechend seines eigenen Workflows gruppieren kann.

Um die Aufmerksamkeit des Nutzers auf die richtigen Agenten lenken zu können, erkennt Herdr Zustände der KI-Agenten per Hook, Plugin oder die Analyse der Terminal-Ausgabe. Optionale Integrationen liefern je nach Werkzeug zusätzlich Sitzungskennung oder Informationen zum Lebenszyklus. Herdr verdichtet die Zustände auf Workspace-Ebene und meldet unbeachtete Rückfragen.

Auch Automatisierung ist vorgesehen. Über Kommandozeile und eine lokale Socket-API lassen sich Panes anlegen, Ein- und Ausgaben übertragen sowie Agentenzustände abfragen. Unter Unix nutzt sie einen Unix Domain Socket, unter Windows eine Named Pipe. Auch tmux lässt sich automatisieren, allerdings ohne die native Integration von Agenten und deren Zuständen.

Weiterlesen nach der Anzeige

Beim Trennen eines Clients oder bei einem Netzwerkausfall laufen Server und Prozesse weiter. Nach einem Neustart des Herdr-Servers oder Rechners dagegen sind Prozesse natürlich beendet. Laut der Restore-Matrix des Projekts stellt Herdr dann Workspaces, Tabs, Pane-Aufteilung, Arbeitsverzeichnisse und Fokus wieder her und setzt Agenten, die das unterstützen, über deren native Sitzungskennung fort.

Die optionale Speicherung der Terminal-Historie ist standardmäßig abgeschaltet, weil sie Zugangsdaten, Token oder Prompts enthalten kann. Ein experimentelles Live-Handoff versucht, Prozesse bei bestimmten Updates zu erhalten, bietet dafür aber keine Garantie.

Auch bei entfernten Rechnern ersetzt Herdr nicht SSH. Nutzer können sich wie gewohnt anmelden und Herdr dort starten. Alternativ verbindet die Remote-Funktion herdr --remote host einen lokalen Herdr-Client über OpenSSH mit einem Herdr-Server. OpenSSH übernimmt Authentifizierung und Host-Key-Prüfung. Als Ziel unterstützt dieser Modus nur Linux und macOS. Windows kann seit Herdr 0.8.2 als lokaler Client dienen, aber nicht als Server.

Seit Version 0.9.0 können mehrere Clients unabhängig voneinander verschiedene Workspaces und Tabs anzeigen. Unterschiedliche Tabs passen sich der Größe des jeweiligen Clients an. Teilen sich Clients einen Tab, bestimmt der zuletzt darin aktive Client dessen Größe.

Die am 7. September 2026 veröffentlichte Version bündelt außerdem lokale und per SSH angebundene Server in einem Fenster. Eine gemeinsame Agentenliste zeigt deren Zustände. Während die ausgewählte Maschine die sichtbaren Terminal-Inhalte liefert und Eingaben erhält, aktualisieren die übrigen Verbindungen weiterhin Statusinformationen und Benachrichtigungen. Diese Funktion wird derzeit unter Linux und MacOS unterstützt. Ein gespeichertes Maschinenprofil bindet jeweils eine Sitzung ein, nicht sämtliche Sitzungen eines Hosts.

Besonders sichtbar wurde Herdr durch Omarchy, die Linux-Distribution des umstrittenen David Heinemeier Hansson. Deren vierte Hauptversion Quattro hat den Multiplexer zusätzlich zu tmux integriert. Die mitgelieferte Konfiguration orientiert sich mit Ctrl+Space als Prefix an Omarchys tmux-Belegung. Die Versionshinweise zu Herdr 0.8.2 nennen DHH als Mitwirkenden an Fenstertiteln, Pane-Größenänderung und Tab-Verschiebung. Omarchy ist damit Konsument und DHH Contributor.

Für ein oder zwei Sitzungen, deren Inhalt bekannt ist, bleibt ssh plus tmux die nüchterne Wahl. tmux ist seit fast zwei Jahrzehnten erprobt, breit paketiert und detailliert konfigurierbar. Wer Statusleisten, Hooks und Benachrichtigungen eingerichtet hat, gewinnt durch einen Wechsel womöglich wenig.

Herdr wird interessanter, wenn mehrere Agenten über Repositories und Rechner verteilt arbeiten und die menschliche Aufmerksamkeit knapp wird. Statusübersicht, Benachrichtigungen, Sitzungswiederaufnahme und semantische API reduzieren dann Eigenbau. Mausbedienung und repositoryorientierte Organisation senken zudem die Einstiegshürde.

Herdr bleibt jedoch jung: In weniger als fünf Monaten sprang es von Version 0.1 auf 0.8. Auch der Plugin-Marktplatz ist keine kuratierte vertrauenserweckende Anlaufstelle. Einträge werden laut Projekt automatisch erfasst und nicht geprüft. Plugins, Hooks und Socket-API haben Zugriff auf Entwicklungsumgebung und Terminal-Inhalte und verlangen entsprechende Vorsicht.

Somit macht Herdr tmux nicht überflüssig. Es behandelt Terminals zusätzlich als Warteschlange für menschliche Entscheidungen. Ob das ein eigenes Laufzeitsystem rechtfertigt, hängt weniger von der Zahl offener Panes ab als davon, wie oft eines unbemerkt auf eine Antwort wartet.


(axk)



Source link

Weiterlesen

Beliebt