Berufserfahrung Programmierer

[Gwaihir]

Eine Frage an die, die beruflich programmieren: Wie ist es so?

Ich bin eigentlich immer Systemadministrator gewesen, auch während meines Informatikstudiums, aber ich überlege, ob ich mich auf eine Stelle bewerben soll, die einen C++ Programmierer sucht. Ich habe meine Diplomarbeit in C++ programmiert, habe aber sonst nie in dieser Sprache groß etwas geschrieben. Aber generell kann ich gut programmieren, nicht sehr gut, aber gut. Ich habe Spaß am programmieren, ich mache es die letzten Jahre nur zu selten. Wie ist es beruflich? Was macht man da den ganzen Tag? Stumpfsinniges programmieren? Oder ist es lockerer als ich denke? Wer macht denn sowas beruflich und kann mir etwas von seinen Erfahrungen berichten? Sollte ich von Systemadministration auf Programmieren wechseln? Ich denke mal, da würde ich sicher wesentlich besser verdienen, oder?

Danke für Antworten!

[Shink]

Eine Frage an die, die beruflich programmieren: Wie ist es so?
Ganz OK wenn mans mag.:freak:

Aber generell kann ich gut programmieren, nicht sehr gut, aber gut. Ich habe Spaß am programmieren, ich mache es die letzten Jahre nur zu selten.
Das klingt schon einmal nicht so schlecht; Spaß daran und ein gewisses Grundtalent ist schonmal sehr wichtig.


Wie ist es beruflich? Was macht man da den ganzen Tag? Stumpfsinniges programmieren? Oder ist es lockerer als ich denke?
Das kommt ganz darauf an wo du arbeitest.
"stumpfsinniges Programmieren" - wie soll ich mir das vorstellen?

Programmieren ist ja eigentlich eine angenehme Tätigkeit bei der man mehr oder weniger mit sich selbst und diversen Geistern aus der Vergangenheit beschäftigt ist.:freak:
Je nach Arbeitsplatz gibt es dann halt mehr oder weniger - besser gesagt extrem viel oder gar kein - Projektmanagement, Zeitmanagement, Umgang mit Kunden, ins Ausland Verreisen, an Hardware rumbasteln, an Fahrzeugen herumbasteln:freak:, in riesige Dokumentationen einlesen, sich in Arbeitsprozessen einer x-beliebigen Branche zurechtfinden und dort Optimierungspotential erkennen, wissenschaftliche Problemfindung, Kurse besuchen, Kurse leiten, Mitarbeiter einarbeiten, Kreativität, Design, dämliche Probleme einer bestehenden Software zu umschiffen probieren (z.B. Browser:rolleyes:), heiße Luft verkaufen, dich mit dämlichen Kunden herumärgern (naja, das kannst du glaub ich bereits) und vieles, vieles mehr. Genannt hab ich jetzt Dinge mit denen ich bisher zu tun hatte. Auch wenn ich inzwischen nur mehr zu ~20% der Zeit Programmiere bin ich noch Programmierer.

Ebenfalls je nach Arbeitsplatz gibt es dann z.B. unglaublich viel (80 Stunden pro Woche) oder kaum Arbeit. Manchmal kann man von zu Hause aus arbeiten, manchmal nicht. Mancherorts gibt es Sachen wie Bereitschaft - oder auch nicht.

Sollte ich von Systemadministration auf Programmieren wechseln? Ich denke mal, da würde ich sicher wesentlich besser verdienen, oder?
Ich denke du solltest wechseln - wenn du es tust um deinen Horizont zu erweitern, weil du es gern tust, weil du die Gelegenheit dazu hast oder weil du es kannst.
Reich wirst du damit ziemlich sicher nicht.
Ich kenne Firmen die zahlen Systemadministratoren und Programmierern gleich viel. Ohne Zweifel gibt es auch welche die das nicht machen - zu den Top-Verdienern gehört man aber nicht als Programmierer, außer man findet eine rentable Nische, ist unersetzbar, findet die geniale Geschäftsidee und setzt die gleich um o.ä. Das ist heute aber alles nicht mehr so leicht wie früher; ich würde mal sagen die fetten Jahre sind vorbei. Wer viel verdienen will muss auch viel arbeiten.
Mehr Gehalt gibt es wenn du dich in Richtung mehr Verantwortung (Management) vorarbeitest.

[Pinoccio]

Da kann ich - wenn auch nicht aus eigener Erfahrung als Programmierer - nur zustimmen.
Was genau du bei der Stelle machst, weiß hier eh keiner. Bewirb dich doch einfach, dann werden sie dir das schon sagen. :smile:

mfg

[Watson007]

bei meinen Vorstellungsgesprächen konnte ich herausfinden das das Beherrschen der aktuellen Frameworks sehr wichtig ist, als Quereinsteiger ohne aktuelle Kenntnisse wirst du wahrscheinlich nicht genommen, aber versuchen kannst du es natürlich.

Interessantes Beispiel dazu ist z. b. WPF, das schon in einigen Stellenanzeigen vorausgesetzt wird. Nach meinen Erfahrungen und dem einiger Teilnehmer unserer .net-Usergroup ist die Oberflächen-Erstellung mittels WinForms aber immer noch deutlich schneller zu bewerkstelligen.

In der Branche herrscht eine zu starke Fokussierung auf die neuesten Frameworks, eine neue Technik ist nicht zwangsläufig besser als eine ältere...

Ich hatte einmal nach einer Bewerbung einen anonymen Telefonanruf, keine Nachricht auf dem AB aber über das Handy konnte ich die Nummer sehen. Als ich dann dort angerufen hatte sollte ich mal die neuesten c#-Features aufzählen... danach hatte ich dann eine Absage bekommen ;) Naja wie auch immer, stell dir das nicht zu einfach vor heutzutage.... achso danach hatte ich mich natürlich auf den neuesten Stand gebracht ;)

Andererseits: gerade im Programmierer-Bereich kann man sich privat sehr gut weiterbilden, auch über OpenSource-Projekte. Das finde ich sehr gut, bei einem Ingenieur wird das schwieriger oder sehr theorethisch...ist nur das Problem mit der Anerkennung, erzählen kann man viel.... wiederum andererseits glaube ich nicht das man bei dem Leistungsdruck bis über 60 in der Branche arbeiten können wird.

Ich empfehle die Webcasts vom MSDN-Netzwerk, die eignen sich auch gut für die Weiterbildung und sind kostenlos. Aber nicht alles vorbehaltlos daraus übernehmen, ich habe schon Fehler darin gesehen...

[Monger]

Programmierer ist ja nicht gleich Programmierer. Das ist ein sehr großes und breites Berufsfeld - ganz besonders bei C++.

Dabei gibt es nicht nur große Variationen beim Produkt (Kernel Mode Treiber vs. Frontend für irgendeine Fensteranwendung), sondern auch bei der Rolle (Coder vs Architekt).

Ich z.B. bin offiziell kein Programmierer, sondern Testautomatisierer. Sprich: ich schreibe Skripte, die im Systemtest eingesetzt werden. Da aber das mittlerweile ziemlich komplex geworden ist, und wir mehrere Bereiche bedienen, sind wir dazu übergegangen da unsere eigenen Bibliotheken zu entwickeln. Bereits das Bibliotheks-Design ist schon ein ziemlich anderes Berufsfeld als Skripte zu schreiben. Ersteres erfordert einen sehr langen Atem. Da wird gerne mal stundenlang darüber gestritten wie eine Methodensignatur auszusehen hat. Beim Skript muss man vorallem schnell zu Resultaten kommen.

Jemand der sich um Setup/Deployment kümmert, hat völlig andere Anforderungen, Prozesse und Tools wie einer der z.B. Windows Forms benutzt.

Ich hab mich z.B. mal bei einer Firma beworben gehabt, die sich auf Office Plugins spezialisiert hat. Das ist der pure Wahnsinn, wenn man mal sich hinten diese APIs von den Office Produkten ansieht, und was man da alles reinklatschen kann. Das ist dann keine klassische Anwendungsentwicklung mehr, sondern eher Plugins.

Es kommt halt sehr stark darauf an, wo konkret du hinkommst. Ich bin z.B. über meinen Job ziemlich froh, weil ich viel Freiheiten habe, und auch Sachen ausprobieren kann die sich ein Entwickler bei uns normalerweise nicht leisten kann (neue Tools z.B. evaluieren und dann auch einsetzen). Hab mir schon etliche male überlegt in die "richtige" Entwicklung bei uns zu wechseln, aber da bist du halt nur ein kleiner Programmierer, der sich sklavisch an den Prozess zu halten hat.

[Watson007]

sondern auch bei der Rolle (Coder vs Architekt).

ja das sollte man auch beachten. Wobei wenn es nach den Unternehmen ginge würden sie nur Softwarearchitekten einstellen... aber das können sie sich nicht leisten.

[Shink]

