Was tun, wenn Sie vor einer Programmieraufgabe stehen, die Sie noch nie erledigt haben?

37

Ich habe meine Karriere vor drei Monaten als .NET-Entwickler begonnen. Nach einem langen Trainingsplan für verschiedene Technologien, Muster und Konzepte haben die Entwickler, die mich betreut haben, entschieden, dass ich bereit bin, an einem der vielen Projekte des Unternehmens teilzunehmen.

Ich freue mich sehr, endlich mit dem Codieren beginnen zu können. Das Team, dem ich beigetreten bin, ist vorerst eher klein, weil ich mit einem neuen Projekt angefangen habe. Das ist großartig, weil ich in den gesamten Lebenszyklus des Projekts involviert bin. Es handelt sich um ein webbasiertes SPA-Projekt mit einer gesicherten Oberfläche, die die ASP.NET MVC / ASP.NET-Web-API und im Front-End das Durandal-Framework und verwandte Bibliotheken verwendet.

Mein Problem ist, dass ich nach einem Treffen mit meinen Kollegen und der Festlegung der Aufgaben und Schätzungen für den nächsten Monat in einer Position bin, in der ich nicht weiß, ob ich in der Lage bin, eine der Aufgaben zu übernehmen.

Ich habe noch nie eine der erstellten Aufgaben erledigt und weiß nicht, wie ich vorgehen soll.

Beispielsweise besteht eine der erstellten Aufgaben darin, einen generischen Fehlerbehandlungsmechanismus für die gesamte Anwendung zu erstellen.

Wie geht man normalerweise vor, wenn man mit Aufgaben konfrontiert wird, die er nie erledigt hat?

aleczandru
quelle
7
Das mag sich beim Programmieren einzigartig anfühlen, aber alle ersten paar Jobs, die die meisten Leute machen, fühlen sich für sie so. Sie haben Sie nicht eingestellt, weil Sie die Antworten kannten - es ist ein Einstiegsjob! - Sie haben dich eingestellt, weil du sie herausfinden könntest.
Marco

Antworten:

59

Es gibt verschiedene Dinge, die Sie tun können und sollten, um sich auf die Aufgabe vorzubereiten:

  • Denken Sie über das Problem nach und zeichnen Sie einige Diagramme. Stellen Sie sicher, dass Sie das Problem kennen, das Sie lösen möchten.
  • Recherchiere, was du versuchst zu tun. Das Internet ist eine wertvolle Informationsquelle. Ich sage nicht Stapelüberlauf fragen - ich sage Nachforschungen darüber an, wie andere Leute bereits ein Problem wie das Ihre gelöst haben oder es angegangen sind. Das hat sich google ausgedacht: "Ausnahmebehandlung als systemweites Problem" . Ich persönlich versuche immer, von anderen zu lernen.
  • Und schließlich, und das ist vielleicht das Wichtigste, sprechen Sie mit den anderen Mitarbeitern Ihres Teams, um mehr Klarheit und Anweisungen zu erhalten, was zu tun ist. Ich möchte immer, dass neue Ingenieure bei Projekten um Rat fragen.

Nicht zu wissen, wie man etwas macht, wird niemals wirklich enden. Jeden Tag stoße ich auf Probleme, mit denen ich mich noch nie befasst habe. Es ist äußerst wichtig, herauszufinden, wie neue Probleme gelöst werden können. Auch alte Probleme sind nie ganz alt - in der Programmierung gibt es fast immer eine neue Wendung oder eine Aufforderung, dass Ihre Lösung auf eine neue oder andere Weise funktioniert.

Deshalb bin ich Ingenieur; Ich liebe es, neue Dinge herauszufinden.

Hören Sie nie auf, neue Dinge zu lernen. Lernen macht dich besser.

barrem23
quelle
27

