Gooose

Ich habe meine Workstation im Büro, und ein Surface für alles MS-lastige. Fürs Telefonieren gab es ein iPhone. Abends landen die Geräte in der Schreibtischschublade. In den letzten 1,5 Jahren wurde ich vielleicht 5 mal angerufen. Unsere Kommunikation ist stark asynchron (Jira/Confluence) und das klappt erstaunlich gut. Ich hatte auch schon mal Notebook + Handy für beruflich + privat zur Verfügung. Da hat es keinen gejuckt, was wir mit den Geräten machten. Für die Zukunft würde ich immer ein Auge darauf haben, ob die mir zur Verfügung gestellte Hardware zum Aufgabenbereich passt. Private Telefonnummern habe ich nie rausgegeben. Ich bin seit Mai in Elternzeit, und bisher hat noch niemand versucht mich zu erreichen. Das ist für mich ein gutes Zeichen, und ich freue mich darauf die Jungs und Madels im September wieder zu sehen.

Ich persönlich bin Fan von Vertrauensarbeitszeit. Wir verständigen uns als Team was innerhalb von zwei Wochen zu schaffen ist. Mittlerweile sind wir mit den Schätzungen gut geworden. Ich möchte mir nicht jedes mal aufschreiben müssen, wenn ich mal eben mit meiner Tochter spazieren gehen möchte. Dies funktioniert gut, da ein guter Teil unserer Kommunikation asynchron ist. Wir haben bei uns nur eine handvoll Meetings. Überstunden kommen praktisch nicht vor.

Du wirst während deiner Ausbildung lernen Lösungen für Probleme zu finden. Am Anfang wirst du erst mal mit wenigen Werkzeugen starten, und während deines Berufslebens kommen weitere hinzu. Die meisten Firmen bilden für den Eigenbedarf aus. Somit ist die Technologiewahl zunächst gesetzt. Wenn du dich für bestimmte Technologien interessierst, such dir eine Firma, die diese auch verwendet. Wenn du neugierig bist, schau dir andere Sachen an, doch beachte, dass das regelmäßige Verwenden einer Technologie erst dafür sorgt, dass man sicher damit umgehen kann. Es ist einfacher, wenn du es auch täglich dein Erlerntes verwenden kannst.

Du könntest ja deinen Kollegen deine Texte zeigen, bevor du sie veröffentlichst. Wenn du über Dinge schreiben möchtest, die einen Arbeitsbezug haben, musst du deine Texte so weit abstrahieren, dass kein direkter Bezug zur Arbeit mehr vorhanden ist.

Zeit ist Unbezahlbar. Von daher so viel Urlaub wie möglich. Ich hatte die letzten Jahre 30 Tage.

docx Dateien sind zip Dateien. Enpacke die docx Datei, die du verschicken möchtest, und suche nach den Kommentaren, die eigentlich nicht mehr da seien sollten.

Wir haben ein relativ gut aufgeräumtes Backlog. Neue Tickets werden soweit angereichert, bis sie den Status "ready for development" haben. Wir schätzen unsere Tickets in Punkten. Mit der Zeit haben wir erkannt, wie viele Punkte innerhalb eines Sprints zu schaffen sind. Das Team trifft gemeinsam die Aussage, ob der Sprint zu schaffen ist oder nicht. Es werden keine Zeiten geschätzt. Tickets sind soweit angereichert, das jeder im Team sie bearbeiten könnte.

Schaue dir mal die Kommandos "cat", "sort" und "head" an.

Das stimmt schon. Es liegt aber auch daran, dass es hier und da nicht gern gesehen wird, wenn man im Lebenslauf so einen Punkt drinstehen hat (ich glaube, das wird aber besser). Dabei kann es ja verschiedene Ursachen haben. Es kann ja sein, das man einfach nicht harmoniert hat. Ein Stellenwechsel ist immer mit einem Risiko verbunden. Deswegen sollte man sich von Anfang an um seine Neuankömmlinge kümmern. Es ist im eigenen Interesse. Sollte es doch nicht passen kann man ja auch dies dem neuen Kollegen sagen, und ihm Zeit geben sich etwas neues zu suchen. Die Welt ist klein, und Fairness spricht sich um. Je häufiger neue Kollegen in ein vorhandenes Umfeld eingefügt werden, desto einfacher fällt es den schon vorhandenen Kollegen mit Neuankömmlingen umzugehen. Sie arbeiten mit in den Teams und laufen/arbeiten mit. Ja, es sind Kosten die hier entstehen, doch einfach nur durch die Geldbrille zu sehen ist hier aus meiner Sicht zu kurz gedacht. Wichtig ist, dass der neue Kollege ins Team passt, und das findet das Team am besten selbst heraus. Alles was fachlich fehlen sollte, kann man lernen. Bei einer Persönlichkeit, die nicht ins Team passt, ist es schon schwieriger sich anzupassen.