wiederum andererseits glaube ich nicht das man bei dem Leistungsdruck bis über 60 in der Branche arbeiten können wird.
Doch, das geht schon - bei uns arbeiten einige in diesem Alter. Wenn das Unternehmen groß genug ist ist man als alter Hase für Betreuung und Weiterentwicklung von "running systems" oder auch für die Stabilisierung und z.B. Performanceoptimierung von neuen Systemen aufgrund der Erfahrung besser geeignet als ein hochmotivierter Jüngling.

Ach ja: Ich hab bisher noch nirgends gearbeitet wo man einen Coder oder Architekten gesucht hat und das dann auch ernst gemeint hat.:freak:

[RMC]

Doch, das geht schon - bei uns arbeiten einige in diesem Alter. Wenn das Unternehmen groß genug ist ist man als alter Hase für Betreuung und Weiterentwicklung von "running systems" oder auch für die Stabilisierung und z.B. Performanceoptimierung von neuen Systemen aufgrund der Erfahrung besser geeignet als ein hochmotivierter Jüngling.


Bedeutet: Die alten Säcke sind leider die einzigen, die das schlecht dokumentierte Frickelwerk noch halbwegs verstehen können und daher unentbehrlich :D

[Frucht-Tiger]

ja das sollte man auch beachten. Wobei wenn es nach den Unternehmen ginge würden sie nur Softwarearchitekten einstellen... aber das können sie sich nicht leisten.
Kann man so auch nicht 100% verallgemeinern, ich habe auch schon in einem Unternehmen gearbeitet, das diese Rollenbilder nicht anwendet(Stichwort agile Vorgehensmodelle).

Ich finde das die Ganze Sache sowieso noch sehr in Bewegung ist, siehe auch die ganzen Tätigkeiten die Shink aufgezählt hat. Für mich zumindest kann ich kein klares firmenübergreifendes Aufgabenfeld für einen Entwicklers festlegen. Hängt also immer von der konkreten Stelle ab :)

[Watson007]

agile Softwareentwicklung... damit habe ich mich noch gar nicht beschäftigt. Gibt soviel was man als Programmierer lernen muss...

Wie seht Ihr eigentlich den Punkt Dokumentation? Ich habe das immer etwas zwiespältig gesehen, einerseits positiv wenn man viel dokumentiert - klar -, aber andererseits gibt man damit auch ein Stück Abhängigkeit der Firma zu der eigenen Person auf... sprich man wird leichter ersetzbar.

[PatkIllA]

Auch bei gut dokumentierter Software muss man sich einarbeiten.

[Watson007]

Auch bei gut dokumentierter Software muss man sich einarbeiten.

gehört aber zu den Sachen bei denen die aufgewandte Arbeitszeit dafür nicht wirklich firmenintern anerkannt wird.

[PatkIllA]

gehört aber zu den Sachen bei denen die aufgewandte Arbeitszeit dafür nicht wirklich firmenintern anerkannt wird.
Ich hab schon öfters Tage damit verbracht Code zu dokumentieren. Dabei kann man auch gleich mal nicht mehr benutzten Krams rauswerfen.
Vor allem bei der Produktentwicklung geht Qualität ganz deutlich vor Geschwindigkeit.

[Pinoccio]

Bedeutet: Die alten Säcke sind leider die einzigen, die das ihr schlecht dokumentiertes Frickelwerk noch halbwegs verstehen können und daher unentbehrlich :Dfixed. :winkWie seht Ihr eigentlich den Punkt Dokumentation? Ich habe das immer etwas zwiespältig gesehen, einerseits positiv wenn man viel dokumentiert - klar -, aber andererseits gibt man damit auch ein Stück Abhängigkeit der Firma zu der eigenen Person auf... sprich man wird leichter ersetzbar.So gut kann man gar nicht dokumentieren, daß ein Fremder alles sofort weiß.
Und wie abhängig von dir möchtest du denn die Firma haben? So weit, daß du keinen Urlaub mehr machen kannst?^^
[Dokumentation] gehört aber zu den Sachen bei denen die aufgewandte Arbeitszeit dafür nicht wirklich firmenintern anerkannt wird.Aber nur von Nicht-Programmierern.

mfg

[Monger]

Wie seht Ihr eigentlich den Punkt Dokumentation? Ich habe das immer etwas zwiespältig gesehen, einerseits positiv wenn man viel dokumentiert - klar -,

Wirklich guter Code ist selbstdokumentierend. Wie gesagt: hab da durchs Bibliotheksdesign ohnehin eine andere Perspektive drauf. Lieber Codequalität verbessern, und stattdessen sich zusätzliche Dokumentation sparen.


aber andererseits gibt man damit auch ein Stück Abhängigkeit der Firma zu der eigenen Person auf... sprich man wird leichter ersetzbar.
Meiner Meinung nach ist bei Software ohnehin nicht so wichtig, was aktuell geschrieben wurde. Wichtig ist, dass man auf Änderungswünsche (Bugs, Kundenanfragen etc.) möglichst flexibel reagieren kann, und mit geringem Aufwand schnell Patches und Nachfolgeprodukte hinterher schieben kann.

Was man dazu braucht, kann man nicht dokumentieren, nämlich Kreativität und Erfahrung. Das steckt nur in den Köpfen der Entwickler.

[PatkIllA]

Wirklich guter Code ist selbstdokumentierend. Wie gesagt: hab da durchs Bibliotheksdesign ohnehin eine andere Perspektive drauf. Lieber Codequalität verbessern, und stattdessen sich zusätzliche Dokumentation sparen.Bei einer Bibliothek hat man doch in der Regel nur die Schnittstellen nach außen und die müssen auch dokumentiert sein.

[RMC]

Wichtig ist, dass man auf Änderungswünsche (Bugs, Kundenanfragen etc.) möglichst flexibel reagieren kann, und mit geringem Aufwand schnell Patches und Nachfolgeprodukte hinterher schieben kann.

Absolut. Aus der Sicht von Programmierern vollkommen nachvollziehbar und wichtig. Dazu gehören eben Flexibilität, Wartbarkeit, aber auch zum Teil Dokumentation.

Das schwierige ist halt nur, wie Pinoccio angedeutet hat, jenen Leuten das klar zu machen, die davon keine Ahnung haben, aber blöderweise eine Ebene höher sitzen und dann auch die Mittel zur Verfügung stellen - und die müssen es dann auch noch den Kunden klarmachen und da hört sich dann der Spaß sowieso auf ;)

Ich bin jemand, der auf Wartbarkeit und Erweiterbarkeit bei der Entwicklung viel Wert legt. Kostet halt dementsprechend auch an Aufwand. Meistens trifft man da dann leider auf taube Ohren.

[Frucht-Tiger]

Bei der Doku favorisiere ich aus der Entwicklersicht ein paar Diagramme zur Architektur/Datenmodell und ansonsten Kommentare + Unittests die das Verahlten des Codes definieren. Von diesen Doku-Monstern die sowieso nie aktuell sind und eigentlich keiner jemals liest halte ich nichts.

[Monger]

Bei einer Bibliothek hat man doch in der Regel nur die Schnittstellen nach außen und die müssen auch dokumentiert sein.
Wer liest schon Dokumentation? ;)

Da unsere Bibliothek nur abteilungsintern genutzt wird, kriegen wir sehr unmittelbare Rückmeldung darüber wie die Skripteschreiber damit umgehen können, und wie schnell sie vorwärts kommen. Da wird auch schnell deutlich: wenn überhaupt, wird allenfalls die Intellisense gelesen.
Und es ist wirklich erstaunlich, wie sehr man das Programmieren beschleunigen kann, wenn man nur die Parameterreihenfolge umordnet, oder hier und da an den Namen schleift. Der Client Code sieht dann auch sofort um einiges sauberer aus, wenn auch die Bibliothek ein klar strukturiertes Interface hat.

Bei einer Bibliothek ist halt die API alles, und der Inhalt zweitrangig. Das ist etwas was sich Anwendungsentwickler nur schwer vorstellen können.

[PatkIllA]

Die Methodenkommentare sind doch schon die wesentliche Dokumentation.

[Monger]

Die Methodenkommentare sind doch schon die wesentliche Dokumentation.
Die machen wir natürlich, aber darüber hinaus nicht viel. Da kenne ich durchaus andere Software, wo alleine die "Liesmich.txt" mehr als 50 Seiten fasst.

[Coda]

Solang das ganze nicht formal ist, halte ich das auch durchaus für eine gute Idee. Den groben Überblick bekommt man aus der Methoden-Dokumentation nicht.

[PatkIllA]

Dann halt noch ein paar Beispiele dazupacken ;)

[Shink]

Bedeutet: Die alten Säcke sind leider die einzigen, die das schlecht dokumentierte Frickelwerk noch halbwegs verstehen können und daher unentbehrlich :D
Naja, nicht nur. Alte Haudegen sind für Aufgaben wie Leistungsoptimierung bei Datenbankabfragen, Suchen von Bugs in riesigen Codehalden o.ä. meistens tatsächlich effizienter.

