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......
Dort, wo UCs programmiert werden sollen, wir ein Maschinenbauer wohl kaum weiterhelfen.
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.
Gähn, solang ist das Thema nun noch nicht her, dass man das schon wieder aufwärmen muss, ...
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ähn Rosa-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 ;-)
Immer wieder amuesant, wie beschraenkt die Elektroniker in ihrem Weltbild sind.
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 :-)
Mich würde ja mal interessiern was unser Kollege Rolf zu dem Thema sagen würde. Schließlich ist er auch Informatiker: http://www.bild.de/lifestyle/2011/piercing/piercing-rekord-raten-sie-mal-was-rolf-beruflich-macht-20508290.bild.html
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.
Ganz ehrlich: Wenn der Kunde zu dumm ist um vernünftige Angaben zu machen, dann will man ihn vielleicht gar nicht wiedersehen ;)
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
Ich lege noch einen drauf: VHDL-Entwicklung läuft bei vielen noch als HW-Entwicklung und wer da ein bissl rumgmacht hat, denkt, er sei jetzt SW-Entwickler. Das Ergbnis ist dann dies hier: Beitrag "Re: Herangehensweise an fremdes, großes VHDL Projekt"
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. |
15 | Kosten: |
16 | Inf: 1450€ + 20 * 400€ = 9450€ |
17 | Ing: 30000€ + 20 * 20€ * 1,5 Aufschlag für Kleinserie = 30600€ |
18 | Vergangene Zeit: |
19 | Inf: 3 Tage |
20 | Ing: 90 Tage |
21 | |
22 | Worst Case: |
23 | 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 ;)
Als Informatikingenieur sitzt man ja voll zwischen den Stühlen ;-)
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!
>Wer hier so platt pauschalisiert gehört in der Beziehung wahrscheinlich eh zum
Bodensatz.
Alle Ingenieure neigen zum Pauschalisieren.
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.
Ein Physiker hat keine Ahnung von Chemie? Komisch, da habe ich aber andere Erfahrung im Studium gemacht ...
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 ...) {
|
2 | return a.getB().getC().getD().getE(); |
3 | } |
Besser wäre es:
1 | if (a!=null) {
|
2 | return a.getE(); |
3 | } |
getE() ist definiert als
1 | return getD() != null ? getD().getE() : null; |
getD() und getC() sind analog definiert.
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 :-)
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? EAL Listen ansehen... http://www.commoncriteriaportal.org/products_OS.html#OS EAL7 wäre vollständig formal verifiziert, davon gibt's nicht viel (Vollständig) formal verifizierte Betriebssysteme bzw. (kurz) davor, seL4 http://ertos.nicta.com.au/research/sel4/ PikeOS http://www.sysgo.com/products/pikeos-rtos-and-virtualization/security-certification/ INTEGRITY http://www.ghs.com/security/security_home.html und einige eher akademische Systeme z.B. http://research.microsoft.com/apps/pubs/?id=122884 In Zukunft dürften es deutlich mehr werden http://en.wikipedia.org/wiki/DO-178C http://www.open-do.org/
Die NASA hat hinter dem Mond einen ALF eingefangen... und schreibt nun eine Stelle aus: "Tierarzt gesucht"
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/Ingenieurinformatik http://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.
Man kann auch hier: http://www.lohnspiegel.de/main/zusatzinformationen/menufolder.2008-04-25.6904528512/online-umfrage-von-lohnspiegel.de sehen, dass Maschinenbauingenieure und Elektroingenieure mehr als Softwareingenieure verdienen. Und das hat bestimmt einen Grund. Aber trotzdem werde ich behaupten, dass die Softwareingenieure unter enormen (Zeitlichen) Druck stehen, und das auch bei großen Konzernen, da sie meistens Projektarbeit machen müssen.
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.
Wie man Pyramiden baut: http://www.tshirthell.com/funny-shirts/slavery-gets-shit-done/?xid=a45caa85-a7ac-4c84-1590-3275f9d90a2a
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.