Hallo Leute,
Eine Frage muß ich loswerden.:)
ich habe im Internet einbißchen recherchiert und einige
Bewerbungsanlagen von Akademiker und sonstigen angesschaut. Dabei ist
mir aufgefallen dass die Angabe über Programmierkenntnisse von einigen
nicht immer einheitlich sind.
Wenn ein Dipl. Inf von sich behauptet dass er über sehr gute Kenntnisse
in C++, Java oder Assembler usw.. verfügt, dann klingt es irgendwie
schon plausibel.
Wenn jedoch ein Dipl. Übersetzer oder Germanist im deren Lebensläufe
dasselbe angibt, dann muß man doch darüber nachdenken, was eigentlich
"sehr gut" oder "fortgeschritt.." bedeutet. Das macht mich total
unsicher.
Wann spricht man von "sehr gut" oder "fortgeschritt.." Kenntnisse ? Was
meint Ihr !
Gruß
sehr gut => man kann alles was innerhalb seines aufgabenfeldes liegt.
dh wenn nen Germanist sich nen vb makro zum suchen/ersetzen schreiben
kann ist es bezogen auf seine tätigkeit sehr gut..^^
Ich frage mich was es bringt eine Programmiersprache "sehr gut" zu
beherschen? Also ich verdiene jetzt schon einige Jahre meine Brötchen
als Programmierer. Ich weiß mittlerweile auch was ein
System.out.println("X: " + ++a); ergibt. Tatsächlich hab ich das außer
bei den Aufgaben die man bei den Vorstellungsgesprächen/Bewerbungen so
bekommt, noch nie gebraucht.
Viel wichtiger ist doch die Analyse und das Design. Wenn man das richtig
hat dann ist das umsetzen in einer Programmiersprache doch die
leichteste Übung.
Vielleicht ist es ja auch bei großen Softwarehäußern die die Entwicklung
in den fernen Osten verlegen anderst. Aber da braucht man dann als
Entwickler eh nicht hin gehen :-)
Manuel wrote:
> Ich kenne keinen Compiler der sich für Rechtschreibung interessiert...
WTF?! Kennst du etwa einen Compiler, der sich NICHT für Rechtschreibung
interessiert?
>Wenn ein Dipl. Inf von sich behauptet dass er über sehr gute Kenntnisse>in C++, Java oder Assembler usw.. verfügt, dann klingt es irgendwie>schon plausibel.
Informatik studiert und Assembler...?
Hm...
Grundkenntnisse: Man kann einen Quellcode lesen, verstehen und
modifizieren sowie selbst einfache holprige Programme schreiben.
Fortgeschrittene Kenntnisse/gute Kenntnisse: Man kann problemlos
grössere Programme schreiben. Abstriche im Stil, in der Performance oder
in der Nutzung spezieller Sprachkonstrukte liegen aber drin.
Sehr gute Kenntnisse: Man kann sämtliche Sprachkonstrukte gezielt
einsetzen, um stilistisch saubere und performante Programme zu
schreiben. Gelegentliche Unsicherheiten über sehr spezielle
Sprachkonstrukte liegen aber drin.
In der Tat sind die Kenntnisse auf den Beruf bezogen. Von einem sehr
guten Informatiker kann man erwarten, dass er einen Webserver mit ASM
auf einem AVR schreibt. Von einem Germanisten erwartet man nur dass er
Excel kann.
"Von einem sehr guten Informatiker kann man erwarten, dass er einen
Webserver mit ASM auf einem AVR schreibt."
Das ist natürlich völliger Quak. Ein guter Informatiker würde nie soviel
Zeit in Assembler stecken, vor allem dann, wenn's gar nicht nötig ist;
er weiß auch wirtschaftlich zu denken und zu handeln.
> Grundkenntnisse: Man kann einen Quellcode lesen, verstehen und> modifizieren sowie selbst einfache holprige Programme schreiben.
Dann besteht der Großteil heutiger Informatiker aus Leuten mit
Grundkenntnissen. Die Zahl derer die Projekte nur durch Anpassung
fertiger Routinen diverser Opensource-Tools zusammenstricken und selbst
keine vernünftige Softwarestruktur hinbekommen ist größer als man
denkt... ;)
Leute, alles ist relativ.
Wenn der Hausarzt schreibt, er kenne sich in Kardiologie super aus, ist
das anders zu bewerten, als wenn der Kardiologe schreibt, er sei sehr
gut in Kardiologie. Mit anderen Worten das sehr gut des Hausarztes langt
beim Kardiologen zum mittelmäßig. Natürlich hat der Hausarzt dafür
andere Vorteile.
Genauso die Frage: "Was ist ein Star".
Die Schülerband, das Nabtaltuo, Julio Iglesias oder Michael Jackson.
Alle sind Stars. Die ersten die Schulstars, die zweiten deutsche Stars
und die letzten beiden Weltstars.
Bei einer Programmiersprache kommt noch hinzu, daß sich die Kenntnisse
schnell verbessern oder verschlechtern. Wenn man ein viertel Jahr nicht
programmiert hat, fallen einige Dinge schon schwerer als wenn man es
täglich macht. Hinzu kommt die Frage des Anspruchs. Der Informatiker
empfindet vielleicht hardwarenahes Programmieren (Assembler) als schwer
und schätzt sich dort als schlecht ein, kann dafür jedoch C# im Schlaf.
Ein guter Programmierer weiss, was die Sprache alles kann. Ein sehr
guter hat 80% wieder vergessen, weil wer weiss, wovon man die Finger
lassen sollte.
Weil das so schwammig ist, wird ja auch meistens in Monaten/Jahren
Erfahrung gerechnet.
Ggf. wird dann noch nach konkreten Projekten/Taetigkeiten gefragt.
Jürgen
Ohh wrote:
> Von einem sehr> guten Informatiker kann man erwarten, dass er einen Webserver mit ASM> auf einem AVR schreibt.
[X] Du denkst, Informatiker lernen im Studium gut zu programmieren.
[ ] Du weißt, worum es im Informatikstudium wirklich geht.
Von einem guten Informatiker erwartet man das er einen Webserver nicht
in Assembler schreibt.
Jetzt mal im ernst. Ein guter Informatiker ist nicht ausgebildet um als
Programmierer zu arbeiten. Der sollte sich wichtigeren Dingen zuwenden.
Manuel Kampert wrote:
> Jetzt mal im ernst. Ein guter Informatiker ist nicht ausgebildet um als> Programmierer zu arbeiten. Der sollte sich wichtigeren Dingen zuwenden.
Studierst du noch, oder woher kommen solche Aussagen? Wer soll denn die
Software entwickeln?
Peter Stegemann wrote:
> Manuel Kampert wrote:>>> Jetzt mal im ernst. Ein guter Informatiker ist nicht ausgebildet um als>> Programmierer zu arbeiten. Der sollte sich wichtigeren Dingen zuwenden.>> Studierst du noch, oder woher kommen solche Aussagen? Wer soll denn die> Software entwickeln?
Entwickeln soll sie schon der Informatiker, programmieren tuts dann der
Programmierer.
Ein Architekt weiß schließlich auch, wie man aus Mörtel und Ziegeln eine
Wand baut, macht dass dann aber doch nur selten selber...
Ernst Bachmann wrote:
> Entwickeln soll sie schon der Informatiker, programmieren tuts dann der> Programmierer.
Das ist Unsinn und fernab der praktischen Realiaet. Leider wird sowas
durch Professoren und Manager gerne verbreitet. Das fuehrt regelmaessig
zu katastrophalen Projekten, weil man in diesen Kreisen wirklich meint,
man koennte Software Top-Down designen (am besten Klickediklick im
UML-Designer) und dann die kleinen Einzelteile irgendwo billig
"ausprogrammieren" lassen.
> Ein Architekt weiß schließlich auch, wie man aus Mörtel und Ziegeln eine> Wand baut, macht dass dann aber doch nur selten selber...
Vergleiche sind meistens falsch und als Argumentersatz kaum zu
gebrauchen.
>Das ist Unsinn und fernab der praktischen Realiaet
Nein ist es nicht. Der Architekt entwickelt das Konzept, sichert
die von ihm erdachte "Linie" durch Design-Reviews und Code Reviews ab.
Der Programmierer setzt um. Dann noch Testplan auf Basis der
Anforderungen erstellen, ebenfalls reviewen und fertig.
Funktioniert wunderbar - mehrfach in verschiedenen Projekten
durchexerziert, nicht theoretisch, ganz nah an der Realität.
Der gute Informatiker weiß, welche Sprache sich für welche Aufgaben und
Anforderungen eignet.
Der sehr gute Informatiker prügelt dem AVR zunächst Java ein und
abstrahiert und kapselt dann sämtliche Portpins als Klassen, sodass er
dann mit zehn Seiten Quelltext und zwanzig Vererbungsebenen die
gottverdammte LED zum Blinken bringt.... SCNR
Sven Pauli wrote:
> Der sehr gute Informatiker prügelt dem AVR zunächst Java ein und> abstrahiert und kapselt dann sämtliche Portpins als Klassen, sodass er> dann mit zehn Seiten Quelltext und zwanzig Vererbungsebenen die> gottverdammte LED zum Blinken bringt.... SCNR
Du liegst mit dem Witz garnicht so falsch.
Der erste Programmierer setzt die Bits vom AVR direkt und macht draus
einen Zweizeiler. Kurz, elegant und funktional. Und scheitert im ersten
Anlauf an einem PIC, weil er nicht gleich kapiert, dass dort Einsen und
Nullen vertauscht sein können (bei der Richtung vom Pin).
Der zweite Programmierer definiert sich für die jeweiligen
Funktionsmodule wie Portpins, UART usw jeweils abstrahierte Klassen
(naja, manchmal ubloss ein paar passende Präproz-Makros), um die
direkten Hardwarefunktionen in einen allgemein gehalteneren API
umzuwandeln. Ist anfangs einige Arbeit, und man muss etwas Überblick
haben.
Natürlich ist das am Beispiel einer LED absurd. Aber bei UART, SPI, I2C,
CAN nicht mehr. Und wenn der API des zweiten Programmierers leidlich
sauber konstruiert ist, dann wird der beim Umstieg von einer Plattform
zur nächsten nur anfangs Arbeit mit der Portierung des APIs haben, die
diesen verwendenden Programme hingegen sind viel leichter übertragbar
weil dort nur noch wenig plattformabhängiger Code enthalten ist.
Ich meine damit übrigens nicht die leidigen HALs von Atmel AT91, ST usw.
Die ersetzen regelmässig nur die eine Abhängigkeit durch die andere.
Und in diesem Unterschied in der Vorgehensweise steckt ein bischen was
von der Qualifikation eines Informatikers. Wobei sich natürlich auch
andere solche Techniken aneignen können, und auch ein Informatiker
strotzdumm programmieren kann.
Naja, was ich sagen will: OOP ist auch nicht die Lösung aller Probleme,
auch wenn man das im Studium bzw. schon im Informatikunterricht so
eingetrichtert bekommt. Das ist alles in Relation zu sehen, wie du ja
beschrieben hast.
Wobei eine Abstrahierung nicht unbedingt OOP bedeuten muss, auch wenn
jemand, der das mal verwendet hat, es gerne auch darauf anwenden wird.
Auch weil dabei so schöne Dinge wie generische Pufferklassen für die
Kommunikation zwischen Transfermodulen wie UART und der Anwendung
rauskommen können.
In einfachen Fällen kann es auch auf ein paar Präprozessormakros
rauslaufen, mit denen man die Portmanipulation des Codes eines
Softwaremoduls für Text-LCDs, 1-Wire Devices oder Feuchtesensoren von
der realen Bitwelt abhebt und damit portabler gestaltet.
