Hardware oder Software?

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.

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.

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

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.

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.

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.

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!?!

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!