Woher wissen Manager, ob eine Person ein guter oder ein schlechter Programmierer ist?

49

In den meisten Unternehmen, in denen Programmierteams und Abteilungen tätig sind, arbeiten Programmierer, die Code entwerfen und schreiben, und Manager, die ... das Management übernehmen. Abgesehen davon, dass sie keinen Code schreiben, sehen sich Manager in der Regel nicht einmal den Code an, den das Team entwickelt, und möglicherweise ist auf ihren Arbeitsmaschinen auch keine richtige IDE installiert.

Dennoch müssen die Manager beurteilen, ob eine Person gut funktioniert, ob sie mit etwas betraut werden soll oder ob ein bestimmter Entwickler einer Aufgabe von größter Wichtigkeit und Verantwortung zugeordnet werden soll. Und last but not least: Die Manager vergeben in der Regel die vierteljährlichen Boni!

Um dies effektiv umzusetzen , sollte ein Manager wissen, ob eine Person ein guter Programmierer ist - unter anderem natürlich. Die Frage ist, wie machen sie das? Sie schauen sich nicht einmal den Code an, den die Leute schreiben, sie können die Qualität der Komponenten, die die Programmierer entwickeln, nicht direkt einschätzen meiste Fälle!

Was ist das Geheimnis?

P Shved
quelle
24
Gute Frage. Die meisten Manager, für die ich gearbeitet habe, sehen die schlechtesten Entwickler (wirklich schlechten Code und Design) als die besten im Team an, weil sie immer pünktlich liefern. Dann sind es andere in den Teams, die nach ihnen fegen und warten. Manager sollten ab und zu Code lesen ...
Martin Blore
18
Denken Sie daran, was einen "guten Programmierer" für Programmierer ausmacht, stimmt möglicherweise nicht mit dem überein, was einen "guten Programmierer" für einen Manager ausmacht.
GroßmeisterB
11
Meistens tun sie es nicht.
biziclop
1
Es scheint die Antwort zu sein, wie Manager wissen sollten , ob eine Person ein guter oder ein schlechter Programmierer ist.
Jigar Joshi
2
Aus diesem Grund habe ich immer behaupten , dass ein Software - Entwicklungsmanager sollte sein ein Programmierer oder vielmehr waren ein Programmierer. Ihre Aufgabe ist es jetzt, zu managen, aber um effektiv zu managen, müssen sie verstehen, was sie managen. Sie können das nur wirklich gut, wenn sie selbst in nicht allzu ferner Vergangenheit Programmierer waren (und sich weiterhin zumindest mit neuen Technologien in der Softwareentwicklung vertraut machen).
CraigTP

Antworten:

31

Normalerweise schaut sich ein Manager das an

  • Lässt der Programmierer Sachen erledigen?
  • Was halten ihre Kollegen von ihnen? Der Code, den sie schreiben?
  • Kommuniziert der Programmierer klar mit dem Manager?
  • Gefällt es dem Programmierer, neue Dinge zu lernen? Mentoren sie andere gut?
  • Brauchen sie viel Aufmerksamkeit des Managements, um Dinge zu erledigen?
  • Scheint der Programmierer Spaß an seiner Arbeit zu haben?

Es ist wahr, dass sie normalerweise den Code von Mitarbeitern nicht sehen (oder oft nicht verstehen), aber das Obige dient ihnen als angemessener Anhaltspunkt dafür, wie gut ein Mitarbeiter in die Programmierrolle passt, die ihm von seinem Arbeitgeber auferlegt wird. Wenn jemand Dinge nicht erledigt, schlechte Noten von seinen Kollegen bekommt, nicht gut kommunizieren kann, frustriert über andere Technologien ist, an die er gewöhnt ist, immer beaufsichtigt werden muss und immer unglücklich ist, ist dies ein gutes Indiz dafür, dass er nicht da ist. ' t gut mit diesem Job ineinandergreifen. *

* Es kann jedoch sein, dass sie in einem anderen Kontext und Umfeld sehr glücklich und enthusiastisch wären. Vielleicht ist es nur eine Art Programmierer, gegen den sie Einwände erhoben, und sie können in einem anderen Kontext sehr gut programmieren. "Programmierer" kann sehr unterschiedliche Jobs an verschiedenen Orten bedeuten. Der Manager kümmert sich jedoch hauptsächlich um die Rolle des "Programmierers" und wie gut ein Mitarbeiter passt.

