Als Chester Bennington 2017 gestorben ist, dachte wohl kaum jemand ernsthaft an ein Comeback. Zu prägend war seine Stimme für den Sound der Band. Als Sänger war er das Aushängeschild. Wenn man ihn hörte, wusste man sofort: Das ist Linkin Park.

Dann kam 2024 das große Comeback – mit der neuen Sängerin Emily Armstrong. Wie konnte das funktionieren? Und was hat das mit einer M-Shaped Personality zu tun?

Gehen wir es der Reihe nach an:

Die Stimme von Chester Bennington war ein klassisches „I“: eine klar erkennbare, außergewöhnlich starke Fähigkeit. Sicherlich basierte sie auf Talent und besonderen körperlichen Voraussetzungen, wurde aber über Jahre hinweg durch Übung und Erfahrung immer weiter verfeinert. Seine Stimme hat den Sound der Band massiv geprägt.

Aber warum funktioniert Linkin Park auch mit einer neuen Stimme noch? Weil die Stimme eben nicht das einzige Element ist, das den Sound der Band ausmacht.

Hinter den Kulissen ist Mike Shinoda aus meiner Sicht der eigentliche Strippenzieher – und ein gutes Beispiel für eine M-Shaped Personality.

Warum? Schaut man sich zum Beispiel den Wikipedia-Eintrag an, hat fast jedes Bandmitglied eine klar definierte Rolle. Mike Shinoda dagegen vereint gleich mehrere: Rap, Keyboard, Gitarre, Sampler, Piano, Gesang. Dazu kommt laut Discogs seine Arbeit als Producer und Co-Producer.

Er beherrscht extrem viele Dinge. Viele davon sehr gut – aber vielleicht keines davon auf absolutem Weltklasse-Niveau für sich allein betrachtet.

Ist er der beste Rapper der Welt? Nein.
Der beste Keyboarder? Auch nicht.
Der beste Songwriter? Wahrscheinlich nicht.
Der beste Produzent? Vermutlich ebenfalls nicht.

Aber er ist in all diesen Bereichen gut genug, und genau diese Kombination macht den Unterschied. Zusammengenommen bilden diese Fähigkeiten das kreative Rückgrat der Band. Wenn man einen Linkin-Park-Song hört, erkennt man oft schon sehr früh, dass es ein Song dieser Band ist – noch bevor der Hauptgesang überhaupt einsetzt.

Will ich damit die Beiträge der anderen Bandmitglieder kleinreden? Natürlich nicht. Für das Comeback war auch die ausdrucksstarke Stimme von Emily Armstrong entscheidend. Und selbstverständlich haben auch die anderen Mitglieder den Sound der Band geprägt und prägen ihn bis heute.

Aber irgendjemand musste sich auf die Suche nach einer neuen Sängerin machen. Irgendjemand musste daran glauben, dass die Geschichte der Band noch nicht zu Ende ist. Irgendjemand musste vermutlich noch ein ganzes Backlog an Songideen im Kopf oder in der Schublade haben.

Und wie bekomme ich jetzt die Kurve zurück zu Technologie und Robotics?

Ganz einfach: In einer Zeit, in der moderne AI-Tools immer stärker die Rolle von Spezialisten übernehmen, braucht es zur Koordination weiterhin diese M-Shaped Personalities – so jedenfalls die landläufige Meinung. Irgendjemand muss diese Spezialisten anleiten, sinnvoll einsetzen und überhaupt erst auf die Idee kommen, welches Ziel es sich zu verfolge lohnt.

Dieser Jemand muss nicht in allem der absolute Top-Experte sein. Es reicht, wenn er ein System aufbauen kann und an den entscheidenden Stellen seine eigenen Fähigkeiten einbringt, um daraus ein starkes Zusammenspiel aus Menschen und Agenten zu formen

Lassen wir dazu einmal Jürgen Appelo zu Wort kommen:

But as AI takes on more complex, specialized tasks, the ability to synthesize information from different fields becomes crucial. The goal is to become M-shaped, combining mastery across multiple fields with strong business and leadership skills.

Auf Deutsch:

Aber wenn AI komplexere, spezialisierte Aufgaben übernimmt, wird die Fähigkeit, Informationen aus verschiedenen Bereichen zu synthetisieren, entscheidend. Das Ziel ist es, M-förmig zu werden: also Kompetenzen in mehreren Disziplinen mit starken Business- und Leadership-Skills zu verbinden.

Dröseln wir diese Modelle noch etwas weiter auf:

I-Shaped Personality

Das ist das, was man früher oft etwas abfällig als „Fachidiot“ bezeichnet hat. Wohlwollender gesagt: jemand mit extrem tiefer Expertise in einem Gebiet, aufgebaut über viele Jahre oder Jahrzehnte. Diese Tiefe geht allerdings manchmal
zulasten von Breite, Kontextverständnis oder sozialen Fähigkeiten. Archetyp Magnus Carlsen

T-Shaped Personality

Hier kombiniert jemand eine sehr starke Kernkompetenz mit einem breiten Überblick über angrenzende Disziplinen. Also: ein tiefes Spezialgebiet plus ausreichend Breite, um mit anderen Feldern gut zusammenzuarbeiten. Archetyp Casey Neistat

Pi-Shaped Personality

Ein Pi π hat zwei „Beine“ – also tiefes Wissen in zwei unterschiedlichen Bereichen. Das erhöht den eigenen Wert oft erheblich, weil die Kombination zweier echter Kompetenzen deutlich seltener ist als reine Einzeldisziplinen. Archetyp Richard Feynman (Pädagogik und Physik)

M-Shaped Personality

Ein M hat mehrere Säulen. Es steht für tiefes Wissen in mindestens drei relevanten Bereichen – kombiniert mit der Fähigkeit, diese sinnvoll zusammenzubringen und in Wirkung zu übersetzen.

Und genau deshalb ist dieses Modell heute so interessant: Nicht, weil Spezialisten unwichtig werden – im Gegenteil. Sondern weil in einer Welt voller hochspezialisierter Menschen und immer leistungsfähigerer AI-Tools diejenigen besonders wertvoll werden, die mehrere Disziplinen verbinden, Teams orchestrieren und aus vielen Einzelteilen ein funktionierendes Ganzes bauen können.

Vielleicht ist genau das der eigentliche Kern der Geschichte von Linkin Park: Nicht nur eine außergewöhnliche Stimme, sondern ein System aus mehreren kreativen Kräften – zusammengehalten von jemandem, der genug von vielen Disziplinen versteht, um daraus etwas Eigenes, Wiedererkennbares und Neues entstehen zu lassen.

The post M-shaped Personality appeared first on Creatronix.

Als Führungskraft erlebt man immer wieder Spannungen im Team, weil die Erwartungen an eine Rolle oder Position nicht klar definiert sind. Was genau wird von einem Junior erwartet? Woran misst sich eine Senior-Rolle wirklich?

