Teambasierter Pragmatismus und Engineering

Wenn es darum geht, irgendeine Art von Entwicklung durchzuführen – es ist mir egal, ob es für das Internet, für Mobilgeräte oder für eine andere Plattform ist – gibt es viele Bücher, Online-Kurse und so weiter, die es unglaublich einfach machen, was auch immer zu lernen Sie wollen lernen.

Um es klar zu sagen, ich klopfe auch nicht an eine der Möglichkeiten, die zum Lernen zur Verfügung stehen. Schließlich lernen wir alle auf unterschiedliche Weise, oder? Und wer bin ich, wenn ich sage, welcher Weg besser ist als jeder andere, besonders angesichts der Tatsache, dass ich täglich über Themen hier und auf anderen Seiten schreibe ?

Aber ich kann definitiv sagen, dass für mich – jemand, der sowohl durch formale Bildung, Tutorials, Kurse usw. gelernt hat – der beste Weg, um Erfahrungen in dieser Branche zu sammeln, zweierlei war:

• Zusammenarbeit mit anderen Menschen,
• Dinge kaputt machen und lernen, wie man sie repariert.

Meine ich damit, es in dieser bestimmten Reihenfolge zu tun? Nö. Bedeutet das, dass ich anderen um Längen voraus bin? Das ist lächerlich.

Aber da ich das Vergnügen hatte, mit anderen an mehreren Projekten zusammenzuarbeiten, mit anderen über Twitter, Konferenzen usw. zu sprechen und sowohl das Gute als auch das Schlechte erlebt zu haben, sollte meiner Meinung nach jeder die Möglichkeit haben, dies irgendwann zu tun.

Wenn ich es zusammenfassen müsste, würde ich sagen, dass es darum geht, eine Balance zwischen teambasiertem Pragmatismus und Ingenieurskunst zu finden. Warum aber mache ich mir die Mühe, jetzt darüber zu schreiben, wenn nichts von dem oben Gesagten neu ist (wenn man bedenkt, dass es Softwareunternehmen schon seit Jahrzehnten gibt)?

Teambasierter Pragmatismus und Engineering

Ich könnte wahrscheinlich eine lange Liste mit Gründen aufstellen, warum ich dieses spezielle Thema für wichtig halte, aber es gibt drei spezifische Dinge, die ich in diesem Beitrag erwähnen möchte. Und aus Gründen der Länge (sprich: Zeit) werde ich tun, was ich tun kann, um sie kurz zu halten.

Tatsächlich hat das TL;DR dessen, worüber ich sprechen werde, mit Pragmatismus und Ingenieurskunst zu tun. Ursprünglich wollte ich auch eine Perspektive auf das Geschäft im Allgemeinen einbeziehen, aber das hat den allgemeinen Beitrag etwas vom Thema abgebracht.

1 Pragmatismus

Ich habe schon früher über die Balance zwischen Technik und Pragmatismus geschrieben.  Ich habe also vielleicht nicht viel Neues zu bieten, aber ich fange an, meine Perspektive ein wenig zu ändern.

Das heißt, an einem Punkt ging es streng darum, ein Gleichgewicht zu finden zwischen der Suche nach einer Lösung, die für den Kunden funktioniert, die gut gebaut ist und die ihr Problem löst. Und dem schließe ich mich immer noch an.

Und natürlich spricht einiges dafür, wie der Code organisiert ist, damit er im Laufe der Zeit beibehalten werden kann. Das ist der Schlüssel. Aber wie der Code geschrieben wird und die Lösung gebaut wird, sind Dinge, die in Bezug auf Pragmatismus etwas verschwommener werden können.

Das heißt, es ist einfach, einfachen objektorientierten Code zu schreiben, ihn zu dokumentieren, ein paar Klassen oder Funktionen einander aufrufen zu lassen, sich in WordPress einzuklinken und dann Schluss zu machen.

2 Ingenieurskunst

Aber ist diese Ebene der Balance zwischen Versand die Lösung und Architektur der Lösung ist ein schmaler Grat. Ich glaube jedoch, dass es gefährlich ist, zu pragmatisch zu sein: Wenn Sie versuchen, immer so pragmatisch wie möglich zu bleiben und Ihre Ingenieursfähigkeiten auf einem bestimmten Niveau zu belassen, können Sie als Entwickler nicht weiterkommen.

Obwohl ich es bei meiner Arbeit vorziehe, objektorientierte Programmierung zu verwenden, bin ich keiner, der in einen Religionskrieg gerät oder in welche Version welcher Sprache, welcher Technologie oder ob funktional, prozedural oder objektorientiert Programmieren ist besser.

Einfach ausgedrückt: Es geht um das allgemeine Qualifikationsniveau, das Sie im Laufe Ihrer Karriere erreichen können.

Und wenn ich mit Entwicklern zusammenarbeite, die an Projekten mit unterschiedlichen Fähigkeiten gearbeitet haben, die auf unterschiedliche Weise ausgebildet wurden und die verschiedene Arten von Problemen gelöst haben, lerne ich ständig neue Dinge.

Das soll nicht heißen, dass es keine Gespräche über Dinge gibt, die wir möglicherweise als Team oder als Partnerschaft implementieren, aber es kann verhindern, dass das Potenzial, als Programmierer zu wachsen, beeinträchtigt wird.

Ich könnte weiter darüber sprechen, aber kurz gesagt: Wenn Sie mit anderen zusammenarbeiten, stellen Sie sicher, dass sie erfahren sind, genießen Sie die Verwendung der gleichen Art von Paradigmen wie Sie, seien Sie offen für nachdenkliche Gespräche und bringen Sie ein vielfältige Erfahrung auf den Tisch.

Letztendlich kann dies dazu beitragen, sowohl Ihre Fähigkeiten als auch die Qualität dessen, was Sie und Ihr Team auf den Tisch bringen, zu verbessern.

Es gibt immer mehr

Wie ich schon früher im Beitrag sagte, es gibt immer mehr. Ich werde wahrscheinlich in zukünftigen Beiträgen mehr über den geschäftlichen Aspekt sprechen.

Aber jetzt lasse ich das, was ich geschrieben habe, dort, wo es sitzt, und werde später von dort aus weitermachen.