Ich bin immer noch der Ansicht, dass der Arbeitgeber die Probezeit besser nutzen sollte, um die letzten Bedenken zu beseitigen. Die Energie, die während des Bewerbungsprozesses investiert wird (Interviews noch und nöcher, Probearbeitstage, Hausaufgaben, Testprojekte...), sollte sie lieber während der Probezeit investiert werden, um den neuen Kollegen zu begleiten. Nach ein paar Wochen kann man schon erkennen wo die Reise mit dem neuen Kollegen hingeht. Für den Bewerber ist die Situation aus meiner Sicht weniger stressbehaftet, da er mehr Zeit hat, sich unter realen Bedingungen zu beweisen.

Wenn man Leute einstellt, sollte man neben den vorhandenen Fakten (Bewerbung/Lebenslauf) sich selbst ein Bild von dem Menschen machen. Man merkt in den ersten Minuten im Gespräch, ob das was wird, oder auch nicht. Dieses "immer auf Nummer sicher gehen" ist eine Sache die ich persönlich nicht mag. Firmen sollten die Probezeit mehr nutzen, und dafür ihre HR Prozesse verschlanken.

Es gibt viele FIs, die mit der Zeit von AE zu SI oder anderes herum wechseln. Sie suchen sich hierfür ggf. Juniorstellen und starten noch mal durch. Das Rüstzeug hierfür haben beide aus dem Startblock heraus. Wenn man als FI anfängt ist es sicherlich einfacher für einen AE eine Entwicklerstelle zu finden wenn man FIAE gelernt hat. Später schaut man aber nur noch, was er gemacht hat. Mich hat bis her (10 Jahre) keiner nach der Ausbildung gefragt. Dem Arbeitgeber interessiert es, ob man deren Erwartungen erfüllen kann oder nicht. Wenn ich in DevOps einsteigen wollte, würde ich mir eine Stelle raussuchen, und mich dann einarbeiten. Ich denke das eine FI Ausbildung reichen würde. Alles andere kann man auch durch "externe Bildungsangebote" verfeinern (z.b. Zertifikate, "micro degrees", was auch immer).

Schau dir mal das PHP Quickstart Beispiel von Google an. Lies dich erst mal in das Thema rein. Vielleicht bringt dich das weiter.

Ich hatte mal ein Probeprojekt für ein Vorstellungsgespräch gebaut. Es geht zwar um vue, aber vielleicht kannst du damit was anfangen. Hier noch ein kleiner Blog Artikel dazu.

Das ist natürlich war. Ich wollte nur herausstellen, dass man mit "MS Boardmitteln" eine Webpräsenz aufbauen kann. Für den Tante Emma-Laden reicht sicherlich ein Managed Wordpress, wo der Betreuungsaufwand sicherlich gering ist. Man darf die aber nicht die Zeit unterschätzen, die man investieren muss, wenn man so etwas nebenberuflich betreiben will.

Stackoverflow hat einen relativ windowslastigen Stack (Stack Overflow: The Architecture - 2016 Edition), aber auch hier findest du Linuxsysteme. Du wirst um Linux nur schwer herumkommen.

Nach ein paar Anläufen bin ich bei Gentoo Linux gelandet. Es hat mich dazu gezwungen, mich mehr mit dem Aufbau des Gesamtsystems auseinanderzusetzen. Es gibt keinen Installer im eigentlichen Sinne. Man baut das System nach und nach auf. Aktuell ist mein System 140GB (ohne portage und home) groß. Viele Pakete muss man per Hand konfigurieren, doch die Dokumentation von Gentoo ist vorbildlich. Die meisten Pakete werden lokal auf der eigenen Maschine kompiliert. Dies dauert zwar länger, aber man kann für sich entscheiden, welche Eigenschaften ein Paket haben soll. So kann man beispielsweise sagen das vim app-editors/vim -X python lua perl tcl keine X11 Unterstützung haben soll, dafür aber python, lua, perl. So kann man unnötige Abhängigkeiten vermeiden. Im beruflichen Umfeld arbeite ich mit Ubuntu, wobei ich auch hier von meinen Gentooerfahrungen profitieren kann.

