Ingenieure entwickeln besser Software

es geht noch besser, man nimmt einen, der erst Hardware erstellt und 
dann die Software programmiert, und dieser wird dann mit <62€ 
abgespeist.

oder er springt nach Abgabe des SCH ab und hüpft zu einem anderen 
Kunden, wie man es mir schon erzählt hat. Das SCh sollte ich dann noch 
mal bearbeiten :-)

Neeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee Daaaaaaaaaaaaaaaaaankeeeeeeeeeee

das ist eben oft das Problem, weil vile Firmen das nicht 
miteinkalkulieren, weil Geiz bekanntlich geil ist

Ich halte das für Unfug. Was gute Software ist, wissen viele Entscheider 
oft gar nicht zu beurteilen. Sobald die Problematik komplizierter wird 
und z. B. stabile Algorithmen gefragt sind, muss der Nichtinformatiker 
passen. Es geht nicht darum, einen bekannten Algorithmus selbst zu 
implementieren, Gott bewahre. Wenn man aber nicht weiß, dass es diesen 
oder jenen Algorithmus gibt, dann kann auch nicht gezielt danach bei 
Google suchen und eine Bibliothek raussuchen, die diesen Algorithmus 
bereits implementiert hat.

Ich kannte mal einen Chef, der die einfachsten Algorithmen seiner 
Mitarbeiter nicht verstanden hat und unmögliches verlangt hatte: Noch 
mehr Funktionalität in kürzer Zeit, bei Algorithmen, die auch er 
versteht. Sein Problem war: Er war zur Jahrtausendwende Quereinsteiger 
und hielt sich für einen guten Programmierer und war geistig nicht in 
der Lage, zu akzeptieren, dass seine Ausbildung einfach nicht 
ausreichte.

Aktionär schrieb:
> Sobald die Problematik komplizierter wird
> und z. B. stabile Algorithmen gefragt sind, muss der Nichtinformatiker

wie oft braucht man das im Berufsalltag ? also ich kann diese 
Situationen an einer Hand abzählen pro Jahr. Zu 90 + x % braucht man 
solche Dinge nicht.

Bei Informatikern habe ich teils oft gesehen, dass die völlig 
unpragmatisch an Lösungen ran gehen. Da wird für einfache Probleme ein 
komplexes UML Model erstellt und raus kommt eine Architektur wo jeder SW 
-  Prof begeistert wäre, aber das ganze wird auch entsprechend teuer. 
Falls mal später ein anderer Entwickler ran geht, muss der sich erst in 
das komplexe Model einarbeiten.

Dann ist manchmal der pragmatische Ing mir lieber, der zwar auch 
Schichtentrennung bei der SW Entwicklung berücksichtigt, aber dennoch 
problemorientierter an die Sache ran geht. Von wegen : "was muss die 
Software können" und nicht "wie muss eine Architektur aussehen, damit 
sie SW technisch perfekt ist"

soll natürlich nicht verallgemeinert sein, es gibt auch sicher viele 
Informatiker, die sehr pragmatisch denken. Ist lediglich eine 
Beobachtung von mir

Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA 
und dem 1 Rubel Bleistift der Russen:
Der Informatiker löst Softwareprobleme wie beim Weltraum Kuli, der Ing 
wählt die "russische Methode".

;-)

Geraffel schrieb:
> Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA
> und dem 1 Rubel Bleistift der Russen:
> Der Informatiker löst Softwareprobleme wie beim Weltraum Kuli, der Ing
> wählt die "russische Methode".
>
> ;-)

Das ist ein modernes Märchen und außerdem: Ein Bleistift bei 
Schwerelosigkeit im Raumschiff lebensgefährlich. Da muss nur die Mine 
abbrechen und irgendwo durch eine Ritze zur Technik gelangen.

Christian Berger schrieb:
> Hmm, die Frage ist, ob man das im Informatikstudium überhaupt noch
> richtig lernt. Ich hatte noch das Glück privat unter DOS auf dem IBM-PC
> zu entwickeln, da bekommt man hautnah die Grundlagen mit. In der Lehre
> habe ich dann gelernt wie furchtbar externe Biliotheksroutinen sind.

An der Uni habe ich auch Assembler gelernt. DOS kenne ich noch aus 
meiner Kindheit/Jugend. Man muss nicht zwangsläufig unter DOS entwickelt 
haben, um "nahe am Grundsystem" zu sein. Ich kann mir nicht vorstellen, 
dass es Informatikstudiengänge ohne Assembler gibt.