Wenn diese Erwartungen nicht transparent sind, entstehen Missverständnisse – sowohl in der Zusammenarbeit als auch in der persönlichen Weiterentwicklung. Dieser Text soll helfen, die Unterschiede klarer zu machen und Orientierung zu geben.

Disclaimer

Die folgenden Gedanken stammen aus meiner persönlichen Erfahrung in der Softwareentwicklung.
Viele Punkte lassen sich sicher auf andere Disziplinen übertragen, der konkrete Kontext ist jedoch die Arbeit in
Softwareprojekten – mit Code, Ticketsystemen, Deployments und technischen Abhängigkeiten.

Junior

Ehrlich gesagt bin ich kein Fan der Bezeichnung „Junior“. In vielen Betrieben wird dieser Begriff jedoch genutzt, um eine Entry-Level-Rolle zu beschreiben. Dabei geht es weniger um Alter oder gesamte Berufserfahrung, sondern vielmehr um den Fit der Skills zur konkreten Stelle.

Denn egal, wie viel Vorerfahrung jemand aus einer anderen Software-Engineering-Position mitbringt: Jede neue Stelle bietet genügend Herausforderungen, um sich über Wochen oder sogar Monate einarbeiten zu müssen.

Beispiele:

• Du hast Erfahrung in Vue 3 – die Firma arbeitet noch mit Vue 2 oder React
• Du kennst dich mit CMake aus – das Unternehmen nutzt jedoch Perforce Jam oder natives make.

Je schneller ein Mitarbeiter oder eine Mitarbeiterin den Anforderungen der neuen Rolle gerecht wird und eigenverantwortlich im Tagesgeschäft arbeiten kann, desto eher kann das Attribut „Junior“ abgelegt werden.

Welche Tipps ergeben sich daraus für eine Junior-Rolle?

Kommunikation & Netzwerken

Vermeide es, in deiner Junior-Zeit zum Einzelkämpfer zu werden – Teamwork makes the dream work.

Hilfe suchen – 30-Minuten-Regel

Wenn du nach 30 Minuten konzentrierter Recherche keinen Ansatz oder keine Richtung siehst – frag nach Hilfe.

Hast du zwar einen Ansatz und vielleicht schon ersten Code geschrieben, siehst aber nach zwei bis vier Stunden noch kein Licht am Ende des Tunnels, dann solltest du ebenfalls Unterstützung einholen.

Adressatenkreis beachten

Wähle die richtigen Verteiler / Personenkreis. Wer benötigt diese Information wirklich?

Flughöhe beachten (Detailgrad der Information)

Wenn du den passenden Verteiler identifiziert hast, überlege dir, wie viele Details die Empfänger benötigen. Führungskräfte möchten meist das große Ganze, neudeutsch: Big Picture. Techniker freuen sich auch über Code-Snippets oder technische Details.

Medienbrüche vermeiden

Kommt eine Anfrage per E-Mail, antworte nicht im Chat. Wird ein Thema in einem Ticket eröffnet, führe die Diskussion dort weiter. Wenn ihr aneinander vorbeiredet, greift zum Hörer und klärt Unklarheiten synchron.

Wichtig: Fasse das Ergebnis eines Gesprächs anschließend schriftlich zusammen.

Tasks gliedern – Nächste sinnvolle Schritte erarbeiten und dokumentieren

Als Full-Stack-Developer in einem Webprojekt solltest du ein Feature sauber zerlegen können, zum Beispiel:

• Button im Frontend einbauen
• API-Endpoint im Backend hinzufügen
• Datenbankschema anpassen

Diese Schritte sollten auch im Ticket dokumentiert werden.

Feedback – Frühzeitiges Einbeziehen weiterer Kollegen

Wenn du Schwierigkeiten bei der Zerlegung von Aufgaben hast, frage erfahrene Kollegen, welche Schritte erforderlich
sind.

Auch den Einsatz externer Libraries oder Tools solltest du vorab abstimmen, bevor du tagelang implementierst. Manche
Projekte verbieten bestimmte Technologien, etwa Exceptions oder Introspection/Reflection/RTTI. Auch OSS-Lizenzen wie
GPLv3 oder AGPL können problematisch sein.

Basiswissen über Produkte und Projekte deiner Firma aneignen

Versuche, möglichst viel über die Produkte und Projekte deiner Firma zu lernen. Gibt es Ausstellungen, Demoräume oder Hausmessen? Nutze diese Gelegenheiten und beschäftige dich intensiv mit den Produkten. Benutze Produkte aus der Perspektive der Endanwender.

Code schreiben

Am Anfang ist es oft schwierig, sich in einer neuen Codebasis zurechtzufinden.

Vermeide es, stundenlang nur Code zu lesen. Starte stattdessen – falls vorhanden – einen Unit- oder Komponententest und debugge dich durch die Anwendung. Das ist meist effizienter.

Wenn du grob verstanden hast, was der Code macht, beginne mit kleinen Experimenten. In der Regel steht der Code unter Versionsverwaltung – du kannst also Änderungen vornehmen und sie jederzeit zurückrollen.

Gibt es noch keine Tests, ist das deine Chance, einen ersten Test für den Happy Path zu schreiben.

Du kannst außerdem:

• undokumentierte Funktionen mit Docstrings versehen
• die Wiki-Seite überarbeiten
• Rechtschreibfehler korrigieren oder defekte Links reparieren

All das hilft dir, dich mit dem Projekt vertraut zu machen – und zeigt Proaktivität. „Däumchen drehen“ wird selten
positiv wahrgenommen.

Spekulative Generalisierung vermeiden

„Premature optimization is the root of all evil.“

Nutze beispielsweise die Rule of Three: Implementiere erst zur Generalisierung, wenn du etwas dreimal nahezu identisch implementiert hast. Man sollte nicht zu früh abstrahieren, sondern erst dann, wenn sich ein Muster wirklich bestätigt hat.

Löse die Probleme von heute – nicht die von morgen.

Versionsverwaltung konsequent benutzen

Committe mehrmals am Tag und pushe deine Änderungen spätestens bevor du abends gehst.

Einsatz von AI

Nutze AI-Tools gezielt als Lern- und Sparringspartner.

Lass dir bestehenden Code erklären – insbesondere dann, wenn du dich in einer neuen Codebasis zurechtfinden musst. Du kannst dir außerdem Verbesserungsvorschläge für deinen eigenen Code geben lassen, etwa in Bezug auf Lesbarkeit, Struktur oder mögliche Edge Cases. Wichtig ist jedoch: Vermeide es, große Code-Blöcke generieren zu lassen, die du selbst noch nicht vollständig verstehst.

Senior

Folgende Themen sind aus meiner Sicht entscheidend, um eine Senior-Rolle auszufüllen:

