Ich habe gerade meine Karriere als Webentwickler für ein mittelständisches Unternehmen begonnen. Gleich zu Beginn hatte ich die Aufgabe, eine vorhandene Anwendung zu erweitern (schlecht codiert, über die Jahre von mehreren Programmierern entwickelt, erledigt dieselben Aufgaben auf unterschiedliche Weise, ohne Struktur).

Nachdem ich diese Anwendung erfolgreich um die angeforderten Funktionen erweitert hatte, gab man mir die Aufgabe, die Anwendung vollständig zu warten. Das war natürlich kein Problem, dachte ich. Aber dann hörte ich, dass ich den vorhandenen Code nicht verbessern und mich nur auf Fehlerkorrekturen konzentrieren durfte, wenn ein Fehler gemeldet wurde.

Von da an hatte ich genau wie oben drei weitere Projekte, die ich jetzt auch pflegen muss. Und ich habe vier Projekte, in denen ich die Anwendung von Grund auf neu erstellen durfte, und ich muss diese auch pflegen.

In diesem Moment fange ich leicht an, von den täglichen Mails der Benutzer (Lese-Manager) für jede Anwendung, die ich pflegen muss, verrückt zu werden. Sie erwarten von mir, dass ich diese E-Mails direkt bearbeite und gleichzeitig an zwei weiteren neuen Projekten arbeite (und es stehen bereits fünf weitere Projekte an). Das Traurige ist, dass ich noch keinen Fehlerbericht über alles erhalten habe, was ich selbst codiert habe. Dafür habe ich nur gelegentlich 180-Grad-Änderungswünsche erhalten.

Wie auch immer, ist das normal? Meiner Meinung nach mache ich die Arbeit eines ganzen Entwicklerteams.

War ich ein Idiot, als ich anfänglich damit gerechnet hatte, dass sich die Dinge ändern würden?

Ich denke, dieser Beitrag hat sich zu einer großen Schande entwickelt, aber bitte sagen Sie mir, dass dies nicht für jeden Entwickler gleich ist.

PS Mein Gehalt ist fast gleich, wenn nicht niedriger als das einer Kassiererin in einem Supermarkt.

Während eines meiner Praktika habe ich viel Zeit damit verbracht, Fehler zu beheben. Sie müssen sich darüber im Klaren sein, dass Sie als Einsteiger nicht die sexieste Arbeit bekommen, sondern die Grunzarbeit, die sonst niemand will. Es ist unglücklich, aber so ist es bei jedem Job.

Darüber hinaus müssen Sie sich darüber im Klaren sein, dass für ein Unternehmen funktionierender Code wichtiger ist als sauberer Code. Aus Sicht Ihres Unternehmens bedeutet eine Änderung der vorhandenen Struktur, dass Sie Geld dafür verschwenden, bereits erledigte Vorgänge zu wiederholen und potenziell noch mehr Fehler zu verursachen. In der Regel sind diese Arten von Unternehmen keine Computer- / Softwareunternehmen, daher verfügt kein ausreichend erfahrener Manager über den technischen Hintergrund, um zu wissen, dass manchmal größere Überholungen erforderlich sind. Das heißt, wenn Ihr Unternehmen von technisch kompetenten Mitarbeitern geführt wird und diese den Wert von gutem Code verstehen, erhalten Sie möglicherweise mehr Spielraum, obwohl Sie manchmal Ihre Schlachten auswählen müssen (der Hauptzweck eines Unternehmens besteht schließlich immer noch darin, Geld zu verdienen ).

Trotzdem sind Sie nicht unvernünftig, wenn Sie in der Lage sein wollen, Ihre Spuren in der Software zu hinterlassen, und wenn Sie eine sinnvollere Arbeit wünschen. Es ist auch bedauerlich, dass Sie sich mit so vielen Projekten gleichzeitig befassen müssen, während Sie Anfragen von so vielen verschiedenen Managern entgegennehmen.

Als Programmierer ist es eine Tatsache, dass Sie mehr Zeit damit verbringen, den Code anderer Leute zu pflegen und zu modifizieren, als von Grund auf Ihren eigenen Code zu schreiben. Wenn dies ein Problem für Sie ist, sollten Sie sich vielleicht als Hobby weiterentwickeln und eine andere Karriere verfolgen. Wenn Sie mit der Pflege des Codes einverstanden sind, sich aber nicht effektiv eingesetzt oder überfordert fühlen, müssen Sie dies mit Ihrem Manager besprechen. Wenn Ihre Probleme schwerwiegender sind oder Sie der Meinung sind, dass Ihre Manager nicht wissen, wie Sie Ihre Fähigkeiten effektiv verwalten können, ist es eine gute Idee, eine Stelle bei einem anderen Unternehmen zu suchen. Angesichts Ihres angegebenen niedrigen Gehalts ist dies wahrscheinlich die beste Vorgehensweise.

Es hört sich so an, als hätte das Management ein Problem beim Verwalten Ihrer Arbeitslast und beim Priorisieren von Aufgaben. Sie sollten mit Ihrem Vorgesetzten sprechen und ihm klar machen, dass Sie überlastet sind und keine effektive Arbeit leisten können, wenn Sie weiterhin von allen mit Anfragen bombardiert werden, die er sofort erfüllen möchte.

Das bringt Sie dazu, von einer Aufgabe zu einer anderen zu springen und zu projektieren, wodurch Sie viel Zeit damit verschwenden, in Ihrem Kopf den Gang zu wechseln. Für eine effektive Softwareentwicklungsarbeit sollte man in der Lage sein, sich auf eine Aufgabe einzulassen und sich voll darauf zu konzentrieren. Je mehr Unterbrechungen auftreten, desto mehr Zeit wird durch Kontextwechsel verschwendet. Die Forschung zeigt , dass es etwa 15 Minuten in Anspruch nimmt , um den Zustand zu tauchen und bekommt Fluss , wo unser Geist am effizientesten arbeitet. Wenn alle 15 Minuten eine Unterbrechung auftritt, kann der Fluss nie unterbrochen werden. Dies ist eine enorme Verschwendung für Sie und das Unternehmen.

Deshalb sollten Sie versuchen, mit Ihrem Vorgesetzten einen vernünftigeren Arbeitsmodus auszuhandeln . Dies sollte die Priorisierung der eingehenden Anforderungen und eine gewisse Vorausplanung einschließen . Alle Benutzeranforderungen sollten in einer nach Prioritäten geordneten Liste gespeichert werden. Und die Prioritäten sollten nicht vom Antragsteller festgelegt werden (da natürlich jeder der Meinung ist, dass seine Anfrage die wichtigste auf der Welt ist), auch nicht von Ihnen, sondern von jemandem, der über ausreichende Geschäftskenntnisse und einen Überblick über die gesamte Produktpalette verfügt, die Sie verwalten ( der Product Owner ).

Idealerweise sollten alle eingehenden Anfragen in einen Issue-Tracker wie JIRA oder Mantis eingegeben werden . Oder zumindest an den Produktbesitzer, nicht an Sie. Und er / sie sollte sich auch mit allen Beschwerden der Benutzer auseinandersetzen, "Warum ist meine Anfrage noch nicht fertig ?!", damit Sie sich auf die Entwicklungsarbeit konzentrieren können. Wenn dies nicht möglich ist, sollten Sie zumindest einige Zeitfenster aushandeln, wenn Sie eingehende Anforderungen prüfen und bearbeiten, und einen ununterbrochenen Teil Ihrer Zeit ausschließlich für die Entwicklung reservieren.

Wenn dies möglich ist, könnte der nächste Schritt darin bestehen, bis zu einem gewissen Grad vorauszuplanen. Schätzen Sie also die Zeit, die für die Implementierung der Anforderungen mit der höchsten Priorität erforderlich ist, und planen Sie Ihre Zeit in Sprints , die jeweils eine oder mehrere Wochen umfassen können. Weisen Sie dem nächsten Sprint genügend Aufgaben zu, um Ihre Zeit abzudecken.

Sie möchten wahrscheinlich einen Teil Ihrer Zeit für eingehende Notfallanfragen verwenden, der Rest kann jedoch im Voraus geplant werden. Vielleicht möchten Sie auch die Arbeit an verschiedenen Projekten in getrennten "Streifen" organisieren, dh am Montag an Projekt A, am Dienstag-Mittwoch an Projekt B, am Donnerstagmorgen an Projekt C und am Nachmittag an Projekt D usw. weiterarbeiten Kontextwechsel reduzieren.

Auf diese Weise haben Sie eine ungefähre Vorstellung davon, was Sie in den nächsten ein oder wenigen Wochen tun werden. Darüber hinaus erhalten auch Ihre Kunden eine Roadmap: Sie können sehen, wann welche Anforderung umgesetzt wird. Vielleicht möchten Sie Ihrem Manager das Wort "agil" hier nicht sagen - dies ist im Grunde genommen eine agile Entwicklung , aber einige Leute sind gegen agil, ohne wirklich zu wissen, was es ist :-)

