Informatiker vs. Ingenieure

[Gast]

Marc++us schrieb:

peanuts schrieb:

Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.

Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.

Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.

Das Zeichnen eines ollen Netzplans kannst Du doch nicht mit einer massiv parallelen Anwendung vergleichen. Die Parallelität wie Du sie aufführst ist in unserem täglichen Handeln verankert während Threading jenseits bekannter Standardlösungen "uns" komplett überfordert und ein noch ungelöstes Problem darstellt.

[Marc++us]

Der Netzplan wird ja irgendwann ausgeführt.

[berniebutt]

Einfach einmal nachgefragt: Ist das noch alles ernsthaft aus eigenem Wissen und Erfahrung geantwortet? Ich fürchte hier den Trollfaktor t=f(a,b,c,...) :p

[also]

µ schrieb:

Marc++us schrieb:

peanuts schrieb:

Ich behaupte auch mal, dass eine mittelgroße Software bereits komplexer ist als ein modernes Hochhaus oder der mechanische Teil eines Autos.

Man kann sowas ja auch schön an Projektplänen messen... z.B. hat ein Projektplan für einen (mittelgroßen) Fabrikbau vielleicht 4000 Einzelvorgänge im Projekt - ein Vorgang ist dann sowas wie "Firma XY montiert Türen". Die Vorgänge müssen alle in die richtige Reihenfolge gebracht werden, um einen Deadlock zu vermeiden. Auch ist gerade die Planung der eigentlichen Bauphase mit der Planung von Anlieferungen (z.B. weil gewisse Wege/Straße nicht permanent verfügbar sind) ein massiv-paralleler Vorgang, wie man ihn nur in Multithreading-Applikationen mit einigen 100 parallelen Vorgängen wiederfinden würde.

Viele Programmierer stöhnen heute wegen der komplexen Abläufe in parallelen Anwendungen, aber viele Maschinen und Automaten sind bereits seit Jahren Systeme mit Parallelverarbeitung, bei denen verschiedene Motoren Dinge gleichzeitig und doch zusammen bewegen.

Das Zeichnen eines ollen Netzplans kannst Du doch nicht mit einer massiv parallelen Anwendung vergleichen. Die Parallelität wie Du sie aufführst ist in unserem täglichen Handeln verankert während Threading jenseits bekannter Standardlösungen "uns" komplett überfordert und ein noch ungelöstes Problem darstellt.

So schlimm ist Multithreading jetzt auch nicht. Viele Sachen lassen sich schon mit einem Parallel-For erledigen. Beim Rest muss man halt sorgfältig planen und sauber programmieren, das passiert aber bei der SW-Entwicklung oft nicht.

[tntnet]

Ich glaube, dass das Problem ist, dass ausprobieren bei der Softwareentwicklung billig ist. Wenn ich ein Haus immer wieder neu baue, bis sie stehen bleibt, dann wird das teuer.

Bei vielen Softwareentwicklern ist es aber üblich, dass sie so lange den Code ändern, bis er funktioniert. Probieren kostet ja nichts (ausser Arbeitszeit). Das nennt sich dann auch "Frickelei".

In anderen Bereichen baut man auch mal Prototypen. Und da ist es einfacher, sich erst Gedanken zu machen und dann erst an die Werkbank zu gehen.

Leider beobachte ich das auch im professionellen Bereich zu oft.

[Zeus]

tntnet schrieb:

Bei vielen Softwareentwicklern ist es aber üblich, dass sie so lange den Code ändern, bis er funktioniert. Probieren kostet ja nichts (ausser Arbeitszeit). Das nennt sich dann auch "Frickelei".

Ich bin mal frei zu ergänzen:

Systematisches und zielgerichtes Probieren = Lernen, Prototyping, ...
Planloses und zielloses Probieren = Frickelei

Immerhin gibst eine jede Menge Software nur für die computergestützt "Frickelei"

[XDXDXD]

zeus schrieb:

