Hallo!
ich mache gerade mein Abi und muss mich solangsam entscheiden, was und
an welcher Uni ich studieren soll. Als Fachrichtung kommt entweder
Informatik oder Wirtschaftsinformatik infrage, als Uni Karlsruhe und
evtl. Mannheim.
Persönlich würde ich eher zur Informatik tendieren, aber angeblich wird
man da eher arbeitslos als bei Wirtschaftsinformatik.
Was sind eure Erfahrungen b.z.w. Meinungen dazu? Könnt Ihr das
bestätigen oder haben beide Richtungen ungefähr gleiche Berufschancen?
Gruß
Das Informatiker eher arbeitslos werden als WInfs wage ich mal stark zu
bezweifeln. Wenn dann eher in die andere Richtung, da dir als
Nicht-Bindestrich Informatiker viel mehr Branchen offen stehen. Die
Frauenquote ist natürlich ein Argument.
Ich weiß nicht wie die Studiengänge in Mannheim/Karlsruhe aufgebaut sind
aber zumindest bei uns war es so, dass WInfs das exakt gleiche
Grundstudium wie die BWL'er hatten. Je nach persönlicher Neigung kann
das tödlich langweilig sein.
Es kommt natuerlich stark darauf an, wo du studierst. Ich selbst
studiere Informatik (angw. mit Mathe & Physik) in Goettingen und kann
ueber die Wirtschaftsinformatik hier nur den Kopf schuetteln. Hingegen
habe ich mit Karlsruher WiInfs bisher nur gute Erfahrungen gemacht, da
koennte sich das also durchaus lohnen.
Ich wuerde dir mal empfehlen, dich mal in Vorlesungen beider
Studiengaenge vor Ort zu setzen und mit den Studis zu sprechen.
Normalerweise sind die Menschen da ganz nett ;) .
Gruesse
Marvin
Kleiner Nachtrag: Bei uns ist es ueblich, dass Studenten, die Informatik
nicht schaffen, einfach in die Wirtschaftsinformatik gehen - und dort
dann auch durchaus gute Noten schreiben. Aber wie gesagt: Das laesst
sich natuerlich nicht von Goettingen auf andere Unis uebertragen.
Gruesse
Marvin
Das perplexe ist, die WiInfs verdienen Schweinegeld, wenn sie für die
richtige Firma arbeiten. Die Ausbildung ist halt weniger
Informatik-theoretisch. Aber was ist an der Informatik-Theorie
eigentlich so geil?
Richtig brauchen tut das eh kaum eine Firma. Meistens endet ihr irgendwo
als "Programmierer" deswegen bin ich lieber Ingenieur geworden :-)
Dr. Wolfram Draht schrieb:
> Die Informatiktheorie ist deshalb so geil, weil sie so abgehoben ist,> wie sonst nur Relativitätstheorie und Quantenphysik.
Bullshit.
Andererseits... Die Quantentheorie ist so abgehoben auch nicht. Immerhin
stellt sie beispielsweise die Grundlage für des Controlleranwenders
allerliebten Flash-Speicher.
Hallo,
danke für eure Beiträge.
Also mit BWL hab ich überhaupt keine Probleme, hab allerdings Angst,
dass bei WiInf eben zu viel an Info auf der Strecke bleibt, das mich
doch etwas mehr als BWL interessiert (auch theoretische Informatik hat
so seinen Reiz).
Was mich aber sehr wundert ist, dass bei WiInf die Frauenquote besser
sein soll, da ich bisher nur das Gegenteil gehört habe und eine meiner
weiblichen bekannten sogar extra nicht WiInf genommen hat, weil das ein
Männerfach sei.
Ein paar Vorlesungen zu beiden Richtungen zu besuchen ist eine gute
Idee, das werd ich ganz bestimmt noch machen.
Wie siehts eigentlich mit Berufen aus, die man als Wi-Informatiker
antreten kann? Liegen sie ausschließlich im Wirtschaftssektor oder kann
man auch als "normaler" SW-Entwickler eingestellt werden, wenn man
entsprechend gute Studiumergebnisse vorlegen kann?
Gruß
Natürlich kann man auch als Wirtschaftsinformatiker Softwareentwickler
werden. Du glaubst ja gar nicht, was da so alles als Softwareentwickler
kreucht und fleucht: Elektrotechniker, Mathematiker, Maschinenbauer,
Techniker... Die Branche wimmelt nur so von Quereinsteigern.
Es kann nützlich sein, wenn man z. B. Maschinen ansteuert... ein
Maschinenbauer kann dann sein Wissen über Maschinenbau verwerten. Aber:
Das große Problem ist, dass die vielen Quereinsteiger auch noch den Ton
angeben müssen, wenn es um Sachen geht, von denen sie keine Ahnung
haben. Gerade wenn es um das Thema Algorithmik geht, müssen die
Informatiker gefragt und auch von den Vorgesetzten unterstützt werden.
Durch Inkompetenz werden dann Algorithmen verwässert, Seiteneffekte
einprogrammiert usw. usf. Nur weil die Nichtinformatiker programmieren
können, können sie damit noch lange nicht das Gleiche wie Informatiker.
Ich habe (leider) genau das erleben müssen, wie Nichtinformatiker bei
der Softwareentwicklung den Ton angeben wollten, in Bereichen, von denen
sie selbst sagten, dass sie davon nichts verstünden. Und das Gros der
Softwareentwickler weiß nicht, was eine topologische Sortierung ist, die
wissen nicht, wie Graphen definiert sind, und haben noch nie etwas von
folgenden Personen gehört: Turing, Dijkstra, Wirth, Bertrand Meyer,
Codd... Meinen aber, etwas von Objektorientierung zu verstehen oder
relationale Datenbanken, was beides bei Nichtkenntnis von Meyer und Codd
ein Problem sein dürfte.
Stattdessen denken die, Bill Gates säße auf dem Olymp der Informatik,
zusammen mit Brin und Page.
Ein Wirtschaftsinformatiker ist daher genauso zur Softwareentwicklung
geeignet wie viele andere auch, sofern er die harte Theorie
verinnerlicht und durch Praxis ergänzt. Praxis alleine genügt nicht!
Meine Empfehlung: Informatik studieren, aber ohne Minimalismus. Es ist
wichtig, viele verschiedene Perspektiven zu erreichen. Ich habe
festgestellt, dass mein Informatikstudium bei weitem nicht abdeckte, was
mich aus der Informatik interessiert hat. Der Lambda-Kalkül wurde gar
nicht thematisiert, Logik höherer Ordnung auch nicht, Objektorientierung
wurde thematisiert, aber in einer Vorlesung, in der ich es nicht
erwartet hätte (übrigens war die Vorlesung super). Diese Vorlesung war
schlecht besucht und ich muss sagen, viele meiner Komilitonen haben da
etwas verpasst.
@Dr. Wolfram Draht:
Klingt sehr nach Uni-geschädigt. Die Praxis im Großteil der Industrie
sieht anders aus.
Diesen hochtheoretischen Kram, den du da nennst, braucht man höchstens
in stark wissenschaftlich arbeitenden Unternehmen oder Instituten,
selten oder gar nicht in der angewandten Softwareentwicklung. In der
Embedded Software kommt es vielmehr auf eine Mischung aus gutem Wissen
aus Elektronik, Software und Wissenschaft an, die oft weniger
theoretisch ist, als was du da nennst.
Bin Entwickler, TH-Ingenieur Nachrichtentechnik, mache jeden Tag
Software, Hardware und diskrete Nachrichtentechnik. Ein Großteil der
Software wird heute schon aus Zeitgründen oft durch Ergänzung
bestehender Implementierungen in eigene Projekte integriert, keiner
erfindet das Rad jeden Tag neu und fängt mit Uni-Theorie an.
Bevor das Dementi in die falsche Richtung geht: war selbst an der Uni
recht erfolreich und interessiert an der ganze Theorie, aber meine
Vermutung und die Belehrungen älterer berufstätiger Ingenieure waren
auch nicht falsch:
Man braucht andere Dinge für die Praxis und ein guter Ingenieur ensteht
durch die tägliche Arbeit und Erfahrung, nicht durch die Uni.
Also, Muttchen/Onko, ett stimmt nitt, watt du hier schreibst.
Abiturient schrieb:
> Was mich aber sehr wundert ist, dass bei WiInf die Frauenquote besser> sein soll, da ich bisher nur das Gegenteil gehört habe und eine meiner> weiblichen bekannten sogar extra nicht WiInf genommen hat, weil das ein> Männerfach sei.
Die Argumentationslogik dürfte vermutlich sein:
BWL --> Frauenquote recht hoch
Informatik --> Frauenquote hält sich doch eher in Grenzen
Wirtschaftsinformatik --> irgendwo dazwischen dann wohl.
"Diesen hochtheoretischen Kram, den du da nennst, braucht man höchstens
in stark wissenschaftlich arbeitenden Unternehmen oder Instituten,
selten oder gar nicht in der angewandten Softwareentwicklung."
Genau der Einstellung haben wir es zu verdanken, dass massenweise
unleserliche, völlig ineffiziente Software sowohl für das
Wartungspersonal als auch für die Anwender täglichen Ärger bedeutet. Ich
komme aus der Ecke Elektronik/Technische Informatik. Auch ich habe
während des Studiums die Informatik eher von der praktischen Seite
erfahren. Ich habe jedoch, um mein Wissen ein wenig zu ergänzen, z.B.
folgende Bücher im Regal stehen:
Compilerbau (Aho, Ullman)
Algorithmen und Datenstrukturen (Ottman, Widmayer)
Informatik (Aho, Ullman)
Die Sprache der Maschinen
und weitere
Dann diverse Bücher über OOP, UML, Datenbanken, Entwurfsmuster etc.
Allerdings würde ich die og. Bücher, vielleicht außer "die Sprache der
Maschinen" und Teile aus Aho/Ullmans "Informatik" auch in die praktische
Ecke einordnen. Aber wenn man die Bücher gelesen hat, versteht man
zumindest die Grundlagen der Informatik. Obwohl ich seit Jahren nicht
direkt in der SW-Entwicklung tätig bin, sehe ich doch im Vergleich zu
Kollegen immer wieder, dass grundlegende theoretische Kenntnisse in
vielen Fällen auch "interdisziplinär" Vorteile bringen können. Wo viele
meiner Kollegen mit brute force arbeiten oder mich um Unterstützung
bitten, fühle ich mich trotzdem noch sicher ;-)
"Diesen hochtheoretischen Kram, den du da nennst, braucht man höchstens
in stark wissenschaftlich arbeitenden Unternehmen oder Instituten,
selten oder gar nicht in der angewandten Softwareentwicklung."
Kommt drauf an was man unter "hochtheoretischem Kram" versteht. Formale
Sprachen und Berechenbarkeit muss man sicher nicht fehlefrfrei
rezitieren können. Aber in vielen Berufen, in denen "die Gefahr"
besteht, in die SW-Entwicklung reinzurutschen, fehlen selbst elementare
Grundlagen. Die Ergebnisse liegen dann irgendwo zwischen "eigenwillig"
und "nicht verwendbar".
Ich bin auch eher praktischer Natur, dennoch sehe selbst ich täglich
wirklich schlimme Dinge ;-)
Gast1 hat verstanden, worum es mir geht. Natürlich nicht um formale
Sprachen und Berechenbarkeit, aber einfache graphentheoretische Probleme
sollte man schon kennen. Und ich habe bei der Beschäftigung mit der
Graphentheorie nicht nur diese Algorithmen gelernt, sondern auch die
Formalisierung von Problemen.
Und der Meinung der betagten Ingenieure muss ich widersprechen: Praxis
ist nicht das Non-Plus-Ultra. So kann nur jemand reden, wer das
theoretische Fundament zur SW-Entwicklung nicht hat. Und ich meine nicht
so einen Hokuspokus wie das SCRUM-Modell. Die Vorgehensmodelle magen
ihre Berechtigung haben, zähle ich aber in großen Teilen wenig fundiert
und sind stark marketinggesteuert. Ich merke bei meiner täglichen
Arbeit, wie sehr mir mein Universitätswissen nutzt.
Eine Gefahr aufgrund der mangelnden Theorie ist vorhanden, z. B. wenn
Akrobaten der regulären Ausdrücke nicht die Grenzen ihres
Lieblingswerkzeugs kennen. Oder auch den Vorteil, nämlich die lineare
Laufzeit O(n).
Würde man den "weltfremden" Theoretikern einfach Gehör geben, innerhalb
der Firma in Form einer Festanstellung, dann würde es die Qualität der
Software erheblich erhöhen. Auch die Geschwindigkeit der
Softwareentwicklung würde beschleunigt. Einer meiner Professoren hat uns
erzählt, kurz nachdem er uns den TopSort-Algorithmus vorgestellt hat (3.
Semester), dass gerade eine Firma aus Karlsruhe angerufen hätte, die
seit Monaten an einem algorithmischen Problem zu knabbern hätten usw.
usf. Die Lösung war banal: TopSort. - Das wirft ein schlechtes Licht auf
die Firma, finde ich. Dass man erst einen Professor anrufen muss, um
Grundlagenwissen der Informatik zu nutzen, ist wirklich ein
Armutszeugnis.
Ich komme zwar aus falscher Ecke um über Software zu sprechen (bin eher
HW-orientiert). Aber ich muss Dr. Wolfram auch widersprechen: die Praxis
ist das entscheindende Kriterium. Wenn ein "brute-force"-Algorithmus das
4-fache der Zeit braucht, wird eben ein 4-fach schnellerer Controller
eingesetzt. Oder der um 0.07€ teuerer Quarz eingesetzt.
Wir haben oft(immer) Requirements abzudecken, und diese werden mit
möglichst geringem Aufwand abgedeckt. Ist es ein Teil, das in
zweistelliger Millionenhöhe abgesetzt wird, ok, dann lohnt sich ein
Blick auf die Theorie (um 7 cent pro Bauteil zu sparen), sonst muss man
halt um 70k (AG-seitige Kosten) pro Theoretiker pro Jahr zahlen.
Quick and Dirty? Wenn es geht und die (internen und externen)Normen/Reqs
nicht verletzt, warum nicht?
Es gibt wirklich einige Produkte, die empfindlich auf den Algorithmus
(dadurch auf Geschwindigkeit) sind. Aber bei der heute verfügbaren
Rechenpower werden es immer weniger. Und die Rechenleistung pro Fläche,
und damit Preis, steigt und steigt und steigt..........
> Und die Rechenleistung pro Fläche,> und damit Preis, steigt und steigt und steigt..........
Eben. Würde mal behaupten 90% des Uni-Informatikkrams ist zwar ganz nett
(wenn es einen interessiert) aber in der Praxis des Berufslebens nicht
nachgefragt.
Ich würde lieber etwas BWL machen, also WiInf, weil damit lässt sich
Geld verdienen.
Mit irgendwelchen berechenbar abstürzenden Graphalgorithmen verschreckt
ihr euch nur die Frauen ;)
Wer spricht hier von Software-Entwicklern, die das Software-Entwickeln
nicht beherrschen?
Wer sagt, dass die Theorie nicht irgendwann auf der Uni mal gelernt
werden sein sollte?
UML? Kein Problem, geile Sache, wenn das Projekt den Aufwand lohnt.
Wer unleserliche Software/Firmware entwickelt, der ist im falschen
Beruf.
Aber zu glauben, man würde an der Uni das Entwickeln lernen, ist auch
auf dem Holzweg. Die Uni vermittelt die theoretischen Grundlagen und ein
bisschen Anwendung, na und, nichts dagegen, mehr aber auch nicht. Ich
glaube, als jemand der Nachrichtentechnik im Unistudiengang TH in den
90ern abgeschlossen hat, weiss ich selbst, wovon ich rede.
Softwareentwicklung auf DSPs und Mikrocontrollern war während der Uni
mein täglicher Begleiter wie heute.
Ich habe das Programmieren Anfang der 80er auf einem ZX81 kennengelernt
mit 10 Jahren, denke, heute mit 38 habe ich schon einige EDV-Geschichte
hinter mir und programmiere täglich.
Als jemand, der MSP430, AT Mega128, ARM7 und ARM9, C++ und C# sowie
Borland Delphi, GNU-Toolchain mit Eclipse sowie TI CodeComposer mit
DSP320F5510, MATLAB und SIMULINK, Labview und Linux zum täglich Brot
zählt, denke ich nicht ganz so realitätsfremd zu sein, wie Leute, die
sich auf der Uni nur in der Theorie vergraben haben, und zur
eigentlichen Entwicklung nur am Rande mal einen Controller ganz stolz zu
ihren Entwicklungsprojekten zählen.
Die Theorie ist wichtig, aber Tatsache ist, dass viele sehr theoretisch
orientiert Hochschulabsolventen bzw. Leute, die lange an der Uni waren,
meinetwegen als HiWi,
mit ihrem Wissen in die Wirtschaft gehen und meinen, es liefe dort
genauso. Das ist falsch, denn dort muss weit mehr als an der Uni der
Kompromiss zwischen Entwicklungsumfang und Zeitaufwand eingegangen
werden. Und da scheitert so mancher Hochschulkandidat daran, dass er
gerade die ersten UML-Diagramme entwickelt hat, während der andere
Kollege schon die ganze Anwendung dahingezimmert hat.
Unleserlich oder quick&dirty muss Letzteres deswegen nicht sein, dafür
aber wirtschaftlich vertretbar, und das zählt heute (leider) mehr als
alles andere, ob's einem passt oder nicht, den Chef interessiert das
selten.
Und wie schon oben angemerkt, diese hochtheoretischen Probleme werden
oft schon durch die Hersteller diverser Entwicklungs- bzw.
Simulationstools in Form von Bibliotheken bereitgestellt. Das kostet ein
paar Minuten, diese hinzuzulinken, getestet und bewährt haben diese sich
dann auch in den allermeisten Fällen, während Eigenentwicklung teuer
Zeit kostet und anfangs fehlerträchtig ist. Dafür ist oft heute keine
Zeit und oft auch kein Geld vorhanden.
So sehr es auch Spaß machen mag, aber die direkte Anwendung des
hochtheoretischen Unistoffs ist nur wenigen Unternehmen im Markt
möglich.
Wie auch, wenn Wissen sich exponentiell vervielfacht und der
Entwicklungszeitaufwand mehr oder weniger konstant bleiben soll, dann
müssen Tools her, die einem dabei helfen und die Arbeit abnehmen. Es ist
ja auch nicht so, dass jeder, der ein Betriebssystem als Unterbau für
die eigene Anwendung braucht, sich jedesmal eben so ein Linux
zusammenproggt, nur weil er auf der Uni mal Betriebssysteme gelernt hat.
Deshalb bleibe ich dabei: das, was von der Uni später in der Wirtschaft
in aller Regel gebraucht wird, ist nur ein Bruchteil, Ausnahmen
ausgenommen.
Deswegen von schlechten Programmieren oder Entwicklern mit schlechten
Resultaten zu sprechen, wäre polemisch.
Der Unbestechliche schrieb:
> Das kostet ein> paar Minuten, diese hinzuzulinken, getestet und bewährt haben diese sich> dann auch in den allermeisten Fällen, während Eigenentwicklung teuer> Zeit kostet und anfangs fehlerträchtig ist.
Das spricht nicht dagegen, Graphalgorithmen einzusetzeh. Aber man kann
sie nicht einsetzen, wenn man sie nicht kennt. Da nutzt es auch nichts,
wenn es diese Bibliotheken gibt, die man nur hinzulinken muss.
So habe ich die Erfahrung machen müssen, dass meine Kollegen (von der
FH) das Leser-Schreiber-Problem nicht kannten, demzufolge waren sie auch
nicht dafür empfänglich, sich mal bestimmte Teile des Paketes
java.util.concurrent anzuschauen. Dort gibt es Semaphoren und auch
spezielle Lösungen für Leser-Schreiber- und
Produzent-Konsument-Probleme. Wer aber sich nie theoretisch damit
beschäftigt hat, wird das auch nicht praktisch nutzen können. Denn immer
nur synchronized auf Verdacht irgendwo zu platzieren, ist Gefrickle. Es
auch für kurze Projekte besser, etwas mehr Zeit in eine saubere Lösung
zu stecken anstatt "quick and dirty" zu betreiben, denn "quick and
dirty" ist nicht zwangsläufig schneller, kostet später
höchstwahrscheinlich wieder Zeit und Nerven und natürlich Geld.
Andreas N. schrieb:
> Ich komme zwar aus falscher Ecke um über Software zu sprechen (bin eher> HW-orientiert). Aber ich muss Dr. Wolfram auch widersprechen: die Praxis> ist das entscheindende Kriterium. Wenn ein "brute-force"-Algorithmus das> 4-fache der Zeit braucht, wird eben ein 4-fach schnellerer Controller> eingesetzt. Oder der um 0.07€ teuerer Quarz eingesetzt.>> Wir haben oft(immer) Requirements abzudecken, und diese werden mit> möglichst geringem Aufwand abgedeckt. Ist es ein Teil, das in> zweistelliger Millionenhöhe abgesetzt wird, ok, dann lohnt sich ein> Blick auf die Theorie (um 7 cent pro Bauteil zu sparen), sonst muss man> halt um 70k (AG-seitige Kosten) pro Theoretiker pro Jahr zahlen.
Das wäre bei mir nicht möglich, da es um große Stückzahlen geht. 7
Cent/Stück einzusparen lohnt es sich schon wenn es um einige
Hundertausend Stück/Jahr geht. Bei zweistelligen Millionen Stück/Jahr
geht es schon um Bruchteile eines Cents je Elektronik, die sich lohnen,
wenn sie eingespart werden können. Da wird gerne in einen Experten
investiert, der sagt, dass er einen Teil der Hardware durch effiziente
Software ersetzen kann, ohne den Speicherverbrauch zu erhöhnen.
Du kannst dir mal ausrechnen was 0,5 Cent/Stück bei 30.000.000
Stück/Jahr und 5 Jahren Produktion ausmachen...
Bei kleinen Stückzahlen wird man sicherlich nicht über ein
Ratiopotential von 0,5 Cent je Elektronik reden. Da wird eher jemand
benötigt, der es irgendwie aber schnell hinbekommt, damit es günstiger
ist. Es kommt also ganz auf die Projekte an mit denen man sich
beschäftigt.
Zum eigentlichen Thema:
Uni Karlsruhe ist super. Es gibt einige sehr gute Professoren und
Dozenten an der Informatik Fakultät. Es wird an vielen interessanten
Themen geforscht mit denen man sich im Studium beschäftigen kann. Und am
Anfang unbedingt bei der O-Phasen Woche mitmachen!
Allerdings ist die Frauenquote an der Uni Karlsruhe nicht berauschend.
Es gibt aber eine PH und die GeistSoz Fakultät ;-)
Auch ist Karlsruhe zum wohnen sehr angenehm. Wohnungen direkt im Zentrum
sind bezahlbar. (Rechtzeitig anfangen eine Wohnung zu suchen bevor alle
anderen Erstis anfangen!) Es gibt auch sehr günstige Studentenwohnheime.
Das Straßenbahnnetz ist genial! Alles ist perfekt mit dem Fahrrad (gutes
Schloss kaufen!) erreichbar, da es keine Hügel oder Berge gibt. Viele
Clubs und Bars zum weggehen - für jeden Geschmack ist was dabei. Und im
Sommer liegt man im Schlosspark anstatt in die Vorlesungen zu gehen
(Viele Sonnentage und warme Temperaturen) ;-) Es gibt einige Baggerseen
in der Nähe.
Vom Flughafen Karlsruhe/Baden-Baden kann man günstig mit Ryanair durch
Europa fliegen.
Es gibt schon einige Sachen, die ich vermisse nachdem ich dort
weggezogen bin...
Omg, Karlsruhe ist total scheisse, weil es kaum Weiber gibt (das liegt
an den ganzen technischen Studiengängen dort). Da nützt dir auch der
Baggersee nischt, wenn Du nur an dir selbst rumspielen kansnt ;) Geht
blos nicht nach Karlsruhe.
Achso, um in Zahlen zu sprechen:
3,7 Studenten auf eine Studentin.
Ich komm nicht drauf klar, wie man Karlsruhe so in den Himmel loben kann
wie der Kollege oben. Omfg.
Naja, das ist die Quote an der TH. Es gibt aber noch andere Hochschulen
in Karlsruhe mit einer deutlich höheren Frauenquote: Merkur FH, HfG, PH,
HfM und andere. Außerdem müssen es auch nicht immer Studentinnen sein.
Auswahl ist durchaus vorhanden!
Was ich an dieser Diskussion interessant finde ist, dass meine Aussagen
zwei Sorten von Opponenten haben. So z. B. die Gruppe, die lieber "quick
and dirty" etwas machen will, weil es billiger sei, eben mehr in HW zu
investieren. Die andere Gruppe - hat sich leider hier nicht gemeldet -
ist besonders Stolz darauf, sehr effizient den Assembler in
Mikrocontrollerbereich einzusetzen.
Ich studiere in Mannheim und kann sagen:
1. Die Frauenquote bei den WiFos ist nicht besonders gut :D
2. WiFo hat nicht das selbe Grundstudium (nagut ist ja nun eh Bachelor)
wie die BWLer.. man kann sich das dann auch schon ein wenig aussuchen ob
man eher Informatik oder BWL machen will. Aber Hardcore Informatik ists
halt nicht. Kommt drauf an was man machen will. Für Softwareentwicklung
sicher ok.
Grüße
Der Unbestechliche schrieb:
> Wer unleserliche Software/Firmware entwickelt, der ist im falschen> Beruf.
Bei der Menge an real existierendem schlechten Sourcecode müssen dann
wohl sehr viele im falschen Beruf sein... :-/
Dr. Wolfram Draht schrieb:
> So habe ich die Erfahrung machen müssen, dass meine Kollegen (von der> FH) das Leser-Schreiber-Problem nicht kannten, demzufolge waren sie auch> nicht dafür empfänglich, sich mal bestimmte Teile des Paketes> java.util.concurrent anzuschauen. Dort gibt es Semaphoren und auch> spezielle Lösungen für Leser-Schreiber- und> Produzent-Konsument-Probleme.
Ich weiß wirklich nicht was das für eine komische FH sein soll... wir
haben alles was Du aufzählst in der Betriebssystem-Vorlesung behandelt,
und ja, ich war an einer FH.
qw schrieb:
> Ich weiß nicht wo du deine Informationen her hast, aber in Karlsruhe> wohnen mehr Frauen als Männer.
Das gilt für so ziemlich jede deutsche Stadt, nützt einem jungen Mann
aber rein gar nichts. Was willst Du als 20- bis 25-jähriger Student mit
Frauen, die locker doppelt so alt sind wie Du? ;-)
Mark Brandis schrieb:
> Das gilt für so ziemlich jede deutsche Stadt, nützt einem jungen Mann> aber rein gar nichts. Was willst Du als 20- bis 25-jähriger Student mit> Frauen, die locker doppelt so alt sind wie Du? ;-)http://www1.karlsruhe.de/Stadtentwicklung/siska/sgt/grafik/sgt02030g.htm
Sieht doch ziemlich ausgeglichen aus, oder?
Für den interessierten:
http://www.ddj.com/architect/217701907
Der Artikel behandelt das Thema, was die Unterschiede zwischen
Informatik und Softwareentwicklung sind. Es gibt auch einen Podcast bei
SE-Radio.
Andreas N. schrieb:
> Ich komme zwar aus falscher Ecke um über Software zu sprechen (bin eher> HW-orientiert). Aber ich muss Dr. Wolfram auch widersprechen: die Praxis> ist das entscheindende Kriterium. Wenn ein "brute-force"-Algorithmus das> 4-fache der Zeit braucht, wird eben ein 4-fach schnellerer Controller> eingesetzt. Oder der um 0.07€ teuerer Quarz eingesetzt.
Und genau so sehen die Ergebnisse dann aus. Kaum leserlich, schlecht
erweiterbar und wenn dann doch mal höhere Stückzahlen gebaut werden,
kann man wieder neu beginnen (oder hat einen höheren Gerätepreis).
Und wenn man schon 70k p.a. für einen Softwareentwickler ausgibt, soll
der das auch richtig machen. Und dazu gehört dann eben zwingend, dass
der auch die theoretische Vorbildung hat, das Problem effizient zu
lösen.
ich frag mich immer warum immer auf die frauenquote im eigenen
stduiengang geachtet wird. ich empfand es immer als sehr schlimm paare
aus dem gleichen studiengang zu treffen (ingenieurinzest), oder wollt
ihr euch morgens am frühstückstisch über die neusten compilerversionen
unterhalten mit eurer liebsten? ;)
Genauso ist es. Ich habe nur wenig Berufserfahrung, aber in der wenigen
Erfahrung habe ich immer wieder erlebt, wie Zeit vergeudet wird, weil
man es scheute, gute Lösungen zu durchdenken. Manchmal ist auch eigener
Gehirnschmalz notwendig und davor haben die auch Angst gehabt. Bei
meinem letzten Arbeitgeber kam es mir so vor, als würde ich mit Leuten
arbeiten, die als Kind mehrmals auf die heiße Herdplatte fassten und
beim ersten Male nicht daraus schlau wurden. Es hieß immer: Das machen
wir später. Das machen wir, wenn der Kunde meckert, das Programm sei zu
langsam. Das Programm war an dieser Stelle schon so langsam, dass die
Gui-Entwicklung erheblich verzögert wurde. Man wollte nicht einsehen,
dass es besser ist, die aktuelle (schlechte) Implementierung des
Subsystems zu ersetzen, anstatt den schlechte, fehlerträchtigen Code,
weiter zu vermehren, um dann zu refaktorieren. Was übrigens sowieso nie
gemacht wird.
Ich habe mich in meiner Entwicklungtätigkeit bei entsprechenden
Entwurfspunkten durchgesetzt, viel Zeit und Geld gespart. Gedankt wurde
es nicht, stattdessen wurde ich gemobbt. Das war ein Kleinunternehmen,
eine Frickelbude, verseucht mit Praktikern.
"Der Unbestechliche schrieb:
> Wer unleserliche Software/Firmware entwickelt, der ist im falschen> Beruf.
Bei der Menge an real existierendem schlechten Sourcecode müssen dann
wohl sehr viele im falschen Beruf sein... :-/"
ACK! Was meint ihr, wie oft ich Programme sehe mit Variablen Hilf1,
Hilf2, tmp1, tmp2? Dann ist eigentlich schon klar, was Sache ist. Viele
Leute versuchen auch, ihr ganzes "Wissen" um die Details der
eingesetzten Programmiersprache auszunutzen (z.B. bei logischen
Ausdrücken). Das Ergebnis ist dann häufig nur mit Hilfe der
Spezifikation der Sprache zu entschlüsseln. Oft wissen die Entwickler
aber selbst nicht, warum es funktioniert.
Ich habe zumeist mit Projekten bis 12 Mannmonaten zu tun. Ich würde mal
grob sagen, 75% davon sind katastrophal schlecht geschrieben.
Dr. Wolfram Draht schrieb:
> Gedankt wurde> es nicht, stattdessen wurde ich gemobbt. Das war ein Kleinunternehmen,> eine Frickelbude, verseucht mit Praktikern.
Ich frag mich grad wirklich warum....
mach lieber Winf, wenn dich auch Wirtschaft interessiert.
Die reine Entwicklung wird immer mehr ausgelagert, aber typische Winf
Tätigkeiten wie Projektleitung, Beratung usw bleibt größtenteils in
Deutschland.
Verdienen tut man dabei eh besser als ein normaler SW Entwickler