Beachten Sie, dass die Verhandlungsmacht Ihres Unternehmens umso größer ist , je mehr Projekte Sie betreuen, auch wenn Ihre derzeitige Position von Ihrem Unternehmen als gering eingestuft erscheint .

Das Finden und Trainieren eines neuen Mitarbeiters zur Pflege all dieser Projekte kostet das Unternehmen viel Zeit (= Geld). Und Sie können zu Recht darauf hinweisen, dass Ihr Code so viel besser ist als die älteren Teile dieser Anwendungen, so dass es nicht selbstverständlich ist, dass sie leicht einen Kandidaten mit ähnlichen Fähigkeiten für den gleichen Geldbetrag finden können. Ganz zu schweigen davon, dass sie, wenn sie die Arbeitsbedingungen nicht verbessern, den nächsten Kerl satt machen und genauso schnell wie Sie aufhören ... Versuchen Sie, ihnen klar zu machen, dass es in ihrem eigenen Interesse liegt, Sie zu behalten, und um dich glücklich zu machen, wo du bist :-) Dies kann dir die Möglichkeit geben, die oben genannten Bedingungen zu verhandeln und / oder eine Gehaltserhöhung anzufordern.

Wie viel Verhandlungsmacht Sie haben - das ist eine große Frage. Ihr Management ist diesen Ideen möglicherweise gegenüber aufgeschlossen oder nicht aufgeschlossen und respektiert Sie möglicherweise nicht genug, um Ihre Bitten ernst zu nehmen. Aber wenn Sie Ihre Karten gut spielen, haben Sie eine Chance. Und wenn sie sich weigern ... können Sie immer nach einem besseren Arbeitsplatz suchen. Diese Situation ist nicht für jeden Starter gleich, obwohl Ihre Erfahrungen (leider) ziemlich typisch sind. Aber es gibt wirklich bessere Arbeitsplätze . Die Qualität des Arbeitsplatzes hängt nur wenig mit der geografischen Lage zusammen, aber ich bin der Meinung, dass Sie in Nordeuropa überdurchschnittliche Chancen haben. Also , wenn Sie nicht spürbar Ihre aktuellen Bedingungen verbessert bekommen, sollten Sie sofort suchen beginnen , bevor Sie ganz oben bekommen gefüttert und ausgebrannt.

Es ist immens besser, einen Job zu suchen, während Sie noch einen haben. Sie müssen also das erste Angebot nicht annehmen, nur weil Sie sofort Geld brauchen. Irgendwann wirst du einen besseren Ort finden :-)

PS Mein Gehalt ist fast gleich, wenn nicht niedriger als das einer Kassiererin in einem Supermarkt.

Ich wollte etwas darüber schreiben, wie man verhandelt, bis ich das gelesen habe. Jetzt kann ich nur noch Abschied sagen! Vorausgesetzt, das ist die Hälfte dessen, was ein Entwickler mit einem Abschluss normalerweise verdient. Und wenn sich die Situation verbessert und Sie sofort um 10% gesteigert werden, können Sie selbst herausfinden, wie lange es dauert, bis Sie dort ankommen. Es sieht auch so aus, als ob Sie am Arbeitsplatz nichts lernen und nicht von brillanten Ingenieuren umgeben zu sein scheinen. Es ist also Zeitverschwendung.

Ich war auch in einer ähnlichen Situation und ich kann Ihnen sagen, dass es niemals endet, wenn Sie auf dieser Strecke bleiben. Das Management schaufelt weiter daran, weil ... sie es können.

Es gibt ein paar zusätzliche Gedanken, die ich zu diesem Thema habe.

1. Tu was du liebst. Wenn Sie es nicht lieben, bereiten Sie sich darauf vor, herauszufinden, was Sie vielleicht lieben.

2. Kommunikation. Kommunizieren Sie klar und deutlich Ihre Unfähigkeit, unrealistische Erwartungen zu erfüllen. In meiner ähnlichen Erfahrung sagte der Architekt (der am meisten geschaufelt hat): "Sie müssen die Erwartungen anderer an Sie handhaben."

3. Ausbrennen. Wenn Sie kein Burnout erlebt haben, versuchen Sie das Schicksal nicht. Es saugt dein Leben und deine Seele aus deinem Verstand. Trotz Ihrer Bemühungen wird Ihr Arbeitszweck grau, trostlos und bedeutungslos. Ich erteile diesen Rat, weil Sie Burnout unbedingt vermeiden müssen.

4. Ausbildung. Hier ist der Silberstreifen. Ihre Ausbildung und Erfahrung sind zwar frustrierend und möglicherweise unterbezahlt, aber für Ihre Karriere sehr wertvoll. Dies ist Ihre Rettung, um dies zu realisieren, denn Sie können so viel wie möglich lernen und unvermeidliche Glasdecken hinauszögern.

Konzentrieren Sie sich darauf, welche Talente und Fähigkeiten Sie entwickeln ... Diese werden Sie durch die nächsten Karrieremöglichkeiten führen.

Sie haben hier mit mehreren Problemen zu tun ... Beginnen wir mit dem Offensichtlichen ...

Ist das normal?

Auf keinen Fall. Aber ... ist es üblich? Leider ja.

In Bezug auf Fehlerbehebung Frustration

Das entschuldigt zwar nicht den Rest des Chaos, mit dem Sie zu kämpfen haben, und die vielen Projekte, mit denen Sie überlastet sind, aber ich möchte kurz darauf hinweisen, dass der Ansatz der "Fehlerbehebung" nur für Sie als Entwickler frustrierend ist kann für das Unternehmen und sein Management ein durchaus vernünftiger Ansatz sein.

Oberfläche für mehr Bugs und Kosten

Je mehr Code Sie berühren, desto wahrscheinlicher ist es, dass Sie Fehler einführen, auch wenn Sie beabsichtigen, ihn zu verbessern. Das bedeutet verlängerte Entwicklungszeit, Testzeit und Kosten. Und wenn es zu einem Service-Release mit einem mittleren bis hohen Defekt kommt, ist das ein großes Durcheinander für sie.

Lärm / Nebel in Ihren Protokollen

Aus SCM-Sicht ist es auch ein wenig sinnvoll, wenn Sie direkt von einem Service Release-Zweig aus arbeiten, da Sie eine saubere Sicht auf Änderungen in Bezug auf Bugfixes haben möchten. Wenn es 15 Commits mit Tausenden von Änderungen gibt, die einen Bugfix betreffen, der möglicherweise eine Codeänderung von einer Zeile erfordert, ist das ein bisschen ärgerlich.

Als Neueinstellung ist es umso sinnvoller, Sie auf das Umgestalten und / oder Verbessern der Software zu verzichten, und in meinem Sinne ist es in Ordnung, mit Ihren Bugfixes so "chirurgisch" wie möglich umzugehen. Es hält nur Kopfschmerzen in Schach.

Können Sie etwas dagegen tun?

Dies bedeutet NICHT, dass es Möglichkeiten gibt, sowohl die Vernunft des Kodex als auch die Vernunft der beteiligten Personen zu erreichen. Als Junior sollte jemand Ihre Änderungen überprüfen, insbesondere Fehlerbehebungen, und sicherstellen, dass sie genehmigt sind, bevor Sie sie für die Service Release-Builds vornehmen. Das würde radikale Veränderungen verhindern oder begrenzen und sicherer sein.

Das Projekt aus der Hölle

Mist Code, Herde von Programmierern, Vervielfältigung, Mist Architektur

Auch hier ist Devil's Advocate, zeigt aber nur, dass Ihre anfängliche Anfrage ein paar nicht-konsequente Teile enthält.

Mein Punkt ist: Ich habe wirklich sehr, sehr selten eine Codebasis übernommen, die nicht in diesem Zustand war. Und aus Versehen waren es kürzlich Projekte oder Prototypen, die von ziemlich herausragenden Programmierern initiiert wurden. Aber die erstaunlich große Mehrheit von ihnen sah aus wie Scheiße, und eine beängstigende Anzahl von ihnen war wirklicher Scheiße. Sogar diejenigen, die von guten oder großartigen Programmierern begonnen wurden, können Mist, Termine und andere Verpflichtungen sein, die ...

Willkommen in der realen industriellen Softwareentwicklung!

Und wissen Sie, was Spaß macht? In der Welt der Webentwicklung ist es oft viel schlimmer. Genießen! :)

Zu viele Projekte und Anfragen, zu wenig Zeit und Zeit

Das Problem liegt hier wahrscheinlich in:

• Ihr Management (vielleicht unbewusst) missbraucht Sie ,
• Ihre Kollegen (vielleicht unbewusst) missbrauchen Sie ,
• Du (vielleicht unwissentlich) verdeckst deinen Arsch nicht und kämpfst genug .