Ownership & Planung

Ownership bedeutet, ein Thema aktiv zu übernehmen – so wie ein Hausbesitzer sich eigenverantwortlich um sein Haus
kümmert. Beispiel: Du bringst den Müll raus, ohne dass dich jemand daran erinnern muss.

Proaktives Handeln

Die Fähigkeit, Themen selbstständig zu identifizieren und anzugehen – ohne explizite Beauftragung.

Beispiel: Du entwickelst an einem Webportal mit nur einem Produktivsystem, während alle lokal entwickeln. Du erkennst, dass ein Staging-System sinnvoll wäre, um vor dem Live-Deployment ausführlicher zu testen und „Works on my machine“-Probleme zu
vermeiden. Also setzt Du ein Staging-System auf.

Den eigenen Standard nicht verhandelbar machen

Arbeitet ihr mit einem Ticketsystem, dann halte dich daran.

Wenn ein Kunde (intern oder extern) dich bittet, einen Bug zu fixen, arbeite nicht einfach „auf Zuruf“. Lass ein Ticket erstellen oder erstelle es selbst im Namen des Auftraggebers.

Kommuniziere gerne per E-Mail, Telefon oder Chat – aber halte wichtige Informationen, Entscheidungen und Anforderungen
im Ticket oder Wiki fest. Bereite diese Kommunikation so auf, dass Du und andere noch nach ein paar Tagen wisst, was gemeint war.

#werschreibtderbleibt

Work Breakdown

Noch stärker als in der Junior-Rolle ist hier die Fähigkeit gefragt, komplexe Arbeitspakete in umsetzbare Unteraufgaben
zu zerlegen. Ich nenne sie gerne Minimum Viable Actions – Aufgaben, die nicht weiter zerlegbar sind.

Warum ist das wichtig?

Gerade wenn man mehrere Projekte betreut, wird man häufig unterbrochen (Task Switching). Wenn die kleinste bearbeitbare
Einheit nicht klar definiert ist, entstehen Reibungsverluste.

Ich habe oft erlebt, dass Projekte stagnieren, weil eine Zuarbeit fehlt und alle warten – obwohl parallel andere Aufgaben erledigt werden könnten.

Deshalb:

• Identifiziere minimal umsetzbare Tasks
• Suche nach Dingen, die jetzt erledigt werden können
• Beantrage Rechte
• Bestelle Server
• Bereite Dokumentation vor.

Das verkürzt Ticketlaufzeiten erheblich.

Abgeben von realistischen Schätzungen und Deadlines

Eine häufige Aussage ist: „Das schaffe ich in ein bis zwei Tagen.“

Dabei werden externe Abhängigkeiten oft vergessen – etwa die IT-Abteilung oder Kollegen, die noch Zugriffsrechte
freigeben müssen.

Für den Auftraggeber zählt nicht nur die reine Entwicklungszeit, sondern wann das Ergebnis vorliegt.

Der „Teufel ist ein Eichhörnchen“: Der Kollege, der Rechte freigeben muss, ist krank oder im Urlaub. Oder der Chef will noch eine Powerpoint sehen, bevor er Budgets freigeben kann – und aus zwei Tagen werden zwei Wochen.

Solche Risiken sollten in der Planung berücksichtigt und transparent kommuniziert werden.

Kommunikation und Delegation

In der Senior-Rolle geht es weniger darum, alles selbst zu erledigen – sondern darum, dass Dinge erledigt werden.

Aufgaben aktiv abgeben oder „Won’t do“ kommunizieren

Andere in die Lage zu versetzen, Aufgaben zu übernehmen, ist essenziell.

Wenn etwas innerhalb der Deadline nicht realistisch umsetzbar ist, ist es fair, das offen zu kommunizieren: „Das werden wir in diesem Zeitraum nicht schaffen.“

Das gibt dem Auftraggeber die Möglichkeit, Alternativen zu prüfen.

Tasks delegierbar aufbereiten & Erwartungen definieren

Wenn du Aufgaben delegieren willst, müssen sie so vorbereitet sein, dass andere problemlos übernehmen können.
Was für dich selbstverständlich ist, ist für andere – besonders Junior-Developer – nicht immer klar. Deshalb:

• Abläufe explizit dokumentieren
• Systeminteraktionen beschreiben
• Erwartungshaltungen definieren
• Idealerweise im Ticket oder Wiki.

Finde eine Balance: Genug Information, damit 80 % der Aufgabe umsetzbar sind – ohne sie faktisch schon selbst erledigt zu haben ( 80/20-Prinzip).

Rechtzeitige Kommunikation & Statusupdates

Für externe Beteiligte muss klar sein:

• Wer macht was?
• Bis wann?
• Welche Blocker gibt es?

Frühzeitige Statusupdates sind kein Zeichen von Schwäche, sondern von Professionalität.

Oft glauben wir, blockiert zu sein, weil Informationen fehlen. Spiegelt man diese Blockade dem Kunden, führt das häufig zu Klarheit oder besseren Alternativen.

Erfahrene Entwickler lernen zudem: Kunden kommen oft mit einem Lösungsansatz – nicht mit dem eigentlichen Problem.

Wenn dieser Ansatz ungeeignet ist, ist es professionell zu sagen: „Wir lösen dein Problem – aber mit einem anderen Weg.“

Einsatz von AI

Verwende AI-Tools gerne intensiv – aber immer als Sparringpartner, nicht als Ersatz für dein Urteilsvermögen. Als Senior liegt dein Mehrwert nicht nur im Schreiben von Code, sondern in Bewertung, Einordnung und Qualitätssicherung.

Beispiele für sinnvollen Einsatz:

• Du schreibst den Unit-Test – die AI schlägt eine mögliche Implementierung vor, die du anschließend kritisch reviewst
• Du implementierst eine Lösung – die AI generiert zusätzliche Testcases oder ergänzt die Dokumentation
• Du lässt dir alternative Lösungsansätze oder Refactorings vorschlagen und vergleichst sie mit deinem eigenen Ansatz
• Du sparst Zeit, indem du dir neue Projekte, Module oder wiederkehrende Strukturen bootstrappen lässt.

Wichtig dabei:

• Behalte die Architekturhoheit
• Hinterfrage generierten Code kritisch
• Achte auf Randfälle, Sicherheit und Projektkonventionen
• Übernimm nur, was du fachlich vertreten kannst.

Ein praktischer Tipp: Committe Änderungen nach jedem sinnvollen Prompt. So bleiben Experimente nachvollziehbar, und du kannst jederzeit zu einem stabilen Stand zurückkehren.

Fazit

Ein Senior ist oft wie ein Zirkusartist, der mit vielen Bällen – oder auch brennenden Hamstern – jongliert. Idealerweise bleiben alle in der Luft und fallen nicht herunter.

