Gooose

Das kommt in den besten Firmen vor. Teile deinem Chef deine Pläne mit, und frag ihn welche Fähigkeiten aus seiner Sicht benötigt werden. Auf sozialer Ebene scheint es ja kein Problem zu sein. Was bringt es dir, irgend einen Techniker oder Bachelor anzustreben, wenn du gar nicht weißt, ob nachher der Chefposten dabei rumkommt? Mach deinen Bachelor oder Techniker, wenn du Spaß daran hast. Das ist die beste Motivation fürs Lernen. Mal angenommen, du bist in 4 Jahren noch nicht fertig, und dein Boss entscheidet sich für einen anderen Weg, was bleibt dir dann noch als Motivation den Techniker oder Bachelor abzuschließen? Fachwissen ist immer nur ein Teil des Arbeitslebens und kein Garant für Erfolg.

Für das Corporate Design, sollte die Firma, die das entwickelt hat (falls vorhanden) Testmuster mitgegeben haben, die in der Regel auch Farbcodes enthalten. Häufig hast du nicht nur die Farbcodes, sondern auch eine art "Anweisung" in welcher Kombination die zu verwenden sind (Freigegebene Schriftgröße, Kursiv ja/nein, Abstände, Überschriften....) Wenn das Druckergebnis mit den gegebenen Farbcodes nicht passt, muss man sich den Drucker anschauen. Wenn die Farben auf den Bildschirm anders aussehen, liegt es am Bildschirm (und dessen Kalibrierung). Wenn man keinen passenden Drucker hat, gibt man die Drucke in Auftrag.

Was würdest du beispielsweise machen, wenn jemand dein System verschlüsselt?

Wir einigen uns während der Sprintplanung über die Tickets, die innerhalb eines Sprints machbar sind. Haben wir am Ende des Sprints unsere Aufgaben erledigt, sind alle Glücklich. Sollte es Überläufer geben, sprechen wir darüber, wie wir es beim nächsten mal besser einschätzen können. Es macht keinen Unterschied, ob wir im Homeoffice oder im Büro arbeiten. Da man anhand der Tickets sehen kann, wer was wann bearbeitet hat, gibt es hier auch kein "Verstecken".

Nun ja, mal eben wird das auch nicht passiert sein. Es zeigt aber, dass man seinen Gegenüber überzeugen kann, unabhängig seiner Ausbildung, eine Aufgabe zu erfüllen, die ~100k€ wert ist.

Wenn eine Firma eine Software bereitstellt, bedeutet jeder Fehler, der erst beim Kunden gefunden wird, nicht nur ein Imageverlust. Alleine für die Chance diese Fehler möglichst früh im Entwicklungsprozess zu finden, lohnt sich der Aufbau eines dedizierten Test Teams. Du kannst davon ausgehen, das sich Softwaretester mehr als selbst tragen.

Das kann alles und nichts sein Ein Hello World wird fast immer performant laufen. Eine Überschrift habt ihr also schon. Jetzt könnte man sich mit den betroffenen zusammensetzen, und ein paar gezielte Fragen stellen, was eigentlich genau benötigt wird. Das müssen ja keine Romane werden. Ein bis zwei prägnante Sätze. Vielleicht schon mal Stories in Jira oder Ähnlichem anlegen. Von da aus sind konkretere Ideen nicht mehr weit. Diskutiert über die Stories. Wägt ab, welche Aufgaben möglicherweise zu komplex sind (vielleicht schon erste Schätzungen abgeben). Erst mal muss man wissen, was umgesetzt werden muss, dann kann man sich überlegen, womit man das umsetzt. Häufig gibt es ja schon eine "Hausmarke". Wenn man sich es leisten kann, lohnt sich einen Blick über den Tellerrand, und versucht etwas Neues. Doch das funktioniert nur wenn alle bis zum Geschäftsführer dahinterstehen. Ich würde zunächst eine technologieneutrale Betrachtungsphase vorziehen, die ruhig ein paar Wochen dauern darf. So fühlen sich alle Beteiligten auch mitgenommen.

Wenn mich eine Stelle interessiert, und ein Wechsel zu dem Zeitpunkt im Bereich des Möglichen liegt, mache ich mich vor dem ersten Gespräch schlau, und überzeuge meinen Gegenüber, dass ich aus Gründen xyz das schaffen kann. Hat bisher immer funktioniert.

Das ist wirklich ein Problem. Du brauchst mindestens einen, der dir das abkauft, sodass sich dein Wissen später in Arbeitszeugnissen widerspiegeln kann. Ein bisschen "Henne Ei Problem". Aber dieses Problem haben alle, die sich in neue Themengebiete einarbeiten wollen. Wenn man das ein paar mal gemacht hat, und dies auch mit Arbeitszeugnissen untermauert ist, ist die Wahrscheinlichkeit höher, dass einem ein Technologieschwenk gelinkt.

Für Python ist der The Hitchhiker’s Guide to Python eine gute Anlaufstelle.