Mir ist schon als Jugendlicher aufgefallen: Programmieren lernt man am 
besten am Quelltext, mit Papier und Bleistift. Alle Ansätze, schnell mal 
was zusammenzuklicken, scheitern, wenn man gerade noch im Begriffe ist, 
eine Sprache zu lernen. Ich habe mich mal an Delphi gewagt und bin 
grandios gescheitert. Dann habe ich mir Borland Pascal besorgt und ganz 
einfache Programme geschrieben. Danach habe ich mich an C/C++ gewagt.

Bei Bibliotheken: Man muss wissen, wonach man sucht. Als Informatiker 
kommt man auch in Kontakt mit Graphalgorithmen und linearer 
Programmierung. Wenn man nicht weiß, dass diese oder jene 
Aufgabenstellung ein bekanntes graphentheoretisches Problem darstellt, 
dann bildet man die Aufgabenstellung auf eine bestehende, allgemeine 
Implementierung ab. Oder aber LP: Wenn man nicht weiß, dass ein Problem 
der linearen Optimierung vorliegt, wird auch nicht zu einer bestehenden 
Implementierung des Simplexalgorithmus greifen. Ein gutes Beispiel ist 
auch die Sortierung von Objekten. Mittlerweile hat jede 
Programmiersprache eine Implementierung von Quicksort dabei. Dem 
Algorithmus übergibt man ein Strategieobjekt, das -1, 0 oder 1 
zurückgibt, wenn zwei Objekte miteinander verglichen werden. Die 
konkrete Ausformung einer Strategieklasse ist ziemlich einfach, aber das 
eigentliche Quicksort ist nur einmal implementiert.

Gerald Hellinghaus schrieb:
> Die meisten, die sich im Projektgeschäft bewegen oder sich öfters mal
> bewerben, werden es ja schon gemerkt haben: Bewirbst Du Dich auf eine
> HW-Stelle kannst Du mit 5-10% weniger Gehalt rechnen, als bei einer
> Softwarestelle, Warum das so ist, das soll dahin gestellt sein.
[snip]

Ist das heutzutage wirklich so herum?

Eine sehr schöne Anekdote dazu:

In einer Firma (angeblich USA) verdienten die HW-Entwickler deutlich 
mehr als die SW-Entwickler.

Einer der Software-Typen ging dann mal zum Boss und fragte wieso das so 
sei?

Die Antwort: Software ist doch nur Tippen!

Ich weiss nicht ob ich darüber lachen kann, ist manchmal zu nahe an der 
Realität.

Coder schrieb:
> Aktionär schrieb:
>> Sobald die Problematik komplizierter wird
>> und z. B. stabile Algorithmen gefragt sind,
>
> wie oft braucht man das im Berufsalltag ? also ich kann diese
> Situationen an einer Hand abzählen pro Jahr. Zu 90 + x % braucht man
> solche Dinge nicht.

Der war gut ;)

Coder schrieb:
> Von wegen : "was muss die
> Software können" und nicht "wie muss eine Architektur aussehen, damit
> sie SW technisch perfekt ist"

Ersetze das Wort 'perfekt' durch 'einwandfrei' und du hast zwei Sätze 
zitiert, die für mich exakt dasselbe bedeuten.

edson schrieb:
> Ersetze das Wort 'perfekt' durch 'einwandfrei' und du hast zwei Sätze
> zitiert, die für mich exakt dasselbe bedeuten.

verstehe schon was du meinst.

Es gibt aber einfach Dinge, da braucht man nicht eine SW technisch 
einwandfreie Architektur.

Beispiel : Kunde möchte ein billig Pressholzfertighaus, das keine 100 
Jahre halten soll, so im Ami Style. Viele Informatiker aber kränkt sowas 
in ihrer Ehre und sie stellen ein Haus hin, was jeder EU Norm, jeder DIN 
Norm usw entspricht und mindestens 5 Generationen ohne Probleme hält.

Nur wenn der Kunde das gar nicht wollte und schon gar nicht bezahlen 
will ? dann ist es manchmal besser, man lässt die 5 mal gerade sein und 
gibt dem Kunden was er will. Bei nem Wirbelsturm wird wieder die 
Kellerdecke saubergefegt und wieder ein Fertighaus drauf gestellt, was 
oft billiger kommt, als eine Ruine von Fachleuten aufwendig nach dem 
Sturm restaurieren zu lassen.