andererseits gibt man damit auch ein Stück Abhängigkeit der Firma zu der eigenen Person auf... sprich man wird leichter ersetzbar.
Man sollte - im Gegensatz zu dem was man vor ein paar Jahrzehnten noch gepredigt hat - unbedingt darauf achten ersetzbar zu sein. Erstens kann man sich nur so mit gutem Gewissen neuen Aufgaben zuwenden ohne immer mit altem Kram belastet zu werden und zweitens... solls auch mal vorkommen dass man selbst vergisst wie der Müll funktioniert.:freak:

Von ausschweifender Dokumentation halt ich allerdings nicht.

Bei einer Bibliothek hat man doch in der Regel nur die Schnittstellen nach außen und die müssen auch dokumentiert sein.
Tja, der Meinung sind sehr viele. Oft steht dann in Prosa das was die Methode mal gemacht hat als sie geschrieben wurde oder ein Text der schwieriger zu lesen ist als der Code selbst.
Wenn dann ist das nur unter Einhaltung von Standards sinnvoll. So ein Standard wäre z.B. "wir dokumentieren gar nichts", "für jede Interfacemethode gibt es mindestens einen Unit- und einen Integrationstest" oder "für jede Interfacemethode gibt es ein Dokument mit Sequenzdiagramm".
Dann ist natürlich auch wichtig dass man die Dokumentation aktualisiert bevor man eine Codeänderung eincheckt.

Die Methodenkommentaresignaturen sind doch schon die wesentliche Dokumentation.
fixed

[Ectoplasma]

1. Wie ist es beruflich?
2. Was macht man da den ganzen Tag?
3. Stumpfsinniges programmieren?
4. Oder ist es lockerer als ich denke?
5. Ich denke mal, da würde ich sicher wesentlich besser verdienen, oder?


1. Aktuell bin ich Berater im Java/JEE Umfeld. Das heißt ich entwickle Java/JEE Anwendungen vor Ort beim Kunden. Ich habe aber auch Jahre lang C++ GUI-Anwendungen entwickelt und mache das heute noch im privaten Rahmen. Der Job ist insgesamt sehr abwechslungsreich. Von total entspannt bis sehr arbeitsintensiv. Die Menschen die in diesem Bereich arbeiten, sind in der Regel sehr angenehme Zeitgenossen, was sich aufs Arbeitsklima positiv auswirkt.

2. Die meiste Zeit schreibe ich Code. Ich bezeichne das aber nicht als stumpfes programmieren. Man muss immer über den Tellerrand hinaus schauen können. Wiederverwendbarkeit und Wartbarkeit von Software sind für mich keine holen Phrasen. Mit ein bisschen Anspruch an sich selber, macht die Arbeit viel mehr Spaß. Des Weiteren erstelle ich Konzepte und schreibe Angebote für den Kunden.

3. Nein, siehe 2.

4. Bleibt die Frage was du genau meinst. Die Arbeit an sich ist locker bis stressig (aber immer noch im positiven Sinne). Das Umfeld, also die Menschen mit denen du es zu tun hast, sind es meist auch. Ausnahmen bestätigen hier die Regel.

5. Kommt darauf an, was du jetzt verdienst. Der Durchschnittslohn einen Beraters im JEE Umfeld beträgt so um 50K im Jahr. Nach oben kann es bis 70K gehen. Das Gehalt für einen C++ Entwickler liegt im Durchschnitt vielleicht bei 40 bis 45K. Aber das können dir andere evtl. besser sagen.

[RMC]

Erstens kann man sich nur so mit gutem Gewissen neuen Aufgaben zuwenden ohne immer mit altem Kram belastet zu werden und zweitens... solls auch mal vorkommen dass man selbst vergisst wie der Müll funktioniert.:freak:

Wenn man das einmal durchgemacht hat lernt man zwangsweise dazu ;) Kleine Anekdote: Wir hatten mal einen Mathematiker bei uns, der die Physik programmierte. Auf dem Gebiet war er super, leider hatte er überhaupt kein Verständnis von Softwareentwicklung. So sah auch sein Code aus :D Das ging so weit, dass er nach 2 Jahren nicht mehr wusste was sein eigener Code macht und konnte ihn nichtmal mehr gscheit debuggen, geschweige denn, dass jemand von uns von diesen Untiefen Wissen hatte oder dort irgendwas nachvollziehen konnte. Kommentare fehlten sowieso.

Naja, schließlich haben wir dann jemand Neues eingestellt. Der hat am Anfang sehr viel geflucht :D und schließlich blieb kein Stein auf dem anderen, er musste den ganzen Code neu schreiben, was ihm wohl selbst am Liebsten war. Dafür war dieser so sauber, ich hab bis heute keinen besseren Code gesehen.

Also jep, ersetzbar sein ist vielleicht gegen das Ego, aber wichtig fürs Team - und das zählt.

[Gwaihir]

Danke für Euere Antworten! Wenn ich es also mal rein aus gehaltssicht sehe, tut sich eigentlich kaum etwas zwischen Systemadministration und Programmieren. An der Systemadministration mit all seinem Drumrum habe ich ja auch Spaß, weil es eben so abwechslungsreich ist und man auch mal Neuland betreten kann.

Ich frage nur, weil ich seit 3 Jahren auf meinem Einstiegsgehalt sitze und ich wohl die Firma wechseln muss, damit ich das bekomme, was ich normal bekommen müsste. Die Frage wäre dann, ob ich ähnliches wie jetzt mache, aber dann eher in einem Dienstleistungsunternehmen mit Kunden, so dass man noch Beratungsfunktion nach außen hat. Hier drinnen im Werk ist man ja eher Mädchen für alles ;)

[Pinoccio]

Ich frage nur, weil ich seit 3 Jahren auf meinem Einstiegsgehalt sitze und ich wohl die Firma wechseln muss, damit ich das bekomme, was ich normal bekommen müsste.Je nach Firma hilft da auch schon ein Gespräch mit dem Chef/Vorgesetzten/Personalbateilung. 3 Jahre Einstiegsgehalt ist nicht unbedingt fair.
(Zum Vergleich: im Öffentlichen Dienst nach TVÖD gibt es nach 3 Jahren ~15% mehr.)

mfg

[RMC]

Ich frage nur, weil ich seit 3 Jahren auf meinem Einstiegsgehalt sitze

Hast du schon mal wegen eine Gehaltserhöhung gefragt? Eine Erhöhung nach 3 Jahren ist normalerweise üblich.

[Binary Outlaw]

Wie seht Ihr eigentlich den Punkt Dokumentation?
Natürlich ist eine Dokumentation wichtig.
Stell dir den Fall vor, du verlässt aus irgendwelchen Gründen die Firma und eines deiner Programme ist produktionsrelevant und keiner hat Ahnung wie es funktioniert.

Oder man schreibt Anwendungen die Daten aus Datenbanken beziehen, du bist weg keiner weiß wo die Daten herkommen.

[Matrix316]

Klar ist eine Dokumentation wichtig, aber wichtiger ist: "Das muss bis gestern fertig sein. Besser vorgestern". Da bleibt einfach auch keine Zeit für Dokumentationen. ;)

[Binary Outlaw]

Eine Doku kann man auch im nach hinein schreiben, zwischen den Projekten sollte ja Pause sein. Ansonsten sollte man drauf bestehen. In großen Firmen ist sowas sonst tödlich.

[Shink]

Ansonsten sollte man drauf bestehen. In großen Firmen ist sowas sonst tödlich.
In großen Firmen muss auch nichts gestern fertig sein wenn man erwähnt dass die Qualität darunter leidet.

Wenn die Doku outdaten kann ist es besser man lässt es gleich bleiben oder schwächt die Richtlinien ab.

[Matrix316]

Eine Doku kann man auch im nach hinein schreiben, zwischen den Projekten sollte ja Pause sein. Ansonsten sollte man drauf bestehen. In großen Firmen ist sowas sonst tödlich.
Pausen? Bei uns laufen immer mehrere Projekte gleichzeitig. Aber zugegeben, wir sind auch nur 3 Leute und keine große Firma. :)

[Monger]

Eine Doku kann man auch im nach hinein schreiben, zwischen den Projekten sollte ja Pause sein.
*Lach*
Als ob jemals die eingeplanten Pufferzeiten verfügbar wären! :D

Nein: wenn nicht sofort dokumentiert wird, wird meistens nie dokumentiert. Oder noch schlimmer: es wird Zeug dokumentiert was so zwei Wochen später schon gar nicht mehr stimmt. Und falsche Dokumentation ist sogar noch schlimmer als gar keine Dokumentation.

Deshalb ist es so wichtig, die Dokumentation direkt in den Entwicklungsprozess einzubinden. Das ist allerdings nach wie vor gar nicht so einfach.

