Schreiben Arbeitgeber Stile und bestimmte Machweisen vor ?

[branleb]

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

[noob_lolo]

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

[Baba Yaga]

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.

[muemmel]

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

[Gast]

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

[berniebutt]

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.

[volkard]

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.

[abc.w]

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...

[berniebutt]

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!

[volkard]

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.

[berniebutt]

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

[5cript]

1. Seit wann gibt es ein Beruf und Ausbildungsforum
2. Sehr interessant, so hatte ich mir das irgwo auch gedacht.
Viel interessantes zu lesen.

[Gast]

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.

[*rant*]

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

[noob_lolo]

/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

[berniebutt]

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.

[noob_lolo]

berniebutt schrieb:

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 es in der Leiche nichts lebendes mehr zu finden ist.

ach die organe von toten sind durchaus begehrtes gut, kommt natürlich auch immer ein bischen darauf an wielang der patient schon tot ist;)

berniebutt schrieb:

Die Wiedererweckung eines gescheiterten Projektes führt in vielen Fällen eben zur kompletten Neuentwicklung. Wie anders will man die falschen Denkansätze vermeiden?

meißt reicht doch ein umschreiben, da muß man doch nicht das ganze ding in die tonne kloppen, außer die substanz ist so schlecht das man da nichts mehr machen kann, solche fälle solls ja auch geben...

berniebutt schrieb:

Das war meine Aussage, dass dies alles zum vorgebbaren Programmiertstil gehört.

was du meinst ist eher die aufgabe eines software architekt und hat mit Programmiertstil wenig zu tun oder

lg lolo

[*rant*]

noob_lolo schrieb:

/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

Nun, es sind halt Vorgesetzte, welche keine Zeit mehr dafür haben, jede Woche stundenlang im Quellcode diverser Projekte herumzukriechen und diesen zu refaktorisieren. Stattdessen widmen sie sich anderen Aufgaben (Pflegen von Kundenkontakten, Planung, Geschäftsleitung, etc.) und geben mir dafür die notwendige Zeit und Freiheit

MfG

[5cript]

berniebutt schrieb:

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.

(Vorweg: ich sage nicht, dass da jemals tot was war oder dass dort was falsch gemacht wurde !)
-> Ich sag nur Windows. Das baut doch schon von Anfang an wie Lego aufeinander auf. Hier und da wird ein blaues Steinchen durch ein Gelbes ersetzt, aber 90 % von Windows 7 sind Vista, von Vista sind wiederum 80 % XP usw.
--> Bei Vista wars dann auch zu sehen: Anforderungen um 100 % gewachsen ( ).

[berniebutt]

noob_lolo schrieb:

berniebutt schrieb:

Das war meine Aussage, dass dies alles zum vorgebbaren Programmiertstil gehört.

was du meinst ist eher die aufgabe eines software architekt und hat mit Programmiertstil wenig zu tun oder lg lolo

Der Begriff Architekt ist anders belegt. Ich würde ihn nie auf Software-Projekte übertragen. Bleiben wir aber bei diesem Begriff aus dem Hausbau. Wenn die Konstruktion eines Gebäudes nicht stimmt, ist das fertige Haus nicht oder nur eingeschränkt nutzbar. Die Analogie zu Software-Projekten ist durchaus ähnlich. Entwurf und Programmierstil gehen da leicht ineinander über. Egal, ob ein Software-Projekt im eigenen Haus verwendet, verkauft, oder im Kundenauftrag erstellt werden soll, es geht immer um dasselbe. Die Entwicklung muss wirtschaftlich, stabil, und auf längere Zeit mit geringem Aufwand wartbar sein. Jeder vernünftige Firmenchef darf und muss da Vorgaben machen dürfen, wenn er morgen nicht selbst vom Fenster weg sein möchte.