Wenn du in einem Thema blockiert bist, solltest du an einem anderen minimalen Task weiterarbeiten können. So entsteht kontinuierlicher Fortschritt – auch bei Abhängigkeiten.

Drei Bücher, die mir geholfen haben:
The Software Engineer’s Guidebook
The 7 Habits of Highly Effective People – Stephen R. Covey
Extreme Ownership – Jocko Willink 

(Amazon Affiliate Links)

Weiterlesen

Five Books every Junior Developer should own

Writing as a complementary skill for your SW engineering career

The post Die Junior und die Senior-Rolle appeared first on Creatronix.

Introduction

Imagine you have 48 hours to find, implement and present a solution for a complex problem. In return you get sleep deprivation and maybe some money.

A hackathon does not sound appealing at first. Nevertheless I have taken several of these competitions and now I want to share my experiences.

I want to show you why such an event can be fun and who it might be suited for.

What is a hackathon anyway?

As mentioned in the beginning, a hackathon is an event that lasts roughly two days and two nights. Companies present a problem which has to be solved by the teams.

After getting to know each other and some other organizational points, there are 48 hours to come up a solution and implement it.

The term hackathon is made up of the words hacking and marathon. Hacking simply describes finding a creative and unconventional solution to a problem aside from the normal way.

Well, and a marathon is simply a sporting event where you run for a long time 😀

My hackathon

The schedule of one of the hackathons I participated in was as following. First there was the “getting to know each other”. You talk to different people, get to know possible team members or learn something about the challenges.
Especially the aspect of getting to know team members was very important, because not many people participated with a complete team, instead they got together shortly before the start.

After that, the organizational part followed. It was explained how everything works. The most interesting part was the challenge pitches in which the problems which have to be solved are explained for the first time.

As soon as that was done, we went into the Challenge Deep Dive, where we got detailed information about the challenge, as well as the opportunity to ask questions. Then the hacking started, open end of course.

On the 2nd day, there were two deep dive sessions in addition to the hacking sessions. There was also a pitch training for the ideal presentation and in the evening a Campfire Talk followed by networking time. On the 3rd day we had the
morning to prepare the presentation. After lunch the pitches began in which the teams had to present their idea within only 3 minutes.

Just building an app?

Even if the agenda is not that demanding from a neutral point of view, you should not forget that you still have to work out a concept and deliver at least a prototype at the end of the 48h. To give a specific example, the challenge of my first hackathon was to find a solution for ordering lunch and dinner in a housing for people with disabilities in a more efficient way than the current solution of Excel sheets. “Then I’ll build an app” my thought of a simple approach easier said than done.

The real difficulty was to implement the complex ordering process in the app and to develop a really good UI so that the use is very easy to handle so easy one does not need hands to handle the app.

Therefore, on the first evening we were instructed in the structure of the company to understand how the ordering process looks like in the kitchen, the individual stations, the administration and, of course, the end customers.

Well, and as we were able to understand the whole thing, we started brainstorming for solutions.

Project on steroids

You can generally say that it is like a software project in a nutshell, the typical project phases are present but very shortened. The approaching deadline is the most stressful part considering everything that has to be done. It doesn’t matter if it’s lunch or if you have to go to the bathroom, your head is always working. Having team members that you don’t know makes things even more challenging.

On the second day it was mainly about the implementation of the solution, but through the Deep Dive sessions, where you get more information or other perspectives, you permanently had to decide, do I discard my idea, do I adapt it or does everything fit, which can be very inefficient if this causes constant discussions in the team.

Another challenge caused by the deep dive sessions was that all teams working on the same challenge were present at the same time to ask their questions. It was a bit like playing poker: you must ask your questions in such a way that the
other teams couldn’t guess which solution you were following and the other way around you tried to find out what your competitors were up to. Even though this was very unusual at the beginning, I have to say that I really enjoyed this game over time, especially if you add some “fake news”.

Presentation

At the end of the event, the challenge was to pitch your idea within 3 minutes. That means you have to summarize your super great solution so tight that everything important was explained in only 3 minutes. My team and I needed half a day for that. With all these tasks, you sometimes ask yourself why I’m actually doing this…

Under pressure

Through this extreme pressure and the many challenges I got into a complete new mode. It was just about finding solutions, everything else didn’t matter on those days. I was in a bubble and that was actually very pleasant away from daily problems and learning that one’s limits are further away than one might think, at least for that period of time.

Conclusion

However, what I liked most was the communication with people within that bubble. Whether it was with the challenge providers who are there almost the whole time of the event. If there were any questions about the project or if you just wanted to quickly discuss your current ideas, this was easy, uncomplicated and direct. But also, with other participants.

Every time I passed someone in the hallway, a small conversation happened – something I usually miss in my daily live. Finally, of course, the communication within the team, although it must be said that this is a gamble and not always positive. Due to the stress and tiredness conflicts can occur within the team.

This not only creates an unpleasant atmosphere, but also leads to inefficiency and increases the thought “why am I doing this and shouldn’t I just leave”. Another point that takes the fun out of work is people who are too ambitious and have a strong desire to win.

These people are uncomfortable both in the team, because they strongly limit the fun you could have in the team and outside the team because the conversation with these people is then exactly the same as in the deep dive session. They don’t want you to know what their idea is, which makes the conversations quite awkward.

But in my case it was very positive and I have found within those 3 days, in 2 strangers I met just before the event, two very good friends. From the beginning on we got along very well and had a lot of fun during the event, which was a good way to reduce stress.

The time consumption of a hackathon is of course a burden. If you think about it, it sounds like a stupid way to spend your free time, at first. But when you get deeply engaged, you have the opportunity to find out where your limits are, gain a lot of experience in a short time. You also can easily exchange and connect with many other people. Therefore, I recommend everyone to try it at least once!

Read more from Max

Surrounded by idiots – Book Review

The post What is a Hackathon? – by Max Brenner appeared first on Creatronix.

Inspect and adapt & Iterative and incremental are the most basic agile principles.

So, inspection of your process after every iteration can be done by a retrospective.

Vegas Rule

First some psychological safety:

Vega’s Rule: What happens in a retro stays in the retro!

Participants only want to share their insights and concerns when they are not afraid of retaliation.

Types of Retro

The following retro types can be used in the gather insight stage

Mad – Sad – Glad

The easiest way to do a retro is the mad – sad – glad strategy:
You draw 3 lanes on a whiteboard, everyone fills out some post-its and puts them into the corresponding lane.
Voila!

The cool thing about this retrospective type is that certainly anyone has feelings about stuff going on.

The drawback is that it is a passive approach and you have to derive some actions to improve the mad & sad points.

Start – Stop – Continue

This type changes the retro to a more active approach:
We write down which habits / processes / practices we need to start doing, stop doing or continue doing.

Keep – Add – Less – More

