4 Hacks, um Frontend-Tests 10x schneller zu schreiben (wahrscheinlich!)
Wir alle wissen, dass das Schreiben von Komponententests wichtig ist, aber manchmal fühlt es sich an, als ob es mehr Zeit in Anspruch nehmen kann als die Feature-Arbeit selbst. Ich habe ein paar praktische Hacks gefunden, von denen ich glaube, dass sie meine Geschwindigkeit beim Schreiben von Tests erhöht und gleichzeitig deren Qualität verbessert haben. Da ich der nette Kerl bin, werde ich sie mit Ihnen teilen:
Hack 1: Benutze Testing Playground
Ich denke, der erste Tipp in diesem Artikel ist - benutze Bibliothek zum Testen. Ich habe das nicht zu meinem eigenen Argument gemacht, weil es bereits so beliebt ist. Aber wenn Sie es noch nicht verwenden, stellen Sie sicher, dass Sie es tun!
Unit-Tests mit der Testing Library sind wirklich einfach und intuitiv. Trotzdem kann es immer noch schwierig sein, die richtigen Abfragen zu finden oder zu verstehen, warum ein Element nicht gefunden wird.
Geben Sie ein Playground testen.
Beim Testen von Playground können Sie eine Komponente in einer Sandbox rendern, sodass Sie direktes visuelles Feedback der Komponente erhalten. Außerdem können Sie mit der gerenderten Komponente interagieren, um die besten Abfragen für die Auswahl von Elementen zu erstellen. Und wie bei Testing Library steht bei allem, was es tut, Barrierefreiheit (a11y) im Vordergrund, sodass Sie bei der Verwendung von a11y über die Bedeutung von a11y und über bewährte Methoden informiert werden.
Es gibt viele Möglichkeiten, Testing Playground zu verwenden, einschließlich eines Chrome-Geräts Ausdehnung und ein browserbasierte App.
Der beste Weg, den ich gefunden habe und der für mich eine absolute Zeitersparnis war, ist der Aufruf screen.log testingPlaygroundUrl () direkt aus dem Testblock selbst. Normalerweise mache ich das, sobald ich das Komponenten-Rendering habe, nur um mir einen Überblick zu verschaffen und herauszufinden, mit welchen Teilen mein Test interagieren möchte.
Hack 2: Benutze test.todo
Bitte springen Sie mir nicht an die Gurgel, aber ich habe es versucht Testgetriebene Entwicklung und mochte es nicht. Wie beim Anarchismus finde ich, dass es in der Theorie großartig klingt, aber ich habe festgestellt, dass es meinen Entwicklungszyklus tatsächlich verlangsamt hat, als ich versuchte, ihn umzusetzen.
Mir gefällt jedoch immer noch die Idee, etwas über das Testen nachzudenken, bevor ich mit der Entwicklung eines Features fertig bin und mich für einen Prozess entschieden habe, der für mich gut zu funktionieren scheint und meine Entwicklung vorantreibt.
Ich verwende jetzt test.todo von Jest, um aufzuzeichnen, was ich testen werde, während ich ein Feature plane und ausbaue (Vielen Dank an Karl dafür, dass du mir die Idee zum ersten Mal vorgestellt hast!).
Mein üblicher Prozess läuft ein bisschen so ab. Zuerst erfasse ich die Anforderungen, die mein großartiger Product Owner (Hi Biz!) für mich formuliert hat im test.todo-Format, wie eine Todo-Liste. Wenn ich dann baue und auf andere Randfälle und wichtige Testbereiche stoße, füge ich diese auch als test.todo's hinzu. Auf diese Weise habe ich in Bezug auf die Testzeit vieles durchdacht, was ich testen werde, und es ist weniger wahrscheinlich, dass ich das Testen von Randfällen oder wichtigen funktionalen Anforderungen übersehe.
Ein einfaches Beispiel für ein test.todo für die folgende Komponente: <UserDetails />
importiere React aus „react“; Exportschnittstelle User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} Exportschnittstelle showHideUserDetailsProps {showDetails: boolean; user: user;} const userDetails = ({showDetails, user}: showHideUserDetailsProps) => (<> {showDetails? (<div><h1>Benutzerdetails</h1> <ul><li>{User.FirstName}</li> <li>{User.LastName}</li> <li>{user.username}</li> <li>{user.emailAddress}</li> <li>{user.SEN}</li></ul></div>): (<div><h1>Privacy Protected</h1></div>)} </>); Standard-Benutzerdetails exportieren;
Könnte wie folgt aussehen:
describe ('<UserDetails />', () => {test.todo ('Sollte Benutzerdetails anzeigen, wenn „Details anzeigen“ wahr ist'); test.todo ('Sollte KEINE Benutzerdetails anzeigen, wenn „Details anzeigen“ falsch ist');});
Hack 3: Builder-Funktionen verwenden
Früher habe ich für jeden Test Objekte erstellt, um Werte für das Testen nachzuahmen. Dann habe ich eine weitere Komponente geschrieben, die dasselbe Objekt verwendet hat, und es dort wieder verspottet. Es muss einen besseren Weg geben, dachte ich. Und Matt Smith von FinoComp hat mir einen vorgestellt.
Ich verwende jetzt Builder-Funktionen, die beim Testen häufig verwendete Objekttypen zurückgeben und es ermöglichen, Eigenschaften überall zu überschreiben. Es ist sicherlich ein bisschen mehr Zeit erforderlich, um sie einzurichten, aber ich finde, dass Sie, wenn sie einmal fertig sind, das nächste Mal, wenn Sie mit dem Objekt interagieren müssen, so froh sind, dass sie da sind.
//Beispiel für das Typinterface User {firstName: string; lastName: string; username: string; emailAddress: string; SEN: string;} interface showHideUserDetailsProps {showDetails: boolean; user: user;}//Builder-Muster zum Erstellen eines Scheinobjekts für den//showHideUserDetailsProps Typeexport const buildShowHideUserDetailsProps = (überschreibt? : Teilweise<ShowHideUserDetailsProps>): showHideUserDetailsProps => {const defaultShowHideUserDetailsProps = {showDetails: false, user: {firstname: „Jazmyne“, lastname: „Jacobs“, username: „Kylee_Skiles37", emailAddress:" Rashawn13@gmail.com „, SEN: „SEN-123456"}}; return {... defaultShowHideUserDetailsProps,... überschreibt};};
Dieses Muster weist jedoch einige Einschränkungen auf, da es bei tief verschachtelten Objekttypen weniger nützlich ist. Außerdem müssen sie gewartet werden, wenn sich Objekttypen in der Codebasis ändern, was mich zu meinem nächsten Punkt bringt...
Hack 4: Benutze ein Tool, um deine Typescript-Typen nachzuahmen
Schau, ich werde direkt herkommen. Das ist der Teil, in dem ich meine eigene Arbeit einfüge, aber wenigstens habe ich sie zum Schluss gelassen, oder?
Immer wenn ich ein anderes Scheinobjekt zum Testen erstellte, schaute ich mir meine Typescript-Typen an und dachte, kann sich das nicht etwas ansehen und für mich tun? Das hat mich auf die Suche nach einer Lösung geschickt und ich war so begeistert, sie zu finden Zwischenmatte welches ist ein Befehlszeilentool, das genau das tut. Es ist zwar noch in Arbeit und hat einige Einschränkungen, aber ich fand es sehr hilfreich beim Schreiben von Tests.
Ich fand es allerdings etwas umständlich, die Kombination aus CLI und Kopieren/Einfügen vom Terminal aus zu verwenden. Wie könnte ich das noch einfacher machen, dachte ich.
Gib meine VSCode-Erweiterung ein, Emulativ. Wählen Sie einfach Ihren Typnamen aus, führen Sie einen Befehl über die Befehlspalette in VSCode aus und Sie können Emulative verwenden, um Typescript-Objekte, Json-Objekte oder die oben genannten Builder-Funktionen aus Typescript-Typen zu erstellen. Diese werden automatisch in die Zwischenablage kopiert, aber die einfachen Objekte können auch in eine neue Scratch-Datei gesendet werden.
Aber warte, es gibt noch mehr! Wo ich arbeite Einfach und agil Wir haben eine Reihe von Eigenschaften, mit denen wir von Jira arbeiten, die nicht genau durch eine Zeichenfolge oder Zahl dargestellt werden. Mit Emulative können Sie Schlüssel/Wert-Paare einrichten, die alle passenden Eigenschaften, die in Ihren Typen enthalten sind, überschreiben.
Ein Lob an Easy Agile, dass sie mir während einer Inception Week die Zeit, die Ressourcen und die Ermutigung gegeben haben, an Emulative zu arbeiten!
Nun, das war's für mich. Ich hoffe, Sie finden einige dieser Tipps und Tricks nützlich, um Frontend-Tests zu beschleunigen.
In jedem Fall können Sie sich gerne in den Kommentaren über raffinierte Tricks äußern, die Sie gefunden haben, um Ihre Komponententestgeschwindigkeit zu verbessern (oder einfach, wie falsch ich in Bezug auf TDD liege).
Verwandte Artikel
CompanyEin Tag im Leben von Jamie
Es ist Montagmorgen und ich bin gerade auf dem Parkplatz des Bahnhofs Kiama eingefahren.
Es ist ein kurzer Weg zum zentralen Geschäftsviertel von Wollongong, wo ich beim Betreten des Büros vom Team begrüßt werde.
Wir beginnen den Tag mit einer morgendlichen Runde, in der jeder von uns etwas Gutes erzählt, das in den letzten 24 Stunden passiert ist, woran wir an diesem Tag arbeiten werden und ob wir auf irgendwelche Blocker gestoßen sind.
Das gesamte Team macht dann einen Spaziergang zum örtlichen Café Beast und trinkt gemeinsam einen Kaffee. Es ist eine wunderbare Art, den Tag mit einer Gruppe inspirierender Menschen zu beginnen.
Für mich steht der Kundensupport als Nächstes an und ich freue mich sehr darauf, unseren Kunden auf ihrer täglichen Reise mit unserem Produkt zu helfen. Meine bisherigen Erfahrungen im Kundensupport haben mir gezeigt, wie sehr Kunden zeitnahe und hilfreiche Antworten schätzen. Es kann den Tag einer Person wirklich verändern.
Wenn Kunden beantwortet wurden, setze ich meine tägliche Arbeit mit den Tools von Easy Agile fort. Ich kann mit Sicherheit sagen, dass dies die Verwaltung und Bearbeitung von Sprints erheblich erleichtert.
Ich habe tolle Teamkollegen. Wenn ich etwas besprechen, Feedback einholen oder mich zusammenschließen möchte, ist mein Kollege Matt immer da, um zu helfen. Hier ist er:
Er ist ein echter Verfechter der Software-Handwerkskunst, und ich stimme diesem Ansatz voll und ganz zu.
Gegen Mittag machen wir alle eine Mittagspause. Einige von uns holen sich etwas zum Mitnehmen im örtlichen Einkaufszentrum, und andere bringen etwas von zu Hause mit, aber im Allgemeinen sitzen wir alle zusammen und genießen die Gesellschaft des anderen. Freitags zieht der Straßenmarkt die Aufmerksamkeit der meisten von uns auf sich. Normalerweise wird es eine Session auf der Switch geben — Mario Kart oder Smash Bros sind die beliebtesten Optionen.
Nach dem Mittagessen geht es wieder los und ich checke mit Dave ein, um zu sehen, wie es läuft. Wir besprechen meine bisherige Reise und meine Ideen für unsere bevorstehende Eröffnungswoche.
Es ist großartig, sich hinzusetzen und darüber zu sprechen, wie wir unsere Systeme verbessern und die tägliche Arbeit unseres Teams verbessern können.
Es gibt noch ein paar Dinge zu erledigen und dann ist es Zeit, zum Bahnhof zu fahren, um nach Hause zu pendeln. Matt und ich unterhalten uns über Softwarearchitektur und verpassen fast den Zug.
Wenn ich auf die letzten Wochen bei Easy Agile zurückblicke, fallen mir die Kultur und die Werte des Teams auf.
Das Bekenntnis zu Integrität, Ehrlichkeit, Inklusion und Arbeitsphilosophie ist wirklich inspirierend und ermutigend. Meiner Erfahrung nach habe ich noch nie einen Arbeitstag begonnen, an dem alle etwas Positives teilen. Das gibt wirklich den Ton für die folgenden Stunden an.
Easy Agile ist ein großartiges Unternehmen, besonders wenn ich es mit meinen Erfahrungen der letzten 20 Jahre in den Bereichen Fertigung, Kundensupport und Softwareentwicklung vergleiche. Das Team von Easy Agile zeigt praktisch einen ganzheitlichen Ansatz für Arbeit und Leben, der gleichermaßen erfrischend und ermutigend ist.
Workflow8 Methoden der Softwareentwicklung erklärt
Softwareentwicklungsteams sind dafür bekannt, eine Vielzahl agiler Methoden, Ansätze und Tools einzusetzen, um Kunden einen Mehrwert zu bieten. Je nach den Bedürfnissen des Teams und der am Produkt Beteiligten ist es üblich, dass Teams eine Kombination von Softwareentwicklungsmethoden einsetzen und nutzen.
Die meisten Entwicklungsteams kombinieren Methoden und Frameworks, um ihren eigenen einzigartigen Ansatz für die Produktentwicklung zu entwickeln. Sie werden feststellen, dass sich viele Prinzipien von einer Methode zur nächsten überschneiden. Der Schlüssel liegt darin, ein System auszuwählen und als Team daran zu arbeiten, diesen Ansatz zu verfeinern und zu verbessern, damit Sie weiterhin Verschwendung reduzieren, die Effizienz maximieren und die Zusammenarbeit optimieren können.
In diesem Beitrag werden wir die folgenden acht Softwareentwicklungsprozesse skizzieren und vergleichen:
1. Methodik der agilen Softwareentwicklung
2. Wasserfall-Methodik
3. Funktionsorientierte Entwicklung (FDD)
4. Methodik der schlanken Softwareentwicklung
5. Methodik der Scrum-Softwareentwicklung
6. Extreme Programmierung (XP)
7. Schnelle Anwendungsentwicklung (RAD)
8. DevOps-Bereitstellungsmethodik
1. Methodik der agilen Softwareentwicklung
Agil ist der gebräuchlichste Begriff zur Beschreibung von Entwicklungsmethoden. Er wird häufig als Überbegriff für Methoden verwendet, die agil sind. Dabei handelt es sich um einen iterativen Prozess, der Verschwendung reduziert und die Effizienz maximiert.
Die meisten Softwareentwicklungsmethoden sind agil und legen im Gegensatz zum traditionellen Projektmanagement einen starken Schwerpunkt auf Iteration, Zusammenarbeit und Effizienz. Es ist, als würde man Jazz mit klassischer Musik vergleichen. 🎷
Traditionelle, lineare Managementmethoden, wie die Wasserfallmethode, auf die wir weiter unten eingehen werden, sind wie klassische Musik, die von einem Dirigenten geleitet wird, der einen festen Plan hat, wie die Musik gespielt werden sollte. Der agile Prozess ähnelt dagegen eher dem Jazz, der durch Zusammenarbeit, Experimente und Iteration zwischen den Bandmitgliedern zustande kommt. Er ist anpassungsfähig und entwickelt sich mit neuen Ideen, Situationen und Richtungen weiter.
2. Die Wasserfall-Methodik
Das Wasserfall-Ansatz ist eine traditionelle Methode, die in der Softwareentwicklung nicht mehr sehr verbreitet ist. Viele Jahre lang war das Wasserfallmodell die führende Methode, aber sein starrer Ansatz konnte den dynamischen Anforderungen der Softwareentwicklung nicht gerecht werden.
Es ist üblicher, dass die Wasserfallmethode eher für das Projektmanagement als für die Produktentwicklung verwendet wird. Zu Beginn eines Projekts sammeln Projektmanager alle notwendigen Informationen und verwenden sie, um im Vorfeld einen fundierten Aktionsplan zu erstellen. Normalerweise ist dieser Plan ein linearer, schrittweiser Prozess, bei dem eine Aufgabe in die nächste übergeht, was ihr den Namen „Wasserfall“ gibt.
Der Ansatz ist planorientiert und starr, sodass wenig Spielraum für Anpassungen bleibt. Es ist mehr oder weniger das Gegenteil von agil und legt Wert darauf, sich an den Plan zu halten, anstatt sich an neue Umstände anzupassen.
3. Funktionsorientierte Entwicklung (FDD)
Feature-getriebene Entwicklung wird auch als ältere Methode angesehen. Obwohl sie einige agile Prinzipien verwendet, wird sie als der Vorgänger der heutigen agilen und schlanken Methoden angesehen.
Wie der Name schon sagt, konzentriert sich dieser Prozess auf die häufige Implementierung von Funktionen, die vom Kunden geschätzt werden. Es ist ein iterativer Prozess, bei dem alle Augen darauf gerichtet sind, den Endbenutzern greifbare Ergebnisse zu liefern. Der Prozess ist adaptiv und verbessert sich auf der Grundlage neuer Daten und Ergebnisse, die regelmäßig gesammelt werden, um Softwareentwicklern zu helfen, Fehler zu erkennen und darauf zu reagieren.
Diese Art von fokussierter agiler Methodik kann für einige Teams funktionieren, die einen stark strukturierten Ansatz und klare Ergebnisse wünschen und gleichzeitig einen gewissen Spielraum für Iterationen lassen.
4. Methodik der schlanken Softwareentwicklung
Schlanke Softwareentwicklung basiert auf den Prinzipien der schlanken Fertigung. Im Kern zielt Lean Development darauf ab, die Effizienz zu verbessern, indem Verschwendung vermieden wird. Durch die Reduzierung von Aufgaben und Aktivitäten, die keinen echten Mehrwert bieten, können die Teammitglieder mit optimaler Effizienz arbeiten.
Das fünf Lean-Prinzipien Stellen Sie einen Arbeitsablauf bereit, den Teams verwenden, um Verschwendung zu identifizieren und Prozesse zu verfeinern. Lean ist auch ein Leitgedanke, der Menschen helfen kann, effizienter, produktiver und effektiver zu arbeiten.
Die Philosophien und Prinzipien von Lean können auf agile und andere Softwareentwicklungsmethoden angewendet werden. Die Lean-Entwicklung bietet eine klare Anwendung für die Skalierung agiler Praktiken in großen oder wachsenden Organisationen.
5. Methodik der Scrum-Softwareentwicklung
Gedränge ist ein System, das regelmäßig von Softwareentwicklungsteams verwendet wird. Wie viele Softwareentwicklungsmethoden ist Scrum agil und konzentriert sich auf einen wertorientierten Ansatz. Der Scrum-Prozess basiert auf Empirismus, der Theorie, dass Wissen aus praktischer Erfahrung und beobachtbaren Fakten stammt.
Ein Scrum findet über einen voreingestellten Zeitraum statt, der als Sprint bezeichnet wird. Normalerweise liegt der Zeitrahmen zwischen zwei und vier Wochen und das Scrum befindet sich zu Beginn des Sprints. Das Ziel jedes Sprints ist es, eine unvollständige, aber fortschrittliche Version eines Produkts herauszugeben, die den Stakeholdern zur Verfügung gestellt werden kann, sodass Feedback sofort in den nächsten Sprint integriert werden kann.
Das Spezifische Ziele jedes Sprints werden bestimmt durch Produkteigentümer wer ordnet und priorisiert Backlog-Elemente (die Artefakte, die fertiggestellt werden müssen). Der Sprint-Prozess wiederholt sich immer wieder, wobei das Entwicklungsteam auf der Grundlage von Erfolgen, Misserfolgen und dem Feedback der Stakeholder Anpassungen vornimmt und iteriert.
Lernen mehr über Scrum — die komplette Programmplanungslösung für Jira.
6. Extreme Programmierung (XP)
Extremes Programmieren, auch XP genannt, ist eine Methode, die auf der Verbesserung der Softwarequalität und Reaktionsfähigkeit basiert. Es handelt sich um einen agilen Ansatz, der sich auf der Grundlage der Kundenanforderungen weiterentwickelt. Das ultimative Ziel ist die Erzielung qualitativ hochwertiger Ergebnisse. Qualität beschränkt sich nicht nur auf das Endprodukt — sie bezieht sich auf jeden Aspekt der Arbeit und gewährleistet Entwicklern, Programmierern und Managern ein großartiges Arbeitserlebnis.
Die Entscheidungsfindung beim Extremprogrammieren basiert auf fünf Werten: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Die Besonderheiten von XP können nicht für alle Situationen gelten, aber das allgemeine Framework kann unabhängig vom Kontext einen Mehrwert bieten.
7. Schnelle Anwendungsentwicklung (RAD)
Schnelle Anwendungsentwicklung (RAD), manchmal auch Rapid Application Building (RAB) genannt, ist eine agile Methode, die darauf abzielt, qualitativ hochwertige Ergebnisse mit einer kostengünstigen Investition zu erzielen. Der Prozess priorisiert das schnelle Prototyping und häufige Iterationen.
Die schnelle Anwendungsentwicklung beginnt mit der Definition der Projektanforderungen. Von dort aus entwerfen und bauen die Teams unvollkommene Prototypen, um sie den Stakeholdern so schnell wie möglich zur Verfügung zu stellen. Prototyping und Bau wiederholen sich immer wieder in Iterationen, bis ein Produkt vollständig ist und die Kundenanforderungen erfüllt.
Dies ist ideal für kleinere Projekte mit einem klar definierten Ziel. Der Prozess hilft Entwicklern, auf der Grundlage häufiger Rückmeldungen von Interessengruppen schnelle Anpassungen vorzunehmen. Es geht darum, schnelle Prototypen zu erstellen, die den Benutzern so schnell wie möglich konstruktives Feedback geben können. Dieses Feedback fließt in das Benutzerdesign ein, sodass Entwicklungsentscheidungen auf den direkten Gedanken und Bedenken derjenigen basieren, die das Produkt verwenden werden.
8. DevOps-Bereitstellungsmethodik
Das DevOps-Bereitstellungsmethodik ist eine Kombination aus Dev (Softwareentwicklung) und Ops (Information Technology Operations). Zusammen entwickeln sie eine Reihe von Verfahren zur Verbesserung der Kommunikation und Zusammenarbeit zwischen den Abteilungen, die für die Entwicklung eines Produkts verantwortlich sind.
Es handelt sich um eine kontinuierliche Kommunikationsschleife zwischen Produktentwicklern und Betriebsteams (IT-Betrieb). Wie so viele agile Prozesse ist es auf kontinuierliches Feedback angewiesen, um Teams dabei zu helfen, Zeit zu sparen, die Kundenzufriedenheit zu erhöhen, die Markteinführungsgeschwindigkeit zu verbessern und Risiken zu reduzieren.
Die Schritte der DevOps-Bereitstellung wiederholen sich mit dem Ziel, die Kundenzufriedenheit mit neuen Features, Funktionen und Verbesserungen zu erhöhen. Diese Methode weist jedoch einige Nachteile auf. Einige Kunden möchten keine kontinuierlichen Updates für ihre Systeme, sobald sie mit einem Endprodukt zufrieden sind.
Softwareentwicklung leicht gemacht
Die meisten Softwareentwicklungsteams verwenden eine Kombination aus Methoden und Frameworks, die zu ihrer Teamgröße, Teamdynamik und Art der zu erledigenden Arbeit passen. Der Schlüssel liegt darin, eine agile Methode zu verwenden und zusammenzuarbeiten, um Ihre Systeme kontinuierlich zu verbessern, während Sie lernen und wachsen.
Easy Agile hat es sich zur Aufgabe gemacht, Teams dabei zu helfen, besser mit Agile zusammenzuarbeiten. Wir entwerfen agile Apps für Jira mit einfacher, kollaborativer und flexibler Funktionalität. Von der Agilität des Teams mit Einfacher agiler Teamrhythmus, zu skalierter Agilität mit Einfache agile Programme, unsere Apps können Ihren agilen Teams helfen, Ihre Kunden besser zu beliefern.
Buchen Sie eine 1:1 -Demo um mehr über unsere Jira-Toolsuite zu erfahren, oder kontaktiere unser Team wenn Sie weitere Fragen haben. Wir bieten eine kostenlose 30-Tage-Testversion an, damit Sie unsere Produkte ausprobieren können, bevor Sie eine Verpflichtung eingehen.
CompanyMein Weg vom Psychologen zum Softwareentwickler
Wir überprüfen die Brandung und haben eine Weile nicht miteinander gesprochen. Zwei Augenpaare auf das Meer gerichtet. Lohnt es sich, an diesem windigen Wintermorgen rauszupaddeln? „Wo arbeitest du jetzt?“ fragst du abgelenkt. „Ich bin eigentlich Softwareentwickler.“ ' Ihre Augen brechen vor dem Anschwellen und suchen instinktiv nach Anzeichen eines Traumas oder Burnouts. „Wow, du hättest nichts anderes wählen können!“ sagst du, ein bisschen überrascht.
Ich habe immer wieder eine Version dieses Gesprächs geführt, seit ich von der Psychologie zum Programmieren gewechselt bin. Die Leute sind oft verwirrt darüber, wie sicher ich bin, dass ich die richtige Wahl getroffen habe, obwohl ich mit Mitte dreißig und um die Geburt meines ersten Babys eine lukrative Karriere verwarf, für die ich viel Zeit und Mühe aufgewendet hatte und für die ich gut geeignet zu sein schien.
Die Wahrheit ist, dass diese Änderung, als ich es tat, meine Gesundheit und das Glück meiner Familie erheblich verbessert hat. Es war ein Privileg, mit meinen Kunden zusammenzuarbeiten und ihre innersten Geheimnisse, Hoffnungen und Träume zu teilen. Es war auch extrem traumatisch und entmutigend und hat mich zermürbt. Dann sagte meine Frau eines Tages: „Sie müssen keine Psychologin sein, wissen Sie?“ Es mag offensichtlich erscheinen, aber dieser kurze Satz hat mir den Verstand geöffnet.
Ich begann darüber nachzudenken, was ich sonst noch tun möchte. Ich hatte Freunde von mir immer beneidet, die Schreiner oder Maurer waren und so viel Befriedigung darin zu finden schienen, ihr Handwerk allmählich zu beherrschen. Das Problem ist, ich kann schlecht mit Werkzeugen umgehen und kann ums Verrecken keinen Nagel hämmern. Ein Gespräch mit einem Freund, der Programmierer ist, in dem er auf die gleiche Weise über sein Handwerk sprach, brachte mich zum Nachdenken.
Ich habe an einem kostenlosen Online-Kurs teilgenommen, um das Terrain zu sondieren, und war sofort begeistert. Ich musste mich bemühen, jeden Abend zu einer anständigen Zeit ins Bett zu gehen, da ich immer mehr über Themen wie CSS, Browser, Clean Code und asynchrones Javascript erfuhr. Ein paar Wochen später begann ich meinen Master in Informationstechnologie und stürzte mich hinein.
Ok, ich dachte, es gibt keinen besseren Weg zum Lernen als bei der Arbeit, also habe ich mich an jedes Unternehmen gewandt, das ich in Fahrweite finden konnte, und bot an, alles zu tun, was auch nur nebenbei mit Programmieren zu tun hat, um einen Fuß in die Tür zu bekommen.
Zum Glück, die Wollongong-Tech-Community (Hallo zusammen Siligong!) ist aufgeschlossen und zwei großartige Unternehmen, zuerst FinoComp und jetzt Easy Agile, konnten meinen ungewöhnlichen Hintergrund hinter mir lassen, um mein Potenzial zu erkennen.
Ich bin jetzt ein echter Frontend-Entwickler und freue mich riesig darauf, jeden Tag zu arbeiten, mein Toolset zu erweitern und mein Handwerk zu verfeinern, um großartige Produkte für unsere Kunden zu entwickeln, die ihr Leben verbessern.
Für jeden da draußen, der über eine berufliche Veränderung nachdenkt, ist es nie zu spät. Es hat mein Leben zum Besseren verändert und es könnte auch deins verändern.
„Die Reise von tausend Meilen beginnt mit einem Schritt“ Lao Tzu.
(Oh, du solltest auf jeden Fall auch in dieser Brandung rauspaddeln. Unabhängig von den Bedingungen ist eine Brandung immer eine gute Idee.)