Systematisches und zielgerichtes Probieren = Lernen, Prototyping, ...

XD

[brotbernd]

Ich bin Maschinenbauingenieur und habe nach der Uni direkt in der Konstruktion eines Mittelständischen MBau Unternehmens angefangen, also ziemlich direkt vergleicbar mit der Tätigkeit eines Programmierers in der IT. Ein MBau Absolvent ist genauso wie ein Informatikabsolvent kein guter Programmierer ist, kein guter Konstrukteur. Dieser wird er erst in seinen ersten Berufsjahren. Bei einem Konstrukteur ist es aber so, dass sein Arbeitsergebnis immer maschinell (eine Art Unit Test) und natürlich IMMER auch von seinem Vorgesetzten bis ins Detail überprüft wird. Eine Zeichnnung wird niemals in Produktion gehen, bevor ein Verantwortlicher da gründlich mit dem Rotstift dran war. Und ich kann mich noch erinnern, wie die Zeichnungen am Anfang immer und immer wieder mit reichlich Rotstift zurück kamen. Ich denke es ist in den meisten Berufen ganz normal, dass Absolventen nicht die Ausbildung haben, um auf Anhieb gute Arbeit zu leisten (Meine Frau ist Lehrerin, die haben im Studium eigentlich überhaupt nichts Praxisrelevantes gelernt. Wie man unterrichtet lernt man ni der Schule ).

Bashar schrieb:

Ach ja, in bin Ingenieur, schreibe aber Software. Das sind die schlimmsten

Ja die sind wirklich schlimm Ich arbeite inzwischen in der Simulation wo ich hauptsächlich für die Softwareentwicklung verantwortlich bin. Was da von den Kollegen jahrzehntelang zusammengefrickelt wurde, heieiei...

[phcn.fraggle]

Gregor schrieb:

BTW: Die Chipindustrie ist definitiv nicht älter als die Informatik. Teilweise kann man Chipdesign sogar als Informatik sehen. Im Informatikstudium "designt" man zumindest auch schonmal einen kleinen Prozessor inklusive dem Befehlssatz. Wir haben das damals noch mit einem CAD Programm gemacht. Und dann haben wir darauf ein Programm für die Türme von Hanoi realisiert und simuliert. Mit Hardwarebeschreibungssprachen wie VHDL sind wir im Rahmen von Eingebetteten Systemen auch in Kontakt gekommen.

[OffTopic]An welcher Hochschule/Uni hast du Informatik studiert @Gregor? Klingt sehr interessant![/OffTopic]

@xepre
Was erwartest du von einem "frischen" Informatiker? Nicht jeder Informatiker ist automatisch ein guter Programmierer. Im Studium lernt man halt
nur die Basics. Dann gibt es da noch das Praxissemester und paar Softwareprojekte ( aus letzterem lernt man nicht so viel wie im Praxissemester *imo* - was ich mitnehmen konnte war das man mit Frickelei nicht immer weiterkommt ). Aber ein Semester Berufspraxis ist natürlich nicht viel aber dennoch eine wichtige Erfahrung. Was ich sagen will :

Erwarte anfangs nicht zu viel ( weil Informatik != Programmierer ), viel schlimmer finde ich sind die, die aus ihren "Fehlern" nicht lernen oder sich nicht verbessern möchten.

[berniebutt]

Ein SW-Projekt kann sehr vielfältige Ziele haben. Der Informatiker kann das eine und der Ingenieur oder jemand anderes das andere besser. Zusammen muss es eine Lösung geben. Niemand kann alles wissen und beherrschen! Ist diese simple Erkenntnis in der Informatik noch nicht angekommen? Zeit dafür war doch genügend vorhanden!

Vielleicht braucht ein Informatiker tatsächlich nicht programmieren zu können? Besser wäre es jedoch, wenn er mit dem Programmierer, dem Ingenieur, oder wem auch immer im Detail reden möchte!