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ß
Ich würde WiInf empfehlen, wenn dir Wirtschaft bissel Spass macht. Gehälter sind recht manierlich. Weiberquote wesentlich besser.
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 :-)
Die Informatiktheorie ist deshalb so geil, weil sie so abgehoben ist, wie sonst nur Relativitätstheorie und Quantenphysik.
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.
Frauen halten doch nur vom Studium ab.
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.
> Auswahl ist durchaus vorhanden!
Ihr habts immer noch nicht kapiert! Die 3,7 gilt für GANZ Karlsruhe,
scheiss egal an welche Uni ihr geht.
Ich weiß nicht wo du deine Informationen her hast, aber in Karlsruhe wohnen mehr Frauen als Männer. Hier die Daten aus dem Jahr 2006 http://de.wikipedia.org/wiki/Einwohnerentwicklung_von_Karlsruhe#Bev.C3.B6lkerungsstruktur Auch im ganzen Regierungsbezirk Karlsruhe wohnen mehr Frauen als Männer. Daten aus dem Jahr 2009: http://www.statistik.baden-wuerttemberg.de/Veroeffentl/Statistische_Berichte/3126_08001.pdf Und an der TH sind es 27,2% Frauen. http://de.wikipedia.org/wiki/Karlsruher_Institut_f%C3%BCr_Technologie Das entspricht einem Verhältnis von etwa 1 zu 3,68.
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?
qw schrieb:
> Sieht doch ziemlich ausgeglichen aus, oder?
Wenn man nicht genau hinschaut, ja. ;)
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? ;)
Gelegenheit macht Liebe, wie man an den vielen Ärzte-, Juristen-, Lehrer- und BWLer-Paaren sieht. Wenig Frauen = wenig Gelegenheit = wenig Liebe ;)
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
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.