Juli 2015

Band 30, Nummer 7

Upstart - deshalb es schwer zu sprechen über Tech ist

Von Ryder Donahue | Juli 2015

Das schwierigste Teil über das Entwickeln von Software könnte darüber zu reden. Jeden Tag müssen Entwickler erläutern tiefgehende technische Detail und breiten logische Konzepte, oft für Menschen mit nur einem vorbeifahrenden Verständnis von was sie reden.

Ich sehe Menschen kämpfen mit die ganze Zeit und ich glaube nicht, dass es ist, weil sie schlechte Kommunikatoren sind oder schlechte Ideen haben. Es ist denn reden über etwas so abstrakt, wie Code äußerst schwierig ist. Dies wäre nicht so ein Problem sein, wenn Kommunikation ein seltenes Ereignis in der Softwareentwicklung waren, aber in der Tat ist es genau umgekehrt. Effektive Kommunikation ist das Herzstück jeder erfolgreiche Team-basierte Software-Entwicklung-Anstrengung.

Selbst wenn Sie freiberuflicher Programmierer, kann schwierig zu verstehen und zu liefern, was ein Kunde wünscht anstrengende Arbeit. Die Herausforderung wird noch härter an großen Projekten mit vielen Entwicklern, wo jedes Teammitglied auf verschiedene Teile eines Puzzles arbeitet, die zusammenpassen müssen.

Zeigt jemand einige Code oder sogar Pseudo-Code, kann eine gute Möglichkeit, Ihre Ideen vermitteln, erhalten aber manchmal nicht der Code zur Verfügung, oder zu groß durch andere während eines Gesprächs sofort genutzt werden. Daher sind wir oft auf Hand winkend und erhabenen Beschreibungen verbannt.

Ein weiterer Fallstrick ist, wenn Entwickler davon ausgehen, die Menschen, die, denen Sie sprechen, sind vertraut mit dem Jargon und Akronyme, die sie in ihren Erklärungen passen, oder dass andere haben das Vorwissen des referenzierten Hilfsfunktionen. Wenn die andere Partei einen wackeligen Griff dieser Konzepte hat, werden es langsam, — wenn nicht völlig zu stoppen — der Weg zum Verständnis. Sobald eine Person eine ungewohnte Abkürzung hört, ist mehr im folgenden Dialog unterlag sie, als sie für Kontext zu kämpfen.

Generell erfordert ein erfolgreicher Dialog über Programmierung, dass beide Parteien in ihren Köpfen zu Beginn des Gesprächs einen ähnlichen Plan halten. Diese Blaupause kann der Kontext des Codes sein, Sie schreiben, oder auch die Architektur des gesamten Projekts. Während dieses Bit normalerweise aus einer Notwendigkeit heraus erklärt wird, ist es nicht immer sehr gut erklärt — UML-Diagramme sind normalerweise zu unbequem und oft es gibt einfach keine Zeit, alle Objekte und Strukturen im Detail zu überprüfen. Fazit: Mannschaften oft nicht erfüllen, fundierte Entscheidungen zu fahren, doch wir alle tun es trotzdem weiter.

Kommunikation ist eine große Herausforderung und mit denen ich persönlich Kämpfe. Aber es ist eine Schwäche, die, wenn bestätigt, bearbeitet werden kann. Als Entwickler, müssen wir uns daran erinnern, dass andere nicht unser Gedankengang so eng folgen können wie wir glauben. Auf der anderen Seite müssen wir bereit sein, lassen andere wissen, wann wir zu kämpfen haben, verschiebt ein Konzept vor dem Gespräch mit dem nächsten Thema zu verstehen.

Angesichts all dieser Schwierigkeiten, finde ich es für ein Triumph des Software-Engineering, die eine Produkt wie Windows auch auf allen funktioniert gegeben, die Tausende von Ingenieuren, die im Laufe der Jahre daran gearbeitet haben.

Vielleicht reden Tech wird immer schwierig sein, oder vielleicht als relativ junge Disziplin der Softwareentwicklung reift, werden wir eine effektivere Methoden der Kommunikation entwickeln sehen. Vielleicht liegt die Lösung in der Technologie selbst, mit besserer Tools für die Zusammenarbeit und mehr konzentriert und Programmiersprachen entwickelt. Wenn die Programmiersprachen der Zukunft mit klarer und intuitive Syntax entworfen sind und beseitige das ausführliche Gepäck von primitiven Sprachen übernommen, können wir sehen Code, die wir können schneller lesen und deren Bedeutung wird leichter absorbiert. Vielleicht liegt Teil der Lösung in neuere, bessere Programmierung Paradigmen, die bessere Analogie-gesteuerte Erklärungen ermöglichen als auch objektorientierte Programmierung jetzt bieten kann.

Eines ist klar, wer erstellt und verabschiedet diese Lösungen einen erheblichen Vorteil gegenüber den gewinnen, die weiterhin Wandern in den Sandsturm von Akronymen und Hand winkend, die Softwareentwicklung heute charakterisieren.


Ryder Donahue ist als Software-Entwickler-Engineer bei Microsoft. Ursprünglich lebt von den hawaiischen Inseln, er in Redmond, Washington, mit seiner Verlobten und ihre Katze, Murmeln.