Es gibt keine perfekte Lösung, aber einige Dinge, die helfen könnten:

  • Zerlegen Sie Aufgaben in kleinstmögliche Einheiten - zerlegen Sie sie, bis Sie die Dinge haben, die Sie tun können.

  • Wiederholen Sie die unmittelbar bevorstehende Aufgabe oder das Problem, um sicherzustellen, dass Sie es wirklich verstehen. Führen Sie dann eine Analyse durch und wiederholen Sie diese.

  • Wählen Sie zuerst die einfachste Aufgabe aus, auch wenn es zu einfach erscheint, nur um Schwung in Gang zu bringen . Einige Leute bevorzugen die schwerste Aufgabe, so dass die "harte Arbeit" aus dem Weg ist. Ich habe festgestellt, dass "einfachste Aufgabe" im Allgemeinen besser funktioniert, da Sie nur versuchen, etwas Schwung in Gang zu bringen, und ich habe gesehen, dass "am härtesten zuerst" Projekte zum Stillstand gebracht hat, bevor sie einen wirklichen Schwung bekommen.

  • Bitten Sie um Hilfe bei der Auswahl der richtigen Aufgabe und Vorgehensweise, um loszulegen.

  • Wenden Sie sich an einen Mentor, der Ihnen ein oder zwei Wochen lang konstantes (im Idealfall tägliches) Feedback geben kann.

  • Stellen Sie viele Fragen, aber achten Sie darauf, höflich zu Ihren Teamkollegen zu sein. Fragen Sie immer, ob sie Zeit haben, und achten Sie auf die üblichen verbalen und nonverbalen Anzeichen, dass sie gerade keine Zeit haben.

  • Führen Sie eine fortlaufende Liste der Probleme, auf die Sie stoßen, und gehen Sie sie dann entweder im täglichen Gedränge oder zu einer regulären Zeit Ihrer Wahl mit anderen durch.

  • Haben Sie keine Angst, die grundlegendsten Fragen zu stellen. Annahmen von anderen können schwer in Frage zu stellen sein, aber wenn Sie nicht mit dem fortfahren können, was Ihnen gegeben wurde, müssen Sie erneut Fragen stellen.

  • Wenn Sie das Ziel kennen, tun Sie so viel wie möglich, bis Sie nicht weiterkommen, und posten Sie dann den Fortschritt und die Frage zum Stapelüberlauf.

Michael Durrant
quelle
11
Ich stimme größtenteils zu, abgesehen von "Wähle zuerst die einfachste Aufgabe" . Aus Sicht des Projektrisikos ist es möglicherweise besser, die schwierigsten wesentlichen Aufgaben zuerst zu erledigen. Es ist besser, frühzeitig zu lernen, ob die harten Teile tatsächlich zu hart sind. Dann können Sie (vielleicht) zu einem einfacheren Design zurückkehren ... oder die Anforderungen neu verhandeln.
Stephen C
18

Natürlich hast du keine Ahnung, wie man einen "generischen Fehlermechanismus" schreibt. Niemand kann einen "generischen Fehlermechanismus" schreiben, bis einige Anforderungen definiert sind. Es klingt so, als ob Sie nur die Vorstellung haben, dass ein "generischer Fehlermechanismus" erforderlich ist, um dieses Projekt zu starten.

Persönlich würde ich diesen Gedanken zurückdrängen. Es ist fast immer Zeitverschwendung, etwas "generisches" zu schreiben, bevor die tatsächlichen Benutzeranforderungen implementiert werden. Und da es generisch ist , ist es per Definition nicht spezifisch für Ihr Unternehmen oder Ihre Anwendung, sodass wahrscheinlich bereits etwas verfügbar ist, das ungefähr 95% Ihrer Anforderungen erfüllt.