Stuttgart Habe mal eben eine kurze XING Suche ".NET Web Developer" / "Stuttgart" / "20km" gemacht. 65 Stellenangebote mit geschätzten Gehältern zwischen 50k und 70k€. Vieleicht ist für dich ja was dabei.

Da mit der Zeit immer mehr funktionale Elemente in C# eingeflossen sind, habe ich mich interessehalber mit Erlang, Haskell und F# beschäftigt. Das "dümpelte" so ein Jahr vor sich hin. Als ich die Möglichkeit bekam, in einem Elixir Projekt mitzuarbeiten, habe ich dann aus Neugier zugeschlagen. Mit meinen Vorkenntnissen habe ich ca. eine Woche benötigt, bis ich meine ersten produktiven Commit erstellt habe. Am Anfang sicherlich nichts Weltbewegendes, aber man kann mit Elixir relativ schnell Fahrt aufnehmen. In Erlang/Elixir ist die funktionale Programmierung ein Mittel zum Zweck. Wichtiger ist es den Supervision Tree zu verstehen; zu verstehen, wie Prozesse miteinander interagieren. Es gibt hilfreiche Abstraktionen wie den GenServer und den Supervisor, der die Kommunikation zwischen den Prozessen ein wenig "normiert". Ein guter Einstieg ist das Phoenix Framework, welches die Möglichkeiten der Sprache ziemlich ausnutzt. Man muss am Anfang nicht alles verstehen. Die Dokumentation ist vorbildlich, und man kann aus fast allen Punkten direkt in den Code springen.

Ich denke du kannst für dich eine Vorliebe entwickeln, und ggf. eine Firma suchen, wo du entweder mit Java oder mit C# arbeiten kannst. Die Problemlösungsstrategien, die du mit der Zeit entwickelst, wirst du auf andere Sprachen übertragen können. Mit der Zeit stellt sich die Frage nach einer Sprache oder einer Plattform/Framework weniger. Man ist eher dazu bereit auch mal was anderes zu probieren. Ich bin beispielsweise nach ca 7 Jahren .NET / C# und co. Richtung funktionaler Programmierung mit Elixir / Erlang gewechselt. Ich bin offen dem gegenüber, was kommen mag. Die Jahre davor sind nicht weggeworfen. Ich profitiere jeden Tag davon.

Ich fahre gerade 10km mit dem Rad zur Arbeit. Ich brauche ca. 30 Minuten. Für den Fall, dass ich einmal komplett durch-geregnet ankomme, habe ich Wechselunterwäsche am Arbeitsplatz. mit dem Auto würde ich ca 15-20 Minuten brauchen. Mit einem E-Bike, würde ich die strecke auf ca 20 Minuten schätzen. Ein Auto nur für die Arbeit ist für mich ein wenig überdimensioniert. Mit einem "guten" Fahrrad macht die Sache sogar Spaß

Sicherlich sollte man nicht anfangen zu optimieren, bevor überhaupt ein Bottleneck zu erkennen ist. Ich kenne auch Prozeduren, die sich über hunderte Zeilen erstrecken, und quasi nur von außen oder "raise info" testbar sind. Ich denke, die Mischung machts. Man kann ja erst mal ohne anfangen, und wenn man beispielsweise merkt, das bestimmte Aktionen zu viele Roundtrips zur Datenbank übernehmen, kann man ja eingreifen. Andere Anwendungsfälle kommen mit Caching bestens zu recht, wenn die "teure" Datenbankaktion nur nach einer Cacheinvalidierung geschieht. Was ich eigentlich aufzeigen wollte ist, dass man mit MicroORMs auch zu guten Ergebnissen kommen kann. Es gibt einfach weniger bewegliche Teile.

Zumal es hier auch leichtgewichtige Lösungen wie Dapper gibt. Wenn man mit Stored Procedures arbeitet bekommt man relativ schlanken Code.

Schau dir mal ein paar Visual Basic Repositories auf Github an. Vielleicht bringt dich das auch weiter.