Hallo, wenn ihr die Wahl habt, würdet ihr eher eien Stelle in der Hardwareentwicklung (Platinendesign, Stücklistenarbeit, Layout,...) oder eher eine in der Softwarentwicklung (Firmware für uC) annehmen? Was hat eher Zukunft?
Zukunft hat beides "zusammen". Wenn du das eine schon hast, mach das Andere. Resp, das auf welchen Gebiet weniger zu finden ist, vorausgesetzt es ist spannend genug.
Je nach dem um was fuer Hard und Software es sich handelt. Den ganzen Tag AVR Boards layouten macht keinen Spass. Den ganzen Tag 100-Zeiler Programme schreiben auch nicht...
Bewerber schrieb: > wenn ihr die Wahl habt, würdet ihr eher eien Stelle in der > Hardwareentwicklung (Platinendesign, Stücklistenarbeit, Layout,...) oder > eher eine in der Softwarentwicklung (Firmware für uC) annehmen? Das was du studierst hast: Informatik oder ET == Soft- oder Hardware. > Was hat eher Zukunft? Beides, keine Firmware ohne Hardware. Dann könnte man noch schauen wofür man ein Händchen hat, bei der Hardwareentwicklung tut man sich mit geschickten Finger, Improvisationstalent und Respekt vor elektrischen Strom besser also ohne, Softwareentwicklung braucht solche praktischen Talente nicht.
Bewerber schrieb: > in der Hardwareentwicklung (Platinendesign, Stücklistenarbeit, Layout,...) Hardwareentwicklung beginnt viel, viel weiter vorne. Das, was du hier aufgezeigt hast, ist quasi der Endspurt. Und tatsächlich zu mindestens 70% reine Verwaltungstätigkeit. > wenn ihr die Wahl habt, würdet ihr eher eien Stelle in der > Hardwareentwicklung (Platinendesign, Stücklistenarbeit, Layout,...) oder > eher eine in der Softwarentwicklung (Firmware für uC) annehmen? Diese Frage ist unbeantwortbar. Oder eine Antwort ist sinnlos. Denn keiner weiß, was du für einen Bildungsverlauf oder welche Präferenzen du hast. Und du weißt nicht, wie das bei "uns" ist. Somit ist jede Antwort beliebig richtig oder falsch, gut oder schlecht, weil es immer einen gibt, der auf irgendeinen Job "optimal" passt... > Was hat eher Zukunft? Beides hat gleich gute Zukunft. In der Layoutecke ist weniger Dynamik...
Zum einen ist das ganze ein Projektgeschäft, was enden kann. Zum anderen kann es ausgelagert werden, auch nach Fernost. Das ganze hat also keine sichere nachhaltige Perspektive und ist eher etwas für Abenteurer, die keine Ambitionen haben sich sesshaft zu binden.
Nun, ich habe bisher als "Allrounder" gearbeiet und sowohl Platinendesign als auch Controllerprogrammierung mit gemacht. Nun muss ich mir eine neue Stelle suchen und stelle fest, dass es insgesamt wenige Stellen als Allrounder gibt und gleichzeitig das Spektrum der Software viel weiter gefasst ist, es dabei aber auch insgesamt in der Softareecke etwas mehr Stellen gibt, als das bei der Hardware der Fall zu sein scheint... Habe auch den Eindruck, dass die Firmen tendenziell eine Reihe an Softwerkern beschäftigen, jedoch meist nur einen einzigen Hardwerker und sogar das Design generell außer Haus geben...
Bewerber schrieb: > Habe auch den Eindruck, dass die Firmen tendenziell eine Reihe an > Softwerkern beschäftigen, jedoch meist nur einen einzigen Hardwerker und > sogar das Design generell außer Haus geben... Ja, das halte ich aber für einen kurzlebigen Modetrend. Das Ausser haus geben dauert doppelt solang und ist viermal teurer und nie fertig da man bei Änderungen immer den externen nachbeauftragen muss... in wenigen Jahren haben die alle wieder eine eigen hardwareabteilung aufgebaut und die Dienstleister buttern ihre HW-Entwickler wieder in die Testabteilungen.
Was ist das denn für eine Frage? Bist Du so gut und versiert in beidem, dass Du zwei Jobs hintergeworfen bekommst?
Troll_Hunter schrieb: > Was ist das denn für eine Frage? Bist Du so gut und versiert in > beidem, dass Du zwei Jobs hintergeworfen bekommst? Nein, das Problem ist anders herum: er kann nichts von beidem richtig und findet daher keinen einzigen Job.
Software wird zunehmend von Informatikern gemacht oder technischen Informatikern. Inzwischen sind die Anforderungen gestiegen, der alte Elektrotechniker der einen 8051 programmieren soll mit ein bisschen C- und Assembler-Code kann es nicht mehr richten. Es reicht nicht nur, bisschen Mikrocontroller zu programmieren, sondern es müssen auch immer öfter PC- und Datenbankanwendungen, Webinterfaces, Cloud-Technologien usw. dabei sein. Auch wird der Entwicklungsprozess immer professioneller mit V-Modell, UML-Diagramm, Softwareanfoderungsspecs, Verifikation, Modul- und Integrationstest usw. Auch die Mikrocontroller haben heutzutage auch ein eigenes Betriebssystem (RTOS, Linux) und sind schon halbe PCs. Es gibt auch Systems On Chips mit Prozessoren, FPGA-Kernen und umfangreicher Peripherie zu programmieren. Da kommst Du mit deinen uC-Programmierkenntnissen nicht weit.
Nun es ist tatsächlich so, dass ich in beiden Bereichen eine Zusage habe und mich entscheiden muss. Allrounder zu sein heißt ja irgendwie auch, dass ich in beiden Bereichen noch etwas nach zu holen hätte und eben kein Experte auf den Gebieten bin. Man steht eben irgendwann an dem Punkt, wo man sich in eine Richtung spezialisieren muss. Hardware ohne Software funktioniert nicht, aber letztlich muss ja nicht beides von der selben Person kommen und ich habe den Eindruck, je größer die Firma, desto eher sind das getrennte Bereiche.
Lothar M. schrieb: > Bewerber schrieb: >> in der Hardwareentwicklung (Platinendesign, Stücklistenarbeit, Layout,...) > Hardwareentwicklung beginnt viel, viel weiter vorne. Das, was du hier > aufgezeigt hast, ist quasi der Endspurt. Und tatsächlich zu mindestens > 70% reine Verwaltungstätigkeit. Ja, und er nannte den nur den schönen Teil. Die weniger schönen Teile werden immer vergessen: - Normenrecherche (Bäh!) - Geänderte Anforderungen nachziehen - EMV/IP/Sicherheitstests - Dokumentation, Pflichtenhefte - Besprechungen - Bauteilrecherchen und Preisvergleiche Das ist ja das schöne bei Basteln zuhause: Man braucht nur rund 1/10 der Zeit. Man spart sich den "lästigen Mist" einfach, weil man weder normgerecht ist, noch in größeren Stückzahlen produziert wird. Den ganzen Overhead für eine serientaugliche, verkaufsfähige Entwicklung vergessen die ganzen Elektronikbastler hier gerne. Würde mich mal interessieren, wieviele Startups schon an der Unterschätzung von "kleinen" "Nebensachen" wie dem schnöden CE-Zeichen eingegangen sind.
Troll_Hunter schrieb: > Software wird zunehmend von Informatikern gemacht oder technischen > Informatikern. > > Inzwischen sind die Anforderungen gestiegen, der alte Elektrotechniker > der einen 8051 programmieren soll mit ein bisschen C- und Assembler-Code > kann es nicht mehr richten. > > Es reicht nicht nur, bisschen Mikrocontroller zu programmieren, sondern > es müssen auch immer öfter PC- und Datenbankanwendungen, Webinterfaces, > Cloud-Technologien usw. dabei sein. > > Auch wird der Entwicklungsprozess immer professioneller mit V-Modell, > UML-Diagramm, Softwareanfoderungsspecs, Verifikation, Modul- und > Integrationstest usw. > > Auch die Mikrocontroller haben heutzutage auch ein eigenes > Betriebssystem (RTOS, Linux) und sind schon halbe PCs. Es gibt auch > Systems On Chips mit Prozessoren, FPGA-Kernen und umfangreicher > Peripherie zu programmieren. > > Da kommst Du mit deinen uC-Programmierkenntnissen nicht weit. Für mich klingt es so, als ob du dein Wissen zusammen "gegoogled" hast und hier zum Besten gibt. Echte Frontkämpfer erzählen dir hier was anders! Du solltest dich umtaufen lassen! Anstatt Troll-Hunter "Knowledge-Hunter" (by Google) Sepp
Latschen S. schrieb: > Für mich klingt es so, als ob du dein Wissen zusammen "gegoogled" hast > und hier zum Besten gibt. Er hat aber Recht. Das Studium der Elektrotechnik bereitet auf die berufliche Praxis im embedded Bereich kaum noch ausreichend vor. Es bringt den Unternehmen keinerlei Vorteile, nicht gleich einen technischen Informatiker zu nehmen.
Alter Hase schrieb: > Er hat aber Recht. Das Studium der Elektrotechnik bereitet auf die > berufliche Praxis im embedded Bereich kaum noch ausreichend vor. Es > bringt den Unternehmen keinerlei Vorteile, nicht gleich einen > technischen Informatiker zu nehmen. Denen fehlt aber elektrotechnisches Know-how. Daher lieber einen E-Technik Ingenieur nehmen, das Wissen über Software-Entwicklung ist schnell ausgebaut, das ist auch wesentlich einfacher und locker ohne Hochschule zu erlernen.
Ingenieur schrieb: > Denen fehlt aber elektrotechnisches Know-how. Daher lieber einen > E-Technik Ingenieur nehmen, das Wissen über Software-Entwicklung ist > schnell ausgebaut, das ist auch wesentlich einfacher und locker ohne > Hochschule zu erlernen. Wozu braucht ein Software-Entwickler denn bitte elektrotechnisches Knoffhoff?
Falscher Hase schrieb: > Wozu braucht ein Software-Entwickler denn bitte elektrotechnisches > Knoffhoff? Na wenn er im Embedded-Umfeld arbeiten will, ist es enorm hilfreich.
Entweder du studierst ET, dann Hardware oder du studierst Informatik, dann Software. Solltest du beides studiert haben, kann ich nur empfehlen, eine Münze zu nehmen und sich dann entscheiden. Keine Münze da, Bafög beantragen und dann entscheiden. Nein, ernsthaft, es ist egal, was du machst. Solange du dich richtig reinhängst und EINE Richtung einschlägst, wirst du schon was finden. Wenn du dich allerdings entschieden hast, zieh deinen Weg durch. Allrounder will später meistens keiner haben, da sie nix Ganzes und nix Halbes sind. Den Aufwand beides zu machen würde ich auch nicht auf mich nehmen wollen, ein wenig Freizeit sollte man doch haben.
Troll_Hunter schrieb: > ... > Auch die Mikrocontroller haben heutzutage auch ein eigenes > Betriebssystem (RTOS, Linux) und sind schon halbe PCs. Erst kürzlich erlebt: Schreiben auf SD-Karte geht irgendwie nicht richtig. Tagelang wird debuggt, die Bibliothek auseinandergenohmen, der Support gequält... Dann kommt der älteste Entwickler (der der früher die Boards designt hat, heute aber nur noch Kunden betreut und testet) aus dem Urlaub zurück, hält das Scope an die Karte -> funzt -> lötet 20 pF an die richtige leitung - funzt immer noch (auch ohne scope) -> sagt dem Geglegenheitslayouter der soll beim nächsten PCB auf den Längenunterschied der Leitungen zwischen uC und SD-Card achten -> fertig. > Da kommst Du mit deinen uC-Programmierkenntnissen nicht weit. Ja mei, wenn die uC Kenntnisse reichen für die ersten Schritte der Inbetriebnahme damit anschliessend die OS/GUI-Hänseln starten und fertig machen können dann ist das weit genug. Ohne erste Schritte gehts nun mal nicht, das vergesehen die High Level Konzept-Programmierer-Könige gerne.
Ingenieur schrieb: > Denen fehlt aber elektrotechnisches Know-how. Daher lieber einen > E-Technik Ingenieur nehmen, Ja, den Code von reinen E-Technik Ingenieuren kennen wir. Der ist nicht selten grausig ;-) Es gibt halt viele Leute die irgendwann mal E-Tech studiert haben, nie in ihrem Leben eine Vorlesung über Softwarearchitektur oder Softwaredesign gehört haben, und anscheinend auch nie ein gutes Buch zu dem Thema gelesen haben. Dementsprechend sehen ihre Arbeitsergebnisse dann auch aus. Der Code funktioniert zwar irgendwie, aber eben auch nur irgendwie. > das Wissen über Software-Entwicklung ist schnell ausgebaut Nein, das stimmt nicht. Dafür ist die komplette Welt der Softwareentwicklung heutzutage zu groß und zu komplex. > das ist auch wesentlich einfacher und locker ohne Hochschule zu erlernen. Im Prinzip kann man sich jegliches Wissen auch ohne den Besuch einer Hochschule aneignen. In der beruflichen Realität macht es aber oft einen deutlichen Unterschied, welchen Background jemand mitbringt. Wer sich in seinem Studium niemals mit Themen wie Requirements Management, Architektur und Design von Software beschäftigt hat, der entwickelt später im Beruf auch nicht unbedingt regelmäßig großes Interesse an eben solchen Themen.
:
Bearbeitet durch User
Mark B. schrieb: >> das ist auch wesentlich einfacher und locker ohne Hochschule zu erlernen. > > Im Prinzip kann man sich jegliches Wissen auch ohne den Besuch einer > Hochschule aneignen. > > ... Wer sich in seinem > Studium niemals mit Themen wie Requirements Management, Architektur und > Design von Software beschäftigt hat, der entwickelt später im Beruf auch > nicht unbedingt regelmäßig großes Interesse an eben solchen Themen. Das hab ich anders erlebt, Requirements schreiben und sich strikt an V-Modell Vorgaben halten wird von Leuten geliebt, die sich mit (stupiden) Abarbeiten von Formalismen das Leben einfach und überschaubar halten. Bei den Hardwerkern sind das die die sich um die Erfüllungen der DIN-Normen, EMV etc. kümmern. Ob man das schon an der Uni gehört hat ist egal und zumindest was offizielle Normen betrifft nie der Fall. Die machen das eben gerne, weil sie mehr die "Arbeit-nach-Schema-V" Typen sind und nicht die "Versuch-macht-Schlau" Typen. Und jedes Schema kann man erlernen, nur macht es den "kreativen" nicht viel Spass nie davon abweichen zu können(dürfen).
> Mark Brandis schrieb: > Vorlesung über Softwarearchitektur oder > Softwaredesign gehört haben, und anscheinend auch > nie ein gutes Buch zu dem Thema gelesen haben Nun, welches gute Buch oder welches gute Vorlesungsscript würdest du denn empfehlen? Da es ja nur um Konzepte geht, sollte das doch auf ca. 100 Seiten erschöpfend zu erklären sein, oder irre ich mich da?
Buch? schrieb: > Nun, welches gute Buch oder welches gute Vorlesungsscript würdest du > denn empfehlen? https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html
Tendenziell geht die Entwicklung in Richtung Software. Natürlich benötigt man am Ende auch Hardware, um irgend eine Wirkung zu erzielen, diese wird aber im Laufe der Zeit immer uniformer und systematischer, die Vielfalt nimmt ab. Das sieht man z.B. bei den Bus/Leitungssystemen hin zu IP (Konvergenz) oder in der HArdware hin zu ASIC, DSP (DSP auf ASIC-Basis) :-). David Precht hat das in einem Vortrag (sinngemäß zitiert) schön pointiert dargestellt: "Heute ist die Autoindustrie schwerpunktmäßig Maschinenbau mit Zulieferung aus der E-Technik und IT. In einigen Jahren besteht ein Auto primär aus IT und Software, mit Zulieferung aus der Elektrotechnik und dem Maschinenbau für Motor und Räder ... "
:
Bearbeitet durch User
Immer das ach so mysteriöse V-Modell von dem manche Unternehmen so tun als hätten sie es erfunden. Haben sie nicht: http://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html Das V-Modell beschreibt lediglich einen Vorgehensrahmen, wie man Systeme (und das beschränkt sich nicht nur auf SW) entwickelt. Für den Entwickler bleibt da schon noch genug kreativer Freiraum - natürlich abhängig von der Abteilung in der er arbeitet. Das man erst einzelne Module entwickelt und testet, die dann integriert und dann im Integrationstest testet würde man wohl auch ohne das mysteriöse V so machen.
Falscher Hase schrieb: > Wozu braucht ein Software-Entwickler denn bitte elektrotechnisches > Knoffhoff? Damit sein (schlimmstenfalls irgendwo zusammenkopierter) Code dann letztlich auch auf dem "schnarchlangsamen" 72MHz STM32 noch schnell genug ist und er in den uC auch tatsächlich noch reinpasst. Und damit er sich vorstellen kann, wie aufwändig diese eine spezielle Codezeile auf dem Zielcontroller umgesetzt wird. Immer wieder habe ich technische(!!) Informatiker als Praktikanten/Diplomanden/Bacheloranden/usw, die sich eine mögliche Problematik an dieser Stelle nicht einmal vorstellen könnnen. Und nachdem wir dann die Ziele der Arbeit abgesteckt haben, dürfen die für einige Zeit drauflosprogrammieren. Regelmäßig kommen die dann zum Schluss, dass "der das nicht kann, da muss ein größerer her". Gemeinsam sehen wir uns dann die Speicher- und Laufzeitfresser an (viele sehen dann zum ersten Mal, dass der Compiler ein Assemblerlisting ausspuckt wenn man will), und hinterher bringen sie dann die Aufgabe doch tatsächlich problemlos im uC unter. Das zeigt mir, dass die Softwareentwicklung an den Schulen offenbar viel zu abstrakt und mit einem hoffnunglos blinden Vertrauen in die Optimierungskünste der Compilerbauer abgehandelt wird. Man sieht diese Bezugslosigkeit der Programmierer z.B. bei irgendwelchen Timeouts auf dem PC. Da "wartet" eine Software tatsächlich sekundenlang auf die Reaktion einer Hardware. Dabei kann ich als Hardwareentwickler sicher sagen, dass Hardware innerhalb von hundertstel Sekunden oder eben gar nicht auf irgendwelche Anfragen reagieren wird, und im zweiten Fall eine andere Strategie als "Warten" nötig ist. Und trotzdem warten viele Computer sekundenlang auf nicht bereite Hardware oder eben auf andere Software, die ebenfalls viel zu lange auf nicht bereite Hardware wartet... Frank E. schrieb: > David Precht hat das in einem Vortrag (sinngemäß zitiert) schön > pointiert dargestellt: "Heute ist die Autoindustrie schwerpunktmäßig > Maschinenbau mit Zulieferung aus der E-Technik und IT. In einigen Jahren > besteht ein Auto primär aus IT und Software, mit Zulieferung aus der > Elektrotechnik und dem Maschinenbau für Motor und Räder ... " Ja, das besorgt mich ein wenig. Denn zumindest die Softwareentwickler, die ich kenne, verlassen sich darauf, dass man ihre Software problemlos updaten kann. Und scheuen sich deshalb nicht, halbfertige und unausgegorene Erzeugnisse auszuliefern.
Mark B. schrieb: > Ja, den Code von reinen E-Technik Ingenieuren kennen wir. Der ist nicht > selten grausig ;-) Das Dumme an der Sache ist, der von Informatikern auch. Die Informatik in Deutschland legt ja besonderen und gesteigerten Wert darauf, sich vom Programmieren abzugrenzen und Programmieren wird von Informatikprofessoren gerne als niedere Tätigkeit dargestellt. Die Informatiker in Deutschland haben die Lücke "praktische Softwareentwicklung" selber aufgerissen und in die sind dann besonders E-Techniker, Physiker, Mathematiker und komplette Autodidakten gestoßen. Die Informatiker, so scheint es mir, sitzen dabei auf der Tribüne, schauen zu, machen alle den Bundestrainer, entwickeln immer kompliziertere, abstrakte, undurchschaubare und undurchführbare Taktiken und Mannschaftsaufstellungen mit nicht vorhandenen Wunderspielern und glauben sie wären alleine dadurch Weltmeister.
Hannes J. schrieb: > Das Dumme an der Sache ist, der von Informatikern auch. > > Die Informatik in Deutschland legt ja besonderen und gesteigerten Wert > darauf, sich vom Programmieren abzugrenzen und Programmieren wird von > Informatikprofessoren gerne als niedere Tätigkeit dargestellt. > > Die Informatiker in Deutschland haben die Lücke "praktische > Softwareentwicklung" selber aufgerissen und in die sind dann besonders > E-Techniker, Physiker, Mathematiker und komplette Autodidakten gestoßen. > > Die Informatiker, so scheint es mir, sitzen dabei auf der Tribüne, > schauen zu, machen alle den Bundestrainer, entwickeln immer > kompliziertere, abstrakte, undurchschaubare und undurchführbare Taktiken > und Mannschaftsaufstellungen mit nicht vorhandenen Wunderspielern und > glauben sie wären alleine dadurch Weltmeister. Das mag für die Uni-Informatik so gelten, bzw. über längere Zeit gegolten haben. Als in Deutschland in den 1970er Jahren die ersten Fakultäten für Informatik konzipiert wurden, waren die Studiengänge damals nicht viel anders als ein reines Mathematik-Studium mit ein paar ergänzenden Informatik-Inhalten. Das sah man zum Beispiel daran, dass man an Unis wie in Karlsruhe Informatik im Grundstudium studieren konnte, und mit 1 oder 2 Scheinen mehr hatte man auch noch das Mathe-Vordiplom gleich mit erledigen können. Wie das nun nach der Umstellung auf Bachelor/Master aussieht weiß ich nicht genau. Ich hoffe mal es ist besser geworden. Gescheiter wär's :-)
Bewerber schrieb: > ... und sogar das Design generell außer Haus geben... Meinst du "außer Haus" erledigt sich das von selbst? Da stecken auch Leute hinter, die die Arbeit machen.
Lothar M. schrieb: > Das zeigt mir, dass die Softwareentwicklung an den Schulen offenbar viel > zu abstrakt und mit einem hoffnunglos blinden Vertrauen in die > Optimierungskünste der Compilerbauer abgehandelt wird. Du musst davon ausgehen, dass Softwareentwicklung an den "Schulen" bei Null anfängt. Die Tage, als noch eine prozedurale Programmiersprache das höchste der Gefühle war, und Assembler (zumindest das Verstehen des generierten Codes) zum Handwerkszeug dazugehört hat, sind in der Lehre vorbei. Heutzutage wird oft nur eine "Hauptsprache" gelehrt, die ist oft auf einem abstrakten Niveau und wird in irgend einer Form interpretiert (Python, Java). Ganz im Ernst: Den generierten Java-Bytecode habe ich mir auch noch nie angeschaut (und das, obwohl ich bei 6502 beginnend, über 68k, i386 und ARM diverse Prozessoren zumindest teilweise in Assembler programmiert habe). Diese OO Sprachen sind sehr komplex, und so hat man damit genug zu tun, den Schülern bzw. Studenten die Feinheiten bzw. Möglichkeiten nahe zu bringen. Been there, done that. Erst wenn dann man µC in C programmiert werden, wird der generierte Code interessant. Das ist für die meisten dann eine Spezialisierung, und man hat wieder genug zu tun, den Schülern bzw. Studenten die prozedurale Denkweise beizubringen. Das führt dann dazu, dass die Schüler zwar C Programme erstellen können, aber das Thema Resourcenmanagement nicht kapiert haben. Und das kann man ihnen auch nicht mit ein paar Folien und Beispielen einbläuen. Programmieren ist ein Handwerk, und das lernt man nur gut durch viel Praxis. Zum Thema: 1) Mache das, was dich mehr interessiert 2) Mache das, was du besser kannst 3) Wenn 1 und 2 nicht reichen, mache Hardware. Meines Erachtens ist bei Hardware eine gute Ausbildung wichtiger als bei Software. Programmieren ist (wie oben schon gesagt) m.E. ein Handwerk. Die Grundlagen lernt man, indem man viel programmiert. Wenn man die Basics kann, sollte man sich dann mal Gedanken über Softwarequalität machen. Dass geht auch mit guten Büchern, aber es hilft ungemein, wenn man sich selbst schon mal bei einem mittleren bis größeren Projekt in den Fuß geschossen hat. Dann versteht man erst die Probleme, die in den Büchern angesprochen werden und weiß, was man gewinnt, wenn man bessere Strukturen einführt.
Buch? schrieb: >> Mark Brandis schrieb: >> Vorlesung über Softwarearchitektur oder >> Softwaredesign gehört haben, und anscheinend auch >> nie ein gutes Buch zu dem Thema gelesen haben > > > Nun, welches gute Buch oder welches gute Vorlesungsscript würdest du > denn empfehlen? > > Da es ja nur um Konzepte geht, Das sehe ich etwas anders. Wie man ein Software-Design für ein konkretes Projekt richtig macht, kann man meiner Meinung nach nicht rein abstrakt erklären, sondern das gelingt eher anhand eines konkreten Beispiels. Zwei der besten Bücher, die ich je über Software-Themen gelesen habe, sind: Clean Code (Robert C. Martin) The Mythical Man-Month (Frederick Phillips Brooks)
Hannes J. schrieb: > Die Informatiker, so scheint es mir, sitzen dabei auf der Tribüne, > schauen zu, machen alle den Bundestrainer, entwickeln immer > kompliziertere, abstrakte, undurchschaubare und undurchführbare Taktiken > und Mannschaftsaufstellungen mit nicht vorhandenen Wunderspielern und > glauben sie wären alleine dadurch Weltmeister. Richtig. Das fängt schon damit an, dass Software-Architekten oft gar nicht mehr selbst entwickeln (Stichwort niedere Tätigkeit) und sich damit immer weiter von der Realität weg entwickeln. Am Ende muss das Ding auch jemand im Tor versenken, sonst wird man nicht gewinnen, egal was man im Elfenbeinturm für taktische Konzepte ausgetüftelt hat. Da langen dann ein, zwei kleinere Fehler, die immer mal vorkommen können, und zack ist man raus aus dem Turnier und Frankreich im Finale.
Mark B. schrieb: > Zwei der besten Bücher, die ich je über Software-Themen gelesen habe, > sind: > Clean Code (Robert C. Martin) > The Mythical Man-Month (Frederick Phillips Brooks) Wehn's interresiert: "Clean Code" kann man hier als PDF downloaden. http://ricardogeek.com/docs/clean_code.pdf und "Mythical Man-Month" hier: https://is.muni.cz/www/208322/The.Mythical.Man.Month.F.Brooks.pdf
Schön dass hier so viele Experten sich versammelt haben. Daher eine praktische Frage in die Runde: Ich habe Software geschrieben und war total undiszipliniert bezüglich der richtigen Formatierung und Lesbarkeit des Sourcecodes. Gibt es einen C-Code-Editor, der automatisch den Coding Style wieder in Ordnung bringen könnte? Es ist egal welche Style dabei rauskommt, es soll nur einheitlich und ordentlich aussehen.
Nut schrieb: > Daher eine praktische Frage in die Runde Stell die Frage in einem eigenen Thread. Hijacking ist nicht beliebt. Und vor du die Frage stellt nimm Google und such nach "code beautifier"
Entwicklen lernt man nicht durch Studium sondern indem man es macht, auch erst mal falsch, daraus lernt man am meisten und von einem erfahrenen Entwickler der einem auf die Finger klopft oder studieren fremden Codes der als gut angesehen wird, letzteres gehört als Grundlagenfach etabliert und nicht Superhippes agile Softwarenewicklungsmodel XY, das gerade angesagt ist oder UML-Gekasper ein Semester lang, das ist doch lächerlich. So Pille-Palle Zeugs wie V-Modell, Agile Methoden,... diesen ganzen Projektmanagmentmüll lernt man auch am besten in der Praxis und nicht in Vorlesungen, dort schlafen einem zu dem Thema die Füsse ein und ist Zeitverschwendung. Endloses Trivialgelaber aufgeschwurbelt mit Pseudofachbegriffen und Diagrämmchen, das meiste davon macht man automatisch intuitiv so wenn man nicht völlig weich in der Birne ist. Das ist halt nochmal extra für Doofe aufbereitet damit die auch wissen wie man es macht. Diese ganze Laberquatsch gehört aus den Vorlesungen gestrichen. Wer sich durch ein ET/IT-Studium gequält hat liest sich später mit Leichtigkeit in diese Materie ein. Dummschwafelnde BWLer gibts schon genug, die BWLisierung der ET/IT-Fächer braucht kein Mensch. Da kommen Leute daher die alle wissen wie man theoretisch Softwareprojekte leitet/durchzieht,... aber scheitern schon an den programiertechnischen Grundlagen. Nur noch Dummlaberer, Eunuchen die wissen wie es geht aber keinen Plan haben und nix gebacken bekommen. Dieser ganze Unsinn gehört zusammengestrichen, wieder E-Technikgrundlagen bei den Informatiker eingeführt wie es früher mal war, digitale Signalverarbeitung, FT, Compilerbau das ist alles heute nicht mehr drinn, nicht mal als Wahlfach, Analysis ist ebenso auf gerade mal Abiniveau zusammengestrichen worden. Aber dafür glauben sie jetzt Softwareprojekte managen zu können. Solche Knallchargen kann man nicht mal als Webentwickler oder Admins gebrauchen.
Bezirksbefruchter schrieb: > ...... Brurr , wackel wackel, schüttel schüttel. Was war das gerade eben!?!
Man sollte den BWL Software Projektleitern schon etwas entgegenzusetzen haben. Waehrend die die effektiv zu tun'de Arbeit als trivial und im hoechsten Fall als auslagerungswuerdig betrachten, sollte der Softwerker jede einzelne geschriebene Codezeile als Megadurchbruch darstellen. In Sinne von 2 Wochen Zeit ergeben 5 Zeilen Code und sind der lang erarbeitete Paradigmenwechsel, der das Potential hat ganz neue Maerkte zu erschliessen.
Oh D. schrieb: > Man sollte den BWL Software Projektleitern schon etwas > entgegenzusetzen > haben. Waehrend die die effektiv zu tun'de Arbeit als trivial und im > hoechsten Fall als auslagerungswuerdig betrachten, sollte der Softwerker > jede einzelne geschriebene Codezeile als Megadurchbruch darstellen. In > Sinne von 2 Wochen Zeit ergeben 5 Zeilen Code und sind der lang > erarbeitete Paradigmenwechsel, der das Potential hat ganz neue Maerkte > zu erschliessen. Super ausgedrückt, werde ich gebrauchen nächstes mal!
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.