Aber da Sie das Junior-Mitglied sind, ist Zurückschieben möglicherweise keine gute Idee. Sie müssen also mit den Leuten sprechen, die glauben, dass sie einen "generischen Fehlermechanismus" benötigen, und herausfinden, welche Dienste sie von diesem Mechanismus erwarten. Suchen Sie dann im Netz, ob etwas bereits geschriebenes ausreicht. Wenn Sie etwas finden, schlagen Sie einfach vor, es zu verwenden. Sie werden sich wahrscheinlich nicht einig sein, weil jeder, der nach einem "generischen Fehlermechanismus" fragt, wahrscheinlich an einem schlimmen Fall leidet, in dem man hier nicht erfunden wurde.

Wenn dies fehlschlägt, besteht der nächste Schritt darin, eine Schnittstelle für den Fehlermechanismus zu definieren und von den Stakeholdern genehmigen zu lassen. Danach wird die Implementierung wahrscheinlich trivial sein.

=================

PS: Es gibt einige Programmierer, die der Meinung sind, dass der Start eines Projekts darin besteht, eine "Plattform" zu erstellen, auf der alle für die Anwendungsmodule erforderlichen allgemeinen Dienste bereitgestellt werden. Dabei geht es in der Regel um monatelange, triviale Arbeit, um Dinge neu zu erfinden, die bereits kostenlos erhältlich sind. Bis Sie an die Leistungsgrenzen der verfügbaren Lösungen stoßen, gibt es keinen Grund, "Plattform" -Dienste zu schreiben. Es gibt auch keinen Grund, Wrapper für vorhandene APIs zu schreiben. Wenn Sie fortlaufend überarbeiten, wird der für Ihre Anwendung erforderliche Wrapper auf magische Weise angezeigt.

Kevin Cline
quelle
5
Ich denke, ich verbringe möglicherweise sogar einen Großteil meiner Zeit damit , Funktionen zu entfernen , die die Leute für nötig hielten, obwohl sich herausstellte, dass dies nur wenig praktisch und problematisch war, wenn es darum ging, sich schnell an neue Bedürfnisse anzupassen. Ihre Warnung ist genau richtig!
Eamon Nerbonne
11

Ich denke, Sie leiden mehr unter Angst als unter einem Fähigkeitsdefizit. War irgendwann nicht alles neu? Wurde Ihnen jemals eine Aufgabe übertragen und konnten Sie diese in gewissem Umfang nicht lösen? Du wirst dafür bezahlt, Dinge herauszufinden.

Setze dein Team ein - Wenn du in einem guten Team bist, solltest du in der Lage sein, um Hilfe zu bitten. Es gibt Dinge, von denen Sie wissen werden, dass sie selbst die Ältesten nicht wissen werden. Um Hilfe zu bitten, ist kein Zeichen von Schwäche (nicht mehr als auf eine Frage zu gehen.).

Suche - Eine Websuche zur generischen Fehlerbehandlung hat nichts gebracht? Möglicherweise finden Sie keine vollständige Lösung. Sie müssen daran arbeiten und es trotzdem in Ihre App integrieren.

Prototyp - Ändern Sie Ihre Sicht auf die Aufgabe von der Produktion bis zum Prototyp. Holen Sie sich einfach etwas zum Arbeiten und bauen Sie von dort aus. Wenn Sie es auf den Punkt gebracht haben, können Sie es verwenden und dann als Produktion betrachten. Jetzt sehen Sie die Aufgabe nicht mehr als etwas, von dem Sie nicht einmal wissen, wo Sie anfangen sollen.

Überwinde es - Nur Dinge zu tun, die du zu tun weißt, wird langweilig. Es führt Sie auch in die Falle, dass Sie einfach nur brachiale Lösungen erzwingen, indem Sie dieselben Dinge immer wieder wiederholen (Wenn Sie es mögen, Dinge zu wiederholen, arbeiten Sie am Fließband.). Seien Sie bereit, Fehler zu machen. Diejenigen, die Ihnen sagen, dass sie alles wissen, niemals um Hilfe bitten oder suchen, lügen nur.