Doug T.
quelle
Ich denke, das wichtigste dieser Themen ist: Lässt der Programmierer Dinge erledigen? - Ich beende es nur durch Hinzufügen. Erledigt der Programmierer die Aufgaben im Zeitplan ?
Herberth Amaral
2
Winziger Vorbehalt in Bezug auf "Kommuniziert klar mit dem Manager": Es kommt mehr darauf an, ob der Manager glaubt , verstanden zu haben oder nicht, als darauf, ob er wirklich verstanden hat oder nicht. Deshalb muss man am Ende überprüfen, was er verstanden hat, denn trotz seiner überheblichen Einstellung hat er möglicherweise etwas völlig anderes verstanden.
Wildpeaks
4
Herberth: "Get's stuff done" (pünktlich oder nicht) ist nicht unbedingt ausreichend, da die anderen Teammitglieder ihre Lose aufheben könnten.
Cercerilla
2
Und "erledigt Sachen" ohne viele Bugs ist auch wichtig. Mit anderen Worten, gehen sie immer zurück und reparieren Dinge oder ist etwas erledigt, wenn es erledigt ist?
Donnerstag,
23

Ich bin mit der Behauptung nicht einverstanden, dass Manager keinen Code betrachten. Wenn ich Teams geführt habe, habe ich mir einige der Ergebnisse aller Ingenieure angesehen - und ein großer Teil davon ist Code. Aber nicht das Einzige - E-Mails, Designdokumente, Whitepapers - das alles ist entscheidend.

Aber das ist definitiv nicht der einzige Faktor. Wenn einer in einer Ecke sitzt und brillanten Code schreibt , aber ein Biest zum Reden ist, keine Fragen beantwortet, keinen Status teilt und keine Kompromisse eingeht, wenn Entwicklungsprobleme auftauchen - ich bin mir nicht so sicher, ob er einer ist Vorteil für das Team. Besonders im Vergleich zu einem Typ, der mäßig anständigen Code schreibt, aber all das oben Genannte kann.

Hier sind einige Dinge, die ich mir anschaue, wenn ich in der Lage bin, Belohnungen auszugeben, aber mit dem großen Vorbehalt, dass es sich absolut um eine Darmreaktion handelt, kann nichts davon quantifiziert werden:

  • Status - ist er klar, genau und aktuell? Wenn besprochen, ist die Person ganz oben auf dem Status oder ein wenig verschwommen in Bezug auf die aktuellen Probleme? Hat die Person das richtige Urteilsvermögen, eine rote Fahne zu hissen, wenn etwas in Brand geraten ist?
  • Problemlösung - Fragen und Antworten sind wichtig. Weiß die Person, wann sie um Hilfe bitten muss oder wo sie auf unbestimmte Zeit ihre Räder dreht? Besser noch, wenn andere Probleme haben, hilft die Person dabei, die Lösung zu finden oder Teil des Problems zu werden? Selbst wenn Sie den gesunden Menschenverstand haben, sich zurückzuziehen, wenn das Problem nicht in Ihrem Fachgebiet liegt, sind Sie ein paar Punkte wert. Es gibt auch Punkte, um außerhalb der Gruppe oder des Unternehmens zu gehen und Websites wie diese oder andere Internet-Antworten aufzurufen.
  • Die Aufmerksamkeit auf die Verarbeitung - normalerweise ist dies ziemlich offensichtlich - selbst in einem nicht anal-zurückhaltenden Unternehmen, wenn sich jemand dem System widersetzt, ist dies in dem Chaos zu sehen, das sie hinter sich lassen. Wenn andere Leute die Eigenschaften einer anderen Person bereinigen, weil sie sich nicht an die Richtlinien oder die Architektur halten, dann haben wir ein Problem. Bonuspunkte gehen zu denen , die Möglichkeiten herauszufinden Konsistenz und Qualität zu machen einfacher .
  • Abschlussraten vs. Bugs vs. Komplexität - erledige Dinge, aber erledige sie richtig. Jeder hat ein paar Fehler, aber wenn der Typ Dinge schnell und fehlerhaft erledigt, haben wir ein Problem. Ich bin im Allgemeinen der Meinung, dass Sie dies nicht im täglichen Sinne beurteilen können - es muss sich um eine Veröffentlichung, eine Phase oder ein Geschäftsquartal handeln.