Ihre Manager sollten sich darüber im Klaren sein, dass Sie an zu vielen Projekten arbeiten, um sie zu verwalten. Wenn nicht, stellen Sie sicher, dass Sie so schnell wie möglich sind. Vergewissern Sie sich auch, dass sie wissen, dass es nicht alles nur eine Kleinigkeit im Park ist und dass Sie sich unter Druck gesetzt fühlen und dass es aufhören muss.

Versuchen Sie sich umzuschauen und stellen Sie sicher, dass Ihre Kollegen nicht mehr Aufgaben und Projekte auf Sie lenken, direkt (indem Sie wirklich sagen "X kann sich darum kümmern") oder indirekt ("Ich bin nicht die richtige Person für Sie") dies, finde jemanden anderen "-> am Ende bist du du selbst).

Persönliche Anekdote hier: Ich habe vor ein paar Jahren ein Praktikum gemacht, und als ich am allerletzten Tag meine Bewertung erhielt, sagte mir mein Chef, obwohl ich insgesamt sehr zufrieden mit meiner Arbeit war, dass einer der Manager das Gefühl hatte, ich zu sein hatte einige "nicht so lustige Aufgaben" auf einem anderen Praktikanten entladen, als sie erwartet hätten, dass ich sie abhole. Ich war beschämt, dass sie sich enttäuscht fühlten, und bei der Vorstellung, dass ich so aussehen würde, als würde ich nachlassen, wenn meine Absicht genau das Gegenteil war: Ich versuchte, die härteren Aufgaben zu bewältigen und den anderen jüngeren Praktikanten mit weniger Haaren zu beschäftigen -Pulling Probleme. Wäre ich in seiner Position gewesen, hätte ich mich über die mangelnde Herausforderung gelangweilt und hätte mich wahrscheinlich so gefühlt wie er. Der Punkt ist, dass Sie kommunizieren müssen, um sicherzustellen, dass niemand falsche Annahmen über drei sehr unterschiedliche Dinge macht:

• was du tun kannst ,
• was du machen willst ,
• und was Sie bereit sind zu tun .

Teilweise liegt es also auch an dir, dass du es so werden lässt. Aber es ist normal, es ist eine Lektion, die jeder lernen muss. Er hält in zwei Buchstaben: N - O .

Normalerweise verwenden Sie es als Präfix für eine längere, aber weniger belastende Antwort: Nein, das kann ich nicht. Nein, ich weiß nicht, wie ich das machen soll. Nein, ich bin mir nicht sicher, ob ich die richtige Person dafür bin. Nein, das habe ich noch nie gemacht.

Zuerst ist es sehr einfach, das Gefühl zu haben, man kann einfach "Ja, ich mache es (irgendwann)" sagen und die Dinge stapeln und erledigen, indem man vielleicht ein paar zusätzliche Stunden einsetzt. Das ist alles falsch. Sie müssen verstehen, dass Ihre Zeit nach Ihren Fähigkeiten für Sie und Ihr Unternehmen das wertvollste Kapital ist. Wenn es missbraucht wird, wirkt es sich auf Projekte, Termine und Budgets aus . So einfach ist das.

Es sieht auch ein bisschen besorgniserregend aus, dass Sie zu viele Leute hätten, denen Sie Bericht erstatten könnten. Es ist in Ordnung, mehrere Kunden und mehrere Projektverantwortliche oder sogar Hauptakteure zu haben, mit denen Sie kommunizieren müssen. Insgesamt sollten Sie sich jedoch, insbesondere als Neueinsteiger, meist nur bei wenigen Managern (und höchstwahrscheinlich nur bei Ihrem direkten Manager und möglicherweise bei einem Lead- oder Senior-Entwickler) melden. Wie ist es so gekommen? Ich weiß es nicht. Es kann ein organisatorisches Problem in Ihrem Unternehmen sein, oder es kann das Ergebnis sein, dass Sie einen Gefallen tun und dann direkt kontaktiert werden und nicht "Nein" sagen. Oder es kann sein, dass Ihr direkter Vorgesetzter, soweit ich weiß, Probleme mit Dispositionsaufgaben hat (ich rate wirklich, aber die Muster sind erkennbar und bekannt).

Ich würde empfehlen, dass Sie ziemlich schnell Folgendes tun: Sprechen Sie persönlich mit Ihrem direkten Vorgesetzten, erklären Sie, dass andere Vorgesetzte möglicherweise etwas aufdringlich sind oder (wahrscheinlich weniger weinerlich), dass Sie zu viele Dinge von zu vielen Leuten aufgeschichtet haben, und dass Sie seine Eingabe (und möglicherweise auch ihre) benötigen, um zu wissen, welche zu priorisieren sind.

180-Grad-Änderungsanforderungen

Dies ist ein weiteres großes Problem. Sie sind wahrscheinlich nicht deine Schuld, aber du kannst versuchen, ihnen dabei zu helfen, das Problem zu lösen.

"180-Grad-Änderungsanforderungen", wie Sie sie wunderschön und präzise nennen, sind ein klares Zeichen dafür, dass die Anforderungen von Anfang an verschwommen sind und dass sich niemand genug Mühe gibt, sie im Laufe der Zeit meißeln und aufräumen zu lassen .

In der Regel muss jemand ans Telefon gehen (oder besser gesagt auf die Beine) und die Stakeholder an der Hand nehmen und ihnen klar sagen: "Dort sind wir, dort möchten Sie, dass wir hingehen. Bestätigen Sie, dass wir da sind in die richtige Richtung? " Es ist in Ordnung, zu Beginn keine klaren Antworten zu erhalten, aber je mehr Zeit vergeht, desto klarer sollten sie werden, oder dieses Projekt ist eine Katastrophe, die darauf wartet, geschehen zu können.

Normalerweise würde ich sagen, schnappen Sie sich alle Stakeholder in Reichweite, platzieren Sie sie in einem Raum, führen Sie sie durch strittige Fragen und versuchen Sie schrittweise, diese Probleme zu lösen - und setzen Sie dabei Prioritäten. In Ihrem Fall ist dies jedoch möglicherweise nicht der Anruf, den Sie bereits tätigen müssen. Aber Sie erwähnen, sie haben Ihnen wirklich die Verantwortung für die Projekte übertragen. Wenn dies wirklich der Fall ist, übernehmen Sie Verantwortung und tun Sie dies. Und scheuen Sie sich nicht zu sagen "das können wir nicht" oder "das werden wir nicht" . Es ist wirklich wichtig, den Umfang eines Projekts zu begrenzen.

Wenn es keinen Spielraum gibt, gibt es am Ende der Diskussion keine klaren Anforderungen.

E-Mail-Überladung

Menschen neigen dazu, sich je nach Kommunikationsmedium unterschiedlich zu verhalten. Persönlich würde ich, obwohl ich ein eher leiser Mensch bin (und hauptsächlich im Ausland gearbeitet habe, weshalb ich am Ende auch nicht gerne zu viel telefoniere), in der Reihenfolge bevorzugen, die auf der Produktivität basiert:

• mit Menschen von Angesicht zu Angesicht sprechen ,
• mit Leuten am Telefon sprechen,
• mit Leuten über Sofortnachrichten sprechen,
• mit Leuten per E-Mail sprechen.

E-Mails eignen sich gut zum Nachverfolgen, zum Abrufen von Bestätigungen und zum Versenden von Notizen.

Zum Planen, Planen und Besprechen problematischer Punkte sind sie nahezu unbrauchbar. Klopfen Sie an die Tür des Mannes, bis er / sie sie öffnet, und setzen Sie sich mit einem Notizblock und einer Kopie Ihrer Dokumentation hin, um die Dinge zu klären. Sobald Sie fertig sind, senden Sie eine E-Mail und fordern Sie eine Bestätigung an. Wenn es eine negative Antwort oder einen etwas versteckten Versuch gibt, etwas anderes in den Umschlag zu schleichen, belagern Sie das Büro Ihres Gesprächspartners erneut.

Dies ist Software-Engineering. Es ist oft produktiver, wenn Sie nicht auf einer Tastatur tippen und den Mist, mit dem Sie zu kämpfen haben, im Voraus reduzieren können.

Die Arbeit eines Teams wert

Tun Sie das Äquivalent zur Arbeit eines Teams? Vielleicht.

Tun Sie das Äquivalent zur Arbeit Ihres Teams? Wahrscheinlich nicht.

Was ich meine ist, dass Ihr Team wahrscheinlich beschäftigt ist und Sie überarbeitet sind. Und das ist das Problem: Sie sind mit Dingen überlastet, die aus den aktuellen Projektzeitplänen verdrängt oder an jemanden weitergegeben werden sollten, der Zeit hat.

War ich ein Idiot, als ich anfänglich damit gerechnet hatte, dass sich die Dinge ändern würden?

Nein; Nur neu für die Party. Es ist wie ein erster Kater oder eine erste Beziehung. Du wirst darüber hinwegkommen.

Ich denke, dieser Beitrag hat sich zu einer großen Schande entwickelt, aber bitte sagen Sie mir, dass dies nicht für jeden Entwickler gleich ist.