Es ist der alte Witz über Ärzte, die immer noch Medizin "praktizieren". Sie haben auch nicht alle Antworten.

JeffO
quelle
Ich bin damit einverstanden, Ihr Team einzusetzen. Wären sie eine Zeit lang offen für Pairing-Programme, um Sie auf den neuesten Stand zu bringen?
Neontapir
Nicht alle Teams / Entwickler befassen sich mit der Idee der Paarprogrammierung, aber das bedeutet nicht, dass Sie sich nicht hinsetzen und über die Schulter schauen können oder umgekehrt.
JeffO
6

Freuen Sie sich, dass Sie nichts tun, was Sie schon hundertmal getan haben. Sie haben die Freude an der Softwareentwicklung gefunden (für mich jedenfalls YMMV) - das Erlernen des Fahrens, während Sie mit außergewöhnlicher Geschwindigkeit die Autobahn entlang rasen. Für so etwas lebt und zeichnet sich ein großartiger Entwickler aus.

Mein persönlicher Prozess sieht ungefähr so ​​aus:

  • Forschung. Finden Sie heraus, ob und wie dieses oder ein ähnliches Problem bereits gelöst wurde. Auch wenn Sie nur Informationen zu Lösungen für verschiedene Sprachen oder Plattformen finden, kann dies äußerst informativ sein.
  • Prototyp. Der absolut beste Weg, etwas richtig zu machen, ist, es zuerst falsch zu machen. Erstellen Sie eine Lösung, die auf Ihren Recherchen aufbaut. Versuchen Sie, es an die Hauptanforderungen anzupassen, und berücksichtigen Sie dabei die Nebenanforderungen. Machen Sie sich nicht die Mühe, es hübsch oder perfekt oder erweiterbar oder flexibel oder performant zu machen, sondern lassen Sie es einfach funktionieren. Machen Sie sich Notizen zu den gewonnenen Erkenntnissen - was hat funktioniert, was nicht, mögliche Hindernisse usw. Dann werfen Sie den Code weg. Wenn Sie befürchten, ein Idiot zu sein, weil Sie zu lange brauchen, tun Sie dies in Ihrer Freizeit. Es kommt Ihnen persönlich in Bezug auf Wissen zugute.
  • Design. Kombinieren Sie Ihr externes Wissen (Forschung) mit persönlichem Wissen (Lektionen aus Prototypen) und formulieren Sie ein Design, von dem Sie glauben, dass es der richtige Weg ist, dies zu tun.
  • Kooperieren. Finden Sie ein Senior-Teammitglied, zeigen Sie ihm Ihr vorgeschlagenes Design und erhalten Sie Feedback. Zeigen Sie es jemand anderem, holen Sie sich dessen Feedback. Verfeinern Sie Ihr Design.
  • Iteriere. Wenn Sie sich bei Ihrer Lösung immer noch nicht sicher sind, stellen Sie sicher, dass Peer Reviews Teil Ihres Iterationszyklus sind. Bringen Sie Ihre Implementierung regelmäßig zu einem erfahrenen Teammitglied, um Feedback zu erhalten.
  • Seien Sie glücklich - Sie haben Ihr Wissen und Ihre Karriere erweitert und müssen etwas Neues und Interessantes tun, anstatt etwas Altes und Langweiliges, das Sie tausendmal zuvor getan haben. Versuchen Sie, Ihr nächstes Projekt zu einer noch größeren Herausforderung zu machen.

Und zum Schluss, mach dir nicht zu viele Sorgen um den Anschein. Als Entwickler-Teammanager hätte ich lieber jemanden, der beweisen kann, dass er alles lernen kann, was er braucht, wenn er es braucht, als jemanden, der beweisen kann, dass er bereits weiß, was wir gerade versuchen. Ersteres ist nützlicher für alles, was wir morgen, im nächsten Monat oder im nächsten Jahr tun.

Adrian
quelle