Und der Input anderer Leute. Häufig war ich in einer Position, in der verschiedene Ingenieure für verschiedene Teile des Projekts verantwortlich waren. Manchmal führt das Team und manchmal nur die Eigentümer eines bestimmten Outputs (wie "der Build-Typ"). Die Menschen LIEBEN es, über die Extreme zu sprechen - über Heldentaten oder die Frustration der Sorgenkinder. Normalerweise erfahre ich gerade viel über BEIDE Partys, wenn ich diese Themen weiterverfolge.

Es gibt auch einen Faktor in Bezug auf das Managen von Menschen . Kein Ingenieur ist genau wie der andere. Sie leuchten also nicht alle im selben Licht. Einer schreibt brillanten, fehlerfreien Code, aber ein anderer hilft bei der Lösung von Problemen, die den Code eines jeden sprengen. Man ist persönlich großartig, man ist schriftlich besser. Man ist um 9.00 Uhr inkohärent, man ist um 15.00 Uhr von hier weg. Es gibt eine gewisse Notwendigkeit, einen Schritt zurückzutreten, herauszufinden, was für das Team am vorteilhaftesten ist und was ein Faktor für die persönliche Voreingenommenheit sein könnte (wie das Verlangen, diesen Kerl von 4:00 Uhr morgens zu töten, nur weil ich bis 11 Uhr nicht funktionieren kann: 00 Uhr).

bethlakshmi
quelle
2
Es scheint die Antwort zu sein, wie Manager wissen sollten , ob eine Person ein guter oder ein schlechter Programmierer ist.
Jigar Joshi
Nach meiner Erfahrung in den Organisationen, in denen ich gearbeitet habe, haben Manager leider nicht die Bandbreite, um sich jeden Entwicklercode anzusehen.
Doug T.
@Jigar Joshi - ich weiß nicht, wie jeder Manager das macht - das habe ich getan, als ich gebeten wurde, Leistungsbeurteilungen durchzuführen oder Empfehlungen abzugeben.
Bethlakshmi
@pythagras - meine Gegenfrage wäre "welcher Manager?" Ein Manager von 40 Leuten - nein, natürlich nicht. Ein Manager mit 10 Mitarbeitern - würde Sie wahrscheinlich nicht umbringen, wenn Sie sich innerhalb von 1 Stunde pro Person in kritischen Bereichen mit dem Scannen von Code befassen. 1 Stunde pro 10 Mitarbeiter über 6 Monate scheint problemlos machbar.
Bethlakshmi
12

Dies ist sehr unterschiedlich und hängt vom technischen Fachwissen des Managers ab.

  • Meistens beurteilen sie Sie wahrscheinlich danach, wie Sie kommunizieren . Wie Sie mit dem Manager kommunizieren und wie Sie die Kommunikation mit Ihren Kollegen sehen.
  • Wenn Sie das Glück haben, einen Lead-Entwickler zu haben , der näher am Manager ist, kann der Manager den Lead-Entwickler um Rat bitten.
  • Denken Sie daran, dass die Hauptverantwortung des Managers darin besteht, die Dinge zu erledigen . Er muss verschiedene Ergebnisse und Ziele erzielen, um den Geschäftsplan zu erfüllen. Wenn Sie also irgendwie so aussehen können, als hätten Sie direkten Einfluss auf das Ergebnis , ist dies ein gutes Zeichen für Sie.
Jonathan Khoo
quelle
2
Weißt du, die Hypothese "Hauptentwickler" erinnert mich an die Exogenese-Theorie, nach der das Leben auf der Erde von Außerirdischen erschaffen wurde. Ja, ein Manager kann sich in der Tat auf die Beobachtungen des leitenden Entwicklers verlassen, aber es war dieser Manager, der diesen Entwickler zum "Leiter" gemacht hat! Das bringt uns zurück zum Problem: Woher weiß das Management, wer zu führen ist?
P Shved
@Pavel: Sie haben auf ein interessantes (noch separates) Problem hingewiesen . Vorausgesetzt, ein leitender Entwickler wurde ernannt: Die Mehrheit der Führungskräfte vertraut und glaubt an ihre Entscheidung (dh an denjenigen, den sie ausgewählt haben).
Jonathan Khoo
if you're somehow able to look like you've having a direct influence on the outcome. Das ist die Sache, die am meisten von guten Bonusverdienern, aber schlechten Programmierern ausgenutzt wird.
IsmailS
7

