GitHub Copilot & Produktivität

Wo der derzeitige Fokus auf Produktivität falsch ist

Der Fokus auf mehr produktiv Ingenieure ist nicht der richtige Weg. Ich erlebe immer wieder, dass Unternehmen sich schwer tun, zu definieren, was Produktivität überhaupt ist, und dann neigen sie immer noch dazu, sich auf Codezeilen zu konzentrieren, die als Maßstab für die Produktivität akzeptiert werden. Wir Ingenieure sind den ganzen Tag mit Aufgaben wie Requirements Engineering, Architekturarbeit, Dokumentation und Diskussionen über das weitere Vorgehen beschäftigt. Wir denken über die Wartbarkeit, Lesbarkeit und Testbarkeit des Codes nach, den wir schreiben. Und dann haben wir in den meisten Unternehmen auch noch all die anderen Dinge, die neben der Codeproduktion anfallen, wie tägliche Meetings, Stand-ups, Check-ins und so weiter. Wir hoffen, dass wir genug Zeit haben, um tatsächlich einen Mehrwert für unsere Endbenutzer zu schaffen! Ich habe sogar einen Ingenieur kennengelernt, der seinen Tag absichtlich später beginnt, damit er weiterarbeiten kann, wenn alle anderen schon gegangen sind: Das ist die Zeit, in der er sich tatsächlich auf das Schreiben von Code konzentrieren kann!

Wir haben in den letzten Jahrzehnten mehrfach gelernt, dass die bloße Betrachtung von Dingen wie produzierten Codezeilen nicht einmal annähernd eine gute Metrik zur Messung der Produktivität ist. Und es kommt noch schlimmer: Die Copilot-Metriken-API zeigt nur die akzeptierten Codezeilen für Vorschläge an, die als Ganzes akzeptiert wurden! Wenn Copilot also 10 Codezeilen vorschlägt und Sie nur 5 (oder ein paar Wörter) akzeptieren, zählt die API dies als 0 akzeptierte Codezeilen. Teilweise akzeptierte Vorschläge werden also nicht einmal in den Metriken berücksichtigt.

Dennoch wollen Unternehmen die vorgeschlagenen und akzeptierten Codezeilen betrachten, und ich habe sogar schon Unternehmen gesehen, die sich darauf konzentrieren wollen, die Akzeptanzrate zu erhöhen! Ich halte das für den falschen Weg, denn es wird dazu führen, dass Ingenieure blindlings Vorschläge annehmen, ohne über den vorgeschlagenen Code nachzudenken. Es ist eine gute Sache, sich einen Vorschlag anzuschauen und zu überlegen, ob man das tun will oder nicht, oder vielleicht die Richtung zu ändern, in die man gehen will! GitHub zeigt in seiner API bereits Informationen an, die auf die Betrag der Vorschläge, die gezeigt wurden, und die Betrag der Vorschläge, die angenommen wurden (einschließlich Teilannahmen). Dies ist bereits ein Schritt nach vorn und hilft Ihnen, sich auf Folgendes zu konzentrieren Verlobung anstelle von Produktivität.

Worauf Sie sich stattdessen konzentrieren sollten

Ich empfehle, sich statt auf Codezeilen auf andere Dinge zu konzentrieren, um zu sehen, ob die Verwendung von GitHub Copilot eine Wirkung hat. Dazu gehört auch die Betrachtung des gesamten Lebenszyklus der Softwareentwicklung (SDLC):