Dies gilt auch für alle Entwickler in chaotischen Organisationen, seien es Start-ups oder etablierte Giganten, und ohne Erfahrung oder Selbstvertrauen, um Ihre Überlebenschancen auf der rechten Seite der Skala zu verbessern.

PS Mein Gehalt ist fast gleich, wenn nicht niedriger als das einer Kassiererin in einem Supermarkt.

Ich habe anständige Gehälter für Jobs gezahlt, die beschissen aussehen würden. Es ist nicht die Zahl auf dem Scheck, die zählt, es ist der Kontext. Was du tust, dein Alter, wo du lebst und arbeitest, etc ...

Das heißt, wenn Sie stark unterbezahlt sind, zu viel arbeiten und nicht ganz jünger sind , fragen Sie nach dieser Gehaltserhöhung oder suchen Sie sich einen neuen Job!

Es ist einfach:

• Wenn sie Wert darauf legen, was Sie tun, stimmen sie einer Gehaltserhöhung gerne zu.
• Wenn nicht, sieht die Zukunft in diesem Unternehmen nicht sehr rosig aus (zumindest für Sie, worauf es ankommt), also fühlen Sie sich nicht schlecht, wenn Sie gehen.

Seien Sie sich bewusst, dass es eine gute Sache ist, nach einer Gehaltserhöhung zu fragen , auch wenn Sie zunächst nicht geneigt wären, dies zu denken. Es zeigt, dass Sie den Überblick behalten, was Sie tun, und weist darauf hin, dass Sie eine andere Option im Auge behalten, während Sie bereit sind, an Bord zu bleiben. Und es ist eine gute Sache, sich daran zu gewöhnen, sie anzufordern, da sie im Allgemeinen wie Vorstellungsgespräche oder Verhandlungen sind: Es ist etwas, das Übung erfordert, und sie fallen nicht vom Himmel, wenn Sie nicht selbst nach ihnen greifen. Einige Unternehmen verteilen regelmäßig Erhöhungen, ohne dazu aufgefordert zu werden, aber das liegt nur daran, dass sie klug genug sind, um zu wissen, dass dies Sie halbwegs glücklich und weniger bereit macht, sich zu verändern etwas unruhig, wenn es darum geht, ein Raise-Angebot zu erhöhen, das ihnen direkt angeboten wurde).

Wie Sie mit dieser Anfrage fortfahren, liegt etwas außerhalb des Rahmens DIESES Projekts, weshalb ich hier nicht auf die Details eingehen werde. Ich empfehle Ihnen jedoch, eine Aufzeichnung Ihrer SCM-Commit-IDs, Ihrer behobenen Fehler und Erfolge sowie Berichte zu erstellen, in denen sie mit dem Gesamtaufwand des Teams verglichen werden. Diesen Weg:

• Sie können für sich selbst messen, ob Sie effektiv viel mehr getan haben als Ihre Kollegen oder nicht,
• Sie können sich behaupten, wenn Ihre Anfrage nicht gerechtfertigt ist.

Zusätzlich zu den Kommentaren anderer Leute:

1. Ja, es ist normal, dass ein Einsteiger die Jobs bekommt, die sonst niemand machen möchte.

2. Sie sollten dies als Baustein für Ihre zukünftige Karriere sehen.

Also, was solltest du tun? Um sich als professioneller Entwickler zu beweisen, müssen Sie sicherstellen, dass Ihre Arbeit strukturiert und geplant ist. Andernfalls fällt es Ihnen möglicherweise schwer, auf den guten Dingen aufzubauen, die Sie gerade tun du bist nicht schon).

1. Protokollieren Sie Ihre Arbeit genau für jedes Projekt. Wenn Sie also eine Stunde damit verbringen, einen Fehler in Projekt A zu beheben, protokollieren Sie diesmal. Dies ist nützlich, um Ihrem Manager zu zeigen, ob Sie die Workloads besprechen möchten.

2. Schreiben Sie Komponententests. Sie erwähnen, dass einige der von Ihnen betreuten Projekte voller Fehler sind, und ich vermute, dass es nur wenige (wenn überhaupt) Unit-Tests gibt. Schreiben Sie für jeden Fehlerbericht einen Komponententest, der den Fehler repliziert, und beheben Sie den Fehler. Dies hilft sicherzustellen, dass keine Regressionen auftreten, die Qualität des Codes zu verbessern und als Plattform zu dienen, auf der Sie den Code umgestalten können, wenn Sie die Möglichkeit dazu haben Qualität ohne Einführung neuer Bugs (aufgrund der Unit-Testsuite).

3. Suchen Sie nach einem neuen Job - Sie arbeiten an vielen Projekten gleichzeitig, haben Code von Grund auf neu geschrieben und wahrscheinlich den gesamten Projektlebenszyklus durchlaufen - all dies sind gute Erfahrungen für die Bewerbung an einem anderen Ort.

Ihre Situation ist ein bisschen nervös, aber immer noch normal. Aber die Art, wie Sie damit umgehen, ist sehr schlecht. Folgendes müssen Sie tun:

• Versuchen Sie, Ihren Chef zu konfrontieren. Sie sollten einige Beweise (Zahlen) dafür haben, wie viel Zeit die fehlerhafte Codebasis tatsächlich kostet. Wenn er Dinge wie technische Schulden nicht versteht, hören Sie auf, sie zu erwähnen. Es würde dir den Kopf zertrümmern und du könntest als ein Typ mit einer schlechten Einstellung bezeichnet werden. Es ist nicht Ihre Aufgabe, Ihrem Chef beizubringen, seine Arbeit zu erledigen.

• Pflegen Sie Ihren eigenen Rückstand (Kanban). Wenn neue Aufgaben eingehen, beenden Sie diese und geben Sie die voraussichtliche Fertigstellungszeit an.

• Erhöhen Sie Ihre Antwortzeit und überprüfen Sie Ihre E-Mails nur zweimal täglich. In der Regel vor dem Mittagessen und kurz vor Ihrer Abreise. (Nach dem Überprüfen von E-Mails sollte keine Codierung erfolgen, da dies den Kopf beschädigen kann.)

• Machen Sie kleine Code-Verbesserungen als Teil jeder Aufgabe. Es ist einfach Ihre Aufgabe, den Code, die Fähigkeiten und die Tools, die Sie verwenden, zu verbessern. Es wird auch Ihre Moral auf lange Sicht stärken.

• Kein Projektwechsel während des Tages. Heute arbeiten Sie einfach an Projekt X und Sie werden morgen mit einer anderen Aufgabe für Y beginnen.

• Planen Sie eine Stunde pro Tag für die Aufbewahrung der Tore ein. Es bedeutet kleine Aufgaben, die einfach zu erledigen sind. Wenn diese Aufgabe länger als 10 Minuten dauert (egal aus welchem ​​Grund), wird sie in den Rückstand aufgenommen und Sie benachrichtigen den Manager, dass sie sich verzögert.

Jetzt kommt der schwierige Teil. Derzeit kommunizieren die Manager nicht miteinander und gehen davon aus, dass Sie ihr eigenes Projekt mit maximaler Priorität abschließen werden. Dies bringt eine Menge Stress auf den Kopf, weil Sie in der Mitte der Auseinandersetzungen sind. Sie müssen Manager dazu zwingen, ihre Arbeit zu koordinieren. Am Ende sollten Sie einen netten und einfachen Rückstand haben und Manager sollten sich ohne Sie gegenseitig schikanieren.

Lassen Sie uns also ein einfaches Rollenspiel machen. Es gibt drei Manager und Projekte (Xavier mit Projekt X, Yvonne mit Projekt Y und Zed mit Projekt Z). Sie haben einen Rückstand von zwei Wochen, 5 Tage für X und 5 Tage für Y.

• Z fordert Sie auf, eine Aufgabe zu erledigen (1 Tag)
• Sie antworten, dass dies in 11 Tagen geschehen wird.
• Z antwortet, dass es eine einfache Aufgabe ist und nicht länger als einen Tag dauern sollte (beachte, dass Z einen kleinen Druck ausübt).
• Sie antworten, dass Sie derzeit für X und letztere für Z arbeiten. Danach können Sie ihre Arbeit erledigen.
• Z antwortet, Sie sollten seine Aufgabe trotzdem sofort erledigen (erhöhter Druck, direkte Verletzung von X- und Y-Territorium).
• Sie antworten, dass das Ausführen ihrer Aufgabe die Arbeit für X und Y verzögern würde. Er sollte sie zuerst fragen. Sie auch CC X und Y.

Jetzt gibt es zwei Enden:

• Manager bellen sich an, viele E-Mails, wahrscheinlich einige Besprechungen ... Sie sollten sich fernhalten und sich vom Gewinner eine Aufgabe zuweisen lassen.

• Nichts wird passieren, Z wird dich zwei Tage später fragen, wo seine Aufgabe ist. Sie antworten, dass Sie derzeit für X arbeiten, und er hat nichts über das Projekt Z gesagt. Wieder CC X.