Im Allgemeinen nicht.

Deshalb ist Programmieren ein "Markt für Zitronen". http://en.wikipedia.org/wiki/The_Market_for_Lemons

Code ist kaputt und es dauert in der Regel zwei bis drei Jahre, bis Sie es wissen. Programmierer bleiben in der Regel 18 Monate, so dass Sie die Schuldigen am Scheitern nie sehen.

Manager müssen sich darauf verlassen, dass beispielsweise eine Veröffentlichung vier Monate und hundert Iterationen dauert. Vielleicht bearbeiten Sie viele Bereitstellungsdateien von Hand und lesen die Protokolldateien von Hand, um Fehler zu erkennen, die mit dem Status vermischt sind. Sie wissen nicht, dass es besser geht.

Also sei ehrlich und professionell und versuche dich zu verbessern. Mit der Erfahrung wird ein Manager anfangen, Muster von gutem und schlechtem Verhalten zu erkennen.

Tim Williscroft
quelle
In Bezug auf meinen Kommentar zur Frage selbst, ob Manager selbst Programmierer sind (oder gewesen sind). Was Sie in Ihrer Antwort beschreiben, ist genau das, was ich erlebt habe, als ich einen Manager hatte, der selbst kein Entwickler war oder war . Leider gibt es viele Manager wie diese da draußen.
CraigTP
5

Woher wissen Manager, ob eine Person ein guter oder ein schlechter Programmierer ist?

Ich beginne mit einer groben Verallgemeinerung: Die meisten Manager können einen "guten" Programmierer nicht von einem "schlechten" Programmierer unterscheiden.

Abgesehen davon ist das, was die meisten Manager (die ich getroffen habe oder für die ich gearbeitet habe) in einem Programmierer für "gut" halten, nicht das, was ein anderer Programmierer für "gut" hält.

wie machen Sie das?

Ein ergebnisorientierter Manager wird nach Dingen wie "klug" suchen und "Dinge erledigen". Es ist ihnen egal, ob Sie in Jogginghosen arbeiten, solange Sie die Arbeiten pünktlich und im Rahmen des Budgets erledigen.

Ein prozessorientierter Manager kümmert sich mehr darum, "wie Dinge erledigt werden". Dies bedeutet, pünktlich zur Arbeit zu gehen, die richtige Kleidung zu tragen und das richtige Deckblatt für den TPS-Bericht zu haben.

Person funktioniert gut, wenn er oder sie für etwas verantwortlich gemacht werden sollte

Verantwortungsbewusstsein erfordert andere Fähigkeiten als das Schreiben von Code. Wenn eine Person über die erforderlichen Fähigkeiten verfügt, um ein Team zu führen, sollte diese Person dazu angehalten werden. Wenn Sie die Beförderung von Personen auf der Grundlage der wichtigsten Jobelemente des Jobs durchführen, den sie gerade ausführen, erreichen sie schließlich eine Ebene, auf der sie jetzt inkompetent sind. Dies nennt man das Peter-Prinzip .

Tangurena
quelle
Ich habe noch nie die Trennung zwischen ergebnisorientierten und prozessorientierten Managern gehört. +1 dafür.
mwilcox
4

Natürlich ist es immer hilfreich, einen Programmier-Manager zu haben, der tatsächlich Code liest und, was noch wichtiger ist, sich mit dem Bug-Tracking-System befasst und versteht, was gerade passiert für viel.