Warum wird immer gleich mit Superlativen um sich geschmissen? Nur weil 
einer mal etwas mehr nachdenkt, heißt das nicht, dass er das "perfekte" 
System haben will. Das wird mir gerne vorgeworfen. Ich mache mir Skizzen 
auf Papier und denke scharf nach. Einfach drauflos programmieren, gibt's 
bei mir nicht. Als Informatiker ist mir die Komplexitätstheorie sehr 
wohl vertraut und auch Verfahren, um dem Dilemma der NP-schweren 
Probleme zu entkommen, kenne ich auch. Dann muss mir aber kein 
neunmalkluger Ingenieur erzählen, dass es sinnlos sei, nach der 
perfekten Lösung zu suchen, und das, obwohl ich das Wort "perfekt" bis 
dahin nie in den Mund genommen habe. Als Informatiker ist mir nämlich 
auch bewusst, dass man es sich nicht zu einfach machen kann und die 
erstbeste Lösung zu nehmen, die einem einfällt. So arbeiten viele meiner 
(ehemalige) Kollegen. Lieber schnell hingepfuscht, anstatt anständig 
nachgedacht und ein Stück Code geschaffen, das die nächsten Monate 
übersteht. Leider ist es so, dass viel Code geringe Lebensdauer hat, 
weil man einem Problem nach dem andere hinterherjagt. Das ist das 
Arbeitsweise von Leuten, die ständig reden, Lösungen müssen schnell und 
einfach sein. Das kosten Zeit, Nerven, Geld.

Coder schrieb:
> Beispiel : Kunde möchte ein billig Pressholzfertighaus, das keine 100
> Jahre halten soll, so im Ami Style. Viele Informatiker aber kränkt sowas
> in ihrer Ehre und sie stellen ein Haus hin, was jeder EU Norm, jeder DIN
> Norm usw entspricht und mindestens 5 Generationen ohne Probleme hält.

Ganz bestimmt nicht. Meine Erfahrung ist eine ganz andere. Der Kunde 
verlangt die verrücktesten Systeme und es alles unnötig kompliziert 
gemacht. Ich betreue einen Kunden, der z. B. ein Programm einer anderen 
Firma mit unserer Software verbinden will. Und in der Spezifikation 
steht dann: Die von der Software gesandten Daten werden in Tabelle X 
abgespeichert. Nach 30 Tagen wandern die ins "Archiv" in Tabelle Y, um 
dort wiederrum nach 60 gelöscht zu werden. Der Kunde will Statistik 
haben und dazu müssen Daten beide Tabellen konsultiert werden. Die 
einfache Lösung wäre gewesen: Man hat nur noch Tabelle X und Datensätze 
werden erst nach 90 Tagen gelöscht.

Andere Kunden halten einen Spezifikation teilweise vor. Die sagen, es 
gilt Regel A. Nach einer Woche heißt es: Es gilt Regel A, mit Ausnahme 
B. Wieder eine Woche später gibt's mit C den Sonderfall von B. Ist 
natürlich Frevel zu verlangen, dass man gleich zu Beginn mit einer 
perfekten  Spezifikation arbeitet. Spezifieren ist genauso anspruchsvoll 
wie das Programmieren. Aber jede Woche eine neue Salve von Sonderregeln, 
ist einfach unmöglich, weil ja bereits Code besteht, der eventuell 
verworfen werden muss.

Und worauf soll die Software laufen?

Gerald Hellinghaus schrieb:
> -> Macht euch auf in die Software, liebe Kollegen

Das hört sich so an, als klappert man etwas mit der Tastatur.

Ich arbeite in einem Unternehmen, das länger (einige Monate) nach einem 
Programmierer gesucht hat, der sich auch mit den Hardwarehintergründen 
der Leistungselektronik etc. auskennt.
Inzwischen haben die wohl einen gefunden.

Geraffel schrieb:
> Das ist wie mit dem Super 1 Mio Dollar Weltraum Kugelschreiber der NASA
> und dem 1 Rubel Bleistift der Russen

Urban legend.

Alex W. schrieb:
> Das der Kuli aber entwickelt wurde, weil das Graphit einer abgebrochenen
> Bleistiftmine zu Kurzschlüssen führen kann (im Weltraum ein Desaster)
> und die Bleistiftspitze eingeathmet werden kann, wird mal munter
> verschwiegen