Jetzt kann diese Art von Verhalten Sie feuern. Aber Ihre Situation ist nicht nachhaltig und Sie werden wahrscheinlich sowieso bald aufhören. Diese Lösung funktioniert nur, wenn Manager gegeneinander antreten (sehr üblich). Sie sollten auch Aufzeichnungen über Ihre Arbeit (Rückstand) führen, falls sich jemand beschweren würde, dass Sie nachlassen.

Vor sieben Jahren habe ich eine Zeit lang so ziemlich 100% Wartungsarbeiten durchgeführt und einen Artikel darüber geschrieben: Die Kunst der Wartungsprogrammierung . Ein Teil, den Sie vielleicht nützlich finden:

1. Lass es dir gefallen

Wie kann jemand wie Wartung programmieren? Entwickler träumen davon, Chefarchitekten in ihren Teams zu sein, und wenn sie am Ende vorhandene Software warten, fühlt es sich fast wie eine Bestrafung an. Es muss nicht so sein: Die Wartungsprogrammierung hat ihre eigenen Herausforderungen und erfordert viel Kreativität, Anpassungsfähigkeit, Geduld, Disziplin und gute Kommunikation. Das kann auch für Ihre Karriere von Vorteil sein: Bombastische Einträge wie "Architected n-Tier 24/7 Enterprise Application" in Ihrem Lebenslauf sehen gut aus, aber Arbeitgeber schätzen Menschen, die Probleme lösen. Und die Wartungsprogrammierung kann eine gute Gelegenheit sein, Ihre Fähigkeiten zur Problemlösung unter Beweis zu stellen.

Ihr Problem hört sich nach etwas an, von dem Sie öfter hören. Es scheint ein Job zu sein, der leicht auf The Daily WTF passen könnte .

Viele Unternehmen konzentrieren sich mehr auf den Verkauf oder das Feature-Push als auf die Qualität. Was diese Unternehmen nicht erkennen, ist, dass es mehr als nur externe Eigenschaften einer Software gibt. Ward Cunningham prägte den Begriff der technischen Schulden .

Vielleicht möchten Sie auch Steve McConnell über technische Schulden lesen . Er hat einige interessante Punkte. In einem Google Tech Talk spricht Ken Swaber über agile Softwareentwicklung . Ein guter Teil handelt von einer ähnlichen Geschichte wie Sie. Er spricht über ein Softwareprojekt, das nach 10 Jahren Programmierarbeit von verschiedenen Programmierern, ohne jemals umgestaltet zu haben, zum "Kopf" geworden ist . Ich denke, wenn Sie dieses Video sehen, werden Sie viele Ähnlichkeiten mit dem sehen, was Sie beschreiben.

Jedes Softwaresystem wird bei der Erweiterung an Qualität verlieren. In der Tat, um zu überleben, muss es. Die Lehman-Gesetze erklären dieses Prinzip recht gut. Letztendlich wird es auf die folgende Frage hinauslaufen: "Wie überzeuge ich Ihren Chef zum Refactoring?" .

Wie ich mich einem ähnlichen Problem näherte:

• Ich habe meinen Chef konfrontiert und ihm erklärt, dass sich die Codequalität verschlechtert, wenn wir uns weiterentwickeln ( Lehman-Gesetze ).
• Ich habe versucht, meinem Chef das Konzept der technischen Verschuldung zu erklären . Und die Art und Weise, wie er Sie arbeiten lässt, wird ihn auf lange Sicht Geld kosten.
• Um ihm tatsächlich zu zeigen, wie schwerwiegend das Problem war, habe ich (zu meiner Zeit) eine statische Code-Analyse durchgeführt. Chefs verstehen keine Software, aber sie verstehen Zahlen. Obwohl Codemetriken ihre Fehler aufweisen , ist es gut, etwas Messbares zu haben, über das Sie sprechen können. Versuchen Sie herauszufinden, welche normalen Werte für diese Metriken gelten, und Sie werden überrascht sein, wenn Sie diese mit Ihrer eigenen Codebasis vergleichen.
• Wenn nichts hilft und sich nichts ändert, können Sie nur erklären, dass eine bestimmte neue Funktion eine Überarbeitung anderer Teile Ihrer Codebasis erfordert. Erklären Sie, dass, wenn Sie doppelten Code haben und er etwas ändern möchte, die Kosten einer Änderung ebenfalls duplizieren.
• Eine übliche Antwort auf den vorherigen Punkt wird sein, dass niemand nachgefragt und somit nicht für diese Nacharbeit bezahlt hat. Dass "vielleicht" diese Überarbeitung überflüssig ist. Sie müssen erklären, dass sich die Software immer ändern muss. Wie die Lehman-Gesetze sagen; es muss geändert werden, um in Gebrauch zu bleiben. Wenn nicht, werden andere Programme, die sich geändert haben, immer überleben. Es sind diejenigen, die Veränderungen erwarten und sich an Veränderungen anpassen können, die überleben werden. Darum geht es in der agilen Softwareentwicklung . ( Wikipedia )

Mein Chef verwendet heutzutage das Konzept der technischen Verschuldung, um unseren Kunden zu erklären, dass wir manchmal Teile der von uns erstellten Software überarbeiten müssen. Nur um das zu beweisen - wenn Sie einen vernünftigen Chef haben, ist es möglich, die Dinge zum Besseren zu wenden.

Die Situation, mit der Sie konfrontiert sind, ist für viele Erstsemester nahezu (wenn nicht sogar völlig) dieselbe.

Dies geschieht in den ersten Phasen einer Karriere. Hier ist der Haken: Wir müssen dieses Problem lösen und unseren Wert für das Unternehmen unter Beweis stellen (sei es mittelgroß oder MNC ). Wir sollten in der Lage sein, Entscheidungen darüber zu treffen, was die Umstände von uns verlangen. Es schadet also nichts, wenn Sie sich anstrengen, vorausgesetzt, Sie werden darauf aufmerksam und stehen als Einzelperson für Ihre Arbeit. Wenn Sie es wert sind, wird das Unternehmen bemerken! Adios und viel Glück.

Meiner Meinung nach lohnt es sich nicht, für ein Unternehmen zu arbeiten, das Refactoring verbietet. Refactoring ist eine wesentliche Software - Entwicklung Fähigkeit und Versionskontrolle Tools machen es sehr einfach , ohne zu verderben die ‚Stamm‘ (falls ein Refactoring tatsächlich Änderungen in Isolation zu entwickeln , tut etwas brechen). Wie Onkel Bob (umschrieben) sagt: "Sie sollten nicht darum bitten, ein Profi zu sein und Ihre Arbeit richtig zu machen."

Wartungsprogrammierung sollte niemals bedeuten, fehlerhaften Code aufrechtzuerhalten.

Ich habe diese E-Mail vor fünf Jahren von einem meiner Freunde erhalten.

Email body:    

Ein neu eingestellter angehender Ingenieur fragt seinen Chef: "Was bedeutet Beurteilung?"

Boss: "Kennen Sie die Bedeutung von Resignation?"

Azubi: "Ja, das tue ich"

Boss: "Lassen Sie mich verstehen, was eine Einschätzung ist, indem ich sie mit Resignation vergleiche."

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Azubi: "Ja Chef genug, jetzt habe ich meine Zukunft verstanden. Für eine Einschätzung muss ich zurücktreten ... !!!"

Wenn ich Sie wäre, würde ich einige späte Stunden nach der Arbeit damit verbringen, die Anwendung kostenlos neu zu erstellen. Es wäre wahrscheinlich eine lustige Aufgabe. Wenn Sie fertig sind, zeigen Sie es Ihrem Chef. Wenn es funktioniert und Sie Wartungsarbeiten daran durchführen, sollte er sich keine Sorgen machen müssen. Dies erleichtert Ihnen die Arbeit erheblich und öffnet die Augen der höheren Köpfe für Ihr Potenzial im Unternehmen.

Ich bin ein Vollzeitstudent, der ein Teilzeitpraktikum für 10 US-Dollar pro Stunde absolviert. Ich mache QA-Sachen, die langweilig, repetitiv und einfach sind. Ich schätze mich sehr glücklich, weil ich weiß, dass dies eines Tages Türen zu größeren und besseren Orten öffnen wird.

Ja, Sie müssen immer Anwendungen verwalten, die sowohl von Ihnen als auch von anderen Personen geschrieben wurden. Die einzige Ausnahme ist, wenn Sie ein Programm schreiben, das niemals gewartet werden muss. Sie sind also besser in der Wartung.

Ich denke, es gibt einen subtilen Hinweis auf einen Fehler in Ihrer Herangehensweise. Das heißt, dass das Beheben von Fehlern keine Verbesserung des Codes beinhaltet.

Aber dann hörte ich, dass ich den vorhandenen Code nicht verbessern und mich nur auf Fehlerkorrekturen konzentrieren durfte, wenn ein Fehler gemeldet wurde.