Nutze die Ausbildungszeit um das Lernen zu lernen. Denn dies wird dich bis zur Rente (wohlmöglich noch darüber hinaus) begleiten. In den seltesten Fällen wirst du irgend jemand haben der dir Neues beibringt. Du musst lernen für dich Wichtiges zu erkennen und es dir selbst beizubringen.

Da kann man sich ja fast nen cron job für anlegen.

Ich frage mich gerade welche Vorteile ein hybrides Model bietet. Mal angenommen ein Teil der Belegschaft arbeitet Remote, der andere arbeitet vor Ort. Meeting vor Ort: Raum buchen Notebook oder ähnliches ausdocken und mit zum Raum nehmen. einer verbindet sich mit dem Meeting Chat. Remote Teilnehmer können Teilnehmen Meeting Remote: Klick auf "Am Meeting teilnehmen" Aufzeichnen (wenn es ok ist) und später ansehen. (keine aktive Teilnahme) Asynchrone Nachfrage, wenn etwas unklar ist. (Chat/Mail) "Stillarbeit" vor Ort: 2-6 Mann Büro Kollege kommt rein und berichtet über das Wochenende Kurze frage zu einem Wert der im Monitoring aufgefallen ist. "Sollen wir bestellen, oder gehen wir uns was holen?" ... Großraumbüro Kollegen sind unterwegs zu Meetings Kaffeemaschine Klo Kopierer Treffen sich unterwegs und sprechen Ad hoc über berufliches und privates. "Stillarbeit" Remote: Chatbot Nachricht im Operationsbereich (oder was auch immer) Chat Nachricht vom Support/PO/what ever Video Anruf vom Kollegen Kaffeemaschine vor Ort: Kaffee Kurzes Gespräch mit Kollegen (man kann manchen ansehen, ob sie auf dem Weg zu Klo sind, oder sich nen Kaffee ziehen) Mal eben über die Oberfläche putzen, weil der Vorgänger unachtsam war. Kaffeemaschine Remote: Kaffee Zeit bis zum ersten einloggen vor Ort: Aufwachen Waschen Klamotten suchen, die für die Öffentlichkeit noch geeignet sind. Zu Fuß / mit dem Zug / mit dem Rad / mit dem Taxi / mit dem Auto zur Arbeit fahren Parken ggf durch die Sicherheitskontrolle durch den Flur gehen, und allen anderen einen Guten morgen wünschen. An einem Montag über das Wochenende quatschen (häufig eilen Kollegen aus anderen Büros herbei und beteiligen sich) Rechner hochfahren ersten Kaffee holen ggf. Gespräch aus dem "guten Morgen wünschen" weiterführen hinsetzen, und sich sammeln einloggen Zeit bis zum ersten einloggen Remote: Aufwachen Rechner anschalten Waschen Kaffee machen hinsetzen, und sich sammeln einloggen Es gibt sicherlich noch mehr Scenarios, die man beachten sollte, doch sollte man sich fragen: Lässt sich ein Produktivitätsverlust auf die Remotesituation zurückführen? Technisch gesehen, kann ich verstehen, dass es erst mal ne weile braucht, bis das VPN einigermaßen stabil läuft. Dies wird bei steigender Mitarbeiterzahl auch aufwendiger. Gibt es Prozesse, die sich nur schwer oder gar nicht remote abbilden lassen? (Produktion, Labore, ect.) Stehen genug Notebooks, Workstations und Bildschirme für alle Mitarbeiter bereit? Können diese adäquat betreut werden? Während meiner Homeoffice Zeit habe ich sogar mehr Zeit mit meinen Kollegen verbracht, als vorher. Wir hatten teilweise Pairing Sessions mit mehreren Kollegen über mehrere Tage. Versucht mal für ein paar Tage ein Meetingraum zu buchen. Schmeiß einfach mal eine grobe Idee in den "Innovationchat", und schau, wer auf dem Knochen rum kaut. Live Coding in speziellen Channels. (ok, das war nicht so häufig, aber sehr witzig). Ich mag meine Kollegen, und habe die Zeit vor Ort auch genossen. Doch für die reine Arbeit, bin ich im Homeoffice produktiver. Ich bin gespannt ob es so für mich bleibt. Nach den NRW-Sommerferien weiß ich mehr. Meine persönliche Präferenz geht zu 100% Remote.

Wir sind mit unseren Schätzungen mittlerweile gut geworden. Die meisten Sprints können wir wie geplant abschließen. Zeichnet es sich ab, das wir bis zum Ende des Sprints Zeit übrig haben gibt es verschiedene Möglichkeiten diese Zeit zu nutzen: Weitere Tickets aus dem Backlog holen Dokumentation verbessern Die Retro erweitern, um evtl. aufgefallene Probleme zu besprechen. erweitertes Backlog Grooming. ... Es gibt eigentlich immer noch genug zu tun. Es wird immer Leute geben die schneller oder langsamer arbeiten. (man muss halt schauen, woran man "schneller" und "langsamer" fest macht.) Um das Wissen innerhalb des Teams besser zu verteilen, könnte man an Tickets arbeiten, die für einen eher "fachfremd" sind (z.b. jemand der eher im Backend unterwegs ist, löst Tickets aus dem Frontend Bereich). So "langweilen" sich später die Kollegen im Grooming nicht so sehr, und können dabei helfen, genauere Schätzungen hinzubekommen.