Warum sollte man auch Blödsinn äußern?

Jürgen G. schrieb:
> Meist sind es ziemlich primitive Argumente, z.B. Verwendung von #define
> statt const.
Behandeln, besser optimieren, die meisten Compiler die beiden Varianten 
nicht gleich?
Außer dass dir beim const der Compiler auf die Finger schaut und zur Not 
auch haut?

Wenn es sich bei dem const um einen Integertyp handelt, wird bei C++ 
kein Platz im RAM angelegt. Das ist bei C++ explizit so festgelegt.
(Demzufolge wird aus dem Modul auch keine Variable mit dementsprechenden 
Namen exportiert.)

Die Idee dahinter ist, die Präprozessoranarchie von C einzudämmen, und 
eben, z. B. ein
const int A = 3;
ein Ersatz für das
#define A 3
sein zu lassen, ohne Speicher zu verschwenden.

Herrje, hier ist ja mal wieder die geballte Fachkompetenz unterwegs, ...

Wie oft manch Inschenör hier schon bei maximal mittelschweren 
algorithmischen Fragestellungen ausgestiegen ist durfte man ja schon 
bewundern. Der Begriff "Dynamische Programmierung" ist nur selten 
bekannt und die einfache pragmatische Lösung des Ings entpuppt sich als 
die naive Brute-Force Lösung...
Von Themen wie Komplexitäten und Graphen mal ganz abgesehen, ...

der Dipl-Inf.-Hasser schrieb:
> Wenn es sich bei dem const um einen Integertyp handelt, wird bei C++
> kein Platz im RAM angelegt. Das ist bei C++ explizit so festgelegt.
> (Demzufolge wird aus dem Modul auch keine Variable mit dementsprechenden
> Namen exportiert.)
>
> Die Idee dahinter ist, die Präprozessoranarchie von C einzudämmen, und
> eben, z. B. ein
> const int A = 3;
> ein Ersatz für das
> #define A 3
> sein zu lassen, ohne Speicher zu verschwenden.

Was haben Sie für einen Computer? Ein Computer, bei dem der Binärcode 
nicht in den Hauptspeicher geladen wird?

Das Verwenden von Konstanten hat außerdem ganz andere gewichtige 
Vorteile. Einerseits kann der Compiler besser optimieren, andererseits 
verringern sich typische Programmierfehler. In funktionialen 
Programmiersprachen kann man noch viel bessere Sachen machen. Wenn eine 
Funktion f(x1,x2,...xn) die Eigenschaft hat, zu jedem Zeitpunkt immer 
das gleiche Ergebnis (bei gleicher Eingabe zurückzugeben), dann kann man 
die Funktion schon zur Übersetzungszeit ausgeben, wenn die Funktion nur 
Konstanten als Eingabe hat. So würde "fakultaet(5)*x" schon zur 
Übersetzungszeit zu "120*x" evaluiert werden und man spart sich fünf 
Multiplikationen pro Durchlauf.

> Vielleicht sollte es heißen "Ingenieure entwickeln irgendwie Software"
> ;-)

"Besser" ist etwas unpassend in diesem Kontext, da es viele Kritierien 
zur "guten" Softwareentwicklung gibt

- schneller Code (da sind #defines oft besser)
- kurz, kompakt
- leicht portierbar
- OS - unanhaengig
- leicht lesbar, gut kommentiert
- nicht leicht lesbar und kopierbar, wenn der Code geschuetzt werden 
soll
- leicht erweiterbar und pflegbar
...

Klaus Wachtler schrieb:
> Nicht einmal alle BWLer sind gleich.

machen die jetzt auch Software? ;)

BWLer machen schon lange SW.
Mit Beschränkung auf Powerpoint und Excel.

Zuckerle schrieb im Beitrag #2335435:
> Die beste Software machen die Physiker

Ich hatte letztens mit FPGA Code zu tun, den ein self made Programmierer 
mit C-Erfahrung erschaffenhatte. Alles war als SW-Konzept gelöst und 
überall blickte multi-tasking-Denken durch, wo RT gefragt gewesen wäre.

Der Herr hatte ursprünglich Physik studiert, dann 3 Jahre an der Uni 
gearbeitet und schließlich 6 Jahre Software gemacht, um dann beim VHDL 
zu landen.