Ich kann nicht glauben, dass Ihnen jemand gesagt hat, dass Sie Fehler beheben müssen, ohne den Code zu verbessern. Dies ist sowohl schwierig als auch unmöglich. Was Sie nicht tun können, ist, die Anwendung neu zu schreiben, nur weil Sie den in der vorhandenen Codebasis verwendeten Ansatz nicht mögen oder schwer verstehen.

Mein Rat ist, Refactor zu lernen. Jedes Mal, wenn Sie einen Fehler beheben, haben Sie die Möglichkeit, zumindest einen Teil des Codes zu verbessern. Wie viel von der Codebasis überarbeitet wird, hängt davon ab, was der Fehler ist und wie gut oder schlecht der Code ist. Aber wenn Sie Fehler beheben und wissentlich überall Code-Gerüche hinterlassen , erledigen Sie Ihre Arbeit nicht und bauen technische Schulden auf .

Einige Fehler werden durch einfaches Refactoring behoben, und manchmal ist das Refactoring hilfreich, damit Sie den Code besser verstehen . Dies liegt daran, dass das Refactoring die Wartbarkeit und Kohärenz des Codes verbessern sollte.

Wenn ich eine Fehlerbehebung schätze, werde ich normalerweise eine Entscheidung treffen, ob ein größerer Refaktor der beste Weg ist, dies zu tun, und dies berücksichtigen. Gleiches gilt für Unit-Tests. Diese beiden Dinge sollten Teil der Art und Weise sein, wie Sie Code schreiben, nicht etwas Optionales, was zusätzliche Zeit erfordert.

Sie sollten also nicht fragen: "Kann ich den Code verbessern, wenn ich den Fehler behebe?" Weil du es sowieso sein solltest. Sie sollten nicht fragen: "Kann ich das Refactoring verwenden, um den Fehler zu beheben?" Denn wenn der Code, der die Anwendung zum Bug-out veranlasst, dringend umgestaltet werden muss, sollten Sie dies trotzdem tun. Sie sollten nicht fragen: "Kann ich Komponententests schreiben, wenn ich diesen Fehler behebe?" Weil Sie einen Regressionstest schreiben sollten, bevor Sie überhaupt versuchen, den Fehler zu beheben.

NB: Ich denke, eine Zuschreibung für diese Antwort sollte an Jeff Atwood gehen, da ich 3 seiner Artikel verlinkt habe.

Hier dreht sich alles um Geld. Ich vermute, dass Sie als Anfänger wahrscheinlich zu freundlich für Kunden sind, die bereits mehr bekommen haben, als sie bezahlt haben.

Erfahren Sie, wie Sie einen Preis für neue Anfragen angeben. Dies ist alles andere als einfach und die Kunden werden Sie oft ausprobieren. Wenn Sie können, lassen Sie sich von einem erfahrenen Projekt- / Produktmanager beraten.

Sobald Sie in Geld denken, wird die Kommunikation mit dem Management viel einfacher. Wenn Ihre derzeitigen Kunden Vollzeit-Geld zur Verfügung stellen, sollten Sie keine neuen Projekte abholen. Aber Sie werden verstehen, dass das Management immer noch versuchen wird, Sie dazu zu drängen, dies zu tun.

Wenn Sie für das Unternehmen wirklich wertvoll sind, gewinnen Sie Verhandlungsmacht. Sie können sie bitten, mehr Mitarbeiter einzustellen, weniger neue Projekte zu erhalten, den Wartungsaufwand zu reduzieren oder Ihr Gehalt zu erhöhen.

Es sollte nicht die Entscheidung Ihres Arbeitgebers sein, Sie so zu verwalten, dass es Ihnen untersagt ist, den bestehenden Kodex zu verbessern. Verwenden Sie Ihr eigenes professionelles Urteilsvermögen. Wenn Sie die Arbeit abschätzen, würde ich zusätzliche Zeit in Betracht ziehen, um eine Umgestaltung zu ermöglichen, falls dies in Zukunft die Produktivität steigern wird.

Wie auch immer, es scheint, dass Sie nicht effektiv mit Ihrem Arbeitgeber kommunizieren.

1. Sie haben Beweise dafür, dass Refactoring Geld spart. Erstellen Sie einen Vorschlag für ein Refactoring-Projekt und zeigen Sie, wie viel Zeit und Geld das Unternehmen sparen kann. Beschreiben Sie genau, welche Änderungen Sie am Code vornehmen würden und wie lange dies dauern würde.

2. Führen Sie ein genaues Protokoll, um aufzuzeichnen, wie viel Zeit Sie für das Codieren, Besprechen und Beantworten von E-Mails aufwenden. Dies schützt Sie, wenn Sie in Verzug geraten.

3. Langsamer. Dies mag etwas kontraproduktiv erscheinen, aber Ihre Zeit wird nur dann missbraucht, wenn Sie alles schnell erledigen. Die Leute werden Ihre Zeit mehr respektieren, wenn Sie weniger tun. Zum Beispiel würde ich nur ein- oder zweimal pro Tag E-Mails abrufen. Andernfalls besteht die Gefahr eines Burnouts.

4. In Anbetracht Ihrer Bezahlung lohnt es sich nicht, Kopfschmerzen zu bekommen. Stellen Sie sicher, dass Sie jeden Tag pünktlich abreisen. Setzen Sie keine zusätzlichen Stunden ohne zusätzliche Entschädigung ein. Die Ausnahme ist, wenn es gute Aufstiegsmöglichkeiten gibt oder wenn der Ruf des Unternehmens Ihren Lebenslauf erheblich steigert, müssen Sie ihn nur aufsaugen.

Ohne mehr zu wissen, würde ich nur vorschlagen, dass Sie versuchen, offener mit Ihren Managern umzugehen. Erhöhen Sie möglicherweise Ihre Aufgabenschätzungen. Erinnern Sie sie ständig daran, wie beschäftigt Ihre Arbeitsbelastung ist. Sie sollten sich auch mit Ihrem Chef treffen und ihm erklären, dass Sie innerhalb der nächsten sechs Monate eine Gehaltserhöhung wünschen, und sich erkundigen, wie Sie Ihre Leistung verbessern können, um diese Lohnerhöhung zu erreichen.

Viel Glück.

Nach meiner Erfahrung sind die akademische Welt oder die ersten 6 bis 12 Monate eines technikorientierten Start-ups die einzigen zwei verlässlichen Bereiche, in denen Sie auf eine echte Lücke stoßen. Beide tragen ihre eigenen Kosten, aber wenn Sie Code lieben und oft entsetzt sind über die Qualität des Codes, den Sie in freier Wildbahn finden, sollten Sie Ihre Karriere in eine dieser Richtungen lenken.

Versuchen Sie, mit Ihren Arbeitgebern zu sprechen, und prüfen Sie, ob Sie das Problem lösen können. Es hört sich so an, als wären Sie überfordert, und es hat nichts damit zu tun, ein schlechter Programmierer zu sein.

Kleinere Web-Unternehmen haben in der Regel viele Projekte gleichzeitig im Gange, was Sie in vielerlei Hinsicht in Bedrängnis bringt. Versuchen Sie entweder, das Beste aus Ihrer Situation herauszuholen, oder suchen Sie einen neuen Job, wenn Sie dies für möglich halten. Ich verspreche, es gibt bessere Codierungsaufträge, also lassen Sie sich von diesem ersten nicht abschrecken.

Viel Glück und ich hoffe, Sie und Ihre Mitarbeiter verstehen die Schwerkraft oder Ihre Bemühungen!

Persönliche Erfahrung

Wie viele hier erkenne ich auch Ihre Situation. Ich bekam im Grunde meinen ersten Programmierjob mit einem geringen Gehalt und musste viel Code mit einer schlechten Struktur aufrechterhalten. Anfangs fand ich es lustig, neue Dinge zu lernen, aber als ich am Ende viele Projekte zu warten hatte, neue Projekte zu machen und eine weiße Tafel, die jeden Tag größer und größer wurde, mit Punkten, mit denen ich nicht fertig war, wurde mir klar, dass das so war es hat nicht funktioniert.

Nachdem ich mich zwei Jahre damit abgefunden hatte, kündigte ich und fand ein paar Monate später einen anderen Programmierjob, der perfekt zu mir passte.

Wie auch immer, oft sind es nicht nur Ihre Projekte, die das Problem sein könnten. Ich fühle mich am Arbeitsplatz wohler, wenn ich für meine Arbeit anerkannt und respektiert werde. Das Problem mit der Situation, in der Sie sich befinden, besteht darin, dass Ihre Arbeitgeber möglicherweise nur die Fehler bemerken, die sich aus erstellten Projekten ergeben, und nicht die Zeit, die Sie zum Entfernen aller anderen Fehler benötigen.

Gehalt

Wenn Sie mehr Geld wollen, können Sie es oft bekommen. Ich habe es geschafft, mein Gehalt in weniger als zwei Jahren auf eine Erhöhung von 33% zu verhandeln.

