Schreiben Arbeitgeber Stile und bestimmte Machweisen vor ?
-
Zumindest die grundlegenden Prozesse für die Entwicklung sollten schon klar definiert sein. Ist das nicht der Fall, würde ich mir ernsthaft Gedanken machen, ob das der richtige Arbeitsplatz für mich ist.
Ob es darüber hinaus Vorschriften gibt, was Tools, Libs und Styleguides angeht, ist individuell verschieden. Wenn nur geile Typen im Projekt arbeiten, kommt man mit wenig Richtlinien aus. Je mehr einfache Codemonkeys dabei sind, um so wichtiger sind klar einzuhaltende Regeln.
Ich halte grundsätzlich wenig von zu vielen Vorschriften. Sowas gaukelt meistens nur eine falsche Sicherheit vor. Nicht selten leidet eher die Qualität darunter, weil Entwickler in ihren Werkzeugen beschnitten werden. Obwohl Tool XYZ für diesen Fall am besten wäre, darf man es nicht benutzen, weil der Herr Chef Architekt es nicht abgesegnet hat. Das ist dann selten wenig verwunderlich, kennt der Herr Chef Architekt das Tool ja nicht mal, weil er die letzten Jahre gar nicht mehr selbst entwickelt hat und somit technisch längst abgehängt wurde.
Wichtiger sind imo regelmäßige Code Reviews. Daran hapert es aber häufig.
-
Baba Yaga schrieb:
Bashar schrieb:
hustbaer schrieb:
Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,Ist das üblich, dass es solche Ränge gibt?
In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.
-
lol du opfer schrieb:
Baba Yaga schrieb:
Bashar schrieb:
hustbaer schrieb:
Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,Ist das üblich, dass es solche Ränge gibt?
In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.
Das ist ein Überbleibsel der DotCom-Blase. Seitdem nennt sich jeder Kioskbesitzer CEO und jeder Hausmeister Facility Manager.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Beruf und Ausbildung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wir sind auch relativ klein, aber bei uns gibts es auch Head Developer, Senior Developer und Junior Developer...
Wobei bei uns das afaik hauptsächlich Arbeitsvertragsgrade sind, die die Bezahlung und so beeineinflussen. Was wer zu sagen hat, bestimmt das können. Zumindest grob. Wir sind aber echt klein.
Branleb
-
Z schrieb:
lol du opfer schrieb:
Baba Yaga schrieb:
Bashar schrieb:
hustbaer schrieb:
Das kommt auch sehr drauf an wo du in der Hierarchie stehst.
Also Junior-Programmer wirst du kaum Freiheiten haben. [...]
Wenn du dagegen Senior-Developer oder gar Lead-Developer bist,Ist das üblich, dass es solche Ränge gibt?
In sogenannten "Spieleschmieden" betiteln sie sich häufig so, um sich wichtig zu tun. Meistens hat noch nicht einmal der Herr "Lead-Developer" eine formale Ausbildung genossen. Dementsprechend schlecht ist auch die Bezahlung.
NS: In Stellenangeboten seriöser Firmen wirst Du solche Bezeichnungen nicht finden.Doch, gerade dort, eher nicht in kleinen Firmen und "Spieleschmieden", die ich jetzt einfach mal dazuzähle, ganz einfach weil es dort viel größere Abteilungen & Teams gibt.
Das ist ein Überbleibsel der DotCom-Blase. Seitdem nennt sich jeder Kioskbesitzer CEO und jeder Hausmeister Facility Manager.
solang es das pipi größer macht ists doch super
oder hast du, wie ich probleme zu verstehen was du dann effektiv machen mußt
-
noob_lolo schrieb:
oder hast du, wie ich probleme zu verstehen was du dann effektiv machen mußt
Wenn mir jemand sagt, er wäre "Head-Developer", dann würde ich ihn als mittelmässigen Friseur einstufen. "Senior-Developer" ist vermutlich einer, der sich um ältere Mitbürger kümmert, während ich meine Aufgabe als "Junior-Developer" darin sehen würde, möglichst viele Nachkommen zu zeugen.
-
Hi Baba Yaga,
Wenn mir jemand sagt, er wäre "Head-Developer", dann würde ich ihn als mittelmässigen Friseur einstufen. "Senior-Developer" ist vermutlich einer, der sich um ältere Mitbürger kümmert, während ich meine Aufgabe als "Junior-Developer" darin sehen würde, möglichst viele Nachkommen zu zeugen.
besser kann man es einfach nicht auf den Punkt bringen.
Ich weise die Leute in den Backshops und Backfaktorys auch liebend gerne darauf hin, daß sie in einem Arschladen oder einer Arschfabrik arbeiten.Und bei Kaffee ToGo möchte ich auch nichts kaufen, was sollte ich schließlich mit einem Kaffe der zum weglaufen ist.
Gruß Mümmel
-
muemmel schrieb:
Und bei Kaffee ToGo möchte ich auch nichts kaufen, was sollte ich schließlich mit einem Kaffe der zum weglaufen ist.
Und ich dachte immer, "Kaffee Togo" ist ein besonders hochwertiger Exklusivimport aus Westafrika.
Baba Jaga: LOL
-
Egal wie gross oder klein eine Softwarefirma ist, auch Richtlinien zum Stil der Programmierung sind notwendig und sinnvoll. Ein hauseigener Stil muss sein, damit jeder andere in der Firma auch den Code pflegen kann und nicht jeder dasselbe anders macht. Du bist im Urlaub, krank, oder hast die Firma verlassen. Soll deine Arbeit dann liegen bleiben oder weggeschmissen werden? Der Kunde wartet und will eine neue Lösung oder ein Fehler muss schnell gefunden werden. Dem Kunden ist es meist egal, wer da angefangen hat mit der Programmierung.
-
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
-
Manchmal bekommt man als Vorgabe ein "Code Checker" Tool, das bei jeder Kleinigkeit im Code eine Warnung ausspuckt - und da kann man nichts anderes als einen besonderen Stil anzueignen, ob der gut ist oder nicht, sei dahingestellt...
-
volkard schrieb:
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
Ja klar, die Strukturierung eines Programmentwurfes gehört ebenso zum Stil. Auch da kann und darf der Chef klare Vorgaben machen. Bei fremden Projekten fehlt oft einiges im Stil. Dann ist leider manchmal eine Neuprogrammierung unumgänglich. Dies zu vermeiden, ist der Sinn von Stilvorgaben!
-
berniebutt schrieb:
volkard schrieb:
Na, aber ein bißchen überbewertet wird der einheitliche Stil jetzt schon. Bei manchen fremden Projekten kommt man nicht rein. Das liegt meistens gar nicht am fremden Stil, sondern an der fremden Logik, nämlich daran, daß der Architekt nicht programmieren konnte.
Ja klar, die Strukturierung eines Programmentwurfes gehört ebenso zum Stil. Auch da kann und darf der Chef klare Vorgaben machen. Bei fremden Projekten fehlt oft einiges im Stil. Dann ist leider manchmal eine Neuprogrammierung unumgänglich. Dies zu vermeiden, ist der Sinn von Stilvorgaben!
Du hast gar nicht verstanden, was ich schrieb. Aber wenn für Dich Stilvorgaben ein Allheilmittel sind, bin ich ja beruhigt. Euch wird niemals ein Projekt umfallen, weil Ihr einen einheitlichen Stil pflegt. Ich kenne es nur andersrum, daß der Rekursion verbietet und sich dann wundert, daß das Sortieren so langsam ist.
-
volkard schrieb:
Du hast gar nicht verstanden, was ich schrieb. Aber wenn für Dich Stilvorgaben ein Allheilmittel sind, bin ich ja beruhigt. Euch wird niemals ein Projekt umfallen, weil Ihr einen einheitlichen Stil pflegt. Ich kenne es nur andersrum, daß der Rekursion verbietet und sich dann wundert, daß das Sortieren so langsam ist.
Es kann schon sein, dass ich nicht alles verstanden habe, was du erklärt hast. Ein Projekt, das irgendwann umfällt, ist einfach schlecht konzipiert. Ich selbst bin schon in viele gescheiterte Projekte eingestiegen und habe die dann ans Laufen gebracht. Ich meine, ich weiss wovon ich rede. Dein Beispiel mit dem Sortieren ist schwach. Wer immer eine bessere schnellere Lösung für was auch immer hat, kann diese doch einbinden und als Firmenwissen bereitstellen. Der Arbeitgeber wird es dir danken und rückt vielleicht mehr Gehalt heraus!
daddeldu
-
1. Seit wann gibt es ein Beruf und Ausbildungsforum
2. Sehr interessant, so hatte ich mir das irgwo auch gedacht.
Viel interessantes zu lesen.
-
berniebutt schrieb:
Ein Projekt, das irgendwann umfällt, ist einfach schlecht konzipiert. Ich selbst bin schon in viele gescheiterte Projekte eingestiegen und habe die dann ans Laufen gebracht.
Projekte scheitern, wenn man erkennt, dass sie sich wirtschaftlich nicht mehr lohnen. Den Profi vom Amateur trennt IMHO, dass er erkennt, wann ein Projekt einzustellen ist und dies auch tut. Demzufolge kannst Du keine gescheiterten Projekte wiedererwecken. Du kannst höchstens das know-how der Projektleiche ausschlachten oder ein neues Projekt daraus definieren.
-
Ich bin noch relativ neu im Geschäft (ein wenig mehr als 4 Monate) und darf trotzdem bereits jetzt meinen eigenen Stil komplett durchsetzen. Wir sind eine kleine Firma und ich muss relativ viel alten Code reorganisieren oder sogar neu schreiben, weil dieser nicht wirklich durchdacht ist (Spaghetti-Code, Copy & Paste, ...). Dabei hat in manchen Projekten, welche nun in meiner Zuständigkeit liegen, die Menge an Quellcode um fast 80% abgenommen und meine Vorgesetzten verstehen zum Teil nicht mehr, wie und warum etwas jetzt noch funktionieren kann (die eleganten Lösungen sind nicht immer die einfachsten ;)). Zufrieden sind wir trotzdem alle
MfG
-
/rant/ schrieb:
Dabei hat in manchen Projekten, welche nun in meiner Zuständigkeit liegen, die Menge an Quellcode um fast 80% abgenommen und meine Vorgesetzten verstehen zum Teil nicht mehr, wie und warum etwas jetzt noch funktionieren kann
scheinst ja ein overcoder zu sein, oder deine vorgesetzten sind etwas das sie nicht sein sollten :p
lg lolo
-
Z schrieb:
Projekte scheitern, wenn man erkennt, dass sie sich wirtschaftlich nicht mehr lohnen. Den Profi vom Amateur trennt IMHO, dass er erkennt, wann ein Projekt einzustellen ist und dies auch tut. Demzufolge kannst Du keine gescheiterten Projekte wiedererwecken. Du kannst höchstens das know-how der Projektleiche ausschlachten oder ein neues Projekt daraus definieren.
Eine Leiche ist tot, töter gibt es nicht. Der Gerichtsmediziner will auch nur herausfinden, was zum Tod geführt hat - und er weiss, dass in der Leiche nichts lebendes mehr zu finden ist. Das Ausschlachten einer Projektleiche kann nicht gehen. Denn die Fehler liegen selten in einer handvoll falscher if-Abfragen oder fehlerhafter Zuweisungen. Sondern eher in einem nicht sorgfältig durchdachtem Konzept. Die Wiedererweckung eines gescheiterten Projektes führt in vielen Fällen eben zur kompletten Neuentwicklung. Wie anders will man die falschen Denkansätze vermeiden?
Das waren meine bisherigen Aussagen, dass dies alles auch zum vorgebbaren Programmiertstil gehört. Ob da nun bei einer Detailaufgabe etwas weniger Code oder ein paar Millisekungen herauskitzelbar sind, ist nicht das Thema. Also nochmals JA - ein paar Firmenregeln dürfen sein und sind jederzeit sinnvoll!
Nichts ist schlimmer, als ein Projekt für gescheitert erkären zu müssen oder einem irgendwie hingepfriemelten Projekt mangels Stabilität oder Erweiterbarkeit später dann doch den Tod zu testieren.