[Captian Sheridan]

Ich denke mal, da würde ich sicher wesentlich besser verdienen, oder?

Am besten verdienen die Labertaschen, bzw. ein Haufen Gedöns von sich geben.
Techniker werden leider nicht wertgeschätzt.

Ansonsten ist Gehalt wie immer abhängig von der Firma, Aufgabe, Chef, dem eigenen Verhandlungsgeschick.


Ich bin eigentlich immer Systemadministrator gewesen,

Was genau ? Anwenderbetreuung, Windows oder *nix, Powershell, Perl, Python Kenntnisse ?


auch während meines Informatikstudiums, aber ich überlege, ob ich mich auf eine Stelle bewerben soll, die einen C++ Programmierer sucht. Ich habe meine Diplomarbeit in C++ programmiert, habe aber sonst nie in dieser Sprache groß etwas geschrieben.

Programmieren benötigt wie jede Tätigkeit erfordert viel Übung, sehr viel Übung.

Bei Stellenanzeigen steht normalerweise dabei, welche "Frameworks" wichtig sind für die Position.
Die Sprache selber ist meistens das geringste Problem, die Syntax erlernt man schnell.


Aber generell kann ich gut programmieren, nicht sehr gut, aber gut. Ich habe Spaß am programmieren, ich mache es die letzten Jahre nur zu selten.


Hast du mit anderen Sprachen gearbeitet ?



Wie ist es beruflich? Was macht man da den ganzen Tag? Stumpfsinniges programmieren? Oder ist es lockerer als ich denke? Wer macht denn sowas beruflich und kann mir etwas von seinen Erfahrungen berichten?

Es kommt darauf, Programmieren!=Programmieren, abhängig von der Firma, Abteilung, Aufgaben( zu erstellender Code).

Meine Erfahrung.
C++/C Projekte sind meistens riesige Codehaufen mit uralt Code, die gepflegt werden müssen.
Allein das Theater mit verschiedenen Compilern, Plattformen.

ich mach das sehr ungern, vor allem mit Vim/make arbeiten, da braucht man Unmengen an Erfahrung, sonst verzweifelt man.
(ich kenne ctags & und die ganzen Scripte für Vim, ist für mich trotzdem nicht das gleiche wie mit Visual Studio & Plugins.)

An einer Stelle winzige Änderung gemacht und irgendwo spinnt/knallt was, und dann soll man dahinter kommen was los ist.

Bei neuen C++/C Projekte mit Qt, boost, C# & .Net Coda kann man kreativ sein, herumtüfteln, abhängig von der Deadline.
Meistens endet das so, wie werden wir am schnellsten fertig ?:rolleyes: danke @ Anzugträger.
Da wird Uralt Code recycled e.g Procedural in C# :biggrin:, mit andern "Compilern" wie VB, Delphi Dlls erzeugt und importiert :rolleyes:.

Na ja Hauptsache es funzt.

Zum Thema Doku, das Doku erstellen eigentlich nur Einsteiger, die dann merken, dass für sowas keine Zeit eingeplant ist.
interessiert sonst kein Schwein, wird auch nie gelesen.:mad:

Hmm .. bin ich heute am labern :eek:, wg. der Stellenanzeige, bewirbt dich bei denen, zu deren Leute die schon Kontakte hast.

a) Bewerbung ist effizienter, du weißt wer sie beurteilt, was du schrieben sollst.
b) du kannst abschätzen, wo & mit wem du landest.

[noid]

*Lach*
Als ob jemals die eingeplanten Pufferzeiten verfügbar wären! :D

Nein: wenn nicht sofort dokumentiert wird, wird meistens nie dokumentiert. Oder noch schlimmer: es wird Zeug dokumentiert was so zwei Wochen später schon gar nicht mehr stimmt. Und falsche Dokumentation ist sogar noch schlimmer als gar keine Dokumentation.

Deshalb ist es so wichtig, die Dokumentation direkt in den Entwicklungsprozess einzubinden. Das ist allerdings nach wie vor gar nicht so einfach.

Eben, und weil sich alles schiebt, außer die Deadlines für deine Sachen... am besten gleich so schreibent, dass es auch lesbar ist was der Code macht.

Ich habe 3 Jahre mal gerätselt warum ein Parameter G20PR heisst - in Assembler (weit vor meiner Zeit) war das mal der Globale, 20te, Parameter im Ram - Kommentare? Eher sowas wie x = x + 1; //Increased by 1.

Hallo?

[robobimbo]

ich fand for ein paar tagen in einem ca. 12 jahre alten produktionscode eine kommentarzeile die wie folgt endete:

"Ob dies den Fehler behebt und zuverlässig funktioniert? Wir werden sehen."

Ich weiss nicht mehr was grösser war, der Lachflash oder WTF-Effekt :)

[Gast]

Frage! Weil der Threadstarter ein Informatikstudium erwähnte: Ist Programmierung ansich nicht eher Arbeit für Leute mit Berufsausbildung (FIAE)? Wie würden die Leute hier, die in so einem Umfeld arbeiten, denn so die Verteilung bzgl. der Backgrounds der verschiedenen Programmierer einordnen? Ich habe da irgendwie immer so ein bischen das Vorurteil, dass es den Berufszweig "Softwareentwickler" gar nicht wirklich gibt und jeder als "Programmierer" arbeiten darf, der mal 2 Module im Mathematik-, Physik- oder Ingenieurstudium gehört hat oder es sich halt selber beigebracht hat. Von unseren Informatikkommilitonen an der Uni höre ich nämlich häufig, dass sie alles Mögliche machen, aber kaum bis gar nicht konkret programmieren.

[Shink]

Ist Programmierung ansich nicht eher Arbeit für Leute mit Berufsausbildung (FIAE)? Wie würden die Leute hier, die in so einem Umfeld arbeiten, denn so die Verteilung bzgl. der Backgrounds der verschiedenen Programmierer einordnen?
Ungefähr 50% der Programmierer hier haben einen Informatikabschluss an Uni oder FH. Bei den Neuankömmlingen ist der Anteil gefühlt sogar noch höher.

Von unseren Informatikkommilitonen an der Uni höre ich nämlich häufig, dass sie alles Mögliche machen, aber kaum bis gar nicht konkret programmieren.
Naja, das macht wohl jeder irgendwann (wenn er das will).

[Pinoccio]