Überflüssig zu erähnen, dass der Herr bei einem kleinen Dienstleister 
arbeitet, der damit protzt, super duper Ingenieure in seinem Team zu 
haben.

Gibt es eigentlich nicht mal so eine unabhängige Prüfstelle fürs 
VHDL-Entwicklen?

> Gibt es eigentlich nicht mal so eine unabhängige Prüfstelle fürs
> VHDL-Entwicklen?

Solche Prufstellen gibt es ja, nennt sich Diplom. Und je nach Inhalt 
und Tiefe hat der Absolvent einen Nachweis, was er erlent hat und damit 
in etwa können sollte. Ich habe in beiden Bereichen ähnlich tiefe 
Erfahrung, beides aber sowohl praktisch als auch theoretisch erlernt. 
Wir hatten sowohl SW-Entwurfsstrategien, Compilerbau, Unix, S5, 
Treiberentwicklung, als auch theoretische Physik, Algorithmik, 
Nachrichtentechnik, Digitaltechnik und Halbleiterphysik.

In anderen Studienrichtungen hast Du eben weniger oder gar keine 
Software, ausser vielleicht ein bissl C. Kommt halt drauf an!

Jeder Arbeitgeber oder Projektgeber muss sich am Ende selber 
entscheiden, wen er nimmt und was sein Aufgabengebiet erfordert! Wenn es 
nur einfaches Programmieren ist und sich der Sachverhalt auf Physik 
bezieht, dann mag ein SW-kundiger Physiker genau der Richtige sein.

Ob so jemand in VHDL fit ist, das Denken für Digitaltechnik besitzt, 
testfreundliche Entwicklungsmethoden kennt, Systemdesign beherrscht und 
sein Design im gesamtkontekt optimieren kann, sowie gleichzeitig auch 
die angrenzenden Elektronik-lastigen Themen beherrscht, das sei 
dahingestellt.

Ich bevorzuge in meinem Team Fachleute, die die Erfahrung einiger Jahre 
haben, in dem Feld gerabeitet haben, das sie bearbeiten und das auch 
vernüftig studiert haben.

Ingenieure entwickeln per se nicht besser Software. Das sagen 
Ingenieure, die ihre Kompetenzen - Softwarekenntnisse - leider nicht 
einschätzen können, weil sie dazu nicht in der Lage sind. Wenn hier 
viele der Meinung sind, dass das so ist, behaupte ich von der Kanzel 
herunter: "Informatiker entwickeln besser Schaltungen".
So'n Quatsch, Rosa

Surfen ist auch so etwas, was manche nicht so richtig beherrschen :-)

Nils S. schrieb:
> static code analysis

Ich glaube, darum geht es ja, dass man solche Dinge erlernt hat und 
nicht erst erfragen muss. Man kennt den Begriff, die Anwendungen, kann 
es einordnen und von anderen Fällen abgrenzen und hat es wenigstens 
schon mal benutzt.

Dafür ist das Studieren da!

In der Software wie in der Hardware gibt es Hundertausende solche 
Begriffe, Methoden, Vorgehensweisen und Tricks und wer das nicht gesehen 
und später auch im Überblick hat, wird an viele Aufgaben komplett falsch 
herangehen.

Da muss man sich einfach auch mal selber zurücknehmen und akzeptieren, 
dass ein Einzelner immer nur einen winzigen Ausschnitt von Wissen 
behaben kann.

Alles andere wird er zu simpel einstufen und glauben, er kann es 
irgendwie auch.

Harald schrieb:
> Jeder Arbeitgeber oder Projektgeber muss sich am Ende selber
> entscheiden, wen er nimmt und was sein Aufgabengebiet erfordert!

Das stimmt absolut. Leider werden heute überall Anfänger und 
Billigheimer drangelassen, statt Fachleute zu nehmen, weil niemand mehr 
deren Wert erkennt, denn die Entscheider sind selber Billigheimer, die 
sich überschätzen.

Mark Brandis schrieb:
> Nils S. schrieb:
>>>C, C++, Java gibt es da jede Menge
>> Würde mich mal interessieren, was genau da nach was geprüft wird. Leider
>> finde ich nur eine Hand voll Tools zum Download wenn ich nach "C Test
>> Tools" suche. Kannst du mir ein Stichwort oder einen Wikiartikel oder so
>> nenen, in dem sowas beschrieben wird?
>
> Statische Code-Analyse, Open Source:
> http://en.wikipedia.org/wiki/List_of_tools_for_sta...
>
> Statische Code-Analyse, kommerzielle Anbieter:
> http://en.wikipedia.org/wiki/List_of_tools_for_sta...