Aber das ist ein idealer Fall. Damit ein Manager das Maß eines Programmierers aus einer nicht-technischen Perspektive erkennt, habe ich einige Vorschläge.

  • Machen sie umgehend / regelmäßig / konsequent darauf aufmerksam, wo es Probleme gibt, Dinge zu erledigen, die den derzeit festgelegten Anforderungen entsprechen ... und sind deswegen gründlich ärgerlich (dies ist schließlich Softwareentwicklung, wenn es nicht komplex genug ist, um diese Probleme zu haben, Es ist kein echtes Entwicklungsprojekt.
  • Wenn sie sich bei etwas nicht sicher sind, sagen sie es sofort - nur ein Programmierer, der sich ihrer eigenen Fähigkeit sicher ist, würde dies tatsächlich tun (und sie wissen, wenn es Ihnen nicht gefällt, können sie leicht einen anderen Job bekommen). Umgekehrt neigt jemand, der weiß, dass er ernsthaft überfordert ist, dazu, sich zu verstecken und Deckung zu suchen.
  • Was sagen / implizieren andere Programmierer im Team über die anderen Programmierer? Wenn Sie ein halbwegs anständiger Manager sind, befinden Sie sich mit Ihrem Programmierteam im Graben - insbesondere während der Integrations- / Fehlerbehebungszeit. Wenn Sie diese Art von Feedback nicht erhalten, sollte jemand anderes Ihre Arbeit erledigen.
  • Und mein Favorit: das, was ich den 'Kater'-Programmierer nenne. Wenn Sie nach einer Weile ständig bemerken, dass verschiedene Programmierer immer am selben Programmierpult sitzen (vorausgesetzt, sie arbeiten und diskutieren ein problematisches Thema, und nicht der ortsansässige Finder von coolem und lustigem Webmaterial), dann gibt es einen Grund für andere Programmierer werden zum Schreibtisch dieser Person angezogen. Wenn sie nicht bereits ein Teamleiter sind, sollten sie wahrscheinlich so schnell wie möglich zu einem gemacht werden.

Wenn einer oder alle dieser Punkte zutreffen, haben Sie wahrscheinlich einen guten Programmierer in Ihren Händen. Beachte, dass ich von einem guten Programmierer nicht nur die Codierungsfähigkeiten bewerte, sondern auch andere nützliche Dinge wie die Fähigkeit, mit anderen Menschen zu kommunizieren ;-)

nomaderWas
quelle
gee danke ... wenn ja, wäre das mein erstes meme. Für den Fall, dass es für niemanden offensichtlich ist, ergibt es sich aus der Analogie der "Hütekatzen".
nomaderWhat
3

Der Manager weiß möglicherweise nicht, wann der von Ihnen geschriebene Code brillant ist oder ob er um einen großen Faktor verbessert werden könnte. Sind Sie eine Person, der er vertrauen kann, um die Probleme zu lösen, die andere Menschen verursachen? Hat der Kunde oder Benutzer ein Problem bemerkt, das zu seinem Vorgesetzten eskaliert ist? Gab es ein schwerwiegendes Unglück auf Ihrer Uhr? (Löschte die Benutzertabelle, vergaß, Backups einzurichten, schickte eine E-Mail an Kunden mit Eigentumsdaten eines anderen Kunden, die sie nicht hätten sehen dürfen, usw.) Hat ihm jemand Ihre Arbeit gelobt (insbesondere schriftlich)? Sagen die Leute hinter deinem Rücken gute oder schlechte Dinge?

HLGEM
quelle
1
Es klingt für mich nach Politik und erinnert mich an eine meiner früheren Firmen.
IsmailS
2
  1. In den meisten Fällen, in denen Ihr Code nicht von Ihrem Manager evaluiert wird, wird er von Ihren Kollegen evaluiert (formell oder informell, wenn sie versuchen, mit Ihrem Code zu arbeiten). Ihr Chef wird in gewissem Umfang die Meinungen Ihrer Kollegen verwenden (auch hier, ob formell oder informell).
  2. Ihre allgemeine Zuverlässigkeit und die Geschwindigkeit, mit der Sie Aufgaben erledigen und erledigen, ist oft ein sehr wichtiger Faktor, unabhängig von Ihrer Codierungsfähigkeit.
  3. Kommunikation. Wenn Sie eine Menge erledigen und es gut machen, muss Ihr Manager darüber Bescheid wissen! (Natürlich nicht angeben). Lernen Sie, "Ihren Manager zu managen" und nicht nur passiv zu sein. Helfen Sie Ihrem Chef zu wissen, wie Sie arbeiten.
Matthew Read
quelle
2

Die Manager sind selbst Programmierer und können daher durch einfache Beobachtung herausfinden, ob der Programmierer gut ist oder nicht.

Wenn Ihre Manager keine Programmierer sind (und Sie im Softwaregeschäft tätig sind), sind Sie durchgeknallt.

Vegai
quelle
2