• Zuallererst müssen Sie sich das Engagement und die Art des Engagements der Ingenieure ansehen. Verwenden sie das Tool tatsächlich und welche Funktionen nutzen sie? Ich treffe immer wieder auf Ingenieure, die nur die Inline-Vorschläge verwenden und die Chat-Funktion überhaupt nicht nutzen! Ich ertappe mich dabei, dass ich den ganzen Tag im Agentenmodus lebe, da ich weiß, wie ich die richtigen Dinge abfragen kann, um die richtigen Änderungen zu erhalten, anstatt alles selbst zu entwickeln. Ich denke in Geschäftswert, statt Code.
• Sehen Sie sich auch wenn sie das Tool verwenden. Wir denken immer noch, dass Ingenieure 8 Stunden am Tag und 5 Tage in der Woche arbeiten (je nach ihrem Zeitplan), aber in Wirklichkeit sind sie nur ein paar Stunden am Tag produktiv. Manchmal kämpfen sie sogar darum, 2 Stunden am Tag ununterbrochen an ihren Aufgaben arbeiten zu können! Fragen Sie doch einmal Ihre Ingenieure, wie viel Zeit sie für ihre Aufgaben haben. Ich sehe Teamkollegen mit überladenen Terminkalendern, die den ganzen Tag über mehrere Besprechungen parallel angesetzt haben. Kein Wunder, dass sie sich nicht auf ihre Aufgaben konzentrieren können! Allein diese Tatsache erstaunt mich jedes Mal aufs Neue, denn Unternehmen wollen immer noch den Return on Investment (ROI) für die Investition von Zeit in ein Tool wie GitHub Copilot definieren und nachweisen. Die normale Business-Lizenz kostet 19$ pro Monat und die Enterprise-Lizenz 49$ pro Monat. Wenn Sie ausrechnen, dass Sie dem Ingenieur eine Verbesserung geben und ihn etwa 1 Stunde pro Monat Zeit sparen lassen müssen, um kostendeckend zu arbeiten, können Sie sehen, dass der ROI leicht erreicht wird. Natürlich ist dabei die anfängliche Einarbeitungszeit nicht berücksichtigt (meiner Meinung nach gibt es eine ziemliche Lernkurve!), aber dennoch ist der ROI insgesamt leicht zu erreichen.
• Als nächstes werfen wir einen Blick auf die nachgelagerten Änderungen im SDLC. Wurden mehr Pull Requests erstellt als zuvor? Sind die PRs kleiner oder größer als zuvor? Gibt es mehr oder weniger Build-Fehler (was darauf hindeutet, dass die Benutzer in der Pipeline testen, anstatt lokal zu testen)? Finden Sie mehr oder weniger Bugs in der Produktion? Gibt es mehr oder weniger Zwischenfälle in der Produktion? All diese Dinge zeigen, welche Auswirkungen die Verwendung von GitHub Copilot in Ihrem Unternehmen hat.
• wir vergessen auch immer wieder, dass es heutzutage fast schon erwartet wird, dass diese Tools für Ihre Ingenieure zur Verfügung stehen. Es wird zu einer normalen Sache, genau wie die Verfügbarkeit einer anständigen Umgebung zusammen mit anderen Tools wie einer guten IDE, einem guten Versionskontrollsystem und einer guten CI/CD-Pipeline. Wenn Sie diese Tools nicht zur Verfügung haben, werden Sie es schwer haben, neue Ingenieure für Ihr Unternehmen zu gewinnen, und schlimmer noch, die vorhandenen Talente könnten Ihr Unternehmen deswegen verlassen. Und Sie können davon ausgehen, dass Ihre Konkurrenten ihren Ingenieuren diese Tools bereits zur Verfügung stellen! Können Sie es sich also überhaupt leisten, in diesem Bereich zurückzubleiben?
• Als Nächstes sollten wir schneller an der Bohrteile unserer Aufgaben, bei denen wir standardmäßige Dinge wie Boilerplate-Code einfacher und schneller implementieren können. Das Ziel ist hier nicht, mehr zu sein produktiv meiner Meinung nach, sondern um Ihre wertvolle Zeit zurückzugewinnen, die Sie für die interessanteren Teile Ihrer Arbeit nutzen können! Nutzen Sie die Zeit, die Sie sparen, um an den Dingen zu arbeiten, die für Sie interessanter sind oder für die Sie normalerweise keine Zeit haben. Ich empfehle Ihnen, vor allem in der Einarbeitungsphase von Copilot Initiativen zu ergreifen, um sich auf die Aufgaben zu konzentrieren, für die Sie nie Zeit zu haben scheinen. Lassen Sie sich in den nächsten beiden Sprints von Copilot dabei helfen, eine bessere Testabdeckung zu erreichen. Bitten Sie Copilot, Stellen ausfindig zu machen, die zu einem besser wartbaren oder lesbaren Code umstrukturiert werden können. Sie werden erstaunt sein, was er alles für Sie finden kann. Trauen Sie sich zum Beispiel, den Agentenmodus zu verwenden und ihn zu bitten, alle Ihre TODOs in der Codebasis zu finden und sie einzeln zu bearbeiten (oder mit Hilfe des GitHub MCP-Servers Issues daraus zu erstellen). Sortieren Sie die niedrig hängenden Früchte mit Copilot aus und bitten Sie ihn um eine Lösung. Sie haben noch keinen Linter in Ihrem Projekt? Fügen Sie ihn hinzu und bitten Sie Copilot, alle Linting-Probleme zu beheben, die er findet. Vergessen Sie immer wieder, Ihre Abhängigkeiten zu aktualisieren? Bitten Sie Copilot um eine Dependabot-Konfiguration für alle Ökosysteme, die Sie in Ihrem Repo haben. Wollten Sie schon immer Ihre Linting-/Einheitstests in einer CI-Pipeline (Continuous Integration) ausführen und sind nie dazu gekommen? Raten Sie mal... Copilot kann hier helfen! Die Möglichkeiten sind endlos, und Sie können Copilot verwenden, um Ihnen bei den langweiligen Teilen Ihrer Arbeit zu helfen.

Was kommt als Nächstes?

In diesem Blogpost habe ich aufgeschrieben, wie wir meiner Meinung nach unsere Denkweise in Bezug auf Produktivität ändern müssen. Dann sind wir frei, darüber nachzudenken, wie GitHub Copilot die Art und Weise verändert, wie wir unsere Anwendungen produzieren und unseren Endbenutzern einen echten Mehrwert bieten. Und noch besser, wie wir unsere Produktivität steigern und auch unseren nicht-technischen Teammitgliedern ermöglichen können, effizienter zu arbeiten. Mehr dazu habe ich in diesem Blogpost geschrieben GitHub Copilot - Ändern Sie das Narrativ.

Lassen Sie uns in die richtige Richtung arbeiten und den zukünftigen Zustand des Arbeitens umarmen, indem wir die generative KI mehr und mehr nutzen und die Vergangenheit hinter uns lassen. Ich denke, wir werden mehr und mehr zu einem Orchestrator von KI-Agenten werden, und die Agenten können nur dann schneller arbeiten, wenn wir verstehen, wie wir eine solide Grundlage schaffen, auf die wir vertrauen können (siehe diesen Blogpost).