An even more pronounced approach is KALM (love the acronym)
Instead of completely stopping to use a technique / process you can just do less of it.
Instead of doing something new you can do more of any existing behavior.
Last but not least you can keep it on the same level or add new stuff as well.

Tool Support

If you want to conduct the retro online you can use

https://retrotool.io/

It supports Mad – Sad – Glad and Start – Stop – Continue

Further Reading

https://creatronix.de/ten-rules-for-agile-retrospectives/
https://creatronix.de/the-agile-manifesto/
Agile Retrospectives: Making Good Teams Great from Derby and Larsen (Amazon Affiliate)

The post Three basic types of agile retrospectives appeared first on Creatronix.

Hi Christoph! Thanks for taking the time. Can you tell us about yourself? How did you become a software engineer?

That is a very good question 🙂 I started as an apprentice IT specialist for system integration. So I dealt more with hardware than software. During this training I quite disliked programming. However, when I finished my training I thought this can’t be all, there must be more. So I went back to school, did my university entrance qualification and started to study computer science. And that’s how it started.

What is your current job description?

My “title” says I am “Head of Mobile & Web Development” at inovex. However, titles are not very important for me or for the company. I do a lot of things but at the same time I can choose by myself what I want to do. First of all I am responsible for my team members and do everything so that they like their job, are happy and have everything to be able to do their job. Next to this there are many small things I do like building up our new site in Erlangen, doing recruitment, doing technical sales, supporting the marketing team and more. That is exactly why I love this job, it has so many interesting tasks and it’s never getting boring.

What is your current / favorite tech stack?

At the moment: Flutter and Dart. I like the ecosystem, the development environment and the language a lot. In my opinion it has a very huge potential to become one of the big languages.

Is there something you wished every developer would know?

Hard question. I am a big fan of Clean Code and Test Automation and I choose these two, if I can choose two 🙂I think it’s something every developer should learn, know and be able to apply. Might sound easy but can be very difficult.

Are there any tools you use you think are highly underrated?

I would not say a specific tool but everything you can automate or that can be done by a program makes your work life easier. When it helps you to fulfill your job in a better way: use it! I see people too often doing things manually when there can be an automated solution or a tool which could help them. Examples are hot keys of the IDE, static code analysis, proper CI/CD tooling and many many more.

What is your favorite 3rd party library?

I don’t have one. I (sadly) code too less to have one. And if I code, I like to try out new things (e.g. languages, libraries, tools, …). Therefore I don’t have a favorite 3rd party library.

What trends in software development do you hope to become mainstream?

That everyone becomes more open for change. We should never stop learning, improving ourselves and how we work.

What are your most recommended books?

• Clean Code by Robert C. Martin
• Refactoring – Improving the Design of Existing Code by Martin Fowler
• The Alchemist by Paulo Coelho
• Way of the Peaceful Warrior: A Book That Changes Lives by Dan Millman

What purchases of 100€ or below have most positively impacted your life?

I choose “plants”, because I like gardening and plants have always had a positive impact on me. The second thing: An air quality meter. It helped me to keep my home office full of fresh air 🙂

What do you do when you feel overwhelmed or unfocused?

Sports like table tennis or beach volleyball. Sport always helps me to free my mind. What also helps me is gardening. Creating something with my own hands and seeing the result afterwards is also very relaxing. Especially compared to my job, where I seldom see a real finished result / product.

Whats your current setup?

• Apple MacBook Pro 14’’
• Keychron K3 Ultra-slim Wireless Mechanical Keyboard
• Hama Air Quality Meter “Safe”
• Logitech LGT-M500
• LG 27UN83A 68.58 Cm (27 Inch) UHD 4K IPS Monitor
• DELL U2412M
• BoYata Laptop Stand
• UHURU Professional 192KHZ/24Bit recording condenser, microphone kit with a table stand

Thank you for the interview! See you on 15. November 2022 at Meetup Let’s talk about Web Security!

You can find Christoph online at
https://www.linkedin.com/in/christoph-menzel/

The post Interview with Christoph Menzel appeared first on Creatronix.

Grow slowly & network consistently

Don’t hire people until you’re walking on your last leg. Work with freelancers at most, if you would otherwise have to categorically reject jobs.

Employees want to be paid on time, are entitled to an ergonomic workplace, regulated working hours, etc. From the very first employee, you are an employer with all rights and, above all, obligations. Avoid fixed costs. They can also lead to liquidity bottlenecks.

You can never have a big enough network  though. Here you should pick from an embarrassment of riches. Especially self-employed people like to network to exchange ideas. So, who in your circle of friends/acquaintances already works independently/freelance? Talk to everyone and tell them about your concept or ask for advice.
Interviewing only the self-employed also has the advantage that there is less feedback in the sense of “Don’t do it, boy”, since most employees are in the mood for change, but often do not dare and therefore advise others against their plans.

Think long-term – set a marketing budget

Most concepts fail because of too little advertising. What use is the best business model if no old sow notices that you are on the market?
Many things also work very well through word of mouth, but the start-up phase can be extremely long as a result.
It doesn’t have to be commercials on RTL at prime time, but if you want to build up your business in the long term, you have to do advertising.
With a budget, you avoid spending 20 euros here and there on advertising, but not driving a strategy.

Set yourself the goal of spending e.g. 300 per six months on marketing measures and spend the money.
An advantage of this approach is that you can now optimize your budget by negotiating discounts for e.g. placing advertising. For example, if you place newspaper ads, you can get at least 20% off.

Diversification – You can’t stand on one leg

The fact that you cannot stand on one leg applies not only in the pub but also in business.

If you only have one way of getting money, you always make yourself dependent on the economy. You better always have an ace up your sleeve.
As a self-employed person, you don’t want to recreate the dilemma of being an employee.
A job usually means a source of income. If your job has been cut, you drop from 100 to 0.
Therefore, as a self-employed person, you should always have several sources of income. They can also be related thematically, you don’t have to be a dog trainer and chip shop operator.
But look for additional sources of income to your previous income. Commonly, one also speaks of synergies.
For example, if you deal in junk, you can also organize a flea market.
It is important that new business ideas do not make your old one categorically impossible, no one can tear off two 40-hour jobs a week. This leads to conflicts over time.
Find the gap! You have to be able to fill vacancies in your appointment calendar elegantly.
Or – as discussed under upselling – create some sort of product that helps your customers and sell those.

The post 15 Steps for successful Bootstrapping – Part 5 appeared first on Creatronix.

Narrow down your niche – the niche is your friend

Who earns more? The hairdresser around the corner or the type and style consultant for career-conscious women who also does the hair and make-up?
Sure, the latter. Go where there is less competition.

Implement concepts from the big city in the village or vice versa.

Then there is only car sharing in Hintertupfingen and an indoor high ropes course in Kreuzberg.

Think global, act local – become an expert on your own topic

Everyone has something to tell, but the most exciting are real-life stories. You run a regional business, but are so unique that people come from far away to use your service?