Als Manager habe ich mir bei der Bewertung meiner Programmierer folgende Dinge angesehen:

  • Peer-Feedback. Ich habe die Programmierer in meinem Team und Programmierer aus anderen Teams gebeten, mir Feedback zu meinen Mitarbeitern zu senden.

  • Gleicher Respekt . Wenn meine Programmierer auf ein Problem stoßen, das sie nicht lösen können, sagen sie: "Fragen wir den einen oder anderen um Rat."

  • Lässt Dinge erledigen . Ich sage "Ich will X" und am nächsten Tag ist X fertig.

  • Macht die Dinge schlau . Ich sage "Ich will X" und am nächsten Tag ist nicht nur X fertig, sondern alle X-ähnlichen Dinge sind gelöst und brauchen keine weitere Aufmerksamkeit.

  • Repariert mich . Ich sage "Ich will X" und der Programmierer sagt "X ist nicht richtig, wir sollten Y machen und hier ist der Grund."

Es gibt nicht viele gute Manager (siehe verwandte Frage: Woher wissen Programmierer, ob eine Person ein guter oder ein schlechter Manager ist?). Menschen gut zu managen ist schwierig und erfordert viel Zeit und harte Arbeit. Sobald ich 5 Leute leitete, hatte ich fast keine Zeit zum Programmieren. Als ich 8+ Leute verwaltete, konnte ich sie nicht mehr so ​​gut verwalten, wie sie es verdient hatten.

Jay Bazuzi
quelle
1

Ich denke, dass die Prämisse Ihrer Frage insofern etwas mangelhaft ist, als behauptet wird, dass Manager den Code nicht wirklich betrachten. Ich habe in vielen Situationen gearbeitet, in denen meine Vorgesetzten Mitingenieure waren und aktiv an Codeüberprüfungen teilgenommen haben.

Es gibt jedoch definitiv eine Vielzahl von Situationen, in denen eine nichttechnische Person für Softwareentwickler zuständig ist und sich nicht auf ihre eigenen Kenntnisse und Erfahrungen verlassen kann.

In diesen Fällen werden die zuständigen Manager die Kollegen des Ingenieurs um Rat fragen. Sie befragen nichttechnische Mitarbeiter in der Organisation, mit denen der Ingenieur interagiert, um festzustellen, ob er über gute Mitarbeiterfähigkeiten verfügt, die mit erhöhter Verantwortung vereinbar sind.

Die Unverantwortlichen werden einfach mit ihren "Bauch" -Reaktionen eine Art allgemein nicht unterstützbarer "Metriken" verwenden.

Es ist ein Mist-Shooting, aber Sie können immer aufhören und auf etwas Besseres hoffen.

Adam Crossland
quelle
1

Wo ich arbeite, senden die Manager bei Mitarbeiterbewertungen einen informellen, anonymen Fragesteller an diejenigen, die regelmäßig mit dem Mitarbeiter interagieren. sowohl Mitentwickler als auch Kunden. Dies gibt anderen Entwicklern die Möglichkeit, einen Beitrag zur Leistung als Codierer zu leisten, den Manager ansonsten möglicherweise übersehen.

Mike Clark
quelle
1

Der Manager muss sich die Messgrößen ansehen. Welche Aspekte der Arbeit sind messbar in Bezug auf die geleistete Arbeit, die Qualität der Arbeit. Sie wissen möglicherweise nicht, ob Sie einen Qualitätsjob ausführen, es sei denn, Sie generieren viele Fehler oder der Endbenutzer kann nicht tun, was er tun soll.

Ihre Arbeit kostet den Manager Geld in den Ausgaben, deshalb müssen Sie finanziell rentabel sein, um Beschäftigung fortzusetzen.

Crosenblum
quelle
1

Ich sage nicht, dass dies der beste Weg ist, aber sie könnten es auf die Kundenzufriedenheit stützen. Wenn sie die Anwendung mögen, die Menge der Fehler akzeptieren und das Gefühl haben, dass Sie rechtzeitig neue Funktionen hinzufügen, könnten Ihre Entwickler dann wirklich so schlecht sein?

Natürlich konnten sie. Sie sind in der Lage, durch Codierung Gewalt anzuwenden, da 10 Personen die Arbeit von zwei Personen erledigen. Oder die Kunden sind zufrieden, weil Sie Ihre App so günstig verkaufen.