Ungefähr 50% der Programmierer hier haben einen Informatikabschluss an Uni oder FH. Bei den Neuankömmlingen ist der Anteil gefühlt sogar noch höher.Das hat möglicherweise etwas damit zu tun, daß Programmieren heute bei den anderen Naturwissenschaften bzw. Mathe nicht mehr so stark wie früher auf dem Stundenplan vertreten ist.
Ich hätte es jedenfalls nicht gelernt im Studium. Und zahlreiche andere haben es auch nicht ... :-(

mfg

[pest]

aber nen Einführungskurs hattest du oder?

ich hatte im 1. Semester 2 VL Programmieren und im 8. Objektorientierte Konzepte,
allerdings konnten die meisten auch im 8. kein bisschen imperativ programmieren.

[Monger]

Frage! Weil der Threadstarter ein Informatikstudium erwähnte: Ist Programmierung ansich nicht eher Arbeit für Leute mit Berufsausbildung (FIAE)?

Wie gesagt: Programmierer ist nicht Programmierer. Wenn du nur "Coder" bist, bist du formell gesehen nicht mehr als ne Tippse: dein Chef sagt dir was du schreiben sollst, und du tippst es herunter.

Das ist auch bei uns hier bunt gemischt: die wenigsten hier sind studierte Informatiker. Wir haben diverse Elektrotechniker und Maschinenbauer, die eher am Rande programmieren gelernt haben. Wir haben auch etliche aus der Berufsschule oder Lehre hier.

Einen studierten Softwarearchitekten kenne ich überhaupt nicht. Ich bin ja selbst auch nicht von der Uni, sondern "nur" von der Berufsakademie. Zumindest ich hab also nicht den Eindruck, dass der Markt von Akademikern überschwemmt ist. Im Gegenteil: ich würde mir da öfters etwas mehr akademischen Anspruch hier wünschen.

[Pinoccio]

aber nen Einführungskurs hattest du oder?Ja, einen einsemstrigen JAVA-Kurs mit 2 SWS. Habe den Prof. aber gleich davon überzeugt, daß ich mir das nicht antun muß - die Hälfte der Kursteilnehmer hatte noch nie einen Computer gesehen mehr gemacht als Word und Minesweeper.
In der Numerikvorlesung sollten zahlreiche Hausaufgaben auch mit dem Computer gelöst werden, aber wirklich programmieren war nicht notwendig. Tja, und das war es. (Wobei man noch 16 SWS freies Studium vollmachen muss, da kann man dann ja Info nehmen ...)

mfg

[RMC]

Wie gesagt: Programmierer ist nicht Programmierer. Wenn du nur "Coder" bist, bist du formell gesehen nicht mehr als ne Tippse: dein Chef sagt dir was du schreiben sollst, und du tippst es herunter.

Sowas gibts doch heute gar nicht mehr wirklich, dass man einfach sprichwörtlich was vorgelegt bekommt und das runtertippen muss was sich ein anderer überlegt hat. Auch die Firmen erwarten sich mehr von solchen Leuten.

Von der Analyse über das Konzept, Design, Implementierung und Test machen "Programmierer" heute eh alles eigenständig, daher ist die Bezeichnung "Softwareentwickler" schon tragender.

Für Tippsen hat doch heut imho noch kaum jemand Verwendung.

[pest]

In der Numerikvorlesung sollten zahlreiche Hausaufgaben auch mit dem Computer gelöst werden, aber wirklich programmieren war nicht notwendig.


Bei uns sollten wir in Numerik von Gauss,LR,QR,DGL und div. Iterationsverfahren zum Lösen von LGS programmieren.
Allerdings haben gefühlte 90% des Kurses die Belege mit Copy&Paste bestanden...dem Prof. wars egal :( - nützt ja dann am Ende doch nix

Allerdings muss ich zugeben dass ich genau das Selbe in PDGL und Matlab gemacht habe ... Matlab stinkt :freak:

[PatkIllA]

Bei uns konnte man sich auch praktisch ohne Programmieren durchs Studium wurschteln und selbst wenn man das mitnimmt, was man machen sollte hat bestenfalls ein paar Basics. Praktisch einsetzbar ist man dann noch nicht.

[robobimbo]

Ich glaub das geht so bei ziemlich jeden Studium, auch durch unseren Studiengang sind genug erfolgreich durchgekommen, ohne jetzt wirklich einen Plan von den ganzen Fächern zu haben die mit Softwareentwicklung zu tun hatten. (angefangen von einfachen C, C unter Linux (pipes, ipc), Java, Verteilte Systeme (RMI, EJB, .NET Remoting), Embedded Systems mit einfachen Microcontrollern)

Liegt halt sehr stark an der Person selbst wie ernst, bzw. wie interessiert sie an der Sache ist.

Geht halt mittlerweile soweit, dass es hier Firmen gibt die keine Vorstellungsgespräche mehr macht, sondern man wird 2 Tage "eingestellt" soll selbstständig ein kleines, einfaches Projekt umsezten und dass wird dann bewertet. O-Ton des Chefs: "Beim Vorstellungsgespräch wird die das blaue vom Himmerl erzählt, die Unterlagen sind perfekt, aber können tun sie nix."

[Shink]

Geht halt mittlerweile soweit, dass es hier Firmen gibt die keine Vorstellungsgespräche mehr macht, sondern man wird 2 Tage "eingestellt" soll selbstständig ein kleines, einfaches Projekt umsezten und dass wird dann bewertet. O-Ton des Chefs: "Beim Vorstellungsgespräch wird die das blaue vom Himmerl erzählt, die Unterlagen sind perfekt, aber können tun sie nix."
Bei uns gibt es einen ziemlich lustigen "Talenttest" den jeder (egal als was er anfangen will) machen muss. Da muss man auf dem Blatt Pseudocode ausführen etc.:freak:

[Monger]

Sowas gibts doch heute gar nicht mehr wirklich, dass man einfach sprichwörtlich was vorgelegt bekommt und das runtertippen muss was sich ein anderer überlegt hat.
Also, die meisten unserer Entwickler sind in erster Linie damit beschäftigt, irgendwelche Tickets abzuarbeiten.

Das geht meiner Meinung nach auch nicht anders, sobald die Projekte mal etwas größer werden. Die Architektur teamübergreifend zu organisieren, ist ein Full-Time Job. Da muss jeder Entwickler relativ präzise Vorgaben bekommen, wie genau die Schnittstellen auszusehen haben. Die Implementierung ist natürlich jedem selbst überlassen, aber die ist nunmal mehr Fleißarbeit als kreative Arbeit.

Wie schon gesagt: ich bin froh, dass ich da an einer Stelle bin wo ich mein eigenes Ding durchziehen kann. Das kann ein normaler Entwickler, der mitten in der Projektphase sitzt eben nicht mehr. Wirklich planen und entwerfen geht nur zu Anfang, alles danach ist Frickelei.

[PatkIllA]

Wirklich planen und entwerfen geht nur zu Anfang, alles danach ist Frickelei.Die einen meist noch vor dem ersten Changerequest wieder einholt.
Wir haben bei den Produkten ganz klar die Vorgabe nichts zu hacken.

[Monger]

Die einen meist noch vor dem ersten Changerequest wieder einholt.
Wir haben bei den Produkten ganz klar die Vorgabe nichts zu hacken.
Dann vermute ich mal, dass du in einer dieser reinrassigen Softwareschmieden arbeitest, sowas wie z.B. SAP oder Microsoft etc.
Die achten naturgemäß sehr stark darauf, dass sie ihre Entwicklungsprozesse im Griff haben. Die leisten sich dann auch gerne diesen "Luxus", lieber etwas mehr Entwicklungszeit zu investieren, und dafür dann hohe Qualität zu bringen.

Das ist aber eher die Ausnahme: jede größere Bäckerei, Bank oder Apotheke haben ihre eigene IT Abteilung, die mehr oder minder aufwändige Softwareprodukte hauptsächlich für den eigenen Bedarf entwickelt. Da ist dann Qualität auch nicht so wichtig, sondern dass es irgendwas tut. Das ist vorallem im Industriebedarf (Maschinenbau etc.) noch umso schlimmer. Was da an Software als Industriestandard gilt, ist schon schmerzhaft.

[RMC]

Das geht meiner Meinung nach auch nicht anders, sobald die Projekte mal etwas größer werden. Die Architektur teamübergreifend zu organisieren, ist ein Full-Time Job. Da muss jeder Entwickler relativ präzise Vorgaben bekommen, wie genau die Schnittstellen auszusehen haben. Die Implementierung ist natürlich jedem selbst überlassen, aber die ist nunmal mehr Fleißarbeit als kreative Arbeit.

Ja klar wirds Vorgaben geben an die man sich halten muss in Koordination mit anderen Teams, eine generelle Architektur usw. Aber keiner wird zu dir hinkommen und dir genau sagen oder auf Papier vorlegen, wie Architektur, Konzept und Design deines eigenen Abschnitts auszusehen haben und wie du es implementieren sollst.

Da ist jeder, auch in größeren Teams, für seinen Teil verantwortlich und kann dort "sein eigenes Ding durchziehen" wie du das nennst. So hab halt ich die Erfahrung gemacht.

Deswegen gibts imho auch keine "Programmierer" mehr, die einfach nur das tippen was man ihnen sagt. Dieses "Berufsbild" (sollte es das irgendwann gegeben haben) stirbt aus. Es wird eine Menge mehr verlangt.

[PatkIllA]

Mit insgesamt knapp 100 Mitarbeitern wohl er Mittelstand und davon baut der größere Teil auch eher Kundenspezifische Lösungen, wo man dann auch froh ist, wenn es funktioniert.
Dafür sind dann bei Updates in der Softwareumgebung auch meist monatelange Upgradeprojekte fällig.
Der andere Teil in dem ich arbeite ist Produktentwicklung und Frickelei rächt sich da spätestens bei der nächsten Weiterentwicklung. Das merken wir grade beim neuen Majorupdate, welche Teile da ordentlich entwickelt wurden und welche so gehackt sind, dass Anpassungen unmöglich sind.

[Shink]

Da ist jeder, auch in größeren Teams, für seinen Teil verantwortlich und kann dort "sein eigenes Ding durchziehen" wie du das nennst. So hab halt ich die Erfahrung gemacht.
Das ist natürlich schlecht aber ja, so ist eigentlich der "natürliche Lauf der Dinge".
Besser ist es wenn der Stil (und damit auch die verwendete Architektur im Kleinen wie im Großen) einheitlich ist. Das erhält man nicht gratis aber dafür gibt es pair programming (machen zugegebenermaßen nichtmal wir), Tool-unterstützte Code-Reviews und Auswertungstools wie Sonar. (Das setzen wir sehr wohl ein.)

[RMC]

Das ist natürlich schlecht aber ja, so ist eigentlich der "natürliche Lauf der Dinge".
Besser ist es wenn der Stil (und damit auch die verwendete Architektur im Kleinen wie im Großen) einheitlich ist. Das erhält man nicht gratis aber dafür gibt es pair programming (machen zugegebenermaßen nichtmal wir), Tool-unterstützte Code-Reviews und Auswertungstools wie Sonar. (Das setzen wir sehr wohl ein.)

Was ich im Detail meinte ist, dass es (wie ich es kenne) einzelne Entwickler oder Teams gibt, die sich um Teilbereiche der Software kümmern (zB GUI, Netzwerk, Server/Client Kommunikation, Ablauflogik, einzelne Anwendungsbereiche etc.). Wie das dort ausschaut, überlässt man den Leuten großteils selbst. Das sind fähige Entwickler, die können sich einbringen und ihren Job machen.

Allgemeine Codingguidelines und Architekturrichtlinien sind bekannt. Rück- und Absprache mit anderen Teams und der Leitung gehört natürlich zum Arbeitsprozess. Tools und Methoden zur Qualitätskontrolle, no problem - solange es nicht Überhand nimmt und die Prozesse lähmt.

Deswegen ist das nicht gleich schlecht. Wenn man einige Leute extra dafür abstempelt, die alles für ihr "Team" von A-Z durchplanen und ausgebildete Softwareentwickler bevormunden müssen indem sie alles für sie vorkauen bis sie nur mehr zu Fließbandarbeitern ohne Hirn degradiert sind, halte ich das auch nicht für das Maß der Dinge.

[RattuS]

Wer glaubt denn ernsthaft, dass ein "Programmierer" den ganzen Tag nur am Rechner sitzt und Code tippt? Solch einen Beruf gibt es im IT-Bereich nicht, es hat einen Grund, warum diese Spezialisierung der Informatik Anwendungsentwicklung heißt. Kein Unternehmen würde sich lange halten können, wenn es Mitarbeiter einstellt, denen vorgekaut werden muss, welche Algorithmen sie zur Realisierung eines Projektes entwickeln müssen. Der Anwendungsentwickler muss ein Projekt komplett selbstständig lösen können. Tatsächlich werden die Aufgabengebiete selbstverständlich im Team entsprechend der Qualifikationen zugeteilt.

Bezüglich der studierten (Uni/FH) Informatiker kann ich nur eines sagen: Ich kenne bisher noch nicht sehr viele von ihnen, aber die, die ich kenne, haben den Kollegen aus der FI:AE nicht sehr viel mehr praktisches Wissen voraus. In der IT zahlt sich nunmal Erfahrung aus.

[Gast]

Das ist durchaus mal versucht worden. Schon mal was von den indischen Codefabriken gehört? Kurzfassung: Irgendwelche Designer haben die Software von A-Z durchgesigned und die Diagramme wurden den Mitarbeiter im Fließbandverfahren vorgelegt, die im Schnellverfahren abzutippen waren unter menchenverachtenden Bedingungen.
Der Schuss ging oft nach hinten los..

Zur FI:AE Geschichte. Das ist ausbildungsbedingt was völlig anderes. Ich war mit nem Kommilitonen im Praxissemester in einem Unternehmen, dass vor allem im Java EE Umfeld tätig war.
In unserem Büro lag von irgendnem Auszubildenen FI:AE der Berufsschulordner rum. Da haben wir mal spaßeshalber reingeschaut und das war ja so was billig, was da in den Klausuren drankam, dass wir uns erstmal einen abgelacht haben.

[RattuS]

[...] von irgendnem Auszubildenen FI:AE der Berufsschulordner rum. Da haben wir mal spaßeshalber reingeschaut und das war ja so was billig, was da in den Klausuren drankam, dass wir uns erstmal einen abgelacht haben.
Das ist so auch gedacht. In der Berufsschule haben Fachinformatiker und Systemelektroniker, egal welcher Fachrichtung, den selben Unterricht. Den überwiegenden Teil der Ausbildung verbringt man aber im Betrieb und genau dort lernt man im Normalfall auch das, was man später als Grundlage braucht. Im IT-Wesen geht nichts über Selbstschulung. ;)

[medi]

Bezüglich der studierten (Uni/FH) Informatiker kann ich nur eines sagen: Ich kenne bisher noch nicht sehr viele von ihnen, aber die, die ich kenne, haben den Kollegen aus der FI:AE nicht sehr viel mehr praktisches Wissen voraus. In der IT zahlt sich nunmal Erfahrung aus.

KA was an der FH abgeht aber an der Uni lernst du kein programmieren. Sowas kannst du dir in der Freizeit beibringen ... deswegen hat der Uni-Informatiker auch in der heutigen Zeit dank der umfangreichen vorhandenen Bibliotheken auch kaum Vorsprung an Wissen was das reine Programmieren angeht. Wer programmiert denn heute noch im Allgemeinen nen Such- oder Sortieralgorithmus was man an der Uni noch lernt? Gibts doch alle schon fix und fertig als Methoden.
Als Uniabsolvent könntest du Vorteile haben wenns um Laufzeitkritische Programme geht oder wenns darum geht etwas komplett neuartiges zu "erfinden" wo Konzepte erdacht werden müssen, Erfindungsgeist zählt und methodisches Vorgehen gefragt ist aber doch nicht wenns um die Standardprogrammierung geht.
Uni-Absolventen werden wohl auch in die mittlere Führungsebene gehen wo es darum geht Konzepte zu entwerfen. Fürs reine Anwendungen entwickeln und Support geben sind die eigentlich zu schade.

[Schnaxel F.]

Was lernt man denn da die ganze Zeit? Ein obszönes Gehalt aushandeln?

[PatkIllA]

Wo kriegt man denn ein obszönes Gehalt?
Außerdem macht es doch auch Spass mit Kollegen über NP-Vollständigkeit zu philosophieren ;)