Then blog as much as you can, publish articles in specialist magazines, show the global village that you are the expert on your topic. This way you can also present yourself nationally and build up a larger customer base.

Forego loans – critically question every expense

Bootstrapping means “growing from your own resources”.
In the case of startups, there is the term “cash burn rate”, i.e. how quickly the money is burned, as an indicator of the company’s success. (sic!) Or rather “sick”

An idea doesn’t get better just by putting a lot of money into it.

Hello “Hello Fresh”? How many gift cards to you wanna spill out?

Too much money often distracts from the priorities of new customer acquisition and customer satisfaction.

You are then busy all day with orders and paying bills instead of improving your service.

You should also put every expense to the test to see whether it is of direct use to the customer.

Your customers don’t benefit if your office chair has built-in air conditioning or your coffee machine squeezes out 10 different specialties.

Next article 15 Steps for successful Bootstrapping – Part 5

The post 15 Steps for successful Bootstrapping – Part 4 appeared first on Creatronix.

Ein Plädoyer für die Einbindung externer Expertise in Softwareprojekten.

Ein Gastartikel von Marcel Müller

Software-Entwicklung besteht längst nicht mehr nur aus den Aktivitäten im Bereich Informatik, die der Erstellung, Gestaltung, Bereitstellung und Unterstützung von Software dienen.

Gute Software-Entwicklung ist Leidenschaft. Gute Software-Entwicklung ist Kunst.

Perspektiven & Spezialisierungen

Man kann Software immer aus verschiedenen Perspektiven entwickeln und bewerten.

Der Fokus kann marktgesteuert sein, das Produkt kann den Fokus vorgeben, der Kunde oder die Marke. Schlussendlich ist aber vor allem auch der Benutzer der Software im Zentrum des Interesses.

Im Laufe der Zeit hat sich die Software-Entwicklung weltweit rasant entwickelt und neben verschiedenen neuen Methoden gibt es zahlreiche Spezialisierungen in den Tätigkeitsfeldern Design, Frontend, Backend oder DevOps.

Es gibt ihn eigentlich kaum noch, den einen Programmierer, der alles macht.

Neben der Forschung an Universitäten und Instituten treiben neben großen Technologie-Firmen auch Firmen mit eigenen Produkten, Händler, Agenturen oder Freelancer die Entwicklung voran.

Dank großartiger Open-Source-Software können Aufwände verteilt werden und sich die Entwickler darauf spezialisieren, die Software zu verbessern anstatt wie früher mit viel Aufwand Content-Management-Systeme oder APIs zu bauen.

Die Wahl der passenden Technologien ist aufwändiger geworden, aber die Umsetzung und die Ergebnisse dafür umso professioneller.

Vor allem die interdisziplinäre Zusammenarbeit zwischen Kerngeschäft, Konzept, Design, Usability, Entwicklung, Testing, Operations, Marketing und Kunden-Support ist auf der einen Seite herausfordernd in Sachen Organisation und Kommunikation, schafft auf der anderen Seite aber perfekt abgestimmte Ergebnisse.

Abhängigkeiten & Overhead

Während man früher noch Baukastensysteme wie WordPress, Typo3 oder Shopware von der Stange gekauft hat, gibt es heute kluge Teams, die „from Scratch“ individuelle, maßgeschneiderte Software, erweiterbar nach Kundenwunsch mit ausgewählten Technologien und Software-As-A-Service Providern passende Produkte entwickeln.

Echte Software Entwicklung also statt komplexer Administrationsoberflächen und eingeschränkter Optimierungsmöglichkeiten mit Plugin-Systemen.

So bauen wir in Zukunft also keine Monolithen mehr auf Basis von Software, die alle handelsüblichen Content-Management-Funktionen hat, aber nur notdürftig ein Shop sein kann, oder im Umkehrschluss zahlreiche Shop Funktionen hat, aber nur notdürftig ein Content-Management-System ist.

Wir konzentrieren uns auf die USPs und Features, die der Kunde wirklich braucht.

Wir minimieren stets den Overhead, um die Wartungskosten zu reduzieren.

Es scheint auf den ersten Blick günstiger, eine Library zu installieren, ist es aber nicht.

Jede – vor allem externe – Zeile Code bedeutet ein Stück weit Abhängigkeit. Updates müssen häufiger gemacht werden und Bugs sind schwerer oder gar nicht ohne ein Refactoring zu beheben. Auch hier gilt also wie so häufig: it depends.

Strategien

Um maßgeschneiderte Software zu entwickeln und die richtigen Entscheidungen aus allen Perspektiven zu erhalten, benötigt es neben Erfahrung im ersten Schritt vor allem sehr gute Strategien.

Die Konzepte müssen auf Basis von exakten Business Requirements entwickelt werden, eingepasst in die technologische Umgebung und den Anforderungen aus dem Design gerecht werden.

Nebenher braucht es Instrumente für die Qualitätskontrolle, zum Testen, für den Kundensupport und für das Marketing. Nebenschauplätze wie Social Media und SEO werden schnell unübersichtlich und selbst dafür gibt es mittlerweile Unternehmen, die sich nur in diesen Bereichen spezialisiert haben und zuarbeiten.

In dieser Komplexität scheint es nur sinnvoll, diese Aufgaben Experten zu überlassen. Zu schnell ändern sich Tools, SDKs, Libraries, Frameworks oder sogar Programmiersprachen.

Zudem wird es stets komplexer in jedem Bereich. Im Design waren es in den letzten Jahren Design-Systeme, die sich etabliert haben, im Frontend Animationen und Headless Technologien und im Backend fallen Buzzwords wie KI oder Blockchain.

Zudem sind die Benutzer von Software durch Apps heutzutage sehr verwöhnt. Wenn eine Funktion in UI, UX oder gar funktionell nicht passt, spricht sich das heutzutage im Internet schnell herum. Falsche Priorität oder schlechte Qualität können schnell das Ende für ein Startup oder gar etabliertes Unternehmen bedeuten.

Doch obwohl das alles nicht neu ist, verhalten sich viele Firmen immer noch anders. Oft wird versucht, die Arbeit spezialisierter Bereiche stiefmütterlich selbst zu erledigen.

Generell scheint sich in vielen Bereichen wie Design und Frontend eine Überheblichkeit entwickelt zu haben, den Experten nicht mehr zu vertrauen. Warum ist das schlecht?

Wenn ich mit einer Frage zu einem Facharzt gehe, sollte ich auf den Rat des Experten hören.

Wenn ich mir wirklich nicht sicher bin, ob es ein Experte ist, dann hole ich mir ggf. als unsicherer Mensch noch eine Zweitmeinung ein.

Was ich aber auf keinen Fall in Betracht ziehen sollte ist, die Ergebnisse aus der eigenen Recherche als besser zu bewerten.

