Ich habe embedded SW geschrieben für Pic32. Das Steuergerät hat viele I2C Sensoren hinter einem Switch, welche Messdaten aufbereitet, in Daten-Buffer verarbeitet, diese per SPI (Slave) an höhere System transferiert. Nicht wirklich schwer, wenn man sowas öfters macht. Die Mitarbeiterin hat einige SW-Erfahrung, aber nicht in solchen Multithread und Echtzeit-Applikation. Eher PC-Programmierung und Oberflächen. Mein Projekt-Chef meint, sie muss das können, aufgrund ihrer Ausbildung (FH), und erwartet, dass sie Code-Erweiterungen selbtständig machen kann. Es liegt an mir, mit Dokumentation und persönlichen Couching das zu erreichen. Irgendwie fehlt es ihr an Geduld, sie hält es nicht für schwierig und hält einfache Hello-World-Projekte nicht für notwendig, um das Prinzip zu verstehen. Persönlich glaube ich kaum, dass sie es kurzfristig verstehen kann, um da selbständig weiterzumachen. Trotzdem will ich von meiner Seite alles probieren, um die Aufgabe zu meistern. Wie könnte ich da vorgehen? Der Projektleiter setzt viel auf Diagramme. Grafische Darstellung vom Code gelingt mir nicht so gut, die zeitliche Abfolge der verschiedenen kommt da nicht klar raus. (Ich kann super Flowcharts machen z.B. bei schwierigen (math., single Task) Algorithmen.)
Ich sehe da kein Problem, das sind eher einfache Aufgabenstellungen. Hast du noch nie etwas Anspruchsvolles gemacht?
> Autor: freelancer (Gast) > Datum: 20.10.2018 08:14 > Irgendwie fehlt es ihr an Geduld, sie hält es nicht für schwierig und > hält einfache Hello-World-Projekte nicht für notwendig, um das Prinzip > zu verstehen. Wahrscheinlich fehlt noch mehr. Mach das mögliche und lass sie auflaufen. Damit die sehen was die an dir haben.
> Mach das mögliche und lass sie auflaufen. > Damit die sehen was die an dir haben. Genau da sehe ich die Gefahr, dass dieses mir unterstellt wird. Informationen/Hilfestellung zurückhalten, um sich unentbehrlich zu machen.
freelancer schrieb: >> Mach das mögliche und lass sie auflaufen. >> Damit die sehen was die an dir haben. > > Genau da sehe ich die Gefahr, dass dieses mir unterstellt wird. > Informationen/Hilfestellung zurückhalten, um sich unentbehrlich zu > machen. Unsinn, wenn eine vernünftige Doku vorliegt, ist alles in Butter. Es wird ja wohl kein Problem sein die wesentlichen Module in Diagrammen zu beschreiben und den relevanten Ablauf in Sequenz- und Nebenläufigkeitsdiagrammen abzubilden und eventuelle Pitfalls zu beschreiben. Das gehört zu professioneller Entwicklung dazu.
Zocker_54 schrieb: > Autor: freelancer (Gast) > Datum: 20.10.2018 08:14 > > Irgendwie fehlt es ihr an Geduld, sie hält es nicht für schwierig und > hält einfache Hello-World-Projekte nicht für notwendig, um das Prinzip > zu verstehen. > > Wahrscheinlich fehlt noch mehr. > > Mach das mögliche und lass sie auflaufen. > > Damit die sehen was die an dir haben. Das ist deine Art ich weiß aber das macht man nicht.
> Autor: freelancer (Gast) > Datum: 20.10.2018 08:52 > Genau da sehe ich die Gefahr, dass dieses mir unterstellt wird. > Informationen/Hilfestellung zurückhalten, um sich unentbehrlich zu > machen. Damit müssen sie eben rechnen, passiert nicht nur bei freelancern sondern kann auch bei Festangestellten passieren. Wer nicht hören will muss zahlen.
Die Firma ist keine SW-Schmiede, sondern stellt spezielle HW her. Es ist das Denken verbreitet, dass man Programmierung in der FH lernt, und dann kann man alles erledigen, was so anfällt. Notfalls nach dem Besuch von Kursen. Ich selber habe mir alles in sehr sehr viel Stunden autodidaktisch beigebracht, und tue mir schwer, Tipps zu geben, wie man Skills erwirbt.
freelancer schrieb: > Die Firma ist keine SW-Schmiede, sondern stellt spezielle HW her. > Es ist das Denken verbreitet, dass man Programmierung in der FH lernt, > und dann kann man alles erledigen, was so anfällt. Notfalls nach dem > Besuch von Kursen. Ja dann lass sie doch dran ersticken, wenn die das meinen. Wie gesagt, mach ne ordentliche Doku, der Rest ist nicht dein Bier.
> Autor: Abradolf L. (Firma: Ricksy Business) (abradolf_lincler) > Datum: 20.10.2018 09:19 > Ja dann lass sie doch dran ersticken, wenn die das meinen. Wie gesagt, > mach ne ordentliche Doku, der Rest ist nicht dein Bier. Sehe ich auch so.
freelancer schrieb: > Grafische Darstellung vom Code gelingt mir nicht so gut, die zeitliche > Abfolge der verschiedenen kommt da nicht klar raus. Dann solltest du DAS mal lernen. Das ist Doku.
Es gibt doch sicherlich ein Pflichtenheft auch im Hinblick auf die Doku.... Darüber hinaus wird kein Wissen weitergegeben.
Beitrag #5593341 wurde von einem Moderator gelöscht.
Beitrag #5593356 wurde von einem Moderator gelöscht.
Beitrag #5593359 wurde von einem Moderator gelöscht.
Dennis schrieb im Beitrag #5593356: > Immer wieder schön wie du selbst von Softwarearchitektur keine Ahnung > hast Du vermischt hier verschiedene Dinge: Architektur kannst Du vorher mit bunten Bildchen machen, wenn es Dir hilft. Den Code nachher mit Bildchen zu erklären ist etwas ganz anderes und ...in der Regel sinnlos, da jeder eine andere Doku bräuchte: der Maintainer eine andere als der Nutzer oder der Inbetriebnahme oder der Tester. Wahr ist nur der Code, also das Design, aus den sich alles andere ableiten lässt.
Beitrag #5593397 wurde von einem Moderator gelöscht.
freelancer schrieb: > Persönlich glaube ich kaum, dass sie es kurzfristig verstehen kann, um > da selbständig weiterzumachen. Trotzdem will ich von meiner Seite alles > probieren, um die Aufgabe zu meistern. > > Wie könnte ich da vorgehen? Das ist nicht ungewöhnlich. Der Chef will zumindest rudimentäres Wissen intern haben, die Mitarbeitern hofft, nichts damit zu tun zu haben. Doku und etwas Einschulung genügt. Wenn wirklich etwas zu tun ist, erst dann wird sie sich entweder hineintigern, oder es wieder an dich geben.
freelancer schrieb: > Grafische Darstellung vom Code gelingt mir nicht so gut, die zeitliche > Abfolge der verschiedenen kommt da nicht klar raus. > (Ich kann super Flowcharts machen z.B. bei schwierigen (math., single > Task) Algorithmen.) Flussdiagramme sind für algorithmen, einfache abläufe, sequenzdiagramme für nebenläufige prozesse. Mit UML ist ne menge mehr möglich, Schaus dir an.
Frauen was Technisches beibringen was sie selber nicht kapieren wollen ... versuch es weiter und lass dir nichts anhängen.
Nebenlaeufigkeit stellt man unter anderem auch in State-Event-Action Diagrammen dar. Die Doku muss das Wesentliche beinhalten. Ganz klar muss die Doku als vollstaendig betrachtet werden, und eben so klar ist, dass die doku erst betrachtet wird, wenn sie auch benoetigt wird. Das wuerd ich auch so machen. Ich wuerd die ersten sagen wir 5 Stunden Support gratis machen, und nachher kostenpflichtig. Dann werden sie sich's ueberlegen bevor sie anrufen und dich nicht mit Trivialitaeten belagern.
freelancer schrieb: > Die Mitarbeiterin hat einige SW-Erfahrung, aber nicht in solchen > Multithread und Echtzeit-Applikation. Wenn du dir das nebenher beibringen konntest, dann können das Andere auch. freelancer schrieb: > Ich selber habe mir alles in sehr sehr viel Stunden autodidaktisch > beigebracht, und tue mir schwer, Tipps zu geben, wie man Skills erwirbt. Dann solltest du dir auch noch beibringen, wie man dokumentiert. Denn auch das ist Teil deiner Arbeit als "Freelancer". > Persönlich glaube ich kaum, dass sie es kurzfristig verstehen kann, um > da selbständig weiterzumachen. Mach dir keine Sorgen. Sie wird das mittel- oder langfristig lernen oder daran scheitern. Oder du bekommst anschließend wieder mal einen Auftrag. Wozu deine Sorgen? > Mein Projekt-Chef meint, sie muss das können, aufgrund ihrer Ausbildung > (FH), und erwartet, dass sie Code-Erweiterungen selbtständig machen > kann. > Es liegt an mir, mit Dokumentation und persönlichen Couching das zu > erreichen. "Couching" mit der "Mitarbeiterin", die zudem von der "FH" kommt und es deshalb nicht schnell genug lernen können wird? Überaus trollig, das hier.
freelancer schrieb: > Genau da sehe ich die Gefahr, dass dieses mir unterstellt wird. > Informationen/Hilfestellung zurückhalten, um sich unentbehrlich zu > machen. Das geht bei Software nicht. Bzw...: Das rettet keine Doku. Entweder Deine SW ist schlecht geschrieben (gebastelt), dann macht es eine Beschreibung nicht besser. Oder Dein SW ist gut und ihre Fähigkeiten begrenzt: Dann kannst Du sie coachen, aber kein Lehrbuch schreiben. Wenn Deine SW gut und Ihre Fähigkeiten angemessen sind, dann kannst Du mit ihr ein Codereview machen. Und natürlich auch neuralgische Punkte (wo Ihr einfach Verständigungsschwierigkeiten habt) gemeinsam dokumentieren (also eine Darstellung der Abläufe entwickeln. Wenn Du von der SW ein perfektes UML-Äquivalent (Flow-Chart, was immer) erstellen würdest, hätte niemand was davon, da die Komplexität in UML nicht kleiner wird. Also kannst Du nur Abstrakte Repräsentationen des Codes in was auch immer erstellen. Es ist nur recht zweifelhaft, dass sie oder irgendwer dort UML (etc.) besser versteht. Mein Rat: 1) Die Umgebung soweit sauber ziehen, dass es mit möglichst geringem Aufwand auf einem neuen Rechner gebuildet werden kann. Also keine Klicks in einer IDE, keine aufwendige Spezialinstallation des Compilers, sondern im Best Case braucht man nur das VCS, checkt ein paar Ordner aus (tools, Code, Doku) und ruft eine Batch-Datei auf. --> Kein verstecktes Spezialwissen, da reicht eine Seite Doku der Pfade 2) Codereview mit ihr und Projektleiter. 2-3 typische Änderungen vornehmen (lassen) und Builden/einladen. 3) Offene Fragen als Liste aufnehmen und nur noch die in der notwendigen Ausführlichkeit nachreichen. 4) Übergabe bestätigen lassen (mit ausstehender Frageliste) 5) weiteren Support ganz normal berechnen (also die üblichen 50-100€/h)
> Es gibt doch sicherlich ein Pflichtenheft auch im Hinblick auf die > Doku.... Nein, da gibt es nichts. Grund ist, dass die Software sehr sehr schnell fertig sein musste. (Bei anderen Projekten, wo viel Zeit ist, nahmen die bisher ein SW-Ingenieurbüro.) Solche Feuerwehr-Sachen liegen mir, ich hatte gerade Zeit, und der End-Kunde (also der Kunde der Firma) war sehr zufrieden. > in Sequenz- und Nebenläufigkeitsdiagrammen abzubilden das scheint das richtige zu sein. Muss noch die Tools zusammensuchen. In der Firma gibt es nichts. Die haben nicht einmal eine Source-Code Versions-Verwaltung. Wie schon erwähnt, SW ist nicht deren Schwerpunkt.
"Wenn du dir das nebenher beibringen konntest, dann können das Andere auch." Nee. Ich habe mir das schon in der Schulzeit beigebracht, und da hatte ich genügend Zeit tagsüber (Nachmittags kein Unterricht) und lange Ferien. (Während Studium und Berufsleben waren die Freiräume schon kleiner.) Die Mitarbeiterin hat nur FH-Wissen/Praxis, also keine private Programmierpraxis. Dann dürfte die Hürde hoch sein, nebenbei sich noch zu vertiefen.
freelancer schrieb: > Die Mitarbeiterin hat nur FH-Wissen/Praxis, also keine private > Programmierpraxis. Dann dürfte die Hürde hoch sein, nebenbei sich noch > zu vertiefen. Das denkst du, die Realität ist eine andere. Den Standardkram auch im Bereich nebenläufige Programmierung hat man recht schnell raus, solange man die theoretischen Grundlagen beherrscht. Wenn man sich dann mal intensiv 1-2 Wochen mit einem abgesteckten Thema beschäftigt, kriegt man schon nen recht guten Überblick.
freelancer schrieb: > Couching Der Boss hat Couching mit der Mitarbeiterin angeordnet? Scheinen ja ziemlich lockere Sitten zu sein in dem Laden... [urban dictionary] couching The act of engaging in promiscuous activities on living room furniture. Such as making love and having sex on a couch. Also could mean getting fingered or giving a hand job on a couch. Oh my god! Did you hear that Nick and Kim were couching last night, while Kim's mother was in the other room working?! [/urban dictionary]
:
Bearbeitet durch User
Echtzeitprogrammierung ist nicht so schwierig zu verstehen. Ein paar Konzepte, und man versteht's. Selbst von Null auf Anwenden dauert etwas laenger. Ist aber machbar.
Lothar M. schrieb: > "Couching" mit der "Mitarbeiterin", die zudem von der "FH" kommt und es deshalb nicht schnell genug lernen können wird? > Überaus trollig, das hier. "Couching" habe ich bewusst überlesen, der restliche Schreibstil lässt eine russische Abstammung vermuten.
Sequenzdiagramme scheinen eine gute Sache zu sein. Habe noch nie was davon gehört. https://www.uml-diagrams.org/sequence-diagrams.html Allerdings müsste ich in dem Diagramm die verwendeten Variablen/Flags unterbringen, um den Signalablauf darzustellen. Z.B. wenn über Uart (oder SPI) ein Request reinkommt, um mit einem bestimmten I2C-Slave was zu machen, ist der I2C vermutlich nicht frei. D.h. da wird eine request-Variable "req_..." beschrieben mit entsprechenden Paramter. An anderer Stelle werden zu einem Zeitpunkt, wo diese Requests gehandelt werden können, diese Variablen abgefragt, und entsprechende Aktionen eingeleitet. D.h. sehr viele State-Machines. Im Source-Code ist das alles sehr verstreut und unübersichtlich, aber mit den Sequenz-Diagrammen könnte das übersichtlich und verständlich werden.
freelancer schrieb: > Sequenzdiagramme scheinen eine gute Sache zu sein. > Habe noch nie was davon gehört. Dafuq?
Abradolf L. schrieb: > Wenn man sich dann mal intensiv 1-2 Wochen mit einem abgesteckten Thema > beschäftigt, kriegt man schon nen recht guten Überblick. Wobei ich das als Mitarbeiterin aber jetzt nicht unbedingt in meiner Freizeit machen würde.
Reinhard S. schrieb: > Abradolf L. schrieb: >> Wenn man sich dann mal intensiv 1-2 Wochen mit einem abgesteckten Thema >> beschäftigt, kriegt man schon nen recht guten Überblick. > > Wobei ich das als Mitarbeiterin aber jetzt nicht unbedingt in meiner > Freizeit machen würde. Davon spricht ja auch niemand. Aber zwei Wochen Arbeit sind auch 50-80 Stunden, da kann man sich schon einen Überblick verschaffen. Vor allem wenn man noch vernünftiges Tooling hat, was einen dabei unterstützt.
freelancer schrieb: > Sequenzdiagramme scheinen eine gute Sache zu sein. > Habe noch nie was davon gehört. Hmmm, UML gehört allerdings zum Standardrepertoire. Sagt allerdings auch viel über den Kunden aus wenn er auf sowas verzichten will. :/ > https://www.uml-diagrams.org/sequence-diagrams.html > > Allerdings müsste ich in dem Diagramm die verwendeten Variablen/Flags > unterbringen, um den Signalablauf darzustellen. > > Z.B. wenn über Uart (oder SPI) ein Request reinkommt, um mit einem > bestimmten I2C-Slave was zu machen, ist der I2C vermutlich nicht frei. > D.h. da wird eine request-Variable "req_..." beschrieben mit > entsprechenden Paramter. An anderer Stelle werden zu einem Zeitpunkt, wo > diese Requests gehandelt werden können, diese Variablen abgefragt, und > entsprechende Aktionen eingeleitet. D.h. sehr viele State-Machines. > Im Source-Code ist das alles sehr verstreut und unübersichtlich, aber > mit den Sequenz-Diagrammen könnte das übersichtlich und verständlich > werden. Als Fasutregel gilt: Wenn etwas schwer fällt zu dokumentieren, dann ist es auch nicht optimal dokumentiert. Oft merkt man erst beim Doku schreiben, dass man einige Dinge hätte eleganter lösen können, das Phänomen dürfte jeder kennen und mit der Erfahrung wird das zum Glück auch immer weniger. Liegt vermutlich daran, dass man erst beim Doku schreiben aus seinem Tunnel rauskommt und anfängt sich selbst zu reviewen. Auch sollte man sich dann nicht vor dem Refactoring Prozess scheuen, vorallem wenn man weiß dass die Codebasis in Zukunft noch weiter verwendet wird. Das gute ist: Am Ende hat man in der Regel alle Unit Tests fertig und hat eine super Grundlage. Wenn nach dem Refactoring alles Grün ist, ist man durch. :-) (Idealerweise hat der Entwickler die Tests nicht selbst geschrieben, wird bei einem Freelancer PRojekt jedoch nur selten der Fall sein.)
UML ist Akademische Onanie. Wenn der code nicht lesbar ist hilft das auch nichts.
Sachen gibts: Ich habe dem Projektleiter meinen Plan erzählt, mit Sequenzdiagrammen zu dokumentieren. Da widerspricht er mir, und sagt, dass ich das mit der Mitarbeiterin abklären soll. Das ist wie im Kindergarten. Wenn ich das mache, dann will sie das womöglich nicht (sondern Flowcharts, irgendwas, was sie schon kennt). Dabei ist der Code ziemlich einfach, könnte man in ein paar Wochen machen. Es waren andere Dinge, die das verzögert haben.
freelancer schrieb: > Wenn ich das mache, dann will sie das womöglich nicht (sondern > Flowcharts, irgendwas, was sie schon kennt). Dann mach halt das. Du wirst dafür bezahlt, das zu machen, was dein Chef will. Und dein Chef will, das du das machst, was die MA will. Also wozu die Diskussion? > Es waren andere Dinge, die das verzögert haben. Das ist neu. Da hängt noch mehr im Argen?
freelancer schrieb: > Wenn ich das mache, dann will sie das womöglich nicht (sondern > Flowcharts, irgendwas, was sie schon kennt). Was soll sie auch mit Deinen ersten Sequence-Diagramm-Versuchen anfangen? Das hilft nur Dir, Deine Gedanken zu ordnen und bringt Dir Erfahrung damit. Macht ein Review und beschränke Dich auf konkrete Fragen.
Abradolf L. schrieb: > freelancer schrieb: >> Sequenzdiagramme scheinen eine gute Sache zu sein. >> Habe noch nie was davon gehört. > > Dafuq? Ist halt getrolle. Die Fähigkeiten der Mitarbeiterin abwertend beurteilen, aber selbst angeblich keine Grundlagen kennen. Der hat so viele Köder ausgelegt, der wartet doch nur darauf, dass der Thread überkocht.
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.