[RMC]

Der ganze Post ist ja richtig selbstverherrlichend.


Uni-Absolventen werden wohl auch in die mittlere Führungsebene gehen wo es darum geht Konzepte zu entwerfen. Fürs reine Anwendungen entwickeln und Support geben sind die eigentlich zu schade.

Zu schade weil sie es gar nicht können. So kann man es auch betrachten ;D

Um auch nur irgendeine deiner Beispiele umsetzen zu können ist Programmierung essentiell. Du wirst kein gutes Konzept vorlegen können, wenn du nicht die bestehenden in- und auswendig kennst und sie auch längere Zeit entsprechend angewendet hast. Denn nur dadurch lernt man Vor- und Nachteile sowie Einsatzzwecke erst richtig kennen. Und das kann man eben nur in der Praxis so richtig.

Aber gut, wenn man von der Uni kommt muss man das nicht können. Man überspringt es einfach, weil man ja was besseres ist oder? Denn mit der Einstellung "Fürs Programmieren bin ich zu gut" landen diesen tollen Uni-Absolventen alle als untaugliche Heißluftföhns irgendwo und bilden sich ein ihre praxisfernen Konzepte könnten mal eben die Entwicklung revolutionieren. Kenn ich schon. Danke, verzichte.

[DanMan]

Auch Erfahrung ist kein Garant für Qualitätsarbeit, wenn derjenige kein Engagement zur Weiterbildung zeigt. Dann mag er das was er kann vielleicht ganz gut beherrschen, ist aber durch neue Techniken überholt und von gestern. Es heißt nicht umsonst Anwendungsentwicklung.

Beispiel: Wer heute noch größere, neue Webanwendungen rein mit PHP 4 Möglichkeiten schreibt, der hat den Schuss mMn nicht gehört. Was wie gesagt halb so schlimm wäre, wenn derjenige alles dransetzt aufzuholen.

[RMC]

Beispiel: Wer heute noch größere, neue Webanwendungen rein mit PHP 4 Möglichkeiten schreibt, der hat den Schuss mMn nicht gehört. Was wie gesagt halb so schlimm wäre, wenn derjenige alles dransetzt aufzuholen.

Und du bist der Ansicht, dass ein fähiger Webentwickler in der Praxis diesen Umschwung nicht mitbekommt?

[PatkIllA]

Und du bist der Ansicht, dass ein fähiger Webentwickler in der Praxis diesen Umschwung nicht mitbekommt?
Es gibt jede Menge Fälle wo Leute Probleme unbedingt mit den ihnen bekannten Techniken umsetzen wollen oder irre Verrenkungen gemacht werden, statt vielleicht mal nach eleganten Lösungen Ausschau zu halten.

[RMC]

Es gibt jede Menge Fälle wo Leute Probleme unbedingt mit den ihnen bekannten Techniken umsetzen wollen oder irre Verrenkungen gemacht werden, statt vielleicht mal nach eleganten Lösungen Ausschau zu halten.

Natürlich. Darum sprach ich auch von "fähig". Unfähige Leute gibts überall.

Ich halte nur die Einstellung "Programmieren braucht man auf der Uni nicht" während man gleichzeitig Konzepte und Optimierungen für selbgies Anwendungsgebiet vornehmen will nicht nur für überheblich sondern auch für gefährlich.

[PatkIllA]

Habt ihr es echt bei euch, dass Leute ohne Programmiererfahrung gleich Chefsoftwarearchitekten werden?
Wenn man will kann man ja auch an der Uni in genug Kursen und Projekten Programmiererfahrung sammeln. Bei Informatikstudenten ist es aber auch eine Möglichkeit statt üblicher Studentenjobs einen Job in der Praxis aufzunehmen. Das merkt man dann auch nicht nur an den Programmierkenntnissen sondern auch an Organisation.