Denken Sie grundsätzlich über den Wert Ihrer Arbeit nach und wie sehr das Unternehmen Sie benötigt. Wenn sie es sich nicht leisten können, Ihnen das Gehalt zu geben, das Sie verdient haben, muss das Unternehmen entweder ihre Ausgaben überprüfen oder feststellen, dass ihr Geschäft nicht funktioniert.

Und wie von vielen hier erwähnt, und ich stimme zu, sind Sie ein sehr wertvoller Teil des Unternehmenspuzzles. Verdammt, Sie sind wahrscheinlich der einzige, der dieses Rätsel lösen kann. :)

Da ich noch keinen Kommentar abgeben kann, weil ich ein Lauer auf dieser Stack Exchange-Site bin, werde ich hier nur die Informationen ergänzen.

1. Da Sie gerade erst anfangen, wird Ihr Gehalt nicht herausragend sein, es sei denn, Sie haben für ein großes Unternehmen wie Microsoft, Amazon oder ähnliches gearbeitet. Aber es sollte nicht das eines Lebensmittelangestellten sein! Lassen Sie sich nicht lange damit abfinden, sammeln Sie Erfahrung mit dem, was Sie tun, und machen Sie weiter, wenn sich eine bessere Gelegenheit ergibt.

2. Für einen Einstiegs-Gig ist das normal. Ihre Arbeitsbelastung ist zu hoch, aber die Art der Arbeit wird erwartet. Um ein besserer Entwickler zu werden, müssen Sie aus den Fehlern anderer lernen. Je mehr Sie sehen, desto besser werden Sie. Aber das bedeutet, dass Sie nach Dingen suchen, aus denen Sie lernen können, und nicht nach schlechten Gewohnheiten ...

3. Das Verhältnis von Instandhaltung zu Projektarbeit sollte sich im Laufe der Zeit ändern. Wenn dies nicht der Fall ist, bedeutet dies, dass das Unternehmen, für das Sie arbeiten, nicht weiß, wie ein guter Entwickler zu halten ist. Sie wollen, dass Sie Tag für Tag dasselbe tun. Machen Sie sich ein jährliches Ziel, wo Sie sein möchten, wie hoch die Gehalts- und Beschäftigungserwartungen sind, und bewegen Sie sich entsprechend.

4) Wenn du nicht glücklich bist, geh! Das Leben ist zu kurz, um mit dummen Leuten umzugehen.

Alles Gute.

Sie beginnen mit der Verwendung eines Issue-Trackers, um Ihre Aufgabenliste im Auge zu behalten.

Dies hilft Ihnen nicht nur dabei, den Überblick zu behalten, was wichtig ist, sondern es hilft den Benutzern und Ihrem Chef, die aktuelle Arbeitslast zu ermitteln.

Sollten sie jemals einen zweiten Entwickler einstellen (oder Sie kündigen und Ihr Nachfolger nimmt jetzt Ihre Arbeitslast in Anspruch), hilft dies auch bei der Verwaltung der Arbeitslast, und Sie können es vermeiden, sich gegenseitig auf die Zehen zu treten.

Die einzige Möglichkeit, diese Kette zu durchbrechen, besteht darin, neue Infrastrukturen zu entwickeln, die auf Flexibilität ausgelegt und auf vollständige Unit + Integration getestet sind.

Wenn Sie es schaffen, dies an das Management zu verkaufen (andere Entwickler und Manager in 1: 1-Meetings an dem Konzept zu beteiligen), können Sie langsam einen Zustand erreichen, in dem sich der größte Teil des Anwendungscodes in der Infrastruktur befindet und leicht zu verwalten ist erweitern und pflegen, während die eigentlichen Anwendungen leicht sind und ziemlich schnell geschrieben werden können.

Die Entwicklung der Infrastruktur kann zunächst das Ersetzen von Teilen bestehender Anwendungen und nach einer Weile (möglicherweise einige Jahre) das Ersetzen ganzer Anwendungen ermöglichen.

Langfristig kann dies die Entwicklungszeit neuer Anwendungen und die Wartungszeit zukünftiger vorhandener Anwendungen drastisch reduzieren.

Die neue Entwicklung erfordert mindestens 80% Engagement (vorzugsweise mehr) mit einem Team von mehr als einem Entwickler (ein paar Köpfe sind besser als einer). Alle Entwickler müssen in der Lage sein, kreativ zu denken und bestehende Vorurteile zu überwinden.

Versuchen Sie, eine solche neue Infrastruktur zu definieren und auf hoher Ebene zu entwerfen, und präsentieren Sie die Definition dann Ihren Kollegen und dem Management.

Bitten Sie unter Berücksichtigung Ihrer Arbeitsbedingungen ein neues Infrastruktur-Team zu leiten, das sich mit diesen Problemen befasst (basierend auf Ihren Definitionen und Ihrem Design) und neue Entwickler hinzuzuziehen, um das alte Material zu pflegen, während Sie ihnen bei Bedarf zur Seite stehen (bis zu 10-20% von die Zeit). Wenn das Management der Idee zustimmt, können Sie eine Neuverhandlung Ihrer Bedingungen beantragen. Bereite dich darauf vor, einen anderen Job zu finden, wenn sie sich weigern. (Denken Sie daran, dass Ihre Arbeit Fähigkeiten, Kenntnisse und Erfahrung erfordert. Sie sind nicht so einfach zu ersetzen, wie sie Sie dafür bezahlen, zu glauben.)

Hat Ihr Manager Kenntnis von all diesen Änderungsanforderungen (Wartungsanforderungen)? Ist ihm / ihr klar, dass Ihre Zeit damit verbracht ist, solche Anfragen zu durchforsten, für die Sie keine Sanktionsbefugnis haben? Oder nehmen Sie einfach jedes Mal Änderungen vor, wenn Sie von einem Manager gefragt werden?

Mir scheint, Ihre erste Anlaufstelle ist es, alles auf den Schreibtisch Ihres Managers zu legen. Niemand sollte direkt zu Ihnen kommen. Probleme sollten durch jeden Bereich kommen - normalerweise durch ein Support-Team. Es ist normal, dass Sie Ihren Code für eine kurze Übergabezeit - normalerweise eine Woche oder so - unterstützen. Änderungen sollten in jedem Unternehmen, das sich selbst als "mittelgroß" einstuft, berechnet und berechnet werden (Transfergebühr), und dies scheint umgangen zu werden (kein Wunder, dass sie Sie überfluten - Sie sind wie die Schlampe beim Abschlussball).

Es sollte ein angemessenes Anforderungsverfahren sowohl für das Erheben von Problemen als auch für Änderungsanforderungen geben. Bei Support / Wartung geht es um die Behebung von Fehlern und Problemen (die mit der ursprünglichen Spezifikation übereinstimmen, jedoch aufgrund eines Fehlers im Code oder eines externen Ereignisses fehlschlagen - z. B. eines Stromausfalls oder eines beschädigten Upstream-Systems usw.).

Wenn Ihr Unternehmen nichts davon anbietet und erwartet, dass Sie diese unzähligen zufälligen Anfragen bewältigen und dafür verantwortlich sind, müssen Sie ernsthaft darüber nachdenken, weiterzumachen. Das Gehalt ist im Grunde immer schlecht - in meinem ersten Programmierjob (vor fast 25 Jahren) habe ich 8 Jahre für dasselbe Unternehmen gearbeitet und mein Gehalt ist wenig gestiegen (obwohl es immer viel höher war als ein Kassierer!). Innerhalb von 2 Jahren nach meiner Abreise hatte ich es verdoppelt - und zwei Jahre später nahm ich mehr als das Zehnfache meiner Anfangszeit mit nach Hause (war aber dann ein unabhängiger Auftragnehmer). Wie immer kannst du dir Sporen verdienen, dein Handwerk erlernen und in eine wärmere Umgebung springen.

Vielleicht sind Sie in der Lage, zu einem Manager zu gehen und zu sagen: "Schauen Sie, ich bin ehrlich zu Ihnen. Mein Gehalt ist schrecklich, ich könnte dies N-mal als Einsteigerprogrammierer bei X bekommen.

Ich mache viel zu viel mit A, B und C. Ich kann das nicht behaupten. Ehrlich gesagt, und ohne Straftat beabsichtigt, werde ich dieses Zimmer entweder mit festem Inhalt oder mit meinem Kündigungsschreiben verlassen. Wie können wir zusammenarbeiten, um dieses Problem zu lösen? "

Die Antwort ist, zu versuchen, es mit verständlichen Begriffen zu erklären.

