Hallo zusammen,
mich interessiert eure Meinung zu dem Thema: Informatiker im technischen
Entwicklungsumfeld.
Jemand hat mal geschrieben: "Maschinenbauunternehmen und Automobilbauer
bevorzugen, wenn man sich Stellenanzeigen für den Nachwuchs anschaut,
eher den Ingenieur als den Informatiker."
Was glaubt ihr, ist das so? und wenn ja, dann ist der Informatiker ein
Techniker oder eher...hmmmm.....genau was ist ein Informatiker?
Dem Frager wurde auch so geantwortet:
"Im technischen Entwicklungsumfeld tun sich Firmen schwer, Informatiker
einzustellen. Ein Hauptgrund ist nach unserer Erfahrung der fehlende
technische Bezug etwa in der Automobilelektronik oder bei
Maschinensteuerungen."
Das heißt auch, dass ein Informatiker ist nicht qualifiziert, um solche
Tätigkeiten auszuüben aber ein Ingenieur kann ohne Probleme Software
entwickeln (z.B. auch bei SAP, Oracle usw.). Dann wozu braucht man
Informatiker......
Wenn eine große komplexe Software entwickelt werden soll, dürfte ein
Informatiker große Vorteile haben, da dazu eben die paar
Minimalbeispiele, die man beim "programmieren lernen" gezeigt kriegt,
nicht reichen. Entwicklungsaufwand skaliert eben nicht linear mit der
Größe des Programms - wenn man sich damit nicht auskennt, könnte das
gerne mal exp() sein :-)
Deutschland ist ein IT-Importland. Software wird in ENGLISH-Ländern
hergestellt. Hardware in Asien. Die CEBIT ist eine Messe, in der man
unseren Einwohnern die Computer dann verkaufen will. Sie nimmt außerdem
jährlich an Größe ab. Informatiker haben das Pech, auf die Werbung zu
diesem Studium hereingefallen zu sein. Ihre Arbeitgeber sind:
Autoindustrie, Behörden und Google. Jeder Schüler kann zu Hause das
Moorhuhn erfinden, am besten wenn ihm die Eltern passende Ideen aus der
eigenen Firma liefern.
Das Arbeitsamt gibt die Arbeitslosenzahl der Informatiker mit 4,4% und
die Arbeitslosenzahl der Elektroingenieure mit 2.7% an.
Wenn du nun als Informatiker -> embedded entwickeln willst? Dann locken
natürlich Aufgaben in Qualitätssicherung und Test. Du könntest dir ja
die EULERsche Identität und LAPLACE-Transformation aneignen. Lustig ist
auch FUZZY-Regelung in der FH: Fuzzy schon, das kannst du nachher
schlecht verkaufen aber Regelung: Oje, Sprungantwort und
Schwingverhalten musst du schon selber mitbringen, wenn nicht merkst du
bis nach der Prüfung nicht, dass es dir fehlt. Fehlen tut es erst, wenn
du es anwenden willst.
Die FH scheint sich aber gebessert zu haben und schaffte vor einiger
Zeit embedded-Prozessoren an. Vielleicht gibt es was, wenn du versucht,
in dem µC XML zu erzeugen und die Daten auf dem PC zu verarbeiten.
Ingenieur werden ganz klar bevorzugt. Warum? Ganz klare Sache. Erstens
haben Ingenieure einen tieferen Einblick in die Technik, also ein
besseres "Verhältnis" zu den Einsatzorten der Software. Zweitens, da wo
sich die Frage gestellt wird Ing oder Inf., da wird die Software sowieso
in Indien oder Co programmiert.
"Dort, wo UCs programmiert werden sollen, wir ein Maschinenbauer wohl
kaum weiterhelfen."
Diese Argumentation ist wayn. Warum? Seit wann sind alle Ings
Maschinenbauer? E-Techniker, Kybis, Mechatroniker können, oh Wunder, uCs
ebenfalls programmieren.
Ein Informatiker koordiniert die Arbeit seiner indischen oder ...
Kollegen und kontrolliert, ob die Software funktioniert. Komplexe
Probleme muss er dann selber lösen. Das ist aber der Grenzfall. Bekannt
schreibt Schulungen. Für wen könnt ihr ja mal erraten.
Vor einiger Zeit war ich mal beim größeren mittelständischen
Schwermaschinenbauer, mehr als 500 Mitarbeiter, Automatisierung.
Ich sah da keinen einzigen Informatiker. Die gesamte Betriebssoftware
einschließlich SPS und Visualisierung machten nur E-Techniker, die sich
in die Gebiete selbst einarbeiteten.
Sagt mal Leute was soll der Scheiß?
Die letzten Wochen geisterte der fast identische Thread hier herum mit
was weiß ich wie vielen Beiträgen.
Wer auch immer den Thread gestartet hat war zu faul oder zu dumm den
anderen Thread zu finden.
Je nachdem ob er Ingenieur oder Informatiker war könnt ihr jetzt für
euch entscheiden welcher Studiengang der dümmere und faulere ist.
Im Ernst schaltet mal euer Hirn ein. Gibt es gute Kinderärzte und
schlechte Allgemeinmidiziner? Sind Heizungsbauer besser als Metallbauer?
Es gibt überall gute weniger gute und schlechte Personen in ihrem Job.
UND ALLE DIE HIER DIE ANDERE STUDIENGRUPPE BASHEN WILL SIND DIE
SCHLECHTEN!!!!!
Ihr hättet studieren sollen statt nochmal in den Kindergarten zu gehen
Sehr genervt
Udo
Tjaja, der allseits übliche Standesdünkel, der stets beim Anderen
beklagt und selbst hochgehalten wird. Abgesehen davon scheint es hier im
Forum bei den Klagen über fehlende oder unterbezahlte Arbeitsplätze oder
"Sklavenhändler" weitaus mehr Ings als Infs zu geben. ;-)
Leute.. jeder weiss, dass die Innovation in meisten Fällen in der
Software stattfindet..
Bei uns in der Entwicklungsabteilung 60 Informatiker und 20
Elektroingenieure.. was nun ?
Glaubt ihr 3 Chips von 3 unterschiedlichen Firmen mit klar definierten
Schnittstellen auf einem Layout zusammen zu bringen und dazwischen
vielleicht einen ASIC rein zu werfen so schwierig ist ?
Als technischer Informatiker habe ich kein Problem Digital Design zu
betreiben.. also was ihr macht ist kein Rocket Science..
Sagt mal Leute was soll der Scheiß?
Die letzten Wochen geisterte der fast identische Thread hier herum mit
was weiß ich wie vielen Beiträgen.
Wer auch immer den Thread gestartet hat war zu faul oder zu dumm den
anderen Thread zu finden.
Je nachdem ob er Ingenieur oder Informatiker war könnt ihr jetzt für
euch entscheiden welcher Studiengang der dümmere und faulere ist.
Im Ernst schaltet mal euer Hirn ein. Gibt es gute Kinderärzte und
schlechte Allgemeinmidiziner? Sind Heizungsbauer besser als Metallbauer?
Es gibt überall gute weniger gute und schlechte Personen in ihrem Job.
UND ALLE DIE HIER DIE ANDERE STUDIENGRUPPE BASHEN WILL SIND DIE
SCHLECHTEN!!!!!
Ihr hättet studieren sollen statt nochmal in den Kindergarten zu gehen
Sehr genervt
hyggelig
RealGuest schrieb:> Leute.. jeder weiss, dass die Innovation in meisten Fällen in der> Software stattfindet..
Nein. Die Änderungen finden meistens in der Software statt. Änderung
bedeutet aber nicht automatisch auch Innovation.
@hyggelig: das ist eine berechtigte Frage aber trotzdem sollte man
sachlich bleiben. Kann mir jemand sagen was ist eine Innovation in der
Software? ich meine kann ich auch so eine Innovation patentieren? z.B.
in der Mechanik kann so eine Piezo-Common-Rail-System eine Innovation
sein aber was ist es dann in der Software?
Termos27 schrieb:> sein aber was ist es dann in der Software?
Amazons One-Click Button? ;-)
Patente sind kein Indikator für Innovation mehr, ganz besonders nicht
bei Software. Mittlerweile dienen sie eher als Innovationsbremse.
Den Thread kann man auch schließen.
(FH-)Ingenieure plappern hier ihre (unhaltbaren) Vermutungen aus. (Uni)
Informatiker lachen sich schrott und jeder hat den Längsten - meint er
zumindest.
Inhaltlich wertlos der Käse hier.
WasSollDas? schrieb:> Wayne?
Mich ;-)
BTW, nach der Diskussion hier, müsste ja der technische Informatiker der
beste Softwareentwickler sein. Er vereint ja aus beiden Welten jeweils
das Beste.
Die EINE Software, sie zu knechten, sie alle zu finden, ins Dunkel zu
treiben und ewig zu binden.
Nachdem wir hier so schön am Plattitüden klopfen sind:
Das was der Ingenieur für pragmatische Lösungen hält ist doch einfach
nur simples Handwerk, Hau-Drauf und Brute-Force.
Sobald das Problem auch nur den geringsten algorithmischen Anspruch
enthält seid ihr am Ende.
ich hatte das Glück genau den richtigen Studiengang belegen zu dürfen,
nämlich
Angewandte Informatik mit Anwendungsfach E-Technik
ich hatte neben der allgemeinen Informatik noch 30%-40% E-Technik und
bin sehr froh darum, weil man einfach als Informatiker einen adneren
Blick für das Programmieren und Entwickeln erhält, dadurch das man eine
relativ gute Vorstellung hat, was genau in einem PC (und vorallem CPU +
RAM) passiert. Trotzdem kennt man das ganze highlevel Informatiker
gedöns mit ihren Patterns usw :) .
Meine persönliche Erfahrung zeigt mir, dass tatsächlich, Ingeneure die
sich nachträglich zu reinen Softwareentwicklern umorientieren, die
besseren Informatiker in der Praxis sind. Sie verstehen die
Uusammenhänge einfach viel viel schneller.
Ich bin schon merhmals verzweifelt einem reinen Informatiker die
Zeitlichen abläufe einer Asynchronen Kommunikation naha zu bringen.
Soger so was simples wie "integer Overflow" ist für einige reine
Informatiker die ich persönlich kenne ein Hexenwerk :)
>Das was der Ingenieur für pragmatische Lösungen hält ist doch einfach>nur simples Handwerk, Hau-Drauf und Brute-Force.>Sobald das Problem auch nur den geringsten algorithmischen Anspruch>enthält seid ihr am Ende.
Deshalb haben die Ings ja auch alle Angst vor den Infs. Deswegen der
Thread...
benwilliam schrieb:> Soger so was simples wie "integer Overflow" ist für einige reine> Informatiker die ich persönlich kenne ein Hexenwerk :)
Das heißt wir vergleichen jetzt den Bodensatz der Informatiker mit der
Creme de la Creme der Ingenieure?
Na da bin ich ja mal aufs Ergebnis gespannt... gähnRosa-Kleidchen schrieb:> Deshalb haben die Ings ja auch alle Angst vor den Infs. Deswegen der> Thread...
Das klingt schon deutlich schlüssiger ;)
benwilliam schrieb:> Meine persönliche Erfahrung zeigt mir, dass tatsächlich, Ingeneure die> sich nachträglich zu reinen Softwareentwicklern umorientieren, die> besseren Informatiker in der Praxis sind. Sie verstehen die> Uusammenhänge einfach viel viel schneller.
Das ist im Bereich E-Technik natürlich - schließlich sind die vom Fach
:-)
In anderen Bereichen sieht das anders aus.
Wäre ich im MaschBau-Bereich, würde sicherlich der MaschBauer derjenige
sein, der am ehesten Zusammenhänge begreift.
> Ich bin schon merhmals verzweifelt einem reinen Informatiker die> Zeitlichen abläufe einer Asynchronen Kommunikation naha zu bringen.
Ebenso verzweifeln die vermutlich an anderen Dingen :-)
> Soger so was simples wie "integer Overflow" ist für einige reine> Informatiker die ich persönlich kenne ein Hexenwerk :)
Irgendetwas ist für jeden Hexenwerk.
Ich würde auch nicht auf die Idee kommen, bei einer zu erstellenden
Reaktionssimulation in der Chemie einen E-Techniker einzubinden - das
ist für 99% dieser nämlich auch Hexenwerk :-)
Eigentlich ist es doch ganz einfach:
Will ich etwas Komplexes in eine Software gießen, gehe ich zum
Informatiker.
Will ich Elektronik, gehe ich zum E-Techniker
Will ich eine Maschine, gehe ich zum Maschbauer
Denn natürlich hat der E-Techniker nicht das entsprechende Wissen eines
Infos in dessen Bereich - wie auch umgekehrt.
Insofern stimmt der Satz "Dem Ingeniör ist nichts zu schwör." immer nur
für sein Gebiet.
Und natürlich gibt es immer Leute, denen es "zu schwör ist, die Leistung
anderer anzuerkennen".
Die nimmt aber niemand ernst.
Chris D.
Rufus schrieb:> BTW, nach der Diskussion hier, müsste ja der technische Informatiker der> beste Softwareentwickler sein. Er vereint ja aus beiden Welten jeweils> das Beste.
Das ist auch so, ja ;-)
Irgendwie doch Popcorn und Bier :-)
Ist schon interessant wie viele offensichtlich inkompetente und mit
Minderwertigkeitskomplexen behaftete Ings und Informatiker sich hier
gegenseitig bashen.
Wenn ihr alle so toll seid warum hängt ihr dann hier mit bashing rum und
überlasst KarlHeinz, MaWin, Falk, Lothar, Rufus, Harald, Peter und noch
einer Handvoll Leute die Arbeit die ganzen Anfragen hier im Forum zu
beantworten?
Ach so das ist unter eurer Würde, dazu habt ihr keine Zeit, ....
...oder doch keine Ahnung?
Ich bin dann mal wieder weg :-)
D. I. schrieb:> Das was der Ingenieur für pragmatische Lösungen hält ist doch einfach> nur simples Handwerk, Hau-Drauf und Brute-Force.> Sobald das Problem auch nur den geringsten algorithmischen Anspruch> enthält seid ihr am Ende.
So schlimm ist es nun auch nicht - aber ich kann mit dir lachen, weil
ich weiß was du meinst.
Brute-Force ist tatsächlich des Ingenieurs Lieblingsmethode.
Das ist auch das von der Natur her beliebteste Prinzip - einfach alle
auffressen - nur extreme Spezialisten überleben das.
:-)
Das Problem dürfte sein, dass "Informatiker" nicht bedeutet, dass
derjenige größere Softwareprojekte in der Industrie umsetzen kann, da
das reine Informatikstudium doch oft eher akademisch orientiert ist. Die
dort gelernten Dinge sind zwar für einen guten Softwareentwickler
nützlich, aber nicht ausreichend, wenn z.b. die Erfahrung mit dem
Anwendungsgebiet oder gar mit der Entwicklung größerer Projekte
allgemein fehlt, da im Studium solch "praktische Fragen" wie "Wie
arbeite ich im Team mit 40 Leuten an großer Software mit minimalem
Chaos?", "Wie muss ich Software strukturieren, dass man sie auch in
einigen Jahren noch an neue Situationen anpassen kann ohne zu riskieren
durch kleine Änderungen das komplette System zu (zer)stören?", ... oft
vernachlässigt werden. Es gibt natürlich praktisch orientierte
Studiengänge auch in der Informatik, die sich teilweise auch als
Ingenieursausbildung für Software sehen...
dall schrieb:> wenn z.b. die Erfahrung mit dem> Anwendungsgebiet oder gar mit der Entwicklung größerer Projekte> allgemein fehlt, da im Studium solch "praktische Fragen" wie "Wie> arbeite ich im Team mit 40 Leuten an großer Software mit minimalem> Chaos?", "Wie muss ich Software strukturieren, dass man sie auch in> einigen Jahren noch an neue Situationen anpassen kann ohne zu riskieren> durch kleine Änderungen das komplette System zu (zer)stören?", ... oft> vernachlässigt werden. Es gibt natürlich praktisch orientierte> Studiengänge auch in der Informatik, die sich teilweise auch als> Ingenieursausbildung für Software sehen...
eben ! Zeugs aus Theo Inf braucht man doch so gut wie nie in der Praxis,
sondern wichtig sind die von Dir angesprochenen Dinge. Theo Inf und
Mathe sind im Inf Studium eher eine Art "Denkschule" bzw. Übung abstrakt
und formal denken zu lernen. Das aber lernt auch ein ET-Ing in Physik,
Mathe, Systemtheorie, Regelungstechnik usw.
Dazu hat der Ing auch noch Kenntnisse von der Technik und nicht nur von
der Software.
ITCrack schrieb:> Dazu hat der Ing auch noch Kenntnisse von der Technik und nicht nur von> der Software.
Und von den oben angesprochenen Dingen - wie entwickelt man Software im
Team, wie strukturiert man Software vernünftig, wie dokumentiert man
Änderungen an der Software so dass es auch nach Jahren noch
nachvollziehbar ist - weiß der Ingenieur standardmäßig (also als
Absolvent frisch im Job) herzlich wenig.
Bei manchen ist's auch nach 20 Jahren im Beruf nicht sehr viel besser,
wenn ich mir deren Code und die Änderungsdokumentation teilweise so
anschaue...
Einigen wir uns darauf: Es gibt Leute, die sich für Softwarethemen
interessieren und sich entsprechend weiterbilden. Die haben es dann in
der Regel auch drauf - und zwar ganz unabhängig davon, ob sie nun
Ingenieure oder Informatiker sind.
Mark Brandis schrieb:> Und von den oben angesprochenen Dingen - wie entwickelt man Software im> Team, wie strukturiert man Software vernünftig, wie dokumentiert man> Änderungen an der Software so dass es auch nach Jahren noch> nachvollziehbar ist - weiß der Ingenieur standardmäßig (also als> Absolvent frisch im Job) herzlich wenig.
das geht einem Inf von der Uni oft auch nicht anders.
Weil sowas lernt man im Job. Bin selbst technischer Informatiker,
arbeite aber u.a. wegen den besseren Aussichten im Bereich SAP. Einer
meiner Vorgesetzen ist ET Ing und es arbeiten in meinem Bereich einige
Ings.
Weil das was man Logik und Ingeneur-Denken für die SAP Entwicklung mit
bringen muss, hat man als Ing gelernt. Den Rest lernt man meist on the
Job. Irgendwelche hardcore Sachen aus Theo. Informatiker braucht man
herzlich selten, sondern eher das lösungsorientierte Denken was man auch
als Ing lernt.
Umgekehrt gibt es in der Tat sehr wenige Informatiker, die
Ingenieuraufgaben übernehmen. Welcher Informatiker, entwickelt schon
Hardware etc.
Allerdings erscheint mir die IT Beratung, insbesondere der Bereich SAP,
deutlich besser bezahlt zu sein als das was man mit Hardware so
verdienen kann. Für die Stundensätze welche hier teils genannt werden,
bekommt man im SAP Bereich meist nicht mal einen Junior Entwickler.
Anton Hirtmann schrieb im Beitrag #2387039:
> Hauptsächlich braucht man Logik um Software (oder Hardware) zu> entwickeln.
Demzufolge wären als Soft- und Hardwareentwickler eigentlich Juristen
ideal. Logisches Denken ist da nämlich auch Voraussetzung, wenn auch in
einem etwas eigenen System. ;-)
Anton Hirtmann schrieb im Beitrag #2387042:
> Dann kommt ein Ingenieur, baut in in einem Bruchteil der Zeit eine> funktionsfähige Software wie sie der Kunde benötigt, und der Laden> brummt wieder.
Dieses Prinzip kann man fortsetzen. Gemäss
http://www.mikrocontroller.net/topic/235481?goto=new#2386528
kann der einfache Techniker das noch viel besser. Wenn man dann noch
Sprüche wie "Das kriegt doch jede Putzfrau besser zustande"
berücksichtigt...
A. K. schrieb:> Demzufolge wären als Soft- und Hardwareentwickler eigentlich Juristen> ideal. Logisches Denken ist da nämlich auch Voraussetzung, wenn auch in> einem etwas eigenen System. ;-)
jaein. Es geht um formale Logik, und bei formalen Sprachen sind Juristen
wohl nicht so gut. Ansonsten hast Du Recht. Was einem "formalen Jurist"
am nächsten Kommt wäre ein Mathematiker oder Physiker, der viel mit
Sätzen, Beweisen und Theoremen arbeitet. Die sind ähnlich wie Gesetze,
allerdings formal notiert, wie Probleme in einer Programmiersprache.
Allerdings muss man als Entwickler auch in der Lage sein,
Anwenderprobleme aus Anwendersicht zu verstehen um diese danach in eine
formale Problembeschreibung bzw. Implementierung überführen zu können.
Dazu braucht man Kenntnisse der Anwenderdomäne, nicht aber unbedingt
Kenntnisse von theoretischer Informatik, da genügen eher Grundlagen.
Man braucht im Berufsalltag zu 90 % eher das Wissen des Anwenders und
vllt zu 5 % das Wissen aus der theo. Inf. Vorlesung, wenn nicht sogar
noch weniger.
Da der Ing das Wissen des Anwenders ( Maschbau, Hardware, E Technik )
besitzt, und gelernt hat, mathematisch-logisch formal zu denken, bringt
er ideale Vorrausetzungen mit um als SW Entwickler tätig zu sein. Der
Inf hat, gerade an der Uni, zwar eine sehr gute mathematisch-logische,
formale Ausbildung genossen, aber kennt sich in der Anwenderdomäne meist
längst nicht so gut aus wie ein Ing.
ITCrack schrieb:> jaein. Es geht um formale Logik, und bei formalen Sprachen sind Juristen> wohl nicht so gut.
Soll das ein Witz sein? Eine formalere Sprache als die der Juristen ist
in der menschlichen Realität kaum anzutreffen. ;-)
dall schrieb:> Das Problem dürfte sein, dass "Informatiker" nicht bedeutet, dass> derjenige größere Softwareprojekte in der Industrie umsetzen kann, da> das reine Informatikstudium doch oft eher akademisch orientiert ist. Die> dort gelernten Dinge sind zwar für einen guten Softwareentwickler> nützlich, aber nicht ausreichend, wenn z.b. die Erfahrung mit dem> Anwendungsgebiet oder gar mit der Entwicklung größerer Projekte> allgemein fehlt, da im Studium solch "praktische Fragen" wie "Wie> arbeite ich im Team mit 40 Leuten an großer Software mit minimalem> Chaos?"
Dasselbe gilt genauso für jeden Ingenieur.
Nach seinem Studium hat der davon nämlich keine Ahnung.
Auch ein Ingenieur muss erst lernen, im Team zu arbeiten.
Wobei wir Projektarbeit im Team schon an der Uni hatten.
> "Wie muss ich Software strukturieren, dass man sie auch in> einigen Jahren noch an neue Situationen anpassen kann ohne zu riskieren> durch kleine Änderungen das komplette System zu (zer)stören?", ... oft> vernachlässigt werden.
Dann war das ein schlechtes Studium.
Selbstverständlich lernt man als Informatiker genau diese Dinge.
Chris D.
ITCrack schrieb:> eben ! Zeugs aus Theo Inf braucht man doch so gut wie nie in der Praxis,> sondern wichtig sind die von Dir angesprochenen Dinge. Theo Inf und> Mathe sind im Inf Studium eher eine Art "Denkschule" bzw. Übung abstrakt> und formal denken zu lernen.
Vor allem lernt man, was geht und was nicht - ein entscheidender
Vorteil.
> Das aber lernt auch ein ET-Ing in Physik,> Mathe, Systemtheorie, Regelungstechnik usw.
Aber nicht bezüglich Algorithmen.
Und zum Infostudium gehört nicht nur theoretische Info. Dazu kommt
Graphen- und Baumtheorie, Warteschlangen, Verifikation, Abschätzungen
von Laufzeit usw.
Alles Dinge, die ein Ing. - wenn überhaupt - nur anschneidet.
> Dazu hat der Ing auch noch Kenntnisse von der Technik und nicht nur von> der Software.
Er hat vor allem Kenntnisse von E-Technik, von Technik allgemein eher
nicht.
Und von Softwareentwicklung weiss er eben nur Rudimentäres.
Chris D.
>eben ! Zeugs aus Theo Inf braucht man doch so gut wie nie in der Praxis,
Das würde ich nicht so unterstreichen. Mir hat alleine die
Komplexitätstheorie - die Klassifizierung eines algorithm. Problems - in
der Praxis enorm geholfen.
Rosa
Mancher Hirnfurz hier ist ja kaum noch zu überbieten.
Anton Hirtmann schrieb im Beitrag #2387042:
> Ein Beispiel: Statt die Software zu entwickeln experimentiert ein> Informatiker mit praxisfernen Konzepten vor sich hin. An der> Aufgabenstellung geht das natürlich komplett vorbei. Jahre später ist> die Software immer noch nicht fertig und die Firma steht vor der Pleite.> Dann kommt ein Ingenieur, baut in in einem Bruchteil der Zeit eine> funktionsfähige Software wie sie der Kunde benötigt, und der Laden> brummt wieder. So sieht es in der Praxis aus. Ich habe auch schon häufig> den Karren aus dem Dreck ziehen muss, den unfähige Vorgänger> hinterlassen habe .
Ein Beispiel: Statt sich vorher Gedanken zu machen, wie ein Problem
sauber gelöst werden könnte hackt der Ing schnell die naive Idee runter.
Da ihm wesentliche Grundkenntnisse der Algorithmik fehlen, begeht er
typische Anfängerfehler. Die Software benötigt Stunden zur Berechnung.
Ein Informatiker analysiert das nochmal kurz, macht die Anfängerfehler
raus und die Laufzeit beträgt nur noch ein paar Sekunden.
Schlussfolgerung: Produktivitätssteigerungen um 1000e % und Ingenieure
halten sich für die Krone von allem anstatt bei ihrer Expertise zu
bleiben. Ein Ingenieur würde ein graphentheoretisches Problem nicht mal
erkennen wenn es nackt vor ihm Samba tanzt.
Gefolgert aus einem (!) Beispiel, klasse oder?
Wie manche hier zu ihrem Diplom gekommen sind, bei so einer beschränkten
Weitsicht ...
Gruß vom Informatiker der in der Digitaltechnik wildert...
Rosa-Kleidchen schrieb:>>eben ! Zeugs aus Theo Inf braucht man doch so gut wie nie in der Praxis,> Das würde ich nicht so unterstreichen. Mir hat alleine die> Komplexitätstheorie - die Klassifizierung eines algorithm. Problems - in> der Praxis enorm geholfen.> Rosa
das mag im Einzelfall so sein. Aber schau Dir mal die üblichen
Informatiker Jobs in der Entwicklung oder IT Beratung an. Mit
algorithmischen Problemen ist da meist nicht viel, klar hier und da
kommt so was mal vor. Selten benötigt man dazu Heuristiken um NP harte
Probleme in passabler Zeit zu lösen. Die üblichen Jobs verlangen viel
mehr praktisches Know How. Kenntnisse von Tools, Entwicklungsumgebungen,
Programmiersprachen, DBs, Projektmanagement etc.
Rosa-Kleidchen schrieb:>>eben ! Zeugs aus Theo Inf braucht man doch so gut wie nie in der Praxis,> Das würde ich nicht so unterstreichen. Mir hat alleine die> Komplexitätstheorie - die Klassifizierung eines algorithm. Problems - in> der Praxis enorm geholfen.
Genau das meine ich.
"Ist das Problem so überhaupt lösbar?"
"Gibt es bessere Lösungsansätze?"
"Brauchen wir eine Heuristik?"
usw.
Chris D.
Chris D. schrieb:> "Ist das Problem so überhaupt lösbar?"> "Gibt es bessere Lösungsansätze?"> "Brauchen wir eine Heuristik?"> usw.
kommt natürlich immer auf das Anwendungsgebiet an.
Nehmen wir mal Standard IT Beratung. Kunde möchte ein bestehendes
Logistik Modul, sagen wir in .net entwickelt, um einige Features
erweitern. Da wird das Frontend etwas verändert, man holt Daten aus der
Datenbank, arbeiten mit denen was, und persistiert diese anschließend
wieder dort. Bei normalen Prozessen die ein Kunde bei sowas wünscht
kommen durchaus hin und wieder komplexere Dinge vor, gerade wenn es um
Analyse oder Datenqualität geht. Aber NP harte Probleme, bei denen man
sich eine geeignete Heuristik überlegen muss, das gibt es vllt in 5 %
der Fällen, oder weniger. Dafür kann man dann auch einen Fachmann kommen
lassen. In 95 % der anderen Fälle kommt man auch ohne solche Algorithmen
klar sondern es zählen viel mehr die Dinge die ich oben genannt habe.
Was bringt ein Algorithmentheoretiker, der sich nicht mit der
Persistenzschicht sauber aus kennt ? der nicht weiß wie er über
verschiedene Instanzen hin weg debuggt, oder nicht mal eine
DB-Verbindung aufbauen kann ? oder sich nicht mit dem genutzen DB System
aus kennt ? DAS nämlich sind die typischen Alltagsprobleme mit denen man
sich als Entwickler oder IT-Berater auseinander setzt und nicht mit
komplexen Heuristiken
anderes Beispiel : Schaut mal in Jobbörsen, wie oft da das Wort
Heuristik oder Algorithmik drin vor kommt, danach schaut ihr wie oft die
von mir genannten Begriffe vor kommen
ITCrack schrieb:> das mag im Einzelfall so sein. Aber schau Dir mal die üblichen> Informatiker Jobs in der Entwicklung oder IT Beratung an. Mit> algorithmischen Problemen ist da meist nicht viel, klar hier und da> kommt so was mal vor. Selten benötigt man dazu Heuristiken um NP harte> Probleme in passabler Zeit zu lösen.
Natürlich benötigt man diese Sachen nicht immer - aber es kommt der Tag,
da braucht man sie.
Es benötigt auch nicht jeder Ing. ständig Laplace-Transformierte oder
Systemtheorie. Trotzdem ist es für ihn wichtig, diese zu kennen, wenn es
darauf ankommt.
> Die üblichen Jobs verlangen viel> mehr praktisches Know How. Kenntnisse von Tools, Entwicklungsumgebungen,> Programmiersprachen, DBs, Projektmanagement etc.
Das lernt man ja auch noch.
Ich verstehe nicht, wo überhaupt das Problem der Leute liegt.
Habe ich (als Informatiker) ein E-Technik-Problem, gehe ich zum
E-Techniker und frage den um Rat.
Hat ein E-Techniker ein Algorithmusproblem, schnappt er sich einen
Informatiker.
Das Optimum ist, wenn man von jeder "Sorte" einen im Team hat. Der kann
dann nämlich eingreifen: "Das, was Du Dir da an Algorithmen ausgedacht
hast, ist zwar ganz schön, lieber E-Techniker - funktioniert aber aus
den und den Gründen nicht."
Und natürlich umgekehrt :-)
Chris D.
D. I. schrieb:> Ein Beispiel: Statt sich vorher Gedanken zu machen, wie ein Problem> sauber gelöst werden könnte hackt der Ing schnell die naive Idee runter.> Da ihm wesentliche Grundkenntnisse der Algorithmik fehlen, begeht er> typische Anfängerfehler. Die Software benötigt Stunden zur Berechnung.
Typisches Szenario bei Beauftragung von Softwareentwicklung, direkt aus
der Praxis:
Der Auftraggeber hat eine Ahnung von Design und vom Schuhverkauf, hat
eine eine super Idee von einer Webseite und vergibt den Auftrag an ein
externes Entwicklungsbüro. Das Entwicklungsbüro sagt "prima, machen
wir", der Entwickler zimmert mit 2 Dutzend Testdaten eine wunderbar
aussehende Lösung hin und liefert sie dem Kunden. Der Kunde stellt da
nun zigtausend Daten rein - und es dauert 10 Sekunden um auch nur die
Startseite zu öffnen, auf Mobilgeräten gar 2 Minuten.
Dass der Auftraggeber keine Ahnung hat, wie sich seine geforderte
Komplexität in der Praxis auswirkt ist ihm nicht anzulasten. Der hat
Ahnung von Webdesign und von Schuhen, aber nicht von Komplexität und
Skalierung von Lösungen. Das Entwicklungsbüro sollte aber daran bereits
in den Verhandlungen daran denken. Die Grundlagen solcher Abschätzung
sind eher Sache der Ausbildung von Infs als von Ings - was nichts daran
ändert, dass hier Praxis sehr hilft und dass Ings ebenso in der Lage
sind, sich das anzueignen, so entsprechendes Talent vorhanden.
Nicht jeder Ing hat wirklich Talent für die Vorgänge in der IT und
etliche Infs haben einen schwachen Bezug zur Technik. Wie das
persönliche Berufsbild nachher aussieht hängt nicht nur von der
Ausbildung sondern auch stark von der persönlichen Eignung fürs Thema
ab. Einen Informatiker mit eher theoretischen Neigungen sollte man
deshalb nicht ausgerechnet in ein Entwicklungsbüro für Mikrocontroller
stecken, aber es gibt ja auch etliche andere Bereiche - die jedoch in
einem Ing-lastigen Forum für Mikrocontrollertechnik nicht stark
vertreten sind.
Chris D. schrieb:> Das Optimum ist, wenn man von jeder "Sorte" einen im Team hat.
In solchen wie anderen Fragen ist das der sinnvolle Ansatz. So braucht
man oft auch jemanden, der strategisch günstig mit Externen diskutieren
kann, ohne dass über kurz oder lang die Fäuste fliegen. Auch sowas ist
eine persönliche Qualifikation, jenseits aller Fachkenntnisse und
Ausbildungsarten. Eine Qualifikation die von stark technisch veranlagten
Leuten eher gering eingeschätzt wird - aber genauso wichtig ist.
A. K. schrieb:> D. I. schrieb:>>> Ein Beispiel: Statt sich vorher Gedanken zu machen, wie ein Problem>> sauber gelöst werden könnte hackt der Ing schnell die naive Idee runter.>> Da ihm wesentliche Grundkenntnisse der Algorithmik fehlen, begeht er>> typische Anfängerfehler. Die Software benötigt Stunden zur Berechnung.>> Typisches Szenario bei Beauftragung von Softwareentwicklung, direkt aus> der Praxis: ...>
Das kann man so wohl unterstreichen. Dann noch die ganzen anderen
Domänen, Computergraphik, High-Performance-Computing, Mustererkennung,
Compilerbau (was nicht gleich heißt dass man einen GCC
zusammenschustert...), ...
Meine (nicht repräsentative) Erfahrung:
Ein Informatiker nimmt einen Industrie-PC um 300 Euro, eine
Motorsteuerung um 100 Euro, installiert eine relationale Datenbank,
schreibt ein kleines Programm und löst das Problem damit in 3 Tagen.
Der Elektrotechniker nimmt einen 8-bit µC, ein paar Transistoren, ...
und löst das Problem in 3 Monaten mit einer Platine, die in der
Serienfertigung 20 Euro kostet.
Welche Lösung ist denn jetzt die bessere?
ITCrack schrieb:> Dafür kann man dann auch einen Fachmann kommen> lassen.
Dafür müssen die Leute, die an dem Projekt arbeiten, erst einmal
zugeben, dass sie überfordert sind.
Wie war das noch mal mit scheiternden Projekten und Soft-Facts?
Es zahlt sich oftmals aus, einen Fachmann ständig im Team zu haben, auch
wenn dieser 95% der Zeit unterfordert ist. In kleineren Firmen mag es ja
recht ineffizient aussehen, aber ständig einen Fachmann für dieses oder
jenes suchen zu müssen kostet auch Zeit, Geld und Nerven. Und von allen
Dreien ist nie genug da.
Was natürlich auch stimmt, ist, dass man für viele Probleme keinen
Informatiker braucht, sondern nur jemanden, der etwas Programmieren kann
und für den SQL kein Fremdwort ist. Wenn man sich auf die Lösung dieser
Probleme spezialisiert, dann sieht die Lage, nona, gleich anders aus.
A. K. schrieb:> externes Entwicklungsbüro. Das Entwicklungsbüro sagt "prima, machen> wir", der Entwickler zimmert mit 2 Dutzend Testdaten eine wunderbar> aussehende Lösung hin und liefert sie dem Kunden. Der Kunde stellt da> nun zigtausend Daten rein - und es dauert 10 Sekunden um auch nur die> Startseite zu öffnen, auf Mobilgeräten gar 2 Minuten.>> Dass der Auftraggeber keine Ahnung hat, wie sich seine geforderte> Komplexität in der Praxis auswirkt ist ihm nicht anzulasten. Der hat> Ahnung von Webdesign und von Schuhen, aber nicht von Komplexität und> Skalierung von Lösungen. Das Entwicklungsbüro sollte aber daran bereits> in den Verhandlungen daran denken.
Es gilt, was im Vertrag steht: Wenn da steht, dass die Applikation mit
mehreren zehntausend Datensätzen und bei N Zugriffen pro Sekunde mit
einer Reaktionsgeschwinddigkeit von höchstens X Sekunden laufen soll,
dann ist dies auch genau so umzusetzen.
Wenn im Vertrag überhaupt keine Angaben über die Performance drinstehen,
dann kann der Entwickler im Prinzip auch ein schnarchlangsames System
abliefern - formal hat er nichts falsch gemacht. Natürlich sollten
beide Vertragsparteien so intelligent sein, solche Fragen rechtzeitig
zu klären. Diese Information auf eine vernünftige Art und Weise zur
Verfügung stellen muss aber im Endeffekt der Kunde.
"Wie viele Datensätze haben Sie denn?" - "Na ja, schon viele..." -
(gedanklich) "Okay, nehmen wir mal ein paar Hundert an, mehr Schuhe kann
es in einem Geschäft der Größe doch wohl nicht geben." Und bumms...
D. I. schrieb:> Das kann man so wohl unterstreichen. Dann noch die ganzen anderen> Domänen, Computergraphik, High-Performance-Computing, Mustererkennung,> Compilerbau (was nicht gleich heißt dass man einen GCC> zusammenschustert...), ...
Alles schön und gut und richtig, nur stellen die von Dir genannten Dinge
in der Realität eben nur einen kleinen Teil aller durchgeführten
Software-Projekte dar.
Mark Brandis schrieb:> Alles schön und gut und richtig, nur stellen die von Dir genannten Dinge> in der Realität eben nur einen kleinen Teil aller durchgeführten> Software-Projekte dar.
Korrekt. Die hier im Forum ventilierten Themen sind freilich ebenfalls
nur ein kleiner Teil der Software-Projekte. Ein anderer Teil eben.
> Wenn im Vertrag überhaupt keine Angaben über die Performance drinstehen,> dann kann der Entwickler im Prinzip auch ein schnarchlangsames System> abliefern - formal hat er nichts falsch gemacht.
Er würde sich mit einer derartigen Reaktion lächerlich machen und hätte
mit Sicherheit den letzten Auftrag von der ganzen Firmengruppe erhalten.
Tja, und nun hast du immerhin für jedermann lesbar dokumentiert, weshalb
BWLer nicht durch Ings ersetzt werden können. ;-)
Fehlende Angaben im Pflichtenheft muss man ausnutzen. Damit kann man
Geld verdienen. Notfalls ist damit der erste Anschlussauftrag jenseits
des vereinbarten Kaufpreises gesichert.
A. K. schrieb:> Fehlende Angaben im Pflichtenheft muss man ausnutzen. Damit kann man> Geld verdienen. Notfalls ist damit der erste Anschlussauftrag jenseits> des vereinbarten Kaufpreises gesichert
Dem kann ich nur zustimmen. Das Ausnutzen muss allerdings geschickt
vonstatten gehen, damit der Kunde sich nicht ausgenutzt fühlt. Probates
Mittel ist, Fehlendes erst spät zu entdecken.
A. K. schrieb:> Fehlende Angaben im Pflichtenheft muss man ausnutzen. Damit kann man> Geld verdienen.
Aber genau das täte man ja, indem man schnell und billig entwickelt (man
muss dem Kunden ja nicht sofort erzählen, dass die Software fertig ist
;-) anstatt länger und teuer und das System dafür toll skaliert.
>schneller entwicklet
Es geht eigentlich nicht, weil man nur den Auftrag bekommt, wenn man
extrem niedrig angeboten hat - entweder weil man den Auftrag unbedingt
haben wollte oder ihn unterschätzt. Irgendeiner unterschätzt ihn nämlich
sowieso und sonst kriegt der ihn.
Es geht in der Folge also darum, Verzögerungen und Zusatzkosten zu
begründen und reinzumauscheln, um Konventionalstrafen zu entgehen.
Nichts ist dafür besser geeignet, als ein funktionelles Manko in der
Planung, das man leider erst "spät" entdeckt. Man weist den Kunden
darauf hin und bietet auch eine Lösung an, die er praktisch nehmen muss.
In diese Richtung hat man zuvor schon entwickelt und kann nur, weil man
diagonal gerarbeitet hat, der Kunde aber "gerade" (Ziel1) und dann
"quer" (Änderunge) sieht, sowohl Kosten als auch Zeit in den Auftrag
quetschen, sodass er wieder halbwegs rentabel wird. Dazu muss natürlich
viel kommuniziert und gereist werden.
So stellt man sicher, dass man beim Kunden als kooperativ gilt und er
die Mehrkosten trägt und nicht nach Indien auslagert. Man muss dem
Kunden seine eigenen UNzuläglichkeiten unter die Nase halten. Dann kann
man ihn melken!
Was fuer tolle Softwareentwickler Ingenieure sind, sieht man ja schon
daran, dass in diesem Forum eine Entprellroutine als genialste Erfindung
seit dem geschnittenen Brot angebetet wird.
>Was fuer tolle Softwareentwickler Ingenieure sind, sieht man ja schon>daran, dass in diesem Forum eine Entprellroutine als genialste Erfindung>seit dem geschnittenen Brot angebetet wird.
Haha, so ist es...
Rosa
Der Informatiker ist doch einfach nur höher spezialisiert.
Es ist ein Teilgebiet des Wissens eines Ingenieurs.
Wie auch Chemie, Mathematik, Mechanik, Elektronik usw..
Ich hab neulich mal Prüfungen für Elektroniker lesen dürfen - na Hut ab.
Der Ingenieur ist der Universalist - der Vergleich ist insofern
unsinnig.
Eine ganz andere Geschichte ist ja das die meissten Informatiker
schlicht als Programmierer arbeiten - was aber nur ein Facharbeiterberuf
ist.
Michael Lieter schrieb:> Es ist ein Teilgebiet des Wissens eines Ingenieurs.>> Wie auch Chemie, Mathematik, Mechanik, Elektronik usw..
Ein bisschen vermessen zu sagen das wären alles Teilgebiete des
Ingenieurs denn das klingt als wär der Ingenieur zuerst dagewesen.
Richtig wäre wohl ein Ingenieur ist eine Kombination der klassischen
Gebiete.
Zuckerle schrieb im Beitrag #2388488:
> Ich sehe den Ingenieur in erster Lienie als Anwender. Nicht alle> Ingenieure arbeiten auch als Entwickler.
Sehe ich auch so
Michael Lieter schrieb:> Der Informatiker ist doch einfach nur höher spezialisiert.>> Es ist ein Teilgebiet des Wissens eines Ingenieurs.
So wie die Elektrotechnik ein Teilgebiet des Physikers ist :-)
> Wie auch Chemie, Mathematik, Mechanik, Elektronik usw..
Ja, allerdings nur zu einem Teil, der bspw. in der Chemie kaum über
Schulwissen hinausgeht. Erlebe ich schon seit Jahren.
> Der Ingenieur ist der Universalist
Natürlich nicht - deswegen gibt es eben auch verschiedene Studiengänge,
die den Ingeneur als Abschluß haben.
Ein Bauingenieur ist genauso Spezialist wie ein Chemiker, Physiker oder
eben auch Informatiker.
> Eine ganz andere Geschichte ist ja das die meissten Informatiker> schlicht als Programmierer arbeiten - was aber nur ein Facharbeiterberuf> ist.
Ja, da arbeiten sie leider weit unter ihren Möglichkeiten - so wie auch
nicht alle E-Techniker als Entwickler arbeiten.
Als Vertriebler arbeitet auch der unter seinen Möglichkeiten.
Das mit dem "der Ingenieur ist Anwender" passt schon ganz gut.
Chris D.
Je universeller der eigene Anspruch, desto näher kommt man dem
ultimativen Ziel dieser Reise, dem Theologen. Der hat von nix eine
Ahnung, ist aber mit dem selbstverständlichen Anspruch gesegnet, überall
mitreden zu dürfen.
horst schrieb:> Ein Informatiker nimmt einen Industrie-PC um 300 Euro, eine> Motorsteuerung um 100 Euro, installiert eine relationale Datenbank,> schreibt ein kleines Programm und löst das Problem damit in 3 Tagen.>> Der Elektrotechniker nimmt einen 8-bit µC, ein paar Transistoren, ...> und löst das Problem in 3 Monaten mit einer Platine, die in der> Serienfertigung 20 Euro kostet.
Ok, rechnen wir doch mal nach, mit einem angenommenem Stundensatz von
60€ für beide (ich weiß ein echte Ingenieur steht für unter 120€/h nicht
auf, das ignorieren wir hier mal ;)
1
Inf
2
---
3
Personalkosten: 3d * 8h * 60€ = 1440€
4
Entwicklungskosten: 10eur für Versand der fertigen Baugruppen an den Entwickler
5
Hardwarekosten: 400eur / Stück
6
7
Ing
8
---
9
Personalkosten: 3m * 4w * 5d * 8h * 60€ = 28800€
10
Entwicklungskosten: 1200€ für Prototypen Platine, Bauteile etc...
11
Hardwarekosten: 20 eur / Stück (in Serie)
12
13
14
Die Firma möchte eine Kleinstserie von 20 Stück produzieren um die Kundenaktzeptanz anhand eines Ausgewählten Publikums prüfen.
Der Test wird ein totaler Flop, das Projekt wird eingestampft
24
[Ende] Zeit Ing-Inf = 87 Tage, Kosten Ing-Inf = 21150€
25
Best Case:
26
Totale Begeisterung --> es geht weiter
27
28
Natürlich soll vor der Serienproduktion noch dies und das angepasst werden und es hat sich gezeigt, dass feature X noch unbedingt rein muß, der Aufwand ergibst sich zu 10% des ursprünglichen Umfangs
29
Inf: +1d (den rest des Tages trinkt der Inf Kaffe oder macht früher Schluss) = 60€
30
Ing: +6d = 360€ + 440€ für neuen Prototypen
31
32
Worstcase: Es stellt sich heraus das die neue Anforderung nicht mit dem altem System umsetzbar ist, ein komplettes Redisgn ist erforderlich
33
Inf: 1440€ + 560€ (bessere HW+Versand)
34
Ing: 28800€ + 2200€ (neue Devboard, neue Prototypen...)
35
Bestcase: Alles geht gut.
36
37
Kosten (worst case):
38
Inf: 9450€ + 60€ + 2000€ = 11510 €
39
Ing: 30600€ + 800€ + 31000€ = 62400 €
40
Vergangene Zeit:
41
Inf: 3d * 2 = 6d
42
Ing: 90 * 2 = 180d
43
44
Nun ist es aber endlich soweit eine Serienproduktion soll vom Band laufen:
45
Ing: Hat nix zu tun
46
Inf: Das muß für 20€ gehen...
47
48
Da nun die Anforderungen feststehen und die Programmlogik bekannt ist sowie die Datenstrukturen und Algorithmen bereits vorliegen wird 50% weniger Zeit für eine Umsetzung auf einem MC benötigt:
49
Inf Extra Kosten: 28800€ / 2 = 14400 €
50
Inf Extra Zeit: 90 Tage / 2 = 45 Tage
51
52
Ergebnis:
53
=========
54
Inf Bestcase:
55
Zeit: 3 + 1 + 45 = 49 Tage
56
Kosten: 9450€ + 60€ + 14400€ = 23910 €
57
Inf Worstcase:
58
Zeit: 3 + 1 + 3 + 45 = 52 Tage
59
Kosten: 9450€ + 60€ + 2000€ + 14400€ = 25910 €
60
61
Ing Bestcase:
62
Zeit: 90 + 5 + 2 (Wochenende) + 1 = 98 Tage
63
Kosten: 28800€ + 800€ = 29600€
64
Ing Worstcase:
65
Zeit: 90 + 5 + 2 (Wochenende) + 1 + 90 = 188 Tage
66
Kosten: 28800€ + 800€ + 31000€ = 60600€
> Welche Lösung ist denn jetzt die bessere?
Im Bestcase hat der Inf die Aufgabe in der Hälfte der Zeit für etwa
gleiche Kosten gelöst.
Im Worstcase hat der Inf die Aufgabe in der Hälfte der Zeit für die
Hälfte der Kosten gelöst.
Allen weiterhin frohes schaffen und keep smiling ;)
Einhart Pape schrieb:> Als Informatikingenieur sitzt man ja voll zwischen den Stühlen ;-)
Nein, da hast du das Wort "Ingenieur" mit in deiner Berufsbezeichnung.
Genau das fehlt einem Großteil der hier herumlabernden, und das kratzt
gewaltig an Ihrem Selbstbewusstsein.
Daß es auf das Können ankommt und nicht auf den Titel, und daß es in
beiden Ausbildungszweigen Gute und Looser gibt hatte ich oben schon mal
angemerkt, aber wie da schon gesagt: Wer hier so platt pauschalisiert
gehört in der Beziehung wahrscheinlich eh zum Bodensatz.
ich brauche neues Popcorn!!!
Zuckerle schrieb im Beitrag #2388488:
> Ich sehe den Ingenieur in erster Lienie als Anwender. Nicht alle> Ingenieure arbeiten auch als Entwickler. So gesehen ist z.b. die> Mathematik oder die Physik für den Ingenieur ein Werkzeug und keine> Offenbarung!
ROFL,
gut ein Drittel aller Informatiker, die ich kenne arbeiten im Vertrieb!
Läubi .. schrieb:> Im Bestcase hat der Inf die Aufgabe in der Hälfte der Zeit für etwa> gleiche Kosten gelöst.> Im Worstcase hat der Inf die Aufgabe in der Hälfte der Zeit für die> Hälfte der Kosten gelöst.
Hallo Läubi,
du hast den Fall vergessen, daß das teil der Renner wird und 20000 mal
verkauft wird.
Lösung Ing.:
Klein, für 30€ zu produzieren, nimmt kaum Platz weg, hält locker die
angedachten 10J in einem Produktionsumfeld (Staub, Öl, etc)
Lösung Inf.:
PC, kostes ca 150€ pro Stück Zukauf.
Nach 2-6 Jahren ist bei 20% die Platte hin, Austauch auf teure SSD auf
Kosten der eigenen Firma. (Pro Stück mit Techniker Anreise und Zeit
Kosten:
500€)
Außerdem muss ein Staubschutz nachgerüstet werden und die Tastatur
teilweise ausgetauscht weil nicht resistent gegen die agressiven Stoff
in manchen Produktionsbetrieben. Kosten bei 10% aller gelieferten Geräte
300€
Kosten über alles
Ing:
20000 * 30 = 600.000 Plus einige Ausfälle (5% Austausch Technikereinsatz
a 400€) = 400.000 = Gesamt: 1.000.000
Inf:
3.000.000 + 1.000.000 + 600.000 = 4.600.000
Ausserdem ist das Renommee bei den Kunden weg, weil die Konkurrenz ein
zuverlässigeres und wesentlich kleineres Gerät (mit µC) anbietet.
(Alleine die Stromrechnung der PCs bei 24h pro tag, 6 tage die Woche und
10 Jahre....
Und schon sieht die Rechnung gaaanz anders aus.
:-)))
Popcorn, Bieeer...
p.s.
Ihr habt gerade gemerkt, ich habe auch mal pauschalisiert, wollte mich
dem Niveau hier anpassen wie Läubi wohl auch :-)
Läubi .. schrieb:> Allen weiterhin frohes schaffen und keep smiling ;)
Genau
Udo Schmitt schrieb:> Und schon sieht die Rechnung gaaanz anders aus.
Ich habe einberechnet das das finale Produkt mit einem uC auf
"Ing-Weise" umgesetzt wurde indem Ing+Inf (möglicherweise)
zusammenarbeiten, es kommt also das gleiche Produkt raus.
Udo Schmitt schrieb:> Popcorn, Bieeer...
Informatiker essen eh nur kalte Pizza :P
Chris D. schrieb:> Michael Lieter schrieb:>> Der Informatiker ist doch einfach nur höher spezialisiert.>>>> Es ist ein Teilgebiet des Wissens eines Ingenieurs.>> So wie die Elektrotechnik ein Teilgebiet des Physikers ist :-)
Das ja, nur hat der Physiker keine Ahnung von Chemie - da fehlt zum
Universalisten schon mal eine Menge.
Im Gegenteil ist Physik aber Teilgebiet für einen Ingenieur.
Chris D. schrieb:> Als Vertriebler arbeitet auch der unter seinen Möglichkeiten.
Vertrieb ist auch nicht einfach - denn überzeugend reden, argumentieren
und Sachverhalte darstellen zu können, ist nicht einfach - da man die
Leute richtig einschätzen muss, was man ihnen erzählen kann.
Die meissten Ingenieure können das in der Tat nicht - da werden Sie von
der kleinen blonden 22jährigen Bankangestellten an die Wand gespielt.
(Anders ist das nicht zu erklären, das technisch hoch gebildete Leute
schwachsinnige Verträge in Masse unterschreiben)
>> Das mit dem "der Ingenieur ist Anwender" passt schon ganz gut.
Das wird heute für die meissten zutreffen - die Idee des Ingenieurs ist
aber die des Baumeisters, der die Spezialisten koordiniert und dabei
genug von der Materie versteht um allen auf die Finger zu klopfen.
Um dahin zu kommen, benötigt man sicher Erfahrung.
Michael Lieter schrieb:> Im Gegenteil ist Physik aber Teilgebiet für einen Ingenieur.
-aber sehr begrenzt. Mal ehrlich: 80% von dem, was ein Ingenieur über
echte Physikthemen weiss, (Mathe und E-Technik abgezogen) kennt er vom
Abitur.
Anton Hirtmann schrieb im Beitrag #2389470:
> Ingenieure sind für die übergeordneten Planungsarbeiten am besten> geeignet, die Fleißarbeit kann man dann locker den Informatikern> überlassen.
(1) - die meisten Informatiker werden Dir darauf ordentlich was husten
(2) - kenne ich exakt diese Aussage anders herum
(3) - klingt eine Aussage, die ich als Informatiker (Mist, verraten) von
Konstrukteuren oft zu hören bekomme, spontan in meinen Ohren nach: "Die
Mechanik kann möglicherweise in kritische Zustände geraten, aber das
kann man ja leicht in der Software lösen."
Michael Lieter schrieb:> Chris D. schrieb:>> Michael Lieter schrieb:>>> Der Informatiker ist doch einfach nur höher spezialisiert.>>>>>> Es ist ein Teilgebiet des Wissens eines Ingenieurs.>>>> So wie die Elektrotechnik ein Teilgebiet des Physikers ist :-)>> Das ja, nur hat der Physiker keine Ahnung von Chemie - da fehlt zum> Universalisten schon mal eine Menge.
Das bestreite ich auch gar nicht. Ich bezog mich auf Deine Aussage:
Michael Lieter schrieb:> Der Ingenieur ist der Universalist - der Vergleich ist insofern> unsinnig.> Im Gegenteil ist Physik aber Teilgebiet für einen Ingenieur.
Aber eben auch nur sehr beschränkt - und noch beschränkter (bis gar
nicht vorhanden) ist dieses Teilwissen in der Chemie.
Ich denke, ich kann das ganz gut beurteilen, weil ich schon Jahre mit
Ingenieuren in diesem Bereich zu tun habe.
Die E-Techniker vor Ort haben wenig bis kein Wissen darüber - aber das
ist auch nicht schlimm: dafür gibt es ja dann uns Externe, die man
dazuholt und die sich damit auskennen.
Dafür sind die E-Techniker dort eben Regelungstechnik-Götter (oder
ähnlich) :-)
Deswegen bricht keinem Ing eine Zacke aus der Krone, denn er hat ja eine
ganz andere auf :-)
Die Zeit des Universalisten ist meiner Meinung schon lange vorbei -
dafür gibt es viel zu viele Felder (gerade in der Chemie) , die
jahrelanger Einarbeitung bedürfen, nur um halbwegs Grundlagen zu haben.
> Chris D. schrieb:>> Als Vertriebler arbeitet auch der unter seinen Möglichkeiten.>> Vertrieb ist auch nicht einfach - denn überzeugend reden, argumentieren> und Sachverhalte darstellen zu können, ist nicht einfach - da man die> Leute richtig einschätzen muss, was man ihnen erzählen kann.> Die meissten Ingenieure können das in der Tat nicht - da werden Sie von> der kleinen blonden 22jährigen Bankangestellten an die Wand gespielt.> (Anders ist das nicht zu erklären, das technisch hoch gebildete Leute> schwachsinnige Verträge in Masse unterschreiben)
Möglich. Vertrieb ist - wie Du schreibst - auf jeden Fall etwas, das man
kann oder nicht. Das kann man meiner Meinugn nach auch nicht lernen.
Man muss sehr gute Menschenkenntnis haben. Dazu kommt dann noch das
entsprechende Wissen.
Erstaunlicherweise haben bisher alle Vertriebler, die ich als sehr gut
bezeichnen würde, eine "normale" Ausbildung durchlaufen - keiner von
denen war auf einer Uni.
Auf jeden Fall ist der Vertriebler einer der wichtigsten Köpfe im
Unternehmen. Er sistzt genau an der Schnittstelle zum Kunden und erfährt
dort in Gesprächen mehr zwischen als in den Zeilen.
Umso dämlicher, wenn die Geschäftsführung nicht auf diese hört (mehrfach
erlebt).
>> Das mit dem "der Ingenieur ist Anwender" passt schon ganz gut.>> Das wird heute für die meissten zutreffen - die Idee des Ingenieurs ist> aber die des Baumeisters, der die Spezialisten koordiniert und dabei> genug von der Materie versteht um allen auf die Finger zu klopfen.> Um dahin zu kommen, benötigt man sicher Erfahrung.
Das ist ähnlich wie bei uns Infos.
Eigentlich führt ein Informatiker ein Team aus anderen Leuten. Er ist
der Baumeister, der seine Horde Programmierer einnordet und die Richtung
vorgibt. (Böse Blicke hab ich mal in einer Messtechnik-Vorlesung
geerntet, als nach einer herablassenden Bemerkung des E-Technik-Profs
über Infos ich meinen Mund bei der nächsten Gelegenheit nicht halten
konnte und auf "das wird dann entsprechend programmiert" mit "dafür hat
man doch seine E-Techniker" antwortete. ;-)
Die Realität sieht aber hüben wie drüben natürlich anders aus: da wird
viel Wissen verschenkt.
Die meisten Ings und Infos erledigen recht stupide Arbeiten - sie sind
eher Maurer als Baumeister.
(Ein Grund mehr, sich selbstständig zu machen)
Chris D.
Das die Informatiker keine Vorlesung nzw. Einführung in die
Regelungstechnik haben, ist seht seltsam. Vielleicht deswegen ein
Informatiker ist kein Ingenieur. Genau, warum die Informatik eigentlich
ist kein Ingenieurwissenschaft?
BTW: Vertrieb, supplier quality management, Einkauf....das sind die
besten Jobs, um eine Karriere zu starten und nicht die Entwicklung. Dort
wird am besten verdient.
Termos27 schrieb:> Das die Informatiker keine Vorlesung nzw. Einführung in die> Regelungstechnik haben, ist seht seltsam. Vielleicht deswegen ein> Informatiker ist kein Ingenieur.
Ich weiss nicht, wie es heute ist, aber damals musste man ein Nebenfach
studieren.
Bei mir war das E-Technik und da gab es natürlich auch Regelungstechnik,
Systemtheorie usw., die zwingend zu belegen waren.
Chris D.
die Frage ist die, ob ein Informatiker so eine Vorlesung wie
Regelungstechnik braucht. Meiner Meinung nach schon, aber diese
Vorlesung wird für Informatiker sehr selten angeboten....niemand weißt
aber warum.
Termos27 schrieb:> Dem Frager wurde auch so geantwortet:> "Im technischen Entwicklungsumfeld tun sich Firmen schwer, Informatiker> einzustellen. Ein Hauptgrund ist nach unserer Erfahrung der fehlende> technische Bezug etwa in der Automobilelektronik oder bei> Maschinensteuerungen."> Das heißt auch, dass ein Informatiker ist nicht qualifiziert, um solche> Tätigkeiten auszuüben aber ein Ingenieur kann ohne Probleme Software> entwickeln (z.B. auch bei SAP, Oracle usw.). Dann wozu braucht man> Informatiker......
Das liegt ganz einfach daran, weil die nicht wissen, was ein
Informatiker ist. Die setzen Informatiker mit Programmierer gleich,
dabei ist ein Informatiker mehr.
Ich täte mich auch eher schwer in einem technischen Umfeld, habe ich
doch nur wenig Ahnung von Regelkreisen und ich täte mich schwer mit
Analogtechnik, trotz Nebenfach Elektrotechnik. Aber was die
Digitaltechnik angeht, bin ich fit und könnte auch mit VHDL Hardware
entwerfen. Sobald es aber darum geht, anspruchsvolle Algorithmen
umzusetzen, sind Informatiker unerlässlich. Von theoretischer Informatik
haben Elektrotechniker, die ja genauso die Programmierstuben besetzen,
null Ahnung, weil es in deren Studiengängen nicht vorkommt. Und sollten
die Nebenfach Informatik gehabt haben, dann war das genauso schmalspurig
wie mein Nebenfach Elektrotechnik.
Ein Hauptproblem sehe ich darin, dass viele Entscheider und Vorgesetzte
nicht wissen, was Informatik alles ausmacht und dann bleibt viel
Potential ungenutzt. Approximationsalgorithmen, Fuzzy-Logik,
Reinforcement Learning, neuronale Netze, lineare Programmierung,
semidefinite Programmierung, logische Programmierung... es gäbe so viele
Möglichkeiten, bestimmte Probleme zu lösen, die in der Realität wirklich
vorkommmen, aber als Informatiker ist man ja nur ein "hauptamtlicher
Programmierer".
Robocash schrieb:> Das Arbeitsamt gibt die Arbeitslosenzahl der Informatiker mit 4,4% und> die Arbeitslosenzahl der Elektroingenieure mit 2.7% an.
Da sollte man sich nochmal genauer informieren. Der Elektroingenieur ist
dem Namen nach ein Akademiker, also Diplom-Ingenieur, Bachelor oder
Master der Elektrotechnik. Ein Informatiker kann aber sowohl
Diplom-Informatiker sein als auch Fachinformatiker. Letzere können wenig
Programmierer sein oder aber Admins und als Lehrberuf rangiert so einer
weit unterhalb des Diplom-Informatikers.
WasSollDas? schrieb:> Den Thread kann man auch schließen.>> (FH-)Ingenieure plappern hier ihre (unhaltbaren) Vermutungen aus. (Uni)> Informatiker lachen sich schrott und jeder hat den Längsten - meint er> zumindest.>> Inhaltlich wertlos der Käse hier.
Ich kenne sowohl Elektrotechniker von der FH als auch welche von der TU.
Da bestehen himmelsweite Unterschiede. Mir ist auch schon einer über den
Weg gelaufen, der weder Galliumarsenid und noch das Bonmot dazu kannte:
Galliumarsenid war immer der Halbleiter der Zukunft und wird es immer
bleiben.
Anton Hirtmann schrieb im Beitrag #2385362:
> Im technischen Umfeld (anspruchsvolle Automatisierungstechnik) habe ich> ehrlich gesagt noch nie einen Informatiker gesehen. Alles lauter> Ingenieure. Kann mir das bitte jemand erklären. Vielleicht hängt es> damit zusammen, daß Ingenieure Software nicht als Selbstzweck sondern> als Mittel zum Zweck ansehen, mit dem Probleme gelöst werden. Ingenieure> sind eben nicht mit der Software "verheiratet" und könnten auch ohne> weiteres stattdessen Hardware einsetzen wenn es die Anforderungen> notwendig machen.
Informatiker sehen Software auch nicht als Selbstzweck. Schon mal
darüber nachgedacht, dass die Informatiker nur länger über Software
nachdenken, weil sie Dinge sehen, für die ein Elektrotechniker keinen
"Draht" hat:
1. Laufzeitverhalten
2. Korrektheit
3. Robustheit
4. Testbarkeit
5. Wiederverwendbarkeit
Vor "Pragmatiker" muss sich schützen, denn Pragmatiker sehen
"Copy'n'Paste" als pragmatisch an, anstatt eine Funktion ordentlich zu
implementieren und wiederzuverwenden, denn bei "C'n'P" kopiert man
fehlerhaften Code mit. Der Informatiker ist dafür eher sensibilisiert.
Michael Lieter schrieb:> Der Informatiker ist doch einfach nur höher spezialisiert.>
Unfug. Der Informatiker ist der größere Generalist. Informatik ist
sowohl eine Wissenschaft als auch eine Ingenieursdisziplin. In der
Informatik wird Mathematik nicht nur aktiv angewandt, sondern auch
erweitert; die ganze theoretische Informatik aus der Mathematik
erwachsen. Als man die angewandte Mathematik einführte, schuf man den
Begriff "reine Mathematik", um die ursprüngliche Mathematik von der
angewandten zu unterscheiden. Die der Komplexitäts- und
Berechenbarkeitstheorie wurde scherzhaft als "abgewandte Mathematik"
bezeichnet, weil zu abgehoben war. Daraus hat sich die theoretische
Informatik entwickelt.
Über die technische Informatik hat man noch starke Anknüpfungspunkte zu
Elektrotechnikern, aber sonst ist die Informatik sehr schon ein eigenes
Ding. Der Elektrotechniker hat nur kaum Vorstellung davon, was der
Informatiker so alles lernt, genausowenig wie der Informatiker nicht die
Phantasie aufbringt, was die Elektrotechnik alles umfasst. Meiner
Erfahrung nach ist das Feld des Elektrotechnikers enger gesteckt.
> Es ist ein Teilgebiet des Wissens eines Ingenieurs.>> Wie auch Chemie, Mathematik, Mechanik, Elektronik usw..>> Ich hab neulich mal Prüfungen für Elektroniker lesen dürfen - na Hut ab.>
Elektrotechniker machen mehr Initesimalrechnung. Hatte ich auch intensiv
im Grundstudium durchgepaukt, aber danach kaum noch, sodass meine
Fähigkeiten darin etwas verkümmerten. Informatiker machen dafür mehr
Beweistechniken, Logik, Algebra und Wahrscheinlichkeitsrechnung. Wenn
Sie eine Klausur für Informatiker läsen, könnte Ihnen genauso der Hut
hochgehen.
> Der Ingenieur ist der Universalist - der Vergleich ist insofern> unsinnig.>> Eine ganz andere Geschichte ist ja das die meissten Informatiker> schlicht als Programmierer arbeiten - was aber nur ein Facharbeiterberuf> ist.
Wenn das Potential falsch genutzt wird... Das Potential der
Elektrotechniker wird wahrscheinlich auch nicht genutzt. Bei der
Informatik ist es nur so, dass die Informatik jünger ist und viele Leute
falsche Vorstellung von Informatik haben. Einige glauben sogar,
Informatik an der Uni wäre ein Computerzusammenschraubstudium.
Ich finde diese Diskussion hier etwas albern. Man muss einfach
akzeptieren, dass Elektrotechniker und Informatiker was verschiedenes
sind und dass Informatiker mehr als nur Programmierer sind. Die falschen
Vorstellungen können nur daher kommen, dass Elektrotechniker nebenbei
auch noch programmieren und in Programmierberufen landen und glauben,
sie machten Informatik.
Anton Hirtmann schrieb im Beitrag #2392548:
> Es ist sicherlich so, daß ein Informatiker vor allem in Richtung> theoretischer Informatik mehr drauf hat. Die Frage ist aber, ob man> diese Kenntnisse in der Praxis wirklich braucht oder ob diese> Fähigkeiten nur in der Forschung benötigt werden. Die meisten Firmen> können es sich eben nicht leisten, so lange an der Software zu schreiben> bis sie 100% perfekt ist. Daher muß man eben häufig pragmatisch> vorgehen, ansonsten wird man von der Konkurrenz überholt.
Sind Approximationsalgorithmen etwa die Suche nach dem "perfekten
Programm"? Ich habe oft gehört bekommen, ich solle nicht die perfekte
Lösung anstreben, obwohl ich das nie vorhatte. Die Leute hören einfach
nicht zu. Ich hatte sogar mal einen Neunmalklugen FH-Ingenieur vor mir,
der mir sagte, viele Probleme lassen sich nicht perfekt lösen, weshalb
ich mir nicht den Kopf zerbrechen solle. Da guckste als Informatiker
erstmal blöde. Man will ja auch nicht frech werden und hält lieber die
Klappe. Ohne Nachdenken geht's halt nicht. Man muss nachdenken darüber,
was die Eingabegröße ist, ob es einen schnellen, deterministischen
Algorithmus gibt, der das Problem perfekt löst (Güte 1), oder ob man auf
ein anderes Verfahren umsteigt, z. B. Approximationsalgorithmen und
wenigstens ein Ergebnis einer bestimmten Güte garantieren kann. Das ist
das täglich Brot des Diplom-Informatikers.
+ Hochschulinformatiker sind 4,4% arbeitslos, Fachinformatiker sind mehr
arbeitslos (irgendwas mit 5%).
+ Wenn der ING den INF sticht (vielleicht mit dem OSZI-Messkabel), dann
muss der INF den ING mit dem Bithämmerchen zurückschlagen.
+ Das Ergebnis von z=e_hoch_jot_mal_phi ist eine komplexe Zahl. Wie kann
ich von z auf phi zurückrechnen und es in einem mit der TAYLOR-Reihe
approximieren? Es soll keine Fallunterscheidung gemacht werden.
Anton Hirtmann schrieb im Beitrag #2392553:
> Informatiker schrieb:>>> Informatiker sehen Software auch nicht als Selbstzweck. Schon mal>> darüber nachgedacht, dass die Informatiker nur länger über Software>> nachdenken, weil sie Dinge sehen, für die ein Elektrotechniker keinen>> "Draht" hat:>>>> 1. Laufzeitverhalten>> 2. Korrektheit>> 3. Robustheit>> 4. Testbarkeit>> 5. Wiederverwendbarkeit>>>> 1. Laufzeitverhalten> Die Komplexität muß man ungefähr abschätzen können (konstant, linear,> exponentielle etc.) und dann die richtigen Datenstrukturen verwenden.> Das ist aber keine Raketenwissenschaft. Trotzdem kann man dabei übers> Ziel hinausschiessen. Ein Informatiker hat z.B. in der Software mal eine> Baumstruktur mit O(log N) durch eine Hashtabelle ersetzt (Best case:> O(1)). Leider war die Hashfunktion falsch gewählt so daß unter> bestimmten Umständen O(N) dabei herauskam. Die Software ist also dadurch> "verschlimmbessert" worden.>
Sie wissen nicht viel von der Komplexität einer Software. Es geht
mitnichten nur um Datenstrukturen.
> 2. Korrektheit> Das sieht man wenn es läuft>
Korrektheit kann man beweisen. Schonmal was vom Hoare-Kalkül gehört? Es
ist ein Unterschied, ob etwas augenscheinlich korrekt läuft oder ob es
bewiesen richtig läuft.
> 3. Robustheit> Kann man sinnigerweise nur unter Praxisbedingungen simulieren, d.h. Last> auf die Anwendung geben.>
Softwaredesign kann von vornherein auf Robustheit ausgelegt sein oder
nicht.
> 4. Testbarkeit> Unit Tests sind doch Standard>
Unit-Tests sind aber weder der Anfang noch das Ende des Liedes. Außerdem
müssen die Algorithmen so geschrieben sein, dass man sie auch
entsprechend schnell und klug testen kann.
> 5. Wiederverwendbarkeit> Auch kein Hexenwerk. Bei vier Identischen Stellen sollte man über eine> generische Lösung nachdenken.
Nein, bei drei Stellen. Und identisch müssen die auch nicht sein,
sondern ähnlich. Ich kenne Elektrotechniker, die es hinbekommen, Klassen
mit 3000 Zeilen zu programmieren, darunter sind dann ellenlange
Methoden. Ich hätte das definitiv anders programmiert und auch auf
Wiederverwendung geachtet und diese auch angewandt. Ich schreibe
kompaktere Programme.
Anton Hirtmann schrieb im Beitrag #2392561:
> Aber in der Praxis interessiert es doch keinen ob die Lösung perfekt> oder nur optimal ist. Als Analogie stelle man sich z.B. einen Bäcker> vor, der auf der Suche nach der "perfekten Semmel" nicht mehr zum Backen> kommt und alle "nicht-perfekten Backwerke" in den Abfall wirft. Dem> Kunden ist das völlig egal, der will einfach nur sein Brötchen haben und> basta.>> Genauso ist es mit der Software. Kein Mensch kann auf eine 100% perfekte> Software warten. Diese wäre nämlich viel zu teuer. Software ist ein> Gebrauchsartikel wie alles andere auch. Sie muß für einen bestimmten> Zeitraum ihren Zweck erfüllen und dann wird etwas anderes angeschafft.> Darauf basiert das gesamte Wirtschaftssystem.
Das ist doch wieder so ein Blödsinn. Niemand strebt 100 % fehlerfreie
Software an. Sie sind wie der FH-Ingenieur, der mir seine Plattheiten
entgegenschleuderte, man könne keine perfekte Software schreiben. Habe
ich nie behauptet. Nichtsdestoweniger sollte man sollte man die Flinte
nicht ins Korn werfen (wie Sie vorschlagen) und trotzdem nach 0 Fehlern
streben. Und da gibt es Methoden, die in der Informatik erforscht
werden.
Dass niemand auf eine perfekte Software warten kann, ist genauso eine
Platitütde. Sie tun ja gerade so, als hätten Sie gerade den Stein des
Weisen entdeckt. Der Weg zur Software, wie sie spezifiziert ist, ist ja
schon steinig genug und oft genug werden IT-Projekte überzogen, weil man
"praktisch" denkt und theoretische Informatik geradezu verteufelt. Das
ist meine Erfahrung innerhalb von zehn Jahren Berufstätigkeit.
Anton Hirtmann schrieb im Beitrag #2392597:
> Ellenlange Methoden sind natürlich Banane und deuten darauf hin daß> diese Routine zu vieles macht.
Ein Informatiker schreibt meiner Erfahrung nach viele kleine Methoden,
gerade dann, wenn er auch viel mit funktionaler Programmierung am Hut
hatte.
Eine häufig gesehenes Antipattern ist auch eine Kaskade von
Punkt-Operatoren.
Sie haben ein Object a und rufen auf:
a.getB().getC().getD().getE();
Das verletzt das "Gesetz" von Demeter. Gesetz ist in Anführungszeichen,
weil es mehr eine Empfehlung ist, die man aus der adaptiven
Programmierung übernommen hat. Hier könnte Ihnen jetzt an vier Stellen
eine NullPointerException um die Ohren fliegen
Sie könnten schreiben:
1
if (a!=null && a.getB()!=null && a.getB().getC() != null ...) {
Anton Hirtmann schrieb im Beitrag #2392627:
> Warum nicht gleich ein "Empty Objekt" definieren, daß statt einer Null> übergeben wird? Dann könnte es nie zu einer NullPointerException kommen.
Weil das "NullObject" wieder für Chaos sorgt. Ist zwar eine feine Sache,
aber wenn man etwas automatisch persistieren will, ist es wieder
störend. Außerdem scheinen gerade Nichtinformatiker damit Probleme zu
haben. Außerdem kann man nicht immer ein standardisiertes
"Null"-Verhalten definieren.
Anton Hirtmann schrieb im Beitrag #2392597:
>>> 2. Korrektheit> Noch nie gehört. In der Praxis auch noch nie benötigt.
Man verwendet in der Praxis also Algorithmen von denen man weder weiß ob
sie überhaupt terminieren, noch ob sie überhaupt das richtige Ergebnis
liefern? Das erklärt einiges.
> Anscheinend geht es dabei aber lediglich um Assertions (also bekannt)
Weil der Begriff Assertion in der Beschreibung vorkommt?
http://en.wikipedia.org/wiki/Hoare_calculus
SMT (satisfiability modulo theories), ATP (automatic theorem prover)
oder Typentheorie gehören auch noch dazu, um mal einige Begriffe zu
nennen.
>>> 3. Robustheit> Ein modularer Aufbau sollte doch Standard sein
Robustheit bezeichnet auch eine Eigenschaft von numerischen Algorithmen
(dort häufiger Stabilität genannt), ebenso sind damit (formale) Methoden
des Testens gemeint (z.B. Fuzzing) bzw. die Eigenschaft der Software
stabil bei nicht vorhersehbaren Eingaben/Zuständen zu laufen.
>>> 4. Testbarkeit> Schon wieder Algorithmen. In der gängigen Unternehmenssoftware gibt es> aber kaum irgendwelchen komplexen Algorithmen.http://de.wikipedia.org/wiki/Unternehmenssoftware
Nur mal ERP oder CAM nehmen und eine Liste der "trivialen" Algorithmen
aufstellen.
Informatiker schrieb:> Informatik ist> auch eine Ingenieursdisziplin
Hört Hört!
Informatiker schrieb:> Elektrotechniker machen mehr Initesimalrechnung
Soso, tun sie das.
Sag mal, was rauchst du?
Das hört sich hier so an, als ob ein paar Blinde sich über die
Nutzlosigkeit eines Optikers auslassen ;-)
Macht doch bitte mal ein Informatik Studium (Uni) und dann sprechen wir
weiter. Ich würde mich niemals erdreisten zu behaupten es bräuchte
keinen E-Ing. oder sonst was, nur weil ich selber auch ein paar
Schaltungen entwerfen kann. Das ist doch voll Banane, wieso macht ihr
euch intellektuell hier so nackig? Das zeugt doch nur von maßloser
Selbstüberschätzung.
gruß cyblord
Julian V. schrieb:> Das hört sich hier so an, als ob ein paar Blinde sich über die> Nutzlosigkeit eines Optikers auslassen ;-)>> Macht doch bitte mal ein Informatik Studium (Uni) und dann sprechen wir> weiter. Ich würde mich niemals erdreisten zu behaupten es bräuchte> keinen E-Ing. oder sonst was, nur weil ich selber auch ein paar> Schaltungen entwerfen kann. Das ist doch voll Banane, wieso macht ihr> euch intellektuell hier so nackig? Das zeugt doch nur von maßloser> Selbstüberschätzung.>> gruß cyblord
Das sehe ich genauso.
Termos27 schrieb:> die Frage ist die, ob ein Informatiker so eine Vorlesung wie> Regelungstechnik braucht. Meiner Meinung nach schon, aber diese> Vorlesung wird für Informatiker sehr selten angeboten....niemand weißt> aber warum.
Natürlich weiß man warum:
Eine Vorlesung in Regelungstechnik kann man nicht sinnvoll hören, ohne
die entsprechenden Grundlagen in Mathematik (z.B. Rechnen mit komplexen
Zahlen, Laplace-Transformation), Systemtheorie und in diesem Fall auch
Elektrotechnik zu haben (wenn jemand keine Funktionsgleichung für einen
RC-Tiefpass aufstellen kann, was will der dann mit Regelungstechnik?).
All das zusammen ist aber wesentlich mehr als ein Nebenfach. Und eben
weil es in der Summe so einen großen Umfang hat, haben es die meisten
Informatik-Studiengänge nicht in ihrem Pflichtprogramm.
Informatiker schrieb:> Korrektheit kann man beweisen. Schonmal was vom Hoare-Kalkül gehört? Es> ist ein Unterschied, ob etwas augenscheinlich korrekt läuft oder ob es> bewiesen richtig läuft.
Und in wie vielen realen Software-Projekten wird dies angewandt? ;-)
Mark Brandis schrieb:> Eine Vorlesung in Regelungstechnik kann man nicht sinnvoll hören, ohne> die entsprechenden Grundlagen in Mathematik (z.B. Rechnen mit komplexen> Zahlen, Laplace-Transformation), Systemtheorie und in diesem Fall auch> Elektrotechnik zu haben (wenn jemand keine Funktionsgleichung für einen> RC-Tiefpass aufstellen kann, was will der dann mit Regelungstechnik?).>> All das zusammen ist aber wesentlich mehr als ein Nebenfach. Und eben> weil es in der Summe so einen großen Umfang hat, haben es die meisten> Informatik-Studiengänge nicht in ihrem Pflichtprogramm.
Also wir hatten das alles im Nebenfach: Regelungstechnik, Systemtheorie,
Theorie der Wechselströme usw.
Komplexe Zahlen hat man selbstverständlich schon in Mathe I+II gehabt,
spätestens in der Algebra schlagen die sowieso wieder verschärft ein ;-)
Zumindest damals war das so.
Chris D.
P.S.:
Übrigens mal für die E-Techniker: Laplace-Transformierte benötigt der
Info weniger für den E-Technik-Teil als für Warteschlangentheorie :-)
Mark Brandis schrieb:> Informatiker schrieb:>> Korrektheit kann man beweisen. Schonmal was vom Hoare-Kalkül gehört? Es>> ist ein Unterschied, ob etwas augenscheinlich korrekt läuft oder ob es>> bewiesen richtig läuft.>> Und in wie vielen realen Software-Projekten wird dies angewandt? ;-)
Überall dort wo Software Sicherheitsrelevant ist (Luft und Raumfahrt,
Medizintechnik usw.). Nur weil ihr Software als ein paar C# Business
Anwendungen und poplige µC Programme definiert heißt das noch lange
nicht dass dies der Aufgabenbereich eines Informatikers ist.
Und das ewige Rumreiten auf euerer tollen Regelungstechnik ist auch
langsam mal lächerlich. Nur weil das mal ein Bereich ist wo ihr ein
bisschen kompliziertere Theorie habt? Im ganzen Info Studium hat man
solchen komplexen theoretische Shit zu hauf.
Dieser Thread wirft wirklich kein gutes Licht auf die Ingeneuere im
allgemeinen. Es ist eher peinlich.
Julian V. schrieb:> Dieser Thread wirft wirklich kein gutes Licht auf die Ingeneuere im> allgemeinen. Es ist eher peinlich.
Peinlich ist hier nur wie viele minderwertigkeitsbehaftete Infs und Ings
sich ihren Frust auf die eigene Unzulänglichkeit mit pauschalem Bashing
einer anderen Studiengruppe abreagieren.
Wer in dem Thread ernsthaft schreibt gehört wohl zu den schlechten Infs
und Ings.
Leute ich werd noch fett hier bei soviel Popcorn und Bier .....
Udo Schmitt schrieb:> Julian V. schrieb:>> Dieser Thread wirft wirklich kein gutes Licht auf die Ingeneuere im>> allgemeinen. Es ist eher peinlich.> Peinlich ist hier nur wie viele minderwertigkeitsbehaftete Infs und Ings> sich ihren Frust auf die eigene Unzulänglichkeit mit pauschalem Bashing> einer anderen Studiengruppe abreagieren.> Wer in dem Thread ernsthaft schreibt gehört wohl zu den schlechten Infs> und Ings.> Leute ich werd noch fett hier bei soviel Popcorn und Bier .....
Seh ich anders, der Thread wurde ja als Inf Bashing eröffnet, greift
also im Eingangsthread und danach klar die Infs an. Die Infs im Gegenzug
behaupten nirgendwo dass sie in Bereichen der Ings genausgut oder besser
wären. Das ist schon ein großer Unterschied.
Es ist ja auch oft so dass die meisten Leute (Ings eingeschlossen) gar
keine Ahnung haben was Informatik überhaupt ist. Dies haben hier einige
Informatiker versucht zu vermitteln. Ein aufplustern kann ich von dieser
Seite her nicht erkennen. Eventuell ein geraderücken des Berufsbildes.
Nur manche Menschen sind einfach derart Beratungsresitent (z.B. der Herr
Hirtmann) da fällt einem nicht mehr viel ein.
gruß cyblord
Udo Schmitt schrieb:> Leute ich werd noch fett hier bei soviel Popcorn und Bier .....
Hehe ginge mir ähnlich, wenn ich nicht zu chronischem Untergewicht
neigen würde ;)
Ich nutze die Zeit jetzt lieber auch produktiver... das
Halloween-Special bereitet sich nicht von selbst vor und die DA schreibt
sich auch nicht von selbst seufz
Julian V. schrieb:>> Und in wie vielen realen Software-Projekten wird dies angewandt? ;-)>> Überall dort wo Software Sicherheitsrelevant ist
Stimmt definitiv nicht.
Julian V. schrieb im Beitrag #2393215:
> Ja, nur die Creme de la Creme hat solche Argumente auf lager. Respekt!> So disqualifiziert man sich selber von jeglicher Diskussion.
Als Informatiker solltest Du wissen, dass eine Aussage widerlegt ist,
wenn man ein Gegenbeispiel bringen kann. Ich bringe eins:
Softwareenticklung in der Schienenverkehrstechnik.
> Und das ewige Rumreiten auf euerer tollen Regelungstechnik
Du musst dringend mal richtig lesen lernen: Niemand hat hier behauptet,
dass Regelungstechnik unendlich toll wäre. Ich selbst mag sie gar nicht
besonders.
Mark Brandis schrieb:> Julian V. schrieb im Beitrag #2393215:>> Ja, nur die Creme de la Creme hat solche Argumente auf lager. Respekt!>> So disqualifiziert man sich selber von jeglicher Diskussion.>> Als Informatiker solltest Du wissen, dass eine Aussage widerlegt ist,> wenn man ein Gegenbeispiel bringen kann. Ich bringe eins:> Softwareenticklung in der Schienenverkehrstechnik.
Umso schlimmer wenn es stimmt dass dort Sicherheitsrelevante Software
wirklich nicht theoretisch verifiziert wird. Quellen?
>>> Und das ewige Rumreiten auf euerer tollen Regelungstechnik>> Du musst dringend mal richtig lesen lernen: Niemand hat hier behauptet,> dass Regelungstechnik unendlich toll wäre. Ich selbst mag sie gar nicht> besonders.
Sie wird aber hier als heiliger Gral der Ingeneuerskunst ausgegeben. Ich
sehe nicht warum einige hier der Meinung sind sie sollte zwingend in
einem Informatikstudium vorkommen und ich kann nicht verstehen wie man
sich als Ingenieuer an diesem vermeintlich fehlenden Wissen derart
hochmachen kann.
gruß cyblord
Julian V. schrieb:>> Als Informatiker solltest Du wissen, dass eine Aussage widerlegt ist,>> wenn man ein Gegenbeispiel bringen kann. Ich bringe eins:>> Softwareenticklung in der Schienenverkehrstechnik.>> Umso schlimmer wenn es stimmt dass dort Sicherheitsrelevante Software> wirklich nicht theoretisch verifiziert wird. Quellen?
Meine tägliche Arbeit. Glaubs oder lass es bleiben. Sourcecode zeige ich
Dir keinen, weil ich sonst eine hypertensive Krise befürchte ;-)
Julian, wer hat eigentlich die Softwaresicherheit für den Marssatelliten
verifiziert? Ich meine den, der wegen der fehlenden Umrechnung zwischen
Fuss und Meter unbedingt im Kern von Mars landen wollte :-)
Udo,
1.) ist die Steuerung eines Marssatelliten sicherheitsrelevant? Eher
nein.
2.) Bewiesene Korrektheit != perfekte Software mit ohne Bugs.
Siehe Ariane 5 Fehlstart, auch ein SW Problem.
Aber worauf willst du hinaus, möchtest du jetzt die Sinnhaftigkeit der
Softwareverfikation per se in Frage stellen oder wie? Und falls ja,
welche Implikationen folgen dann deiner Meinung nach daraus?
gruß cyblord
Informatiker schrieb:> Korrektheit kann man beweisen. Schonmal was vom Hoare-Kalkül gehört? Es> ist ein Unterschied, ob etwas augenscheinlich korrekt läuft oder ob es> bewiesen richtig läuft.
Und es ist ein Unterschied die Korrektheit einer Fibonacci-Funktion zu
beweisen, oder die eines TCP/IP-Stacks.
Andreas Schwarz schrieb:> Und es ist ein Unterschied die Korrektheit einer Fibonacci-Funktion zu> beweisen, oder die eines TCP/IP-Stacks.
Da stimme ich zu!
In der Realität ist es schwer bis unmöglich große Softwareprojekte als
Ganzes zu verifizieren. Soweit ich weiß wird das auch nicht gemacht. Es
werden teilaspekte der Software verifiziert.
Es ist auch so dass große und komplexe Software niemals Fehlerfrei ist.
Es ist eine Frage des Aufwands und des Preises die
Fehlerwahrscheinlichkeit unter eine bestimmte Marke zu drücken.
Allerdings ist die Entwicklung von komplexer Software kein triviales
Problem und mitnichten kann man es als "gelöst" betrachteb. Der Mythos
vom Fehlerfreien Programm ist genau das, ein Mythos.
gruß cyblord
Andreas Schwarz schrieb:> Und es ist ein Unterschied die Korrektheit einer Fibonacci-Funktion zu> beweisen, oder die eines TCP/IP-Stacks.
Jepp ich stelle mir gerade vor, wie jemand die Korrektheit einer
komplexen sicherheitsrelevanten Regelung beweisen will die Dutzende von
nichtlinearen Eingangssignalen erhält, deren Zusammenhang nur durch
komplexe und nur partiell lösbare Modelle angenähert werden kann.
Nehmen wir mal als Beispiel die Fluglageregelung eines vom Prinzip
instabilen Flugkörpers wie eines Hubschraubers oder des
Nurflüglerkonzepts wie des B2-Bombers der Amerikaner.
Ist das sicherheitsrelevant genug?
Hmm, das gibt noch viel Stoff fürs Kino. Der nächste Thread kann man
dann Theoretiker gegen Praktiker nennen, da wird bestimmt wieder genauso
wunderbar pauschalisiert und ge-basht bis die (virtuellen) Backen glühen
:-)
DotCom schrieb:> Ein Physiker hat keine Ahnung von Chemie? Komisch, da habe ich aber> andere Erfahrung im Studium gemacht ...
Ich rede ja auch von der Realität - schon mal den Spruch gehört: An der
Schauspielschule sind alle die größten Schauspieler.
Einhart Pape schrieb:> Als Informatikingenieur sitzt man ja voll zwischen den Stühlen ;-)
Es gibt keine Informatikingenieure.
Informatiker schrieb:> Fuzzy-Logik,
Fuzzy-Logik ist Unsinn - wird nur von Leuten verbreitet die die
Regelungstechnik nicht verstanden haben. (Der Quatsch ist aber auch
schon 50 Jahre alt - Einige sind darauf hängen geblieben, wie man so
sagt...)
Es gibt keine unscharfe Lokik - das sollte man als Informatiker
verstanden haben.
> Das Arbeitsamt gibt die Arbeitslosenzahl der Informatiker mit 4,4% und> die Arbeitslosenzahl der Elektroingenieure mit 2.7% an.
Schon seit Langem nicht mehr so gut gelacht ..
Die tatsächliche Zahl dürfte etwa um den Faktor 10 höher liegen ..
Julian V. schrieb:>> Als Informatiker solltest Du wissen, dass eine Aussage widerlegt ist,>> wenn man ein Gegenbeispiel bringen kann. Ich bringe eins:>> Softwareenticklung in der Schienenverkehrstechnik.>> Umso schlimmer wenn es stimmt dass dort Sicherheitsrelevante Software> wirklich nicht theoretisch verifiziert wird. Quellen?
Der Schienenverkehr legte sozusagen den Grundstein dafür, dass man
anfing Systeme zu verifizieren. Es musste verhindert werden, dass zwei
Züge im selben Gleisabschnitt fahren. Das nennt sich dann
wechselseitiger Ausschluss.
Und wenn man sich heute mit Model-Checking, stößt fast immer auf ein
einfaches Beispiel mit zwei Zügen, ein paar Gleisabschnitten, Weichen
und Signalanlagen.
Und wie bereits erwähnt, spielt die Verifikation von Software eine große
Rolle bei Luft- und Raumfahrt. Auch In der Finanzindustrie können
Korrektheitsbeweise nicht schaden. Wenn man weiß, dass falsche Bilanzen
großen Schaden anrichten können und teure Gerichtsverfahren nach sich
ziehen können, dann würde man nicht so leichtfertig Unsinn schreiben,
wie Sie es getan haben, Herr Brandis.
Julian V. schrieb:> Da stimme ich zu!>> In der Realität ist es schwer bis unmöglich große Softwareprojekte als> Ganzes zu verifizieren. Soweit ich weiß wird das auch nicht gemacht. Es> werden teilaspekte der Software verifiziert.> Es ist auch so dass große und komplexe Software niemals Fehlerfrei ist.> Es ist eine Frage des Aufwands und des Preises die> Fehlerwahrscheinlichkeit unter eine bestimmte Marke zu drücken.> Allerdings ist die Entwicklung von komplexer Software kein triviales> Problem und mitnichten kann man es als "gelöst" betrachteb. Der Mythos> vom Fehlerfreien Programm ist genau das, ein Mythos.>> gruß cyblord
Sie haben den Punkt getroffen. Und zum Thema Robustheit wäre noch zu
sagen: Ziel einer guten Architektur ist Robustheit und das heißt unter
anderem, dass der Ausfall einer Komponente möglichst nicht zum Ausfall
des Gesamtsystems führen sollte. Heute Automobile sind ja vollgestopft
mit. Ein kaputtes Radio sollte nicht dazu führen, dass der
Scheibenwischer nicht mehr funktioniert. Das ist jetzt bei einem
verteilten System prinzipiell leichter zu bewerkstelligen, aber wenn man
ein monolithisches System hat, dann knallt einem bei einer
NullPointerException im schlimmsten Falle das gesamte System um die
Ohren. Dann kann es passieren, dass die Software, aufgrund eines zu
steuernden, aber kaputt gegangenen Bauteile abstürzt und die anderen
Bauteile, z. B. in einer Fertigungsanlage, nicht mehr ansteuert.
Gutes Beispiel ist eine Fertigungsanlage im Lebensmittelbereich, bei dem
Kühlung notwendig ist. Robust ist, die gesamte Kühlung separat zu
steuern. Sollte die Steuerung, die Gemüse und Pommes sortiert,
ausfallen, muss die Kühlung in jedem Falle aufrechterhalten werden, in
den Bereichen, wo es notwendig ist. Sollte die Kühlung ausfallen, dann
gäbe es Verluste: Die Lebensmittel müsste man wegschmeißen und man hätte
auch einige Zeit Produktionsausfall.
Michael Lieter schrieb:> Einhart Pape schrieb:>> Als Informatikingenieur sitzt man ja voll zwischen den Stühlen ;-)>> Es gibt keine Informatikingenieure.
Den kennt sogar wikipedia
http://de.wikipedia.org/wiki/Ingenieurinformatikhttp://www.tu-ilmenau.de/studieninteressierte/studieren/master/ingenieurinformatik/> Fuzzy-Logik ist Unsinn - wird nur von Leuten verbreitet die die> Regelungstechnik nicht verstanden haben. (Der Quatsch ist aber auch> schon 50 Jahre alt - Einige sind darauf hängen geblieben, wie man so> sagt...)>> Es gibt keine unscharfe Lokik - das sollte man als Informatiker> verstanden haben.
Dann wissen wir schon mal, wer nicht Informatiker ist
Die Boolesche Logik ist eine Untermenge der Fuzzy-Logik.
Arc Net schrieb:> Dann wissen wir schon mal, wer nicht Informatiker ist> Die Boolesche Logik ist eine Untermenge der Fuzzy-Logik.>
Fuzzy-Logik wird da verwendet wo die "richtige" Logik nicht verstanden
wird.
Z.B. Drehzahlregelung in Waschmaschinen oder Bremskraftregelung un
U-Bahnen.
Das einfachste Konstrukt ist folgendes:
Ich messe Temperatur und Druck eines Reaktors und muss die
Brennstoffzufuhr begrenzen damit der Reaktor nicht explodiert.
Da gibt man der Temperatur eine virtuelle Skala von 1 - 10 und dem Druck
auch. Man multipliziert und bei Wert 50 setzt der Begrenzer ein. Fertig
ist die Fuzzy-Logik. Man könnte sie auch integrale Logik nennen.
Über boolesche Logik sind solche Systeme nicht so einfach beschreibbar.
Zuckerle schrieb im Beitrag #2395250:
> Es gibt in der Quantenphysik so etwas wie Fuzzy-Logik. Für das> " Prizip der Unschärfe " hat Werner Heisenberg 1936 den Nobelpreis in> Physik bekommen.>> Wird wohl aber noch mindestens 50 Jahre dauern bis ein Quanten-Rechner> betriebsbereit ist. Die "richtige" Logik hat eben Ihre Grenzen!
Wenn wir das technisch hinbekommen könnte man wirklich KI bauen.
Julian V. schrieb:> Es ist ja auch oft so dass die meisten Leute (Ings eingeschlossen) gar> keine Ahnung haben was Informatik überhaupt ist. Dies haben hier einige> Informatiker versucht zu vermitteln. Ein aufplustern kann ich von dieser> Seite her nicht erkennen. Eventuell ein geraderücken des Berufsbildes.> Nur manche Menschen sind einfach derart Beratungsresitent (z.B. der Herr> Hirtmann) da fällt einem nicht mehr viel ein.
richtig, viele wissen gar nicht was Informatik ist. Selbst viele
Unternehmen und Personaler wissen das nicht.
Aber : richtige Informatik wie theoretische Algorithmen oder KI oder gar
theoretische Informatik braucht man in mind. 90 % der IT Jobs nicht.
Sondern dort ist praktisches IT Wissen gefordert. Was nutzt mir da ein
theo.Inf Nerd der nicht weiß wie er ein aktuells MVC Framework nutzen
kann. Weil auf sowas kommt es doch in der Praxis an, wenn man ein
produktiver Entwickler sein
will !
> richtig, viele wissen gar nicht was Informatik ist. Selbst viele> Unternehmen und Personaler wissen das nicht.
bla
> Aber : richtige Informatik wie theoretische Algorithmen oder KI oder gar> theoretische Informatik braucht man in mind. 90 % der IT Jobs nicht.> Sondern dort ist praktisches IT Wissen gefordert.
Warum schließt das vollständige Wissen (also Theo, Technisch und
Praktisch) um Informatik ein praktisches Wissen denn aus?
Wo ist der Unterschied zu den Ings? Oder jedem anderen Beruf? Man muss
ein umfassendes Wissen über alle Bereiche seines Berufes mitbringen auch
wenn es im Alltag meist nicht direkt benötigt wird. Das ist nunmal so,
und ob man im Berufsleben was taugt erzählt meist das Uni Zeugniss
nicht. Inwiefern ist das nun eine Informatikspezifische Sache?
Wenn du schon im Bereich Softwareentwicklung bleiben willst, ein
Informatiker dort wird meist als Team oder Projektleiter eingesetzt. Als
Code-Monkey eher sowieso nicht. Ich kann keinen Grund erkennen wieso
hier Ings besser geeignet wären. Selbst im Bereich praktische Informatik
sollte die Ausbildung eines Ingieneuers hoffnungslos hinter der eines
Informatikers hinterherhinken.
> Was nutzt mir da ein> theo.Inf Nerd der nicht weiß wie er ein aktuells MVC Framework nutzen> kann.
Was meinst kommt bei einer Umfrage heraus, wenn wir Ings und Infs nach
dem MVC Pattern befragen? Wieviel % aus jeder Gruppe könnten dir eines
mit einem aktuellen Framework implementieren?
gruß cyblord
Julian V. schrieb:> Was meinst kommt bei einer Umfrage heraus, wenn wir Ings und Infs nach> dem MVC Pattern befragen? Wieviel % aus jeder Gruppe könnten dir eines> mit einem aktuellen Framework implementieren?
Ruby on Rails, Job done
D. I. schrieb:> Julian V. schrieb:>> Was meinst kommt bei einer Umfrage heraus, wenn wir Ings und Infs nach>> dem MVC Pattern befragen? Wieviel % aus jeder Gruppe könnten dir eines>> mit einem aktuellen Framework implementieren?>> Ruby on Rails, Job done
War das jetzt die Antwort auf meine Frage? Es soll ja MIT einem
Framework eine MVC Anwendung implementiert werden. Das Framework selber
gibts es natürlich schon das ist nicht die Frage.
Liest du alle Anforderungen und Spezifikationen derart sorgfältig durch
und startest dann einen Schnellschuss in die falsche Richtung? Super!
gruß cyblord
+ Informatik ist irgendwie ein Fach, bei dem nicht so richtig geplant
wird. Das Internet ist voll von Sozial-Gruppen-Anwendungen. Häufig
scheitern Projekte.
+ Immer: Schreib schneller! Diskutiere nicht soviel! Berichtigt wird
nicht, es muss von vornherein stimmen! Hauptsache viel.
+ Einmal bekam ich ein Programm als Codegenerator. Es war sehr lang und
ich sah nicht durch. Durch Versuch entfernte ich 1/3 der C-Funktionen
und das Programm lief nachher trotzdem noch.
+ Bei Programmen findet man auch oft eine Dokumentation, die lediglich
einzelne C-Funktionen beschreibt. Ein Gesamtüberblick fehlt meist.
+ Spitzenmäßig beschrieben ist die Architektur von MS-DOS als
Schichtenmodell und die Architektur von UNIX als Schalenmodell.
Eigentlich handelt es sich um C-Quellcode. Eine Schicht oder eine Schale
hat in dem ganzen Computer nie jemand gesehen.
+ Es nennt sich zwar INFORMATIK, aber man ist dann doch nur Bediener
einer modernen Büromaschine. FPGA oder Grafikkarte könnte auch
Informatik sein. Wäre schön abwechslungsreich.
+ Mich würde sowieso mal eine Gesamtsicht unter dem Motto interessieren:
Wo landen Informatiker später überall? Was steckt überhaupt an
Möglichkeiten in dem Beruf (am Ende nicht viel)?
robocash schrieb:> Bei Programmen findet man auch oft eine Dokumentation, die lediglich> einzelne C-Funktionen beschreibt. Ein Gesamtüberblick fehlt meist.
Das ist in der Tat ein Problem, aber keines der Informatik. Es schreiben
und dokumentieren nicht nur Informatiker, sondern sehr viele
Quereinsteiger und Ingenieure.
Es ist ähnlich, wie Mephisto in der Schülerszene spricht:
"Wer will was lebendig’s erkennen und beschreiben,
Sucht erst den Geist heraus zu treiben,
Dann hat er die Theile in seiner Hand,
Fehlt leider! nur das geistige Band."
Die Methoden und Funktionen sind beschrieben, aber das geistige Band,
das diese Funktionen zu einem Gesamtwerk macht, fehlt. Das ist aber
nicht nur ein Problem der Informatiker, auch nicht nicht nur der IT,
sondern betrifft auch angrenzende Abteilungen (z. B. in der
Hardwareabteilung). Man wünscht sich einfach ein bisschen mehr Prosa,
ein paar Absätze zur Motivation, warum(!) man eine Sache so und nicht
anders macht. Das kann man dann gerne bei einem guten Glas Rotwein
bereden.
Das aufgemachte Fass ist leider viel größer. Man wird durch
unternehmenseigene Bürokratie belästigt. So verstehe ich nicht, warum
man vor jeder Auslandsreise noch eine schwachsinnige Erklärung
unterzeichnen muss und warum nicht die einmalige Unterzeichnung reichen
soll.
Anton Hirtmann schrieb im Beitrag #2402311:
> @robocash>> Gute Zusammenfassung. Wichtig ist noch zu erwähnen, daß Softwareprojekte> häufig scheitern oder falls sie doch fertiggestellt werden voller Fehler> sind. Brücken hingegen stürzen in der Regel nicht ein. Woran das wohl> liegen mag?
Eine Brücke ist genau spezifiziert und die Anforderungen sind klar
formuliert. Das Pflichtenheft einer Software ist dagegen noch oft in der
Mache, während schon längst programmiert wird.
Außerdem, so meine Feststellung, sind die Verkäufer von IT-Projekten oft
ahnungslos und sprechen sich einfach nicht mit den IT-Leuten ab. Der
Verkäufer einer Brücke würde niemals irgendwelche Versprechen an den
Kunden machen, ohne sich mit dem Bauingenieur der eigenen Firma zu
unterhalten. In der IT geschieht dies tagtäglich.
1. Es werden irrsinnige Performanzversprechungen gemacht.
2. Aufgrund dieser Versprechungen zerkloppt man die Architektur der
Software und geht faule Kompromisse ein.
3. Der Code wird dadurch schlecht wartbar, sodass
4. sogenannte Change Requests leicht formuliert sind und in der Sache
auch sehr einfach sind, wenn die Architektur der Software sauber wäre.
Wenn Change Requests auf dem Tisch liegen, sollte man mit der doppelten
der veranschlagten Zeit rechnen. Gerade dann, wenn jemand ohne konkreter
Erfahrung aus dem jeweiligen Projekt drangesetzt wird.
Die IT ist der Prügelknabe in jeder Firma. Das kann bestimmt nicht daran
liegen, dass in der IT nur Idioten wären und alle anderen Abteilungen
spitzenmäßig. Ich bin ja selbst in der IT und fühle mich in der
Zwickmühle. Einerseits strebe ich gerne nach Perfektionismus¹ und
robusten Lösungen, die dann aber durch äußere Umstände immer wieder
aufgegeben werden müssen, sodass es ziemlich frustierend ist, weiterhin
so viel zu leisten. Überstunden habe ich nicht wenige. Ich könnte aber
genausogut weniger Gehirnschmalz reintun.
¹Ich will mich nicht zu viel loben, aber: Ich bin noch jemand, der sich
hinsetzt, nachdenkt, verschiedene Lösungsansätze formuliert und
entscheidet. Ich bin niemand, der drauflosprogrammiert, weil ich die
Erfahrung mache, dass sich das nicht auszahlt. In Mehrmannprojekten, in
denen alles drunter und drüber geht, setzt sich diese Arbeitsweise nicht
durch, weil Projektleiter dann oft auf die weniger nachdenklichen
Schreihälse hört.
robocash schrieb:> + Mich würde sowieso mal eine Gesamtsicht unter dem Motto interessieren:> Wo landen Informatiker später überall?
Sie machen sich selbstständig und wildern in Ingenieurbereichen - mit
ihrer Ausbildung ist das kein großes Problem ;-)
> Was steckt überhaupt an> Möglichkeiten in dem Beruf (am Ende nicht viel)?
Zumindest reicht es, um E-Technikern Brot und Arbeit zu geben :-)
Chris D.
robocash schrieb:> + Informatik ist irgendwie ein Fach, bei dem nicht so richtig geplant> wird. Das Internet ist voll von Sozial-Gruppen-Anwendungen. Häufig> scheitern Projekte.>> + Immer: Schreib schneller! Diskutiere nicht soviel! Berichtigt wird> nicht, es muss von vornherein stimmen! Hauptsache viel.>> + Einmal bekam ich ein Programm als Codegenerator. Es war sehr lang und> ich sah nicht durch. Durch Versuch entfernte ich 1/3 der C-Funktionen> und das Programm lief nachher trotzdem noch.>> + Bei Programmen findet man auch oft eine Dokumentation, die lediglich> einzelne C-Funktionen beschreibt. Ein Gesamtüberblick fehlt meist.>> + Spitzenmäßig beschrieben ist die Architektur von MS-DOS als> Schichtenmodell und die Architektur von UNIX als Schalenmodell.> Eigentlich handelt es sich um C-Quellcode. Eine Schicht oder eine Schale> hat in dem ganzen Computer nie jemand gesehen.>> + Es nennt sich zwar INFORMATIK, aber man ist dann doch nur Bediener> einer modernen Büromaschine. FPGA oder Grafikkarte könnte auch> Informatik sein. Wäre schön abwechslungsreich.>> + Mich würde sowieso mal eine Gesamtsicht unter dem Motto interessieren:> Wo landen Informatiker später überall? Was steckt überhaupt an> Möglichkeiten in dem Beruf (am Ende nicht viel)?
Endlich mal wieder gute Satire. Vielen Dank!!!
Informatiker schrieb:> Und wie bereits erwähnt, spielt die Verifikation von Software eine große> Rolle bei Luft- und Raumfahrt.
Ein Kollege von mir war 5 Jahre in einem europaeischen Luft- und
Raumfahrtunternehmen beschaeftigt. Ein Tollhaus, aber ganz sicher nicht
ein Ort, an dem Software verifiziert wird.
> Auch In der Finanzindustrie können Korrektheitsbeweise nicht schaden.
In der Finanzindustrie habe ich selbst 7 Jahre gearbeitet. Auch hier:
Keine Verifizierungen. Im Gegenteil, dort habe ich viele Leute
getroffen, die noch nicht mal wussten, warum floats fuer
Finanzkalkulationen nicht geeignet sind. Viele von diesen Leuten waren
uebrigens Quereinsteiger: Physiker, Elektroniker, etc.
Vor vielen Jahren habe ich mich fuer ein Praktikum bei einem
Medizingeraetehersteller beworben. Ich hatte in den ersten 2 Semestern
viel ueber Softwarebeweise und deren Relevanz in der Industrie gehoert
und war nun gespannt, was ich dort antreffen wuerde. Es war ein Graus:
Ich sollte dort ein halbes Jahr in der Qualitaetssicherung arbeiten,
meine Aufgabe waere gewesen, nach Gutduenken eine Menschsimulation zu
entwickeln und eine Validierung fuer die Maschine, die diesen Menschen
ueberwacht. Von Softwarebeweisen keine Spur. Noch nicht mal von einer
soliden Spezifikation!
> dann würde man nicht so leichtfertig Unsinn schreiben, wie Sie es getan haben,
Herr Brandis.
Herr Brandis spricht von der Praxis, Sie von der Theorie.
nach den BWLern sind nun die Informatiker an der Reihe und bekommen von
den Forumsusern mal ordentlich gezeigt wo der Bithammer hängt =)
Göttlichst wie manche hier von sich selbst überzeugt sind
Naja, ich glaube diese Forum muss eher als Ventil dienen.
Die Leute, die hier am selbstbewusstesten Auftreten, sind in der Realiät
eben Duckmäuser. Logisch, dass dies irgendwo kompensiert werden muss.
Hier wird ja fast in jedem Thread geweint.
Mal die BWLer, mal die Banker, dann die Informatiker und die ganze Welt
... alles sind Schuld woran?
An der EIGENEN bescheidenen Situationen.
Naja, vor der eigenen Haustür kehren, da würde wohl zu viel ans
Tageslicht kommen.
Softwareentwicklung ist einfach schwieriger als eine Brücke oder ein
Hochhaus zu bauen. Natürlich hört das Ingenieuer nicht allzu gerne, aber
die Realität zeigt das deutlich. Das hängt natürlich auch damit zusammen
dass Informatik im Vergleich zu, sagen wir mal der Bauingenieuerskunst,
ein paar tausend Jahre Rückstand hat. Diese Tatsache der Informatik
negativ anzulasten ist schon ein bisschen armselig (gut das sind
eigentlich alle Posts vom Anton in diesem Thread aber seis drum).
Wie ich schon weiter oben schrieb, komplexe Software fehlerfrei zu
erstellen ist aktuell ein noch nicht gelöstes Problem. Eine Brücke oder
einen 200 stöckigen Wolkenkratzer kann man dagegen ohne Probleme bauen.
Wo steckt nun mehr Herausforderung?
Ausserdem ist ja nun die Ingenieuerskunst durchaus auch zu gravierden
Fehler fähig. Es wird hier immer so getan als habe nur Software Fehler.
Was ist mit havarierten AKWs, mit entgleisten Zügen wegen gebrochenen
Radreifen, Space Shuttle abstürzen und und und? Um nur mal ein paar
prominente Beispiele zu nennen.
gruß cyblord
Anton Hirtmann schrieb im Beitrag #2403328:
> Der Qualitätsstandard bei Software ist nämlich eine ziemliche Katastrophe.
Der Aussage muss man in vielen Fällen wohl leider zustimmen.
Julian V. schrieb:> Softwareentwicklung ist einfach schwieriger als eine Brücke oder ein> Hochhaus zu bauen. Natürlich hört das Ingenieuer nicht allzu gerne, aber> die Realität zeigt das deutlich.
Schwieriger? Mir dünkt du unterschätzt da etwas - baue mal so eine
Pyramide!
Anton Hirtmann schrieb im Beitrag #2403616:
> Selbst mit heutiger Technologie wäre es kaum möglich, ein> derartiges Bauwerk zu errichten.
Quark. Nur teuer und sinnlos.
Anton Hirtmann schrieb im Beitrag #2403616:
> Richtig. Bis heute ist nicht bekannt wie die Pyramiden von Gizeh gebaut> worden sind. Selbst mit heutiger Technologie wäre es kaum möglich, ein> derartiges Bauwerk zu errichten.
Wäre heute nicht möglich. Weil: 38h Woche, Urlaub, Feiertage,
Gewerkschaften usw. - aber das wäre es nicht mal - die Grundmotivation
könnte man heute nicht mehr vermitteln. Technisch - wäre es kein
Problem.
Das andere ist aber das was "Schwierig" wäre.
Anton Hirtmann schrieb im Beitrag #2403623:
> Die Gründe dafür sind rein technischer Natur. Wie will man> z.B. die tonnenschweren Steinquader an die richtige Stelle bewegen?
Nimmt man einen Kran?
Anton Hirtmann schrieb im Beitrag #2403623:
> Irrtum. Bis jetzt hat es noch niemand geschafft, eine Pyramide> nachzubauen.
Hat es jemand denn überhaupt versucht? Also ernsthaft, mit ausreichend
Geld ausgestattet.
Es hat wohl auch noch niemand versucht, in Alaska Ananas zu züchten
(trotz entsprechender Androhung). Das bedeutet aber nicht automatisch,
dass es trotz reichlich Sinn fürs Geldverbrennen unmöglich sei.
Anton Hirtmann schrieb im Beitrag #2403664:
> Hier eine interessante Lektüre. Demnach sind die Steinblöcke vermittels> Töne in der Luft levitiert worden. Wirklich beeindruckend!
Wahrhaftig, der Klappentext von Amazon ist wirklich urig: "Geboren wurde
Jan van Helsing 1967 in Dinkelsbühl. In seiner Familie gingen Hellseher,
Heiler, Channeling-Medien oder mit dem Jenseits korrespondierende
Menschen ein und aus."
Der soll mal schön brav seine Vampire jagen, denn davon gibts dieser
Jahre massenhaft, egal welchen Kanal man einschaltet.
Der simple Kran ist einfach zu abwegig. Gehe man heute auf einer
Großbaustelle vorbei und da steht ein Kran - und man schaut sich den
genau an - was an diesem Kran ginge vor 3000 Jahren nicht so wie heute?
Gewicht, Gegengewicht, Seilzug. Ein Kran ist so primitiv das man damit
sogar Pyramiden bauen könnte - die Stahlseile ersetzt man durch
Hanfseile oder Seile aus Seide - noch Fragen?
Der Trick mit den Pyramiden ist ganz einfach: Genug Leute, genug Geld
(aka Mittel um Material und Verpflegung zu bezahlen), genug Zeit.
Dann braucht man nichtmal nen Kran, dann kann man auch die viel
zitierten Rampen aufschütten.
Mark Brandis schrieb:> Anton Hirtmann schrieb:>> Der Qualitätsstandard bei Software ist nämlich eine ziemliche Katastrophe.>> Der Aussage muss man in vielen Fällen wohl leider zustimmen.
Wobei das nicht unbedingt an der Informatik liegt. Es liegt oft an der
Unternehmensführung und -kultur, die dem Softwaretest keinen Wert
beimisst.
Das fängt oft damit an, dass Anfänger als Tester anfangen und dann zum
Entwickler werden. Es müsste genau umgekehrt sein.
Informatiker schrieb:> Mark Brandis schrieb:>> Anton Hirtmann schrieb:>>> Der Qualitätsstandard bei Software ist nämlich eine ziemliche Katastrophe.>>>> Der Aussage muss man in vielen Fällen wohl leider zustimmen.>> Wobei das nicht unbedingt an der Informatik liegt. Es liegt oft an der> Unternehmensführung und -kultur, die dem Softwaretest keinen Wert> beimisst.
Vor allem liegt es daran, dass es bei Software praktisch keine
Produkthaftung gibt.
Stürzt eine Brücke ein, dann haftet der Verantwortliche.
Bei Software?
Nichts dergleichen. Demenstprechend wenig Wert wird auch Qualität
gelegt:
man kann ja zur Not noch beim Kunden nachbessern.
Chris D.
P.S.: Brücken konnten übrigens schon die Römer vernünftig bauen, wie man
an den vielen noch stehenden Bauwerken sieht. Im Gegensatz dazu halten
heutige Brücken nicht einmal einen Bruchteil der Zeit. Soviel zur
heutigen Ingenieurskunst.
Chris D. schrieb:> P.S.: Brücken konnten übrigens schon die Römer vernünftig bauen, wie man> an den vielen noch stehenden Bauwerken sieht. Im Gegensatz dazu halten> heutige Brücken nicht einmal einen Bruchteil der Zeit. Soviel zur> heutigen Ingenieurskunst.
Wie viele 18-Tonner pro Stunde fuhren wohl über die Brücken im alten
Rom? ;-)
Informatiker schrieb:> Das fängt oft damit an, dass Anfänger als Tester anfangen und dann zum> Entwickler werden. Es müsste genau umgekehrt sein.
Welcher Entwickler würde denn testen?
Das ist eine Art Arbeit die mit dem Geist der Entwicklung nichts mehr zu
tun hat - stumpfes testen von Möglichkeiten um einen Fehler zu finden.
Und da die Fehlermöglichkeiten fast unendlich sind, ist das eine quasi
in Zeit unlösbare Aufgabe.
Daher auch der Begriff Bananensoftware.
Das Produkt reift beim Kunden.
Entwickler empfinden es als Stafversetzung ins Testcenter.
Allein Codereview scheut der Informatiker wie der Teufel das Weihwasser.
Michael Lieter schrieb:> Informatiker schrieb:>> Das fängt oft damit an, dass Anfänger als Tester anfangen und dann zum>> Entwickler werden. Es müsste genau umgekehrt sein.>>> Welcher Entwickler würde denn testen?>
Leute, die Ahnung haben. Testen heißt nicht, dass man Affe alle Dialoge
durchklickt. Testen kann, wenn man es richtig anstellt, eine äußerst
kreative Arbeit sein, bei der viel Gehirnschmalz erfordlich ist.
> Das ist eine Art Arbeit die mit dem Geist der Entwicklung nichts mehr zu> tun hat - stumpfes testen von Möglichkeiten um einen Fehler zu finden.> Und da die Fehlermöglichkeiten fast unendlich sind, ist das eine quasi> in Zeit unlösbare Aufgabe.>
Unfug. Es gibt erschöpfendes Testen und einfache Stichproben. Beides
verbietet sich. Erschöpfendes Testen ist unmöglich, einfache Stichproben
taugen nichts. Man benötigt n gut gewählte Stichproben, um möglichst
schnell, möglichst viel Funktionalität abzutesten.
> Daher auch der Begriff Bananensoftware.> Das Produkt reift beim Kunden.>
Genauso Unfug. Das können sich nur Firmen leisten, die ausschließlich
Software als Produkt anbieten. Die meiste Software ist aber Teil von
bestehenden System, ob eingebettet oder nicht. Da darf nichts beim
Kunden reifen.
> Entwickler empfinden es als Stafversetzung ins Testcenter.>
Mitunter ja, weil die Verantwortlichen selbst von Testen keine Ahnung
haben und glauben, man man muss wie ein Affe durch Dialoge klicken.
Außerdem stört mich eines: Man muss sich entscheiden zwischen Test und
Entwicklung. Beides gehört zusammen, man muss beides können, natürlich
ohne die Rollen zu durchmischen.
Chris D. schrieb:>> Wobei das nicht unbedingt an der Informatik liegt. Es liegt oft an der>> Unternehmensführung und -kultur, die dem Softwaretest keinen Wert>> beimisst.>> Vor allem liegt es daran, dass es bei Software praktisch keine> Produkthaftung gibt.
Dsa ist kompletter Unfug. Wenn beim neuen BMW etwas kaputt ist, dann
muss BMW dafür haften und kann sich nicht damit herausreden, dass eine
kaputte Software daran schuld ist.
Informatiker schrieb:>> Vor allem liegt es daran, dass es bei Software praktisch keine>> Produkthaftung gibt.>> Dsa ist kompletter Unfug.
Du weisst selbst, dass es so ist.
> Wenn beim neuen BMW etwas kaputt ist, dann> muss BMW dafür haften und kann sich nicht damit herausreden, dass eine> kaputte Software daran schuld ist.
Dann geht es aber immer um ein konkretes Gerät, nie um die Software.
Bei welchem Deiner PC-Programme hast Du beispielsweise eine
Produkthaftung?
Chris D.
Die in der Antike hatten etwas, was wir heute nicht mehr in der
damaligen Quantität haben: Zeit im Überfluss.
Wenn es mehrere Generationen gedauert hat, ein Bauwerk zu planen/zu
errichten, hat's keinen gestört. Noch weniger in der Steinzeit, siehe
Stonehenge o.ä. Heute hingegen muss alles ganz schnell fertig werden,
dementsprechend die Qualität.
Chris D. schrieb:> Bei welchem Deiner PC-Programme hast Du beispielsweise eine> Produkthaftung?
Das wäre das Geschäftsmodell, wie es beispielsweise Microsoft, Adobe,
Oracle und Corel betreiben: Software als eigenständiges Produkt, keine
Auftragsarbeit. Das ist aber nur der geringere Teil, bei mit Software
Geld verdient wird. Der größere Teil von Software wird für eingebettete
Systeme entwickelt oder sind genau auf die Kundenanforderungen
zugeschnitten. Bei industriellen Anlagen steuert eine Software die
komplette Anlage. Es wird aber nicht die Software als solche verkauft,
sondern die Anlage inklusive Software. Und da haftet man sehr wohl.
Apropos Haftung: Wenn ich mir einen Pelikan-Füllfederhalter kaufe, dann
würde Pelikan einen Füllfederhalter wahrscheinlich ersetzen, wenn er in
den ersten Tagen kaputt gänge (Produkthaftung). Für die Folgen, die mir
der kaputte Füllfederhalter eingebrockt hat, würde Pelikan nie haften.
Angenommen, man saut aufgrund einer kaputten Feder ein. Dann kann man
erstmal fünf Minuten nicht seiner Arbeit nachgehen, sondern muss sich
säubern, verbraucht Seife für einen halben Cent, natürlich Wasser usw.
usf. Dafür haftet Pelikan nicht.
Lukas K. schrieb:> Die in der Antike hatten etwas, was wir heute nicht mehr in der> damaligen Quantität haben: Zeit im Überfluss.> Wenn es mehrere Generationen gedauert hat, ein Bauwerk zu planen/zu> errichten, hat's keinen gestört. Noch weniger in der Steinzeit, siehe> Stonehenge o.ä. Heute hingegen muss alles ganz schnell fertig werden,> dementsprechend die Qualität.
Manchen Leuten scheint aber die Qualität zu reichen. Natürlich hat man
als Ingenieur oder Informatiker ganz andere Ansprüche. Ich z. B. schäme
mich für die Software, an der ich herumprogrammiere, weil ich den Code
der Kollegen nicht ertrage und ich selbst absoluten Mist aufgrunddessen
schreibe. Zum Glück sieht der Kunde den Quellcode nicht. :-)
Einer meiner Professoren sagte uns Studenten: "Sie werden die letzten
sein, die eine so gute Ausbildung genossen haben. Softwareentwickler
haben heute ein geringeres durchschnittliches Ausbildungsniveau als
früher und es wird noch weiter absinken."
Er meinte damit 1. die Umstellung auf Bachelor/Master, 2. dass es viel
mehr Fachhochschulen gibt, die Programmierer auswerfen und 3. dass es
auch schon den Ausbildungsberuf zum Programmierer gibt. In den 1970ern
gab es kaum Fachhochschulen und programmiert haben ausschließlich
Akademiker.
Ich habe schon Fachinformatiker erlebt, die noch nicht einmal "Dijkstra"
richtig aussprechen können. Die sagen dann "Deukstra". Das ist so, als
wenn ein Arzt zweiter Klasse vom "Zwergfell" reden würde.
Informatiker schrieb:> Er meinte damit 1. die Umstellung auf Bachelor/Master, 2. dass es viel> mehr Fachhochschulen gibt, die Programmierer auswerfen und 3. dass es> auch schon den Ausbildungsberuf zum Programmierer gibt. In den 1970ern> gab es kaum Fachhochschulen
Zu der Zeit gab es a.) auch sehr wenige Universitäten, die ein
Informatik-Studium anboten und b.) die Vorgänger der Fachhochschulen
existierten vielerorts selbstverständlich schon.
> und programmiert haben ausschließlich Akademiker.
Ja wie jetzt, ich dachte Akademiker entwerfen die Architektur der
Software und programmieren nicht selbst? Zumindest ist dies gerade an
Universitäten immer wieder gerne so behauptet worden.
> Ich habe schon Fachinformatiker erlebt, die noch nicht einmal "Dijkstra"> richtig aussprechen können. Die sagen dann "Deukstra". Das ist so, als> wenn ein Arzt zweiter Klasse vom "Zwergfell" reden würde.
Na was ein Glück, dass alle Niederländer deutsche Namen immer korrekt
aussprechen. Bestimmt weißt Du auch genau, wie man "Shang-Hua Teng"
richtig ausspricht, Du toller Held. ;-)
>Ich habe schon Fachinformatiker erlebt, die noch nicht einmal "Dijkstra">richtig aussprechen können. Die sagen dann "Deukstra". Das ist so, als>wenn ein Arzt zweiter Klasse vom "Zwergfell" reden würde.
Als wenn...! Wenn ich das schon lese. Honk!
Rosa