Was neuerdings als Cyberchondrie bezeichnet wird, also das krankhafte Googlen nach Symptomen, kann auch in der IT zur Gefahr werden, wenn man versucht, immer alle Probleme selbst zu lösen. In der IT passiert das leider aber immer noch sehr oft.

Zu Themen wie Funktionsumfang, Design und Usability hat natürlich jeder eine Meinung und das ist auch gut so, denn diese Meinung wird in Business Requirements und User-Tests auf die Probe gestellt.

Dadurch ergibt sich ein auf Evidenz basierendes Zielbild, das eben nicht subjektiv nach Gefühl entschieden wurde.

Doch trotz alledem vergleichen wir sehr oft. Doch nur weil ein Konkurrent ein Feature entwickelt hat, muss es nicht zwingend so sein, dass dieses Feature für unsere Zielgruppe notwendig ist oder gar funktioniert.

Strategie ist hier ein wichtiges Schlagwort. Nur ein einziger USP im Leitbild des Unternehmens kann dafür sorgen, dass ein komplettes Feature nicht nur sinnlos ist, sondern dem gesamten Unternehmen schaden kann.

Gerade wenn man sich einen Purpose wie Nachhaltigkeit auf die Brust schreibt, kann das schnell nach hinten losgehen. Es gibt nicht umsonst bei sehr großen Unternehmen bereits Personen, die tagtäglich nur danach schauen, dass die Unternehmenswerte eingehalten werden.

In vielen Bereichen wie Security ist es klar, dass dieses Thema für Firmen wie Google oder Apple existenznotwendig ist. Aber gerade Apple hat auch mit dem iPhone bewiesen, wie wichtig Markenentwicklung, Design und Usability für den Erfolg eines Konzerns sind.

Und auch Apple entscheidet oft über die Köpfe der Benutzer hinweg, was die beste Lösung für die Zukunft ist.

Software zu entwickeln und zu betreuen ist also anspruchsvoller geworden, die Software selbst ist aber einfacher geworden. Klingt paradox! Früher war – oder als Spezialist ist – man es gewohnt, in tiefen Menüstrukturen eine Funktion wiederzufinden.

Gerade Microsoft ist mit Windows und Office dadurch erfolgreich geworden und viele Expertenprogramme im Bereich Design, Musikproduktion oder CAD funktionieren so. Die meisten B2C-Kunden und selbst viele B2B-Kunden sind damit aber heutzutage überfordert und erwarten einfache Lösungen wie sie es von ihren Apps kennen, die in den letzten Jahrzehnten geschaffen wurden.

Auch hier hat man oft nicht mehr nur noch eine Software, die zahlreiche Probleme löst, sondern mehrere Tools die jeweils genau ein Problem sehr gut lösen. Genau wie bei Design, Musik und Kunst ist hier auch oft die Prämisse: Weniger ist mehr.

Teamwork & Long game

Das Stichwort ist also nach wie vor „Perspektive“. Auch Vielfalt spielt hier eine große Rolle. Einfach gesagt:
Team work makes the dream work.

Um Qualität umzusetzen, braucht es interdisziplinäre Experten.

So kümmert sich eine Gruppe um das Geschäftsmodell, gemeinsam kümmert man sich um das Produkt und ein Software-Team um die Software-Entwicklung.

Andere Bereich wie Kundensupport, Lager, Marketing finden Gehör und bringen sich thematisch in die Feature-Entwicklung mit ein.

Dieser demokratische Prozess führt mithilfe von guter Organisation und Kommunikation häufig zu exzellenten Ergebnissen.
Man kann sich auf die Themen konzentrieren, die gerade wirklich wichtig sind.

Natürlich gibt es in der Realität immer unternehmerische Phasen, in denen dieser demokratische Prozess temporär nicht beibehalten werden kann. Jedoch sollte man sich immer bewusst sein, dass das reine Betrachten von Einnahmen und Ausgaben oftmals das Unternehmensziel verfälscht. Viele Startups beweisen es, in dem sie in den ersten Jahren nur rote Zahlen schreiben und dann erfolgreich werden.

Man muss investieren und man sollte es auch, denn gerade in der IT ist der Veränderungsprozess sowohl der Nutzer als auch der Technologien rasant. Es bietet sich daher an, mutig zu sein und auch in Themen zu investieren, die erst mal keinen kurzfristigen, aber vor allem einen nachhaltigen Wert schaffen.

Schließlich funktionieren Menschen so. Oder erinnert sich einer noch an kurzfristige Freundschaften oder Geschäftsbeziehungen? Auch hier sind es die langjährigen, verändernden Kontakte, die uns positiv im Gedächtnis bleiben.

Fazit

Abschließend bleibt zu sagen, dass gerade in Deutschland immer viel gemeckert wird, dass wir in der Digitalisierung so abgeschlagen sind im internationalen Vergleich.

Das stimmt auch und kann man zu Recht kritisieren. Aber es liegt an uns allen, wie wir miteinander arbeiten und wie wir uns vertrauen. Egal wie groß oder klein eine Firma ist, egal wie alt oder neu das Thema.

Egal ob Politik, Forschung oder Wirtschaft. Man kann Großes gemeinsam schaffen, wenn man offen und mutig ist. Lasst uns also auch in Zukunft reden und gemeinsam einen tollen Mix aus unterschiedlichen Perspektiven erstellen.

Über den Autor

Marcel Müller ist seit 8 Jahren Lead Frontend-Engineer bei der Zweischneider GmbH in Wiesbaden.
Ihr findet mehr Infos über ihn unter https://www.marcelmueller.de

The post Stolz und Vorurteil in der Software-Entwicklung appeared first on Creatronix.

Ein paar Tugenden vorweg

Rechtschreibung

Nichts bringt uns mehr auf die Palme, als Rechtschreibfehler: Verben werden klein, Nomen werden groß geschrieben.

Nutze bitte die Rechtschreibprüfung in deinem Schreibprogramm. Lass noch jemanden drüberschauen, wenn Du dir unsicher bist.

“Komm wir essen Opa” vs “Komm, wir essen, Opa”. Satzzeichen können Leben retten

Timing & Pünktlichkeit

Wenn dir jemand anbietet, deine Bewerbung weiterzuleiten (Vitamin B ist immer gut), gib ihm deine Unterlagen innerhalb von maximal 2 bis 3 Tagen.

Wenn Unterlagen wie Zeugnisse nachgefordert werden, erledige dies auch bitte innerhalb von 1 bis 2 Tagen.

Komme nicht zu spät zu einem Gespräch, beachte ggf die Zeitzone und sage Gespräche ab, an denen du kein Interesse mehr hast.

Knigge

Am Telefon solltest Du dich immer mit deinem vollen Namen melden. Gerade, wenn Du eine Festnetznummer angegeben hast und vielleicht in einer WG oder bei deinen Eltern wohnst.

