mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Programmiersprachen im Beruf (Elektrotechnik)


Autor: Quentin B. (land)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich studiere E-Technik und hatte bis jetzt die Programmierung mittels
C, und C#.

Nun stelle ich mir die Frage, was später für Sprachen im Beruf zum
Einsatz kommen?

Speziell interressiert mich, mit was ein
Leistungselektronik, elektrische Energie und Antrieb



Ich freue mich, wenn ihr etwas aus eurem Berufsleben preisgeben könntet.

MFG
Land

Autor: Chris K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C und ganz selten noch was Assemlber

Autor: Stefan (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
LISP, Haskell und Prolog sind die wichtigsten. C solltest du gleich 
vergessen.

Ernsthaft: C, C++, Im Testbereich Python, im Toolbereich Java, außerdem 
natürlich MATLAB (wenn du das mitzählst)
S.

Autor: waflija (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefan schrieb:
> LISP, Haskell und Prolog sind die wichtigsten. C solltest du
> gleich
> vergessen.
>
> Ernsthaft: C, C++, Im Testbereich Python, im Toolbereich Java, außerdem
> natürlich MATLAB (wenn du das mitzählst)
> S.

Also als "normaler" E-Techniker Automatisierung wirst du fast nur 
SPS-Sprachen wie Codesys oder propiritäres Zeuch finden. C ist da eine 
gute Grundslage, mehr nicht.
Wenn du Antriebe / Motore entwicklst wirst du ziemlich zwangsläufig by 
µC / embedded ankommen, dann geht es eher in Richtung C, C++ und 
Mathlab.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Arbeit, für die ich bezahlt wurde (also nicht nur private oder 
Uniprojekte) habe ich bisher C, C++ und Java (und VHDl, wenn man das 
zählen will) eingesetzt. Ein Kollege musste aber zum Beispiel auch mit 
Fortran programmieren.

Autor: Zocker_50 (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
> Autor: Quentin Biawa (land)
> Datum: 11.01.2017 11:30

> Nun stelle ich mir die Frage, was später für Sprachen im Beruf zum
> Einsatz kommen?

Warte erst mal ab. Wenn du später SPS-Steuerungen programmierst wirst du 
praktisch bei jedem Hersteller, und es gibt weltweit ein paar davon, mit 
einer bestenfalls neuen Syntax konfrontiert.

Das geht von einfacher Assembler-Anwendung bis hin zur Pascall ähnlichen 
Hochsprache wie bei B & R.

Warum eine Pascall ähnlichen Hochsprache wie bei B & R bei einer 
Garagentor-
Ansteuerung nötig ist habe ich bis heute nicht verstanden.

Es geht auch einfacher, aber das versteht dann ja jeder !

Autor: Claymore (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Programmiersprache ist gar nicht so wichtig. Entscheidend sind die 
verwendeten Konzepte und Mechanismen. Also z.B. OOP, aber z.B. auch RTOS 
oder digitale Signalverarbeitungsalgorithmen. Wenn man die Grundlagen 
beherrscht, kann man sie recht leicht auf eine neue Programmiersprache 
übertragen.

Autor: Amateur (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das kommt darauf an.

Auf der untersten Ebene (µP und Konsorten) wirst Du Assembler (können 
viele schon nicht mehr), C und gelegentlich C++ brauchen.

FPGAs haben ihren eigenen Zweig bzw. ihre eigene Sprache.

B&R sind als der SPS-Familie zugehörig eine "eigene" Spezies. 
Interessant für Leute, die den Output ihrer Simulationssoftware direkt 
in eine SPS packen wollen. Ich glaube aber nicht, dass Quentin diese 
Richtung gemeint hat.

Außerhalb der Mikrokontroller oder oberhalb der Treiberebene ist es fast 
immer "Firmenpolitik", welche Sprache bevorzugt wird.
Fortran kann ich mir aber nur vorstellen, wenn der Chef wenigstens 65 
Jahre alt ist, bzw. dessen "oberster" Entwickler.

Autor: Ratgeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du eine graphische Programmiersprache (z.B. LabVIEW oder Simulink) 
sowie eine textuelle Programmiersprache (Vorzugsweise C) beherrschst 
dann kannst du daraus fast alles ableiten was dir im Arbeitsleben über 
den Weg läuft.

Lediglich ein tiefer Einstig in die objektorientierte Programmierung 
könnte dann noch schwieriger werden.

Mit fortschreitender Erfahrung wirst du dann feststellen, dass eine 
Programmiersprache lediglich ein Werkzeug ist, und es eher darauf 
ankommt ein tiefes Systemverständnis zu entwickeln sowie eine saubere SW 
Architektur zu entwerfen.

Just go for it!

Autor: Dr. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Quentin B. schrieb:
> Speziell interressiert mich, mit was ein
> Leistungselektronik, elektrische Energie und Antrieb

Kommt eben stark drauf, was du machst dh welchen Job du haben wirst.

Wenn du z.B. oft Daten auswerten, verarbeiten und visualisieren musst 
(z.B. weil du als Testingenieur für Leistungselektronik arbeitest und du 
gerade die Daten von mehreren Testruns deiner Bauteile bekommst), kann 
es schon sein, dass du als gewiefter E-Techniker, der Python kann, schon 
nach Hause gehst, während dein Kollege, der nur Excel beherrscht, noch 
eine Nachtschicht einlegen muss...

Aber da es ja heutzutage eher unüblich ist, dass man von 
Studienabschluss bis zur Pension nur einen Job hat, würde ich versuchen, 
erstmal die Grundlagen zu lernen (und die lernt man in jeder 
Programmiersprache). Wenn dich Programmieren wirklich interessiert 
solltest du durchaus einen Kurs aus "Grundlagen der Datenstrukturen" mit 
dazugehöriger (Programmier)übung aus dem Informatikstudium als Freifach 
belegen. Ist vielleicht ein wenig Arbeit, aber bringt dir sehr viel.

Autor: Achim S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Für Motorsteuerungen etc. vor allem Differntialgleichungen, 
Z-Transformation, Regelungstechnik, höhere Mathematik.

Die Umsetzung auf SPS/µC/DSP ist dagegen zweitrangig. Mit C und C# 
deckst Du alles ab (von embedded bis zur Visu am PC). Vertiefe Dich in 
diese Sprachen (Diplomarbeit, Studentische Hilfkraft, Hobby, 
Semesterjob) und versuche, jedes Jahr eine weitere (und sei es nur 
oberflächlich) kennenzulernen.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sprachen sind nur mittel zum Speck.
Bin in Leistungselektronik und Antriebsthemen unterwegs....

Wir machen viel in C, C++ (visualdsp++), skripte schreibe ich alle in 
python, dann noch Matlab/Simulink und VHDL, für Prüfstände kommt noch 
Labview zum einsatz (bin nicht so der Fan davon :D)

Kennste eine kommste in ne andere schnell rein. Wenn du unbedingt was 
lernen willst, mach VHDL da darfste en bissel anders denken und lernst 
was...
Und das kannste später sicher mal brauchen ....

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zocker_50 schrieb:
> Pascall
Auch hartnäckige Wiederholung macht es nicht besser. Der namensgebende 
Bursche hieß "Pascal" mit nur einem "l".

Autor: Richard H. (richard_h27)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Zocker_50 schrieb:
>> Pascall
> Auch hartnäckige Wiederholung macht es nicht besser. Der namensgebende
> Bursche hieß "Pascal" mit nur einem "l".

Am wichtigsten ist immer noch Zeh.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Amateur schrieb:
> Fortran kann ich mir aber nur vorstellen, wenn der Chef wenigstens 65
> Jahre alt ist, bzw. dessen "oberster" Entwickler.
Es ging um eine alte getestete Steuerung, die angepasst werden musste. 
Da ist es einfacher, dass jemand in Fortran was ändert, als alles neu zu 
schreiben und wieder zu testen oder zertifizieren zu lassen.
Ich wollte damit auch nur ausdrücken, dass alles kommen kann.

Autor: Quentin B. (land)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke  Dusse

Autor: Sebastian L. (der_mechatroniker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch fast nur mit proprietären Sprachen (oder zumindest 
proprietären Dialekten von "Standards") zu tun.

AWL für Siemens-SPSen
Transact-SQL für den Microsoft SQL Server
Die halb-grafische Konfigurationssprache der Produkte meines eigenen 
Arbeitgebers
C#. Ist theoretisch offen und alternative Implementierungen existieren, 
praktisch doch auch recht proprietär
PHP habe ich ganz selten mal in der Hand.

Autor: Quentin B. (land)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DANKE für den Tipp :) ;)

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grafisch und hier noch nicht genannt:
Agilent "VEE". Da ist man unter sich  ;)
Wird oft im Prüffeld eingesetzt, wenn der Gerätepark vornehmlich aus HP, 
AGILENT, KEYSIGHT usw. besteht.

Wenn Du das kannst, melde dich bei mir.
Aber auch jeder andere im Raum Berlin ist herzlich eingeladen :)

StromTuner

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Claymore schrieb:
> Die Programmiersprache ist gar nicht so wichtig. Entscheidend sind die
> verwendeten Konzepte und Mechanismen. Also z.B. OOP, aber z.B. auch RTOS
> oder digitale Signalverarbeitungsalgorithmen. Wenn man die Grundlagen
> beherrscht, kann man sie recht leicht auf eine neue Programmiersprache
> übertragen.

Im Prinzip vollkommen richtig.

Leider sind viele Personaler an der Stelle nicht besonders schlau und 
erwarten, dass man genau die Programmiersprache XYZ beherrscht.

Autor: Nop (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Zocker_50 schrieb im Beitrag #4860560:
> Spielt das überhaupt eine Rolle ?

Bewirb Dich mal mit einem Anschreiben, wo Du schreibst, Erfahrung in 
"Pascall" zu haben. Einmal mit doppel-L wäre ein Posting-Tippfehler, 
aber zweimal nicht.

Zum Topic, also Assembler ist embedded nach wie vor wichtig, selbst wenn 
man nur noch recht wenige Anteile darin macht. Man muß nämlich schon 
eine Vorstellung haben, in was eine Zeile Code denn letztlich umgesetzt 
wird und sich mitunter auch mal ansehen, was der Compiler da rauswirft.

Autor: Nop (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Mark B. schrieb:
> Leider sind viele Personaler an der Stelle nicht besonders schlau und
> erwarten, dass man genau die Programmiersprache XYZ beherrscht.

Kann auch hin und wieder sein Gutes haben.

Ich hatte mal ein lustiges Gespräch bei einer Firma, da wurde ich 
gefragt, ob ich Sprache X könne. Ja, schon, hab ich schonmal mit 
programmiert und so einiges gemacht. Nein, ob ich das so richtig extrem 
gut könne.

Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin 
parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet. 
Die Antwort war der Brüller: Der Code WAR die Doku.

Bei mir ging die rote Warnleuchte an, ich hab mich schon in einem 
riesigen Haufen von laienhaft zusammengeschustertem Spaghetticode 
gesehen, worauf ich keine besondere Lust hatte. Wenn der 
Entwicklungsprozeß schon Pfusch ist, der auf Wartbarkeit nicht 
abgestellt ist, wird der Code ja auch nicht besser aussehen.

Also habe ich einen Testballon losgelassen und ganz freundlich gefragt, 
ob denn geplant sei, die Entwicklung auf eine professionellere Basis zu 
stellen.

LOL - Das Gesicht des Chefs versteinerte sich regelrecht. Ich wußte in 
dem Moment, daß diese Firma bei mir genauso durchgefallen war wie ich 
bei denen, und ich war froh drum.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin
> parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet.
> Die Antwort war der Brüller: Der Code WAR die Doku.

Man kann in jeder Programmiersprache schlechten Code schreiben ;-)

Autor: klausi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> LOL - Das Gesicht des Chefs versteinerte sich regelrecht. Ich wußte in
> dem Moment, daß diese Firma bei mir genauso durchgefallen war wie ich
> bei denen, und ich war froh drum.

Gut gemacht! ;-)
Kommt mir bekannt vor!
Mein 1. Job nach dem Studium war auch ähnlich!
Konnte das nicht gleich erkennen, da ja "Testdoku" zu jedem Bug gemacht 
wurde!

Da wurde geflucht, der ganze Spaghetticode auf der Baustelle 
zusammengeschustert!
Keine einzige Doku, evtl ein kleines Wiki war da, das haben wir aber 
selbst erstellt.
Der Teamleiter hatte sowieso keine Ahnung für ihn kostete Doku und Test 
nur wertvolle Zeit!
Also halt genau wie Negativbsp. im Lehrbuch - wie man es nicht machen 
sollte!

Sagte dann auch so nicht mehr! Qualität zählt, gleich beim 1. Mal 
richtig machen!
Hab dann keiner zu aber danach gings besser.
Trotzdem kündigte ich mit Freude da ich einen neuen besser bezahlten Job 
bekam.

Die Top3 der Sprüche dort:
Testen ist für Feiglinge
Code ist die beste Doku (!)
Einfach machen dass es geht

Autor: Shellfisch (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
klausi schrieb:
> Code ist die beste Doku (!)

Man hört das ja öfter mal. Code sollte im Optimalfall schon so 
geschrieben sein, dass er auch Doku ist, aber dass er die Doku 
darstellt, ist natürlich Blödsinn. Diese Auffassung rührt zumindest 
teilweise wohl aus einem Missverständnis (nicht im beschriebenen Fall 
natürlich):
https://www.martinfowler.com/bliki/CodeAsDocumentation.html

Autor: Nase (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Shellfisch schrieb:
> https://www.martinfowler.com/bliki/CodeAsDocumentation.html

Zitat von der Seite:
> One of the common elements of agile methods...

Hier hab ich aufgehört zu lesen.
Eigentlich alle mir bekannten Projekte, die wirklich knallhart "agil" 
aufgezogen wurden, sind gnadenlos damit abgesoffen und wurden 
anschließend doch wieder mühsam zurück auf einigermaßen konventionelle 
Entwicklung umgebaut.

Wer mag, kann ja mal schmökern: Einmal ein verirrter, verunglückter 
agiler Versuch mit Test Driven Development[1] und einmal jemand, der den 
"Scheiß-Sudoku-Löser" dann mit etwas Nachdenken runterprogrammiert[2].


[1] http://ronjeffries.com/xprog/articles/oksudoku/ ff.
[2] http://norvig.com/sudoku.html

Autor: Achim S. (achs)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> Da wurde ich mißtrauisch und hakte nach, daß man sich doch ohnehin
> parallel zum Code auch die Doku durchliest, wenn man sich einarbeitet.

Jeder hat eine andere Vorstellung von Code und Doku. Doku braucht es 
natürlich für
- andere Projektbeteiligte (also nicht Entwickler)
- ein übergeordnetes Verständnis
- nicht aus dem Code ersichtliche Aspekte (Randbedingungen, Erfahrungen, 
Entscheidungen)

Wenn aber ein Programmierer eine Doku der Quellen braucht (oder meint 
intensiv pflegen zu müssen), dann ist entweder der Programmierer 
ungeeignet oder die Quellen. Beides kenne ich.

Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:
> Hier hab ich aufgehört zu lesen.

Ich halte agile auch nicht für Snakeoil (auch wenn es für einige das 
richtige sein mag). Aufzuhören brachte Dich aber um den Link: 
http://www.developerdotstar.com/mag/articles/reeve...

Dort beschreibt Reeves ein grundlegendes Missverständnis von 
Software-Design zu anderen Disziplinen. Im Beispiel oben würde der 
Bewerber sagen: Nein, technische Zeichnungen kenne ich nicht sehr gut, 
aber es gibt ja eine Beschreibung zu dem Getriebe. (Und natürlich sollte 
es die geben, sie wird aber kaum das lesen der Zeichnung erleichtern)

Autor: Tom (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nase schrieb:
> Wer mag, kann ja mal schmökern:

Das ist ein überaus idiotisches Beispiel für TDD. 99.9976% der 
Softwareentwicklung bestehen nicht aus dem Finden von eleganten 
Algorithmen für isolierte, übersichtliche Probleme, sondern daraus, 
irgendwelche Daten trivial verändert hin und her zu schieben und dabei 
keine Nebenwirkungen zu übersehen.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Achim S. schrieb:

> - andere Projektbeteiligte (also nicht Entwickler)
> - ein übergeordnetes Verständnis
> - nicht aus dem Code ersichtliche Aspekte (Randbedingungen, Erfahrungen,
> Entscheidungen)

Eben, und vor allem Punkt 2 ist daran entscheidend, aber auch der Rest 
ist wichtig. Das ist nämlich die Denkarbeit, die zum Code geführt hat. 
Hat man nur den Code der Vorgänger, muß man sich das rückwirkend 
erschließen, also reverse engineering machen. Geht, ist aber sch**ße und 
außerdem teuer (weil langwierig). Besonders, wenn man es auch noch mit 
Multitasking zu tun hat, wo die Tasks miteinander kommunizieren, 
synchronisieren und was weiß ich.

Zumal "keine Doku" üblicherweise noch schlimmere Folgen hat, weil das 
dann passiert, wenn in einer Pfuschbude gleich drauflosgehackt wird. Das 
Problem ist dann nicht nur, daß es keine Designdoku gibt, sondern es 
gibt auch nur ein adhoc-Design, ein Designreview hat es nie gegeben, und 
das wird ein gewachsenes System (auf gut deutsch: ein Haufen Spaghetti).

Genau deswegen war es mir recht, daß der Chef der Pfuschbude dann nicht 
wollte. Der hat ja nichtmal begriffen, daß er ein ernstes Problem hatte.

> Wenn aber ein Programmierer eine Doku der Quellen braucht

Was genau ist "Doku der Quellen"? Also z.B. ne Schnittstellendoku sollte 
schon da sein: WAS kann das Modul (und was nicht!), WIE steuert man es 
an, WELCHE Ergebnisse kann es zurückliefern?

Im Code selber halte ich es so, daß ich immer dann kommentiere, wenn ich 
länger nachdenken mußte. Bei kniffeligen Passagen ist dann schonmal im 
Schnitt genausoviel Kommentar wie Code drin.

Vorteil ist aber, wenn ich in nem halben Jahr nochmal ran muß, finde ich 
mich rasch ein. Und wenn wer anders in 5 Jahren da Bugs beheben muß, 
weiß er anhand der Kommentare, was der Code bewirken SOLL, und ob es 
Codierfehler oder schon Denkfehler waren.

Autor: Geplagter (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
klausi schrieb:
> Die Top3 der Sprüche dort:
> Testen ist für Feiglinge
> Code ist die beste Doku (!)
> Einfach machen dass es geht

Das Extrem ist sicherlich auch nicht gut. Aber in meiner aktuellen Firma 
erlebe ich gerade das genaue Gegenteil: Da steht eher die Einhaltung des 
formalen Prozesses im Vordergrund als das eigentliche Vorankommen mit 
der Software. Hauptsache es ist alles richtig dokumentiert, es werden 
seitenlange Verwahrensanweisungen abgearbeitet, um den formal korrekten 
Prozess eingehalten. Zu den anderen Abteilungen und nach "oben" wird 
dann kommuniziert wie wichtig bei uns die Qualitätssicherung sei.

Aber die eigentliche Software ist schei***. Da sitzen zwei Entwickler 
dran (u.a. ich), kommen kaum hinterher die Anforderungsliste 
abzuarbeiten und an jeder Ecke wird man ausgebremst.

So entsteht höchstens auf dem Papier qualitativ hochwertige Software.

Autor: genervt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Geplagter schrieb:
> Aber die eigentliche Software ist schei***.

Sicher, dass es nicht an dir liegt?

Autor: Geplagter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genervt schrieb:
> Geplagter schrieb:
>> Aber die eigentliche Software ist schei***.
>
> Sicher, dass es nicht an dir liegt?

Ich hoffe doch nicht ;-)

Ich bin da relativ neu dran. Vielleicht habe ich da einfach einen 
anderen Blick drauf.

Autor: Skippy (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Guter Code kann Doku sein,  dazu gehört eben der Testcode, bei letzterem 
sieht es meist mau aus.
Veraltete Doku in Form von Word Dokumenten ist Zeitverschwendung IME

Autor: Jobst Quis (joquis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Skippy schrieb:
> Guter Code kann Doku sein

Denk ich auch. In jeder mir bekannten textuellen Programmiersprache kann 
man Kommentare schreiben für alles, was nicht unmittelbar im Code 
erkennbar ist.

Eine Bedienungsanleitung ersetzt es natürlich nicht.

Autor: Sebastian L. (der_mechatroniker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Anforderungsmanagent auch nicht. Allerdings gibt es auch keine agile 
Methode, die darauf verzichtet. Wohl gibt es anscheinend Organisationen, 
die darauf verzichten, aber das ist dann nicht agil, sondern chaotisch, 
und die gab es schon immer.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Geplagter schrieb:
> Das Extrem ist sicherlich auch nicht gut. Aber in meiner aktuellen Firma
> erlebe ich gerade das genaue Gegenteil: Da steht eher die Einhaltung des
> formalen Prozesses im Vordergrund als das eigentliche Vorankommen mit
> der Software. Hauptsache es ist alles richtig dokumentiert, es werden
> seitenlange Verwahrensanweisungen abgearbeitet, um den formal korrekten
> Prozess eingehalten. Zu den anderen Abteilungen und nach "oben" wird
> dann kommuniziert wie wichtig bei uns die Qualitätssicherung sei.
>
> Aber die eigentliche Software ist schei***. Da sitzen zwei Entwickler
> dran (u.a. ich), kommen kaum hinterher die Anforderungsliste
> abzuarbeiten und an jeder Ecke wird man ausgebremst.
>
> So entsteht höchstens auf dem Papier qualitativ hochwertige Software.

Extreme Übertreibungen sind natürlich in keine Richtung gut. Wobei der 
Fall, dass zu viel dokumentiert wird, deutlich seltener auftritt als die 
"Doku? Mir doch scheißegal" Einstellung vieler Programmierer.

Autor: genervt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geplagter schrieb:
> Ich hoffe doch nicht ;-)
>
> Ich bin da relativ neu dran. Vielleicht habe ich da einfach einen
> anderen Blick drauf.

Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt 
ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur.

Sieh zu, dass man dir ein paar passende Schulungen verpasst, wenn du die 
nicht kriegst, schau dich nach nem neuen Job um!

Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart 
im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät.

Autor: Qwertz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genervt schrieb:
> Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt
> ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur.

Exakt so ist es. Wenn ich schon lese, dass es nur zwei Entwickler 
gibt...

> Sieh zu, dass man dir ein paar passende Schulungen verpasst, wenn du die
> nicht kriegst, schau dich nach nem neuen Job um!

Mach das besser sofort!

> Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart
> im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät.

Na hoffentlich kein Amoklauf.

Autor: Wühlhase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um mal auf die Ausgangsfrage zurückzukommen:
Ich habe (beruflich!) bisher nur VBA benutzt-um Excelprogramme zu 
schreiben. Kein Witz.
Zwar nur in Werkstudentenstellen und meine Skripte waren auch schon 
relativ ausgewachsen (das letzte Projekt hatte insgesamt ca. 12.000 
Codezeilen, Kommentare und Leerzeilen nicht einberechnet), ich war aber 
froh um meine Java- und C-Vorlesungen. Das hat den Einstieg erheblich 
erleichtert, ich mußte mir VBA autodidaktisch beibringen.

Ansonsten: Sprachen lernt man relativ fix. Viel wichtiger ist, Konzepte 
wie OOP verinnerlicht zu haben wenn man gute Programme schreiben will.

Ansonsten: Möglicherweise brauchst du für den von die angesprochenen 
Bereich gar keine Programmierkenntnisse. Du entwickelst Hardware, die 
irgendwann mal einem Softwerker vor die Füße geworfen wird mit den 
Worten "Mach!".
Dann arbeitest du aber möglicherweise mit einem CAD-Programm, das 
irgendeine abgefahrene Programmiersprache für Skripte unterstützt und 
die du nutzen könntest (was erstmal nie ein Nachteil ist).

Autor: Geplagter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genervt schrieb:
> Euch scheint ein erfahrender Softwareentwickler zu fehlen, das klingt
> ein wenig nach Klitsche mit "günstiger" Gehaltsstruktur.

Ich weiß: Eigenlob stinkt, aber in bin schon ein erfahrener 
Softwareentwickler. Und eine "Klitsche mit günstiger Gehaltsstruktur" 
ist das auch nicht.

> Wenn sich da nicht ändert, dann steckt in 1-2 Jahren das Projekt derart
> im Dreck, dass der Frust eskaliert und dann ist es ohnehin zu spät.

Weg möchte ich da eigentlich nicht, da sonst alles stimmt: Kollegen, 
Vorgesetzte, Gehalt, Anfahrt... Dass das Projekt in Verzug ist, scheint 
auch keinen zu stören, im Gegenteil über jeden kleinen Fortschritt 
freuen sich alle. Insofern läuft es für mich ganz gut. Ist halt nur 
frustrierend, wenn man weiß es könnte viel schneller und besser voran 
gehen. Insofern eskaliert der Frust eher bei mir - und nicht bei denen, 
wo er eigentlich eskalieren sollte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.