[Monger]

Im IT-Wesen geht nichts über Selbstschulung. ;)
So denken viele, aber ich halte das für eine fatale Fehleinschätzung. Natürlich: Übung hilft. Man muss eine Sprache flüssig beherrschen, bevor man mit ihr irgendwas anfangen kann. Aber Übung alleine macht noch keinen guten Entwickler.

Jeder Depp kann mit ein bißchen Übung letztendlich programmieren. Mit Trial & Error kann sich jeder - mit genügend Zeit - zu einem funktionieren Stück Code hinhangeln.

Aber zu einer Software gehört ja in Wahrheit weit mehr als nur der Programmcode. Es geht darum, Termine einzuhalten, den Wartungs- und Erweiterungsaufwand gering zu halten, vorausschauend zu planen und richtig zu priorisieren. Das Zeug dann noch runterzuschreiben, ist im Endeffekt Fleißarbeit.
Und da bringt Erfahrung alleine herzlich wenig: ich kenn die Leute die programmieren seit 20 Jahren, und schreiben immer noch fürchterlichen Schrott. Die erkennen gar nicht, was schlecht an ihrem Code ist.

Und um guten von schlechtem Code unterscheiden zu können, braucht man viel theoretischen Hintergrund. Der kommt im Beruf für meinen Geschmack oftmals ein bißchen zu kurz.

Edit: und auch in Informatik finde ich, dass z.B. Projektmanagement regelmäßig zu kurz kommt. Viele Informatiker können für sich alleine am Schreibtisch hervorragend wurschteln, sind aber im Team schlicht unfähig. Und Teammanagement - gerade beim Programmieren - ist kaum durch Praxiserfahrung alleine zu lernen.

[Tiamat]

Also ich studiere an einer FH und da hat programmieren schon ein hohen Stellenwert.
Dabei kommt die indivudelle Leistung eigentlich nur ein den Klausuren oder Prüfungen zum Tragen, Testate und Präsentationen sind meist Teamarbeit.
Im 3. Semester ist Projektmanagement angesagt, allerdings nur von der theoretischen Seite. Richtig angewendet, wird das im 4. wo das Semester aus einem Projekt besteht, wo für nen richtigen Kunden Software entwickelt wird.
Da schlüpft man dann in Rollen wie zum Beispiel Projektleiter, Tester e.t.c und wird dann auch für sein Verhalten darin bewertet. Vorrangig ist allerdings trotzdem die Gruppenleistung.

Praxisbezug ist extrem wichtig.
Aber ohne die theoretischen Aspekte dahinter kommt man auch nicht aus und den Mix find ich an der FH sehr gut.

[DanMan]

Und du bist der Ansicht, dass ein fähiger Webentwickler in der Praxis diesen Umschwung nicht mitbekommt?
Was heißt fähig? Ich will ja niemandem Dummheit unterstellen. Es geht mir mehr um den Willen. Es wird sich auf dem ausgeruht, was man bereits kann, weil es bisher ausgereicht hat. "Wieso? Es läuft doch!", heißt es dann. Wenn der Vorgesetzte/Chef dann Null Ahnung von Programmierung hat, ist für den die Welt in Ordnung. Dass ihn der Murks seiner Angestellten dann Wettbewerbsvorteile kostet, weil z.B. Erweiterungen einen viel größeren Aufwand darstellen, ist ihm gar nicht bewusst.
Ich spreche dabei aus Erfahrung.
Es gibt jede Menge Fälle wo Leute Probleme unbedingt mit den ihnen bekannten Techniken umsetzen wollen oder irre Verrenkungen gemacht werden, statt vielleicht mal nach eleganten Lösungen Ausschau zu halten.
Hab ich auch schon erlebt. Lieber schön Copy'n'Paste vom alten, angestaubten Projekt, als neue, arbeitserleichternde Methodiken zu benutzen. Oft traut man sich nicht oder scheut den einmaligen Aufwand der Umstellung, oder ruht sich auf den planlosen Vorgesetzten aus.

Die Gegenseite sind dann Projektleiter, die in irgendeiner Zeitschrift ein neues Buzzword gelesen haben, und das natürlich direkt irgendwo noch mit reingefrickelt haben wollen...

[RattuS]

...
Du musst meine Aussage unbedingt differenzieren. "Selbstschulung" bedeutet ja nicht, dass man sich durch irgendein notwendiges Thema schnellstmöglich durchfriemelt, sondern das man Zusammenhänge sucht und versteht. Es gibt FI:AE, die im Betrieb Programmierung in einer Hochsprache gelernt haben, aber nicht einmal wissen, was Speicherallokierung bedeutet. Und genau so verhält es sich auch mit den Uni-Absolventen, die zwar wissen, wie ein Konzept für eine Softwarelösung auszusehen hat, aber die erforderlichen Wege und Mittel nicht kennt weil es schlichtweg an der praktischen Anwendung mangelt. Ein guter Mitarbeiter ist der, der sich selbst für beide Seiten interessiert und informiert, denn ohne Theorie keine Praxis, aber ohne Praxis hilft auch keine Theorie.

Übrigens gehöre ich demnächst der scheinbaren Minderheit der FI:AE, die Informatik trotzdem noch studieren, an. Danach werde ich mir sicherlich ein tatsächliches Bild von diesem Zusammenhang machen können. Es bleibt spannend. :)

[Monger]

Ein guter Mitarbeiter ist der, der sich selbst für beide Seiten interessiert und informiert, denn ohne Theorie keine Praxis, aber ohne Praxis hilft auch keine Theorie.

Dem stimme ich einfach mal voll und ganz zu. Genauso sehe ich das auch.

Richtig angewendet, wird das im 4. wo das Semester aus einem Projekt besteht, wo für nen richtigen Kunden Software entwickelt wird.
Da schlüpft man dann in Rollen wie zum Beispiel Projektleiter, Tester e.t.c und wird dann auch für sein Verhalten darin bewertet. Vorrangig ist allerdings trotzdem die Gruppenleistung.

Das hört sich richtig gut an. Bei mir war das alles relativ theoretisch, und das trotz BA. Wir haben zwar verschiedene kleinere Projektarbeiten im Team gemacht, aber mit keiner so realistischen Rollenaufteilung.

[Ectoplasma]

So denken viele, aber ich halte das für eine fatale Fehleinschätzung. Natürlich: Übung hilft.

...



Sehr schwieriges Thema. Ich finde schon, dass Übung hilft. Viel wichtiger sind aber echter Team-Geist und die Fähigkeit, weit über den eigenen Tellerrand schauen zu können. Man sollte selbstkritisch sein und sich auch von anderen gefallen lassen können, wenn etwas nicht so gut umgesetzt wurde. Den Code den man produziert, gehört einem nicht! Daran sollte man sich einmal gewöhnen

Ich habe Informatik an FH studiert und die oben genannten Dinge lernt man dort nicht. Wir hatten auch viel Theorie, die einem natürlich beim Gesamtverständnis der Materie geholfen hat. Die wirklichen Anforderungen, die einem im Berufsleben helfen könnten, bekommt man dort nicht vermittelt.

Und die Leute von der Uni ... Ne, da fast man sich doch wirklich manchmal an den Kopf, wie wenig die können. Das schmerzt echt.

[Captian Sheridan]

Auch Erfahrung ist kein Garant für Qualitätsarbeit, wenn derjenige kein Engagement zur Weiterbildung zeigt. Dann mag er das was er kann vielleicht ganz gut beherrschen, ist aber durch neue Techniken überholt und von gestern. Es heißt nicht umsonst Anwendungsentwicklung.
Es geht mir mehr um den Willen. Es wird sich auf dem ausgeruht, was man bereits kann, weil es bisher ausgereicht hat. "Wieso? Es läuft doch!", heißt es dann. Wenn der Vorgesetzte/Chef dann Null Ahnung von Programmierung hat, ist für den die Welt in Ordnung. Dass ihn der Murks seiner Angestellten dann Wettbewerbsvorteile kostet, weil z.B. Erweiterungen einen viel größeren Aufwand darstellen, ist ihm gar nicht bewusst.
Ich spreche dabei aus Erfahrung.

"You get what you paid for"

Die "Leuchttürme" sind entweder in der Forschung oder werden von IBM etc. abgesaugt oder verschwinden gleich ins Ausland.
Und die meisten ITler merken sehr schnell, das sie ein ungeliebter Kostenfaktor sind.
Mit Engagement arbeitet man sich nur auf, ohne eine Gegenleistung zu bekommen (hab ich auch erst lernen müssen).
Wird man krank, wird gern der Nächste eingestellt und verheizt.

Sieh es positiv, ohne diese Trägheit wären die Leute sehr schnell weg,
Die Inder und Chinesen sind weg, sobald jemand 1 Cent mehr zahlt. (ist übertrieben, aber stimmt)
Der Gesichtsausdruck der Chefs. :biggrin:


Die Gegenseite sind dann Projektleiter, die in irgendeiner Zeitschrift ein neues Buzzword gelesen haben, und das natürlich direkt irgendwo noch mit reingefrickelt haben wollen...
Sowas ist leider der Normalfall, oft sind auch die Memos, Vorgaben einfach nur Müll.:rolleyes:
Ein direkter Draht zu den anderen "Ameisen" in der Abteilung oder beim Kunden ist bedeutend wichtiger.

[Tiamat]

Dem stimme ich einfach mal voll und ganz zu. Genauso sehe ich das auch.

Das hört sich richtig gut an. Bei mir war das alles relativ theoretisch, und das trotz BA. Wir haben zwar verschiedene kleinere Projektarbeiten im Team gemacht, aber mit keiner so realistischen Rollenaufteilung.

Ja ist es auch. Die Profs haben gesagt, dass es sehr viele Gespräche erfordert hat, bis man mal ein ganzes Semester für ein Projekt zur Verfügung stellen konnte.
Im 2. hatten wir auch sowas in einer Vorlesung zur Objektorrientierung wurden jeweils 13er Teams gebildet und es gab ein begleitendes Projekt mit fixen Rollen, was aber kleiner dimensioniert war.
Ansonsten überwiegt natürlich die Theorie.

[RMC]

Habt ihr es echt bei euch, dass Leute ohne Programmiererfahrung gleich Chefsoftwarearchitekten werden?

Bei uns gottseidank nicht. Ich arbeite mit Softwareentwicklern zusammen, die sowohl von der FH als auch von der Uni kommen, sich aber schon seit der frühesten Jugend mit Programmieren beschäftigt haben und nicht mal eben 2 Kurse auf der Uni belegt haben. Ich selbst mache da auch keine Ausnahme.

Die Projektleiter sind bei uns jene, die sehr viel Erfahrung auf dem Gebiet aufweisen können. Das sollte auch so sein. Ich persönlich halte wenig davon, Leute an Positionen zu setzen, bei deren Entscheidungen oder Entwicklungen Wissen aus einem Bereich wesentlich ist, den man aus Hochmut heraus übersprungen hat. Gibt leider viele Firmen die das so praktizieren.

[Tiamat]

Ich brech jetzt mal ne Lanze für unsere Uni-Informatiker.

Meines Wissens ist das sehr formal, was man dort betrachtet. Von allen Lehrformen, die es gibt, ist das die formalste Lehrmethode. Formale Betrachtungen sind immer schwieriger als konkrete Betrachtungen.

Jetzt kommt der Punkt. In meinem Praxissemester hatte ich auch die Gelegenheit, in nem Berufsschulordner eines FI:AEs zu schauen, und ich war geschockt darüber, auf welchem Niveau dort Dinge behandelt wurden.

Das Niveau der Ausbildung trägt wesentlich zum Niveau jeden Abgängers bei. Jetzt kann mir keiner erzählen, dass ein Abgänger einer FI:AE Ausbildung sich in annehmbarer Zeit in eine Aufgabe einarbeiten kann, für die hochkarätige Mathekenntnisse erfolderlich sind oder sehr formelle Betrachtungen. Für jemand der das ganze auf so nem Niveau von der BS mitbekommen hat, ist das doch n unüberwindbares Hindernis.

Oder stellen wir uns vor, es soll durch Gegenüberstellung von Beweisen ermittelt, ob Konzept A oder Konzept B besser für die Realisierung eines Produktes ist. Dazu muss zuvor Konzept A, als auch Konzept B bewiesen werden. Viel Spaß bei der Recherche sag ich nur, für jemand der diese Grundlagen nie gelernt hat und das ganze übernächste Woche beim Chef präsentieren soll ;D

[RattuS]

Jetzt kommt der Punkt. In meinem Praxissemester hatte ich auch die Gelegenheit, in nem Berufsschulordner eines FI:AEs zu schauen, und ich war geschockt darüber, auf welchem Niveau dort Dinge behandelt wurden.
Du schlussfolgerst zu pauschal. Nur, weil man in der BS nichts lernt, heißt das nicht, dass man nichts im Betrieb lernt. Betrachte lieber die Prüfungsnote, denn dort fließt ein wesentlicher Teil ein, z.B. die Projektpräsentation und -dokumentation. Wer unter 90% FI abschließt, ist in meinen Augen auf dem Arbeitsmarkt eh nicht sehr viel wert.

[Hamster]

Jetzt kann mir keiner erzählen, dass ein Abgänger einer FI:AE Ausbildung sich in annehmbarer Zeit in eine Aufgabe einarbeiten kann, für die hochkarätige Mathekenntnisse erfolderlich sind oder sehr formelle Betrachtungen. Für jemand der das ganze auf so nem Niveau von der BS mitbekommen hat, ist das doch n unüberwindbares Hindernis.

logo. hochkarätige mathekenntnisse sind auch nicht ausbildungsinhalt eines FI:AE. deswegen gibt es ja auch uni-absolventen die diesen kram beherrschen sollten.

[Gast]

Warum werden hier FIAEs so fertig gemacht? Die können doch nichts dafür das die Ausbildung so schlecht ist.

[Ectoplasma]

Warum werden hier FIAEs so fertig gemacht? Die können doch nichts dafür das die Ausbildung so schlecht ist.

Es macht sie ja keiner fertig. Das Problem ist doch, dass die verantwortlichen Manager in der Regel die Unterschiede der einzelnen Informatikabschlüsse gar nicht genau kennen und oft glauben, man kann jeden auf jede Aufgabe loslassen. Habe ich leider zu oft erlebt.

Die FIAEs können dafür nichts. Das Allgemeinwissen über Informatik in der Bevölkerung strebt gegen null. Bei Managers ist das oft nicht anders. Ich persönlich bin dafür das Fach Informatik, als Pflichtfach in der Schule einzuführen. Wie viele hier sicherlich wissen, hat Informatik nicht nur etwas mit PCs zu tun.

[Monger]

Es macht sie ja keiner fertig. Das Problem ist doch, dass die verantwortlichen Manager in der Regel die Unterschiede der einzelnen Informatikabschlüsse gar nicht genau kennen und oft glauben, man kann jeden auf jede Aufgabe loslassen. Habe ich leider zu oft erlebt.

Das ist aber ein grundsätzliches Problem, was nicht nur für die Informatik gilt. Ich weiß noch, wie ich meinen Chefs erstmal erklären musste, was eine Berufsakademie eigentlich ist... und zwar als ich bereits in der Praxisphase vom Studium war.

Ein Manager muss delegieren können, und muss sich die entsprechenden Leute besorgen die Detailfragen klären können. Das gilt für jeden Fachbereich: egal ob Informatik, Medizin oder in einer Schreinerei.

[medi]

Der ganze Post ist ja richtig selbstverherrlichend.



Zu schade weil sie es gar nicht können. So kann man es auch betrachten ;D

Um auch nur irgendeine deiner Beispiele umsetzen zu können ist Programmierung essentiell. Du wirst kein gutes Konzept vorlegen können, wenn du nicht die bestehenden in- und auswendig kennst und sie auch längere Zeit entsprechend angewendet hast. Denn nur dadurch lernt man Vor- und Nachteile sowie Einsatzzwecke erst richtig kennen. Und das kann man eben nur in der Praxis so richtig.

Aber gut, wenn man von der Uni kommt muss man das nicht können. Man überspringt es einfach, weil man ja was besseres ist oder? Denn mit der Einstellung "Fürs Programmieren bin ich zu gut" landen diesen tollen Uni-Absolventen alle als untaugliche Heißluftföhns irgendwo und bilden sich ein ihre praxisfernen Konzepte könnten mal eben die Entwicklung revolutionieren. Kenn ich schon. Danke, verzichte.

Wenn das "selbstverherrlichend" auf meinen Post bezogen war dann hast du mich wohl missverstanden. Ich geh jetzt nur von mir aus (an der Uni Informatik studiert und seit 5 Jahren im Beruf bei 3 versch. AGs tätig) und da konnte ich mein an der Uni erlerntes Wissen noch in keinem Fall anwenden. Da ich in den letzten 5 Jahren rein in der Programmierung tätig war schließe ich nun für mich daraus, dass es für meinen Anwendungsfall (Standardprogrammierung im Team) unnötig ist einen Uni-Absolventen zu nutzen. Zusätzlich kenn ich noch ne Uni-Absolventin mit Info-Dipl. die bisher auch nichts aus ihrem Uniwissen abrufen musste (ausser etwas Mathematik was bei der FI:AE Ausbildung ja komplett ausgeblendet wird)
Übrigens haben wir an der Uni auch Projekte im Team realisiert. Dabei kam es aber aufs Ergebnis und die Präsentation an. Den Code dahinter und wie was realsiert wurde hat keinen interessiert.