Achte ansonsten auch auf korrekte Umgangsformen. “Bitte” und “Danke” sind zeitlos und kommen nicht aus der Mode.

Vor der Bewerbung

Benutze für Anschreiben und Lebenslauf bitte schöne Vorlagen. Etwas Farbe kann auch nicht schaden, aber bitte nicht übertreiben.

Wenn du Dokumente hochlädst oder verschickst, nutze bitte PDF als Format. Kein Word, kein OpenOffice. Es wäre schade, wenn der Recruiter deine schöne Bewerbung nicht öffnen und lesen kann.

Das Anschreiben

Wenn dir die Stelle wichtig ist, zeige es im Anschreiben, indem du auf die konkrete Stellenausschreibung Bezug nimmst.

Mache deutlich, warum Du der passende Kandidat bist und wiederhole nicht einfach den Inhalt deines Lebenslaufs.

Hast Du bereits Freunde oder Bekannte, die in dem Unternehmen arbeiten, erwähne dies auch. Sorge aber dafür, dass deine Kontakte auch wissen, dass Du dich bewerben willst.

Der Lebenslauf

Dein Lebenslauf sollte nicht zu weit in die Vergangenheit reichen, jeder war mal auf der Grundschule, das ist kein Auswahlkriterium. Beruf der Eltern und Namen der Geschwister kannst Du auch getrost weglassen.

Empfehlung von uns: Schreibe deine Stationen in zeitlich rückläufiger Reihenfolge, damit die neuesten Erfahrungen oben stehen.

Deine technischen Fähigkeiten solltest Du nicht erst am Schluss in eine Zeile quetschen. Sie sind der Kern deiner Bewerbung.

Techniken, die du beherrscht, aber nicht magst, solltest Du weglassen.

Nicht übertreiben!

Wenn Du Skills erwähnst, wird im Interview auch nachgebohrt. Wenn Du dann sagst, du hast bereits mit Python 4 gearbeitet, oder Du den Unterschied zwischen einem Array und einer HashMap in der erwähnten Sprache nicht kennst, wird es eng.

Also: Liste keine 3rd class skills. (Du hast mal vor Jahren C# gesehen, aber nie wirklich genutzt? – lass es raus!)

Mache am Besten deutlich was dein Haupt-Techstack ist.

Links zu Online-Profilen

Bist du im Netz unterwegs mit einem Blog, LinkedIn, github: rein damit.

Aber Achtung: die Profile sollten dann auch aufgeräumt sein: Profilbilder, sinnvolle Code-Projekte etc. enthalten.

Wenn dir die Zeit fehlt, die Profile aufzuhübschen, lasse sie lieber weg. Stelle sicher, dass die Links auch im PDF tatsächlich funktionieren oder wenigstens kopierbar sind.

Die Kür: passe deinen Lebenslauf an die gewünschte Stelle an.

Für e-commerce, security oder fintech relevante Skills solltest Du für solche Unternehmen hervorheben.

Vor dem Interview

Hurra! Du wurdest zu einem Telefoninterview eingeladen. Spätestens jetzt solltest du wissen, was dein potenzieller neuer Arbeitgeber genau macht.

Who is Who?

Wer sind die Kunden / Auftraggeber der Firma, wer sind Kooperationspartner? Was waren die letzten erfolgreichen Projekte? Welche Standorte gibt es? Wie viele Mitarbeiter?

Techstack

Der Techstack lässt sich aus den verschiedenen offenen Stellenausschreibungen der Firmen ableiten.

Culture check

Über die Firmenkultur kannst Du dich bei glasdoor oder kununu informieren.

Fragen vorbereiten

Was hast Du auf der Website der Firma nicht verstanden?

Was ist dir wichtig am potentiellen Arbeitsplatz/Team?

Falls es im Vorfeld nicht erwähnt wurde: Wie geht der Bewerbungsprozess weiter?

Im Telefoninterview

Fragen stellen! Bitte im Interview nicht nur lächeln und winken. Firmen entwickeln seit Jahren oder Jahrzehnten ihre Produkte und Tools. Wenn uns jemand sagt: “Alles klar, kenne ich schon alles” kann das einfach nicht stimmen.

So, das soll vorerst genügen. In den kommenden Teilen dieser Artikelserie kümmern wir uns dann um die Vorbereitung auf ein Coding Interview, das Vorgehen bei der Gehaltsverhandlung und um die ersten 100 Tage im neuen Betrieb. Viel Erfolg bei euren Bewerbungen.

The post Tipps für Bewerber appeared first on Creatronix.

My simple answer: “Write about it!”

An hour later I had finished ranting about why writing is such a crucial skill when becoming a software engineer.

tl;dr; Writing fosters learning. Writing clears your mind. Writing can empower your career.

Why you need to become good at writing as a software engineer

Specifications & Requirements

Very often you have to improve existing specs from your customer to clarify details about how features should actually work.

Sometimes you have to define your own requirements because the customer hasn’t made up his mind yet, but expects you to finish the project on time nevertheless. So you have to fill the gaps.

You need to be able to translate a feature or a use case into a test case for manual testing.

Documentation

Most of the docs I have ever written have been for myself.

When you stop working on a project for a couple of weeks you almost always forget everything about your code.

And when you – as the author of the code – need documentation, chances are high, that many colleagues appreciate every additional info.

Pro tip #1: Use the spell checker in your IDE

How to enable spell checking for German in PyCharm

Communication

Most of today’s communication is done in written form either by email or in chat groups. Every email you’ve sent has the potential to be forwarded to dozens of colleagues regardless of the initially intended audience.

Pro tip #2: Double check your email before sending. Check the grammar, punctuation and overall logical structure.

Pro tip #3: When writing on the web (e.g. Stackoverflow Q&A) enable your browsers spell checker.

Firefox: Enable Spellchecking in Single Line Fields

How to practice writing

Read more books

The more you consume well written sentences and paragraphs the more it will influence your writing style. It will improve your vocabulary and your capability of explaining topics more concisely.

Thoughts on building a library

Write a journal

To be able to write about complex topics, you need to be able to formulate everyday experiences first. Get into the habit of writing a couple of lines about your day every day.

Post on Stackoverflow

You can use SO for your benefit be either posting questions or helping others with your answer. You will see, that most of the approved answers for a problem are the ones best written.

But there is more: you can also improve existing answers or questions to make them more readable. SO has included gamification to give you points for your effort. The more points you get, the more you can get involved with the platform.

Write a blog

Blogging is another possibility to practice writing. The cool thing is that you can deep dive into a topic and share it afterwards. Most articles on my blog start as a cheat sheet for future references e.g. Pandas Cheat Sheet and evolve into tutorials and how-tos over time.

Learn more about writing

My book writing workflow

The post Writing as a complementary skill for your SW engineering career appeared first on Creatronix.