Man sollte unterscheiden zwischen statischer Code-Analyse und Test. 
Testframeworks wie TestNG und JUnit für Java, CppUnit für C++ usw. Damit 
schreibt man wohldefinierte Testfälle, die dann mindestens einmal 
täglich ausgeführt werden.

Man sollte statische Codeanalyse nutzen, ohne auf Testfälle zu 
verzichten.

Klaus Wachtler schrieb:
> Wer glaubt eigentlich allen Ernstes, alle Ings würden gleich gut oder
> gleich schlecht SW entwickeln?
> Entsprechend Informatiker, Physiker oder andere?
>
> Noch platter geht es ja kaum.
>
> Nicht einmal alle BWLer sind gleich.

Aber nachts sind alle Katzen grau. Informatiker sind halt die 
Spezialisten. Das sollte man akzeptieren und sich nicht auf seiner 
Erfahrung ausruhen. Softwarenentwicklung ist mehr als nur Programmieren, 
Hauptsache, es funktioniert.

Ich freue mich immer, wenn jemand Softwareentwicklungsliteratur liest, 
was selbst unter Informatikern nicht immer der Fall ist. Von einem guten 
Entwickler erwarte ich, dass er sich auskennt in Algorithmen und 
Komplexitätstheorie, Automatentheorie, Architektur und 
Programmiersprachen. Man muss nicht aspektorientierte Programmierung 
anwenden oder mögen, aber man muss wissen, was es damit auf sich hat. Da 
Nichtinformatiker kaum mit Komplexitätstheorie und Algorithmik in 
Berührung kommen, haben sie gewisse Nachteile.

So sehe ich häufig, dass einige Menschen es sich besonders kompliziert 
machen, weil unbedacht einen Mealy-Automaten bauen, wenn es doch ein 
Moore-Automat genauso getan hätte. Nein, nicht genauso, sondern bessern, 
denn: Ein Mealy-Automat ist viel komplizierter zu pflegen. Oft entstehen 
durch solche unbedachten Entscheidungen Zeitverzüge von vielen 
Manntagen. Das ist kein Witz!

>So sehe ich häufig, dass einige Menschen es sich besonders kompliziert
>machen, weil unbedacht einen Mealy-Automaten bauen, wenn es doch ein
>Moore-Automat genauso getan hätte. Nein, nicht genauso, sondern bessern,
>denn: Ein Mealy-Automat ist viel komplizierter zu pflegen. Oft entstehen
>durch solche unbedachten Entscheidungen Zeitverzüge von vielen
>Manntagen. Das ist kein Witz!
Ist es tatsächlich nicht. Vormals Elektrotechnik habe ich neben BWP auch 
noch Informatik studiert, weil ich als E-Techniker zwar programmieren 
konnte, aber keine Ahnung von Komplexitäts- und Automaten-Theorie hatte. 
Ich hatte die Basics einfach nicht drauf gehabt. Vielleicht hätte ich 
vor zwei Jahren auch behauptet, ich als E-Techniker kann doch Software 
entwickeln. Konnte ioch aber aus heutiger Sicht eben nicht.

Rosa

Hallo,

vergesst mal das Studium, Einarbeiten kann man sich immer, soweit 
Interesse da ist. Praxis zählt viel mehr!!!

bruder-herz schrieb:
> vergesst mal das Studium, Einarbeiten kann man sich immer, soweit
> Interesse da ist. Praxis zählt viel mehr!!!

Aber ohne ein vernünftiges Fundament wirst du immer ein Hacker bleibt. 
Und dieses Fundament wird in einem Studium gelegt.

Die Programmierer streiten sich, wer den Job verdient und wer gehen 
muss. So ist es richtig. Ich habe mich auch schon in meiner FH 
beschwert. Die Hochschule hat kaum eigene Stellenangebote, suggeriert 
aber, dass das Informatik-Studium Chancen bringt. Für den Prof. eine 
feine Sache: Geld kommt und die Arbeit ist bequem. Viele Dinge sind 
Halbwissen:

+ Kein Programmieren von Interrupts im Fach Betriebssysteme, aber immer 
schön das Unix anhimmeln.
+ Hardware ist auch kein Problem: Das Bild der Intel-CPU betrachten aber 
bitte nirgendwo den Program-Counter setzen.
+ N über K sollte man schon erklären, am besten aber nicht mit dem 
Urnenversuch.
+ 4 Jahre Informatikstudium ohne 10-Fingersystem sind überhaupt kein 
Problem, man kann es dann mit SEHR-GUT abschließen.
+ Mit welcher Suchtechnik findet die SQL-Datenbank innen einen RECORD: 
Nobody knows...
+ FUZZY-TECHNIK bekommt man erklärt ohne wissen zu müssen, dass 
Regelkreise auch schwingen können. Aber große Visionen!
+ Für den Netzwerk-Prof. sind Kabel nur wegen der Stabilität verdrillt: 
Dann schreibt doch mal über Satelliten-Internet.

Neben Embedded-Steuerungen sollten Informatiker eigentlich auch den PC 
programmieren. Aber das wird ja in den USA gemacht. Folgenden Satz hätte 
ich in der FH hören wollen: "Deutschland ist ein IT Importland". So kann 
ich nun versuchen zwischen Logitech und USB-Hub noch eine Marktlücke zu 
finden. Als Informatiker erlebte ich die Embedded-Programmierung eher 
autoritär. "Du sollst viel Text produzieren und Klappe halten!" Es 
werden hier sämtliche Teile des Projektes exakt benannt und 
dokumentiert.

Es ist eben auch so, dass die meisten selbsternannten Informatiker 
nichts drauf haben und denken, eine Studium befähigt sie zum 
intelligenten Planen und Arbeiten. Codezeilen hinschreiben ist aber 
letztlich auch nichts anderes, als Sätze hinformulieren, wie es ein 
Theologie oder Soziologiestudent tut.

Wo ist da die Leistung???

Wissen ist gefragt! Wer das Wissen hat, warum bei der Commerzbank wieder 
mal ein Server nicht  richtig geht, der kriegt dort als Entwicker 
85TDE. Wenn er weiss, warum bei Mama der Staubsauger nicht geht, kriegt 
5,- die Woche Taschengeld.

Kein Mensch braucht Programmierer. Wir haben Inder und Chinesen genug.

Robocash schrieb:
> + Kein Programmieren von Interrupts im Fach Betriebssysteme, aber immer
> schön das Unix anhimmeln.
> + Hardware ist auch kein Problem: Das Bild der Intel-CPU betrachten aber
> bitte nirgendwo den Program-Counter setzen.
> + N über K sollte man schon erklären, am besten aber nicht mit dem
> Urnenversuch.
> + 4 Jahre Informatikstudium ohne 10-Fingersystem sind überhaupt kein
> Problem, man kann es dann mit SEHR-GUT abschließen.
> + Mit welcher Suchtechnik findet die SQL-Datenbank innen einen RECORD:
> Nobody knows...
> + FUZZY-TECHNIK bekommt man erklärt ohne wissen zu müssen, dass
> Regelkreise auch schwingen können. Aber große Visionen!
> + Für den Netzwerk-Prof. sind Kabel nur wegen der Stabilität verdrillt:
> Dann schreibt doch mal über Satelliten-Internet.

Man merkt schon, dass Sie von der FH sind.

McDesign schrieb:
> Kein Mensch braucht Programmierer. Wir haben Inder und Chinesen genug.


McProgrammierer? Mit Verlaub: Programmieren oder besser gesagt, Software 
zu entwickeln, ist eine anspruchsvolle Tätigkeit. Besser als in der 
Commerzbank eine abgestürzte Software zu identifizieren, ist es, 
Software zu bauen, die

1. weniger abstürzt,

2. und wenn sie abstürzt, dann so, dass sie möglichst wenig Schaden 
anrichtet und auch nur die eine Funktionalität nicht mehr angeboten 
werden kann, die abstürtzt. Das nennt sich Robustheit.

Beispiel: Textverarbeitung. Die Textverarbeitung kommt regelmäßig in 
einen  Zustand, in der es nicht möglich ist, Wörter fett zu machen. Dann 
gibt es Exception. Bei einer guten Architektur würde einfach ein Dialog 
aufploppen und Nutzer auf die Fehlfunktion hinweisen. Bei einer 
schlechten Architektur verabschiedet sich das komplette Programm und 
damit auch das Dokument, an dem man gearbeitet hat.