• Es ist wie ein Ölwechsel. Sie sind nicht dringend ... müssen aber trotzdem regelmäßig durchgeführt werden
• Übermal Rost und es wird toll aussehen. Bis es durchblutet
• Bauen Sie einen neuen Dachterrassen-Schreibtisch, ohne die Stützen zu verstärken. Es wird vielleicht eine Weile funktionieren. Dann wird es zusammenbrechen und die Menschen verletzen und Sie werden dafür verantwortlich sein.
• A / C ist großartig. Eine Fenstereinheit eignet sich hervorragend für ein oder zwei Zimmer. Wenn Sie versuchen, 146 Fensterklimageräte in ein Wohnhaus zu stellen, haben Sie ... Probleme.
• Es ist in Ordnung, 5 Kinder zu unterrichten. 10 ist nicht so schlimm. Aber es gibt Grenzen. Versuchen Sie, 75 Kinder informell zu unterrichten, und Sie werden es sehen.

Wenn diese nicht mitschwingen. Urlaub - an dem Tag, an dem Sie ein Angebot zum Schreiben erhalten, nicht am nächsten Tag! Wenn Sie einen neuen Job gefunden haben, kündigen Sie dies mit NULL. Kommen Sie buchstäblich nicht an diesem Tag. Aber stellen Sie sicher, dass Sie einen oder zwei Kollegen haben, die wissen, was Sie getan haben. Dies wird dem Unternehmen tatsächlich helfen, wenn dem Unternehmen geholfen werden kann, indem es ihnen zeigt, dass ihre Missachtung und Arroganz einen Preis hat. Letzte Firma, bei der ich innerhalb von 6 Monaten bei THREE OF THE FOUR TECH's LEFT war, ohne einen Job zu machen. Zumindest gab es eine Erklärung ab und gab der abreisenden Person einmal eine gute Gelegenheit zu sagen: „Ja, schön, wenn du jeden Tag sagst, aber du bist so voll davon, dass ich dir nicht einmal die Befriedigung meiner Kündigung gebe.

Schließlich sollten Sie wissen, dass dies vor 20 Jahren die NORM und der Standard war, bevor Agile, Tdd, Bdd und Refactoring mehr als normal wurden. Sie sprechen vielleicht mit älteren Leuten, die sofort antworten: "Nun, ich habe das selbst gemacht und es hat gut funktioniert, bla, bla, bla." Nun, sicher, dass Pferde und Kutschen vor 150 Jahren gut funktionierten. In Technologiebereichen sind Techniken von vor 20 Jahren genauso veraltet wie Transporttechniken von vor 150 Jahren. Wenn sie dieses Bußgeld ablehnen. Wisse nur, dass sie niemals anständige aktuelle Technologieentwickler einstellen werden, die dabei bleiben werden. Sie werden das Schlimmste vom Schlimmsten bekommen und es wird ihr Geschäft fürchterlich verletzen. Wenn sie auf Technologie angewiesen sind und sich nicht anpassen können, werden sie scheitern und letztendlich ist dies die beste Belohnung für Sie. Es'

Es hört sich so an, als würde Ihr Management Sie grundsätzlich nicht respektieren oder Ihre Arbeitsbelastung nicht verstehen.

Sie sollten nicht jede Feature-Anfrage implementieren, die eingeht. Ihr Manager sollte als Puffer zwischen Ihnen und eingehenden Anforderungen fungieren (mit Ausnahme der vielleicht einfachsten Break / Fix-Anforderungen). Dann sollte er oder sie sich mit Ihnen zusammensetzen und die Machbarkeit und Priorität für genehmigte Anfragen bestimmen.

Außerdem solltest du wahrscheinlich 2x (zumindest) das machen, was sie dir bezahlen.

Es hört sich so an, als bräuchten sie wirklich mindestens 1 Entwickler mehr, um mit Ihnen zusammenzuarbeiten, aber mit dem, was sie für Sie bezahlen, klingt das ziemlich unwahrscheinlich.

Wenn sie nicht bereit sind, Sie angemessen zu bezahlen oder Ihnen bei der Bewältigung Ihrer Arbeitsbelastung zu helfen, würde ich nach einem neuen Job suchen. Sie möchten an einem Ort arbeiten, an dem Sie Teil eines Teams sind und an dem Ihr Management mit Ihnen zusammenarbeitet, um Ihre Projekte abzuschließen. Verlasse das sinkende Schiff sobald du kannst.

Ein Held in einem Team von einem zu sein, wird dich nur verbrennen.

Ich bin nur ein Student (noch), aber das ist ziemlich normal (aus meiner Praktikumserfahrung). Das bekommen Sie, wenn Sie in Support- und Webanwendungen arbeiten.

Ich rate Ihnen zu verstehen, was der Client (Manager) möchte, bevor Sie mit dem Codieren beginnen. Das kann schwierig sein, weil sie es manchmal selbst nicht wissen, also arbeiten Sie mit ihnen, bis sie sich auf etwas einigen. Stellen Sie sicher, dass Sie beide die endgültige Lösung vereinbaren, bevor Sie sie codieren.

Auch wenn Sie ein Betreuer sind, können Sie so ziemlich alles im Code ändern - stellen Sie einfach sicher, dass es das Verhalten nicht ändert oder Fehler einbringt. Ich gehe davon aus, dass Manager Ihnen nicht erlauben, etwas zu ändern, weil sie daran gewöhnt und zufrieden sind, wie es jetzt ist, und nicht für neue Änderungen bezahlen möchten.

Machen Sie sich keine Sorgen, wenn Sie mit etwas nicht umgehen können, weil Sie etwas anderes tun. Ich rate Ihnen, die Leute wissen zu lassen, dass Sie mit Arbeit überfordert sind und ihre Anfrage einige Zeit in Anspruch nehmen wird. Wenn Sie keine Manager wären, würden Sie einfach denken, dass Sie faul sind. Teilen Sie ihnen mit, dass Sie bereits eine Arbeit haben und dass sie möglicherweise mehr Leute einstellen. Es gibt keine andere Möglichkeit für sie zu wissen, dass die Arbeit für eine einzelne Person zu viel ist.

Dies ist ein Projektmanagementproblem. Verwenden Sie eine Art Projektmanagement, um zu entscheiden, woran die höchste Priorität bei der Arbeit liegt.

a) Sie benötigen einen Rückstand an Artikeln, an denen Sie arbeiten können. Sie haben Ihren Plan zur Verbesserung des Codes in den Rückstand aufgenommen.

b) Alle Fehler gehen in den Rückstand

c) Der Rückstand wird priorisiert.

d) Sie erledigen alles in Prioritätsreihenfolge.

Bugs haben zwar eine höhere Priorität, aber wenn Sie einmal alle Zyklen behoben haben, die Sie für neue Funktionen oder für das Refactoring von Designs ausgeben müssen.

Am einfachsten ist es, Verbesserungen nur schrittweise umzugestalten, wenn Sie Abschnitte überfliegen, in denen Probleme / Fehler behoben werden müssen. Dann können Sie dem Management sagen: "Ich musste A reparieren, aber B war grundlegend kaputt und ich musste Lösung C durchführen, um alles zu reparieren, damit D in Zukunft einfacher / billiger wird." Wobei A = der Fehler, B = der Fehler Anti-Muster, C = Lösung, D = Zukünftige Gewinne

Wenn Sie Arbeit nicht als eine Investition rechtfertigen können, die sich lohnt, werden Geschäftsleute sie niemals akzeptieren.

Das ist Business as usual. Sie werden ausgenutzt, solange Sie dort weiterarbeiten, wie es scheint. Es liegt im Interesse des Unternehmens, dieses Modell weiterzuverfolgen, anstatt dass Sie sich bei dem, was Sie tun, glücklich fühlen. Wenn es darauf ankommt, ist es ihnen eigentlich egal. Es geht darum, verlässlichen Code für sie zu erstellen, und wenn Sie eine Ein-Mann-Band sind, machen sie Sie mit Sicherheit zur Bank. Warum sollten sie sich ändern?

Die gute Nachricht dabei ist, dass Sie ein VIP für sie sind, auch wenn sie es nicht wissen. Ich schlage vor, vor dem Springen des Schiffes noch ein paar weitere Möglichkeiten zu finden, diese dann an den Bällen zu packen und ein höheres Gehalt zu verlangen. Wenn nicht, gehen Sie zu einer besseren Gelegenheit. Meiner Meinung nach sollten Sie bald spannendere Arbeiten finden. Zielen Sie so hoch wie möglich. Wenn Sie erst einmal in einem Entwicklergeschäft sind, sind Sie viel glücklicher als bei Google oder einem unterhaltsamen Startup, wo es eine kollaborative Entwicklerkultur gibt, in der Sie sich wirklich glücklich fühlen werden.

Was ich persönlich tat, war, eine Headhunter-Unternehmerorganisation zu nutzen, und schnell viele großartige Erfahrungen zu sammeln, von einem zum anderen zu wechseln, während ich immer noch eine feste Anstellung bei meinem Unternehmer hatte. Es hält Sie davon ab, sich zu langweilen und fordert Sie heraus. Schließlich baute ich in meiner Freizeit ein kleines Geschäft auf, das sich zu einem echten Geschäft entwickelte, und dann sprang ich von der Auftragsarbeit ab.