Wir sind seit März 2020 im Homeoffice. Nach den Sommerferien (NRW) schauen wir, ob wir wieder sinnvoll im Büro arbeiten können. Bei der Entscheidung, wie die zukünftige Zusammenarbeit aussieht, werden wir zumindest angehört. Ich bin auf das Ergebnis gespannt.

Ab August 2021: Berufserfahrung: ca. 12 Jahre Gesamtjahresbrutto: 67500€ zusätzliche Tätigkeiten: .NET / ASP.NET / MS SQL / Azure / Angular

Ich habe mal die Antwort des Stackoverflow Artikels getestet: Process p = new Process(); p.StartInfo.FileName = "cmd.exe"; p.StartInfo.Arguments = "/c dir *.cs"; p.StartInfo.UseShellExecute = false; p.StartInfo.RedirectStandardOutput = true; p.Start(); string output = p.StandardOutput.ReadToEnd(); p.WaitForExit(); Console.WriteLine("Output:"); Console.WriteLine(output); Das scheint zu funktionieren.

Ich ignoriere sie. Nur wenn ich Spaß daran habe, oder es mich persönlich weiterbringt. Wie soll man denn dann tagsüber arbeiten 🤔 Hier bräuchte man nur einen Informatiker unter zig tausenden zu finden, der sportlich aktiv ist um diese Aussage mit nein zu beantworten. Wenn mein Gegenüber sich mit solchen Gedanken plagen würde, würde ich schnell das Interesse an einem Gespräch verlieren. Ich habe für sowas keine Zeit.

Heizungsdaten werden mittlerweile gerne per Funk übertragen, sodass die Ableser nicht mehr ins Haus müssen.

Am Anfang ist man fast immer schnell dabei. Die Geschwindigkeit verliert man hinten raus (wie z.B. durch mangelnde oder fehlende Dokumentation).

Arbeit ist Arbeit, Freizeit ist Freizeit. Im Arbeitsvertrag sollte alles geregelt sein. Das heißt aber auch, das man in der Regel immer den "gleichen Schlag Mensch" bekommt. Wenn ich mir für die Arbeit etwas aneignen muss, ist das Arbeitszeit. Ich bin von Natur aus ein neugieriger Mensch, doch wenn der Arbeitgeber erwartet für ein bestimmtes Thema neugierig zu sein, ist dies Arbeitszeit. Wenn dem nicht so ist, hat man schnell seinen Stundensatz halbiert Das ist das Problem des Arbeitgebers. Die mangelnde Dokumentation und die "freiwillige Zusatzarbeit" verwässert den Aufwand eines Projektes. Irgendwann wird dies stillschweigend mit geschätzt, und man wird mit der Zeit immer unglücklicher. Man muss aufpassen, dass dies nicht zum Teufelskreis wird.

Sind eure offenen Stellen auf Neueinsteiger orientiert, oder habt ihr auch "erfahrene" Bewerber? So könnte das Gespräch schon anders ablaufen. Gerade wenn man sich über seine letzten Stationen unterhält.

Wie im Beispiel angedeutet, jemand den ich auf jedes Problem ansetzen kann. Der sich auch in Sachen einarbeiten kann, von den er keine Ahnung hat. Der Sachen ausschließen kann und ein wenig logisch ran geht. Das beschreibt einen Entwickler. Softwareentwicklung 1st/2nd/3rd Level Support PreSales Verantwortung für Projekte Ansprechpartner für Kunden Du startest also als Entwickler und "endest" als entwickelnder, verkaufender Ansprechpartner/Projektleiter. Und das nach ein bis zwei Jahren nach Berufseinstieg. Das ist schon ziemlich steil. Genau diese Transparenz solltet ihr euren Bewerbern geben.

Wenn es bis dato kein Problem ist, würde ich von diesen Tests erst mal absehen. Organisation und Dokumentation ist eher Standard als Ausnahme. Für Unternehmen ist dies langfristig überlebenswichtig (wenn man angenehm leben möchte). Was währe aus deiner Sicht stark? Dies haut in die Kerbe "Organisation und Dokumentation". Wer ist für den Kunden zuständig? Macht das auch der Entwickler? Hat der direkten Kontakt? ... Ihr erwartet, dass ein Berufseinsteiger sich nach einer gewissen Einarbeitungszeit sich einem Altkunden widmet, in einem (vermutlich) nicht dokumentierten System? Wahrscheinlich ohne Testumgebung? Quasi: Kundenkontakt, Projektverantwortung für Bestandskunden, (Dark)Brownfield Kenntnisse aufbauen ... Mal abgesehen, dass sich das für mich sehr schmerzhaft anhört, hätte ich als Bewerber wahrscheinlich ein paar Fragen. Seid einfach ehrlich zu euren Bewerbern, und die Wahrscheinlichkeit, dass diese auch ehrlich zu euch sind, ist groß.

Hat sich dieser Ansatz bei euch als problematisch erwiesen?