Ein weiteres Problem bei diesem Ansatz besteht darin, dass Sie warten müssen, bis eine Bewerbung fast vollständig ist, bevor der nicht technische Manager Kundenfeedback erhalten kann. Erstellen Sie eine App für ein Jahr, um sie freizugeben, und niemand mag sie.

Das Leben wäre einfacher, wenn Sie sich darauf verlassen könnten, dass die Leute sagen: "Lass es einfach funktionieren." Wenn Sie verstehen und die Leute dazu bringen, sich an den richtigen Prozess zu halten, beseitigen Sie viele Probleme. Sie können anspruchsvolle Termine haben, die realistisch sind. Jeder Dummkopf kann unrealistische Forderungen stellen und riskieren, talentierte Leute zu verlieren.

JeffO
quelle
1

Ich denke, die meisten von uns in einem technischen Team wissen, wer rockt und wer saugt. Wenn Sie keinen enormen Umsatz haben, steigt die Creme nach oben und das Eigengewicht sinkt. Die miesen Entwickler sind immer in Schwierigkeiten - sie vergessen, ihren Code zu testen, bevor sie ihn einchecken, so dass Builds kaputt gehen. Sie haben immer eine Ausrede, wenn sie etwas nicht erledigen, und so weiter und so fort.

SnoopDougieDoug
quelle
1

Ich denke, sie wissen nicht, ob jemand ein guter Programmierer ist , weil sie nicht die Fähigkeiten dazu haben. Sie prüfen, ob jemand ein guter Entwickler ist . Programmieren ist eine Aktivität der Entwicklung, aber Entwicklung hat viele andere. Sie überprüfen also, ob Sie pünktlich sind, ob Ihre Schätzungen gut sind, ob es viele Mängel in Bezug auf Dinge gibt, die Sie in Ihrem Bug-Tracking-System getan haben, Ihre Soft Skills, Ihr Engagement, Ihre Kommunikation usw.

Was manche It-Gurus manchmal vergessen und sich darüber aufregen, ist, dass unsere Arbeit nicht nur das Programmieren ist, wir haben viele andere Dinge zu tun, die auch sehr wichtig sind. Während Ihr Manager sieht nicht, wie Sie Ihren Code sieht nehmen wie (weil es völlig unwichtig er ist), prüft er , ob Sie ein Teamplayer, verantwortlich, respektvoll und macht eine qualitativ hochwertige Arbeit sind in insgesamt .

Manchmal denke ich, dass Code überbewertet ist.

JSBach
quelle
0

Ich denke, es gibt sehr wenige Leute (geschweige denn Manager), die die Hackordnung für Entwickler nicht allgemein verstehen. Jeder glaubt, ein erstklassiger Entwickler zu sein. Die einzigen Leute, die nicht wissen, wer die schlechten Entwickler sind, sind die schlechten Entwickler selbst. Wie auch immer, wenn Sie jemanden bitten würden, die Entwickler zu bewerten, mit denen er zusammenarbeitet, wäre das für die meisten Menschen sicher eine leichte Aufgabe. Es ist also keine Magie festzustellen, wer eine sehr gute Leistung erbringt und wer eine durchschnittliche oder schlechte Leistung erbringt usw. Das einzige Problem, mit dem Entwickler und Manager nicht einverstanden sind, sind die Verkäufer, die laut klingen, als wüssten sie, wovon sie sprechen über aber wirklich nicht. Die meisten Manager sind von ihnen bamboozled, aber die Entwickler nicht.

Danach bestimmen die Vorurteile Ihres Managers Ihr Ranking. Für manche ist das Codieren eine Einstiegsaufgabe, so dass Sie zwar hervorragend codieren können, aber nicht die gewünschte Promotion erhalten. Während andere die Design- oder Architekturaspekte als am wichtigsten betrachten. Andere wiederum sind der Ansicht, dass die Definition und Erfassung von Anforderungen (dh die Geschäftsanalyse) am wichtigsten ist. Wenn Sie wissen möchten, was für Ihren Manager wichtig ist und Sie kein Top-Performer-Ranking erhalten haben, fragen Sie ihn, was ich tun muss, um ein Top-Performer-Ranking zu erhalten? In dieser Antwort erfahren Sie, worauf es ihnen ankommt, und dann liegt es an Ihnen, sicherzustellen, dass Sie in diesen wichtigen Bereichen hervorragende Leistungen erbringen.

Dunk
quelle