pr0gg3r

https://cloud.google.com/about/locations/?hl=de&region=europe#region
https://support.google.com/firebase/answer/9019185?hl=de
Glaub mir, ein Gang zum Anwalt wird dir definitiv nicht erspart bleiben. Du musst dir bewusst sein, dass dich das ganze einige tausend Euro kosten wird. Aber alleine, ohne juristisches Wissen im Bezug Datenschutz und Digitales wirst du nicht weit kommen und Halbwissen aus dem Internet ist eher schädlich als förderlich.
 

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Der TE hat gar nix weiter gepostet, daher ist der Rest reine Spekulation. Wenn alle so ticken würden und sich abschrecken ließen, gebe es diese Unternehmen erst gar nicht. Mir geht es nicht um ehrliche Erfahrung, sondern das dem Poster irgendwas unterstellt wird und der Tenor „packste eh net“ und so ein Schwachsinn wie „Schwanzverlängerung“, echt jetzt? Er solls machen, vllt finde er es super + hat Glück. Was soll schon gross passieren. Alles eine Erfahrung wert.
Davon abgesehen ist manchmal ein bisschen Naivität nicht verkehrt.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Alles, was du über den Browser anzeigen lassen möchtest (in diesem Fall $storagefile_srv01_user_verzeichnis_dokumente.$file) muss über HTTP erreichbar sein. Um das zu erreichen, gibt es verschiedene Möglichkeiten:
Das Verzeichnis /var/www/cloud_storage/ über HTTP verfügbar machen. Dazu musst du, je nachdem was für eine Server-Software (z.B. Apache oder nginx) du verwendest, entsprechend die Konfiguration des Webservers anpassen. Zum Beispiel machst du die Dateien darin unter "storage.domain.tld" verfügbar, dann lautet die Adresse zum Bild http://storage.domain.tld/$file. Das bringt den Nachteil mit sich, dass alle Dateien dort frei zugänglich sind. Du kopierst die abzurufenden Daten erst in ein von HTTP erreichbares Verzeichnis, dann bindest du das Bild entsprechend ein. Dann sammeln sich aber die Dateien nochmal an einer anderen Stelle an, deshalb ist das nicht zu empfehlen. Vielleicht könnte man irgendwelche Linux-Spielereien wie einen Symlink auf das cloud_storage-Verzeichnis machen, um die Dateien aus /var/www/html/... zugänglich zu machen. Du könntest ein PHP-Script "get-file.php?file=foo.bar" schreiben, das dann die Datei einliest und zurück gibt, indem es die Datei /var/www/cloud_storage/foo.bar einliest und den Inhalt einfach ausgibt. Hierbei nicht vergessen, den Content-Type header anzupssen, dass dieser zur gespeicherten Datei passt. 

Bei meinen Kommilitonen und mir im Bachelor 14-17€, im Master 16-22€. Ausreißer nach unten (Mindestlohn) und oben (25€/Std. im Bachelor) nicht inbegriffen. Großraum Stuttgart. Allerdings so weit ich weiß jeder in der Softwareentwicklung und nicht in der Administration.

Sehe ich auch so. Ein Azubi ist schließlich in der Lernphase und kein Senior-Dev bzw. -Admin. Ich finde, ein Azubi darf Fehler machen dürfen. Überall, wo ein hohes Risiko besteht, muss jemand anderes prüfen, hier sollte nicht der Azubi verantwortlich sein und wenn er doch dafür verantwortlich gemacht wird, läuft grundsätzlich etwas schief. 
Wichtig ist auch der Umgang mit Fehlern. Zum Beispiel sollte man diese nicht auf andere schieben oder versuchen zu vertuschen sondern offen und ehrlich kommunizieren: "Cheffe, ich hab hier Mist gemacht und brauch kurz deine Hilfe". Ich habe die Erfahrung gemacht, dass das genauso geschätzt wird, wie von Anfang an gute Arbeit ohne Fehler zu machen.
 

Mein Chef hat sogar gesagt das man ruhig eigene Verantwortung übernehmen soll und wenn dabei auch mal Fehler passieren das es nicht schlimm wäre, weil man eben daraus lernt. Also nicht, weil man mal einen Fehler gemacht hat direkt zurück schrecken und bestimmte Dinge nicht mehr machen...
Aus Fehlern lernt man und klar oft ist es peinlich aber das ist den besten schon passiert und wenn du in deiner Firma leute hast mit denen du auch gut reden kannst und die auch Verständnis zeigen sollte das kein Problem sein.

"Gegen die Wand fahren lassen" heißt ja nicht unbedingt, dass das ganze Projekt scheitert. Das heißt erst mal nur, dass der TE die Verantwortung nicht haben sollte die er hat, da er diese weder in seiner Position als Entwickler haben sollte, noch in seiner Gehaltsklasse liegt.
Auf jeden Fall muss der TE die Sache eskalieren, so dass von seiner Seite aus alles sauber ist. Wenn dann der Verantwortliche nicht reagiert, ist es nicht seine Schuld. Aber solange der Verantwortliche reagiert, ist das Projekt auch (noch) nicht in Gefahr. Ich zumindest habe ich die Erfahrung gemacht, dass Eskalationen erst mal nichts negatives sind, sondern manchmal sogar nötig sind, um Projekte erfolgreich abzuwickeln. Dazu muss natürlich eher früher als später eskaliert werden. Bei guten Arbeitgebern werden dann alle Projektbeteiligten in ein Eskalationsmeeting eingeladen, das Problem erörtert und eine Lösung gesucht. Wenn sowas in die Richtung nicht stattfindet, laufen grundsätzlich andere Sachen in der Firma schief.
Ich sehe das grundsätzliche Problem in den verschiedenen Rollen des "Chefs". Auf der einen Seite, möchte er jedes Projekt annehmen und verkaufen, auf der anderen Seite sollte er als Personalverantwortlicher nicht sein Team verbrennen. Das ist eben ein Konflikt. Sind die Rollen getrennt, dann kann der Teamleiter sagen: "Moment mal, wir haben nicht die nötigen Kapazitäten dafür" und man muss auch mal einen Auftrag ablehnen oder kleiner stricken. 
 

Ich würde mit sowas aufpassen. So wie ich das verstanden habe, hat dein Projektleiter (Chef) direkte Weisungsbefugnis dir gegenüber. Es ist immer eine ganz schlechte Idee, diesen zu sagen, was sie zu tun haben. Denn sie sehen das ja wohl anders (Er nimmt Projekt an, du machst das. Fertig). Wenn du nun Probleme darin siehst, dass ihr nicht die nötigen Ressourcen dazu habt bzw. du das Gefühl hast das nicht alleine bewältigen zu können, dann rede mit ihm. Aber nicht in Form von: "Du musst das und das machen" sondern in Form von: "ich brauche hierfür so und so lange, dafür ca. so lange, bis zur Deadline werden wir das nicht hinbekommen" und dann ist es in seiner Verantwortung, dafür Lösungen zu finden.
Oder du arbeitest einfach deine vertraglich vereinbarten Stunden und gut ist es. Wenn dann das Projekt aufgrund von falscher Planung der Kapazität gegen die Wand fährt, ist es nicht dein Problem. Auch wenn du es nicht siehst, dein Chef bekommt nicht nur das Lob, sondern auch den Tadel und muss für das Projekt gerade stehen.
Wie in den anderen Antworten bereits geschrieben wurde: das scheint doch gut zu funktionieren. Du hast dich also gewissermaßen selber in diese Position hineinmanövriert. Er weiß, er kann alles auf dich abwälzen weil du eben die Überstunden machst, um das Projekt zu ermöglichen. Für ihn funktioniert das, solange du da so mitmachst. Letztendlich liegt es dann an dir, daraus zu lernen und die Situation zu ändern oder ggf. dir eine neue Stelle zu suchen. 

Ich würde mit sowas aufpassen. So wie ich das verstanden habe, hat dein Projektleiter (Chef) direkte Weisungsbefugnis dir gegenüber. Es ist immer eine ganz schlechte Idee, diesen zu sagen, was sie zu tun haben. Denn sie sehen das ja wohl anders (Er nimmt Projekt an, du machst das. Fertig). Wenn du nun Probleme darin siehst, dass ihr nicht die nötigen Ressourcen dazu habt bzw. du das Gefühl hast das nicht alleine bewältigen zu können, dann rede mit ihm. Aber nicht in Form von: "Du musst das und das machen" sondern in Form von: "ich brauche hierfür so und so lange, dafür ca. so lange, bis zur Deadline werden wir das nicht hinbekommen" und dann ist es in seiner Verantwortung, dafür Lösungen zu finden.
Oder du arbeitest einfach deine vertraglich vereinbarten Stunden und gut ist es. Wenn dann das Projekt aufgrund von falscher Planung der Kapazität gegen die Wand fährt, ist es nicht dein Problem. Auch wenn du es nicht siehst, dein Chef bekommt nicht nur das Lob, sondern auch den Tadel und muss für das Projekt gerade stehen.
Wie in den anderen Antworten bereits geschrieben wurde: das scheint doch gut zu funktionieren. Du hast dich also gewissermaßen selber in diese Position hineinmanövriert. Er weiß, er kann alles auf dich abwälzen weil du eben die Überstunden machst, um das Projekt zu ermöglichen. Für ihn funktioniert das, solange du da so mitmachst. Letztendlich liegt es dann an dir, daraus zu lernen und die Situation zu ändern oder ggf. dir eine neue Stelle zu suchen. 

Ich denke, du kommst eben von dem einen Extrem in das andere Extrem. Ich kenne beide Extreme in der Form nicht, meistens war es bei meinen Arbeitgebern irgendwo dazwischen, also dass man sich zwar auch über Privates unterhalten hat und mal ein Bier trinken gegangen ist oder auch so seine Späße gemacht hat, aber dann auch wieder ein paar Stunden effektiv gearbeitet hat. Wobei das auch immer auf den Workload ankommt.
Das hört sich für mich jetzt so an, als ob das Team (arbeitet ihr denn überhaupt im Team oder "jeder so vor sich hin"?) ziemlich unpersönlich ist. Dadurch ist ersichtlich, dass das Team noch nicht alle Teamphasen (einfach mal danach googeln) durchgemacht hat, also gar nicht entwickelt ist. In diesem Falle liegt es definitiv nicht an dir und du solltest aufhören, an dir wegen anderen Faktoren, die du nicht beeinflussen kannst, zu zweifeln.
 
 
 
 

Firebase Cloud Massaging ist was du suchst. 

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.

Erst einmal hat Git mit der IDE nichts zu tun. Viele IDEs beinhalten zwar auch einen Git-Client, aber du kannst das auch per Kommandozeile nutzen, was ich erst einmal empfehlen würde, damit du verstehst wie das ganze funktioniert. Wenn du auf einen Button in einem Git-Client klickst, weißt du quasi nicht, was da im Hintergrund tatsächlich passiert. 
Einfach gesagt funktioniert es so, dass du Änderungen am Code erst commitest (git commit), dann sind deine Änderungen im lokalen Branch eingereicht. Damit die auch auf den Git-Server gelangen, pusht du die lokalen Commits auf den Server hoch (git push). Wenn du dich nun an einen anderen Rechner setzt, kann du die Änderungen herunterladen (git pull) und weiter dran arbeiten.
Zu Empfehlen ist auch immer eine "Git Strategie". Davon gibt es mehrere, häufig verwendet man sogenannte Feature-Branches. Das heißt, jedes Feature (oder Bugfix) bekommt einen eigenen Branch, den du auch auf den Server pushen kannst. Nun gibt es mehrere Branches die du zusammenfügen (mergen) kannst, zum Beispiel Feature/X in den Masterbranch mergen. Meist schützt man den Masterbranch auch, so dass niemand ohne Review in den Masterbranch mergen kann. Wenn es Konflikte zwischen den Branches gibt (z.B. eine Datei wurde in zwei Branches verändert), müssen die Konflikte erst aufgelöst werden.
Nicht ganz. Durch einen gemeinsamen Ordner hast du zwar die Dateien auf mehrere Rechner verteilt, aber du hast eben keine Versionsverwaltung, weil es logischerweise nur eine Version gibt. Der Vorteil an Git liegt eben darin, dass du viele Branches hast und dadurch jeder Entwickler unabhängig von den anderen in seinem Branch entwickeln kann, also ohne sich gegenseitig zu beeinträchtigen.
Meiner Meinung gehören Git-Grundlagen zu den Grundlagen, die jeder Entwickler heutzutage beherrschen sollte. Ich selber verwende es inzwischen auch für private Projekte, auch wenn ich da alleine entwickle.
/Edit: Eine "richtige" Versionsverwaltung hast du eigentlich erst, wenn du Continuous Integration (CI) betreibst. Hier wird nach dem Mergen in Master (oder bei getaggten Commits) die Software auf einem Server komplett zusammengebaut und erhält dadurch natürlich auch eine neue Version. Wenn man das auf die Palme bringt, kann man Software so gleichzeitig auch verteilen (Continuous Delivery, CD), zum Beispiel auf einem Server deployen oder in einen Appstore ausliefern.

Erst einmal hat Git mit der IDE nichts zu tun. Viele IDEs beinhalten zwar auch einen Git-Client, aber du kannst das auch per Kommandozeile nutzen, was ich erst einmal empfehlen würde, damit du verstehst wie das ganze funktioniert. Wenn du auf einen Button in einem Git-Client klickst, weißt du quasi nicht, was da im Hintergrund tatsächlich passiert. 
Einfach gesagt funktioniert es so, dass du Änderungen am Code erst commitest (git commit), dann sind deine Änderungen im lokalen Branch eingereicht. Damit die auch auf den Git-Server gelangen, pusht du die lokalen Commits auf den Server hoch (git push). Wenn du dich nun an einen anderen Rechner setzt, kann du die Änderungen herunterladen (git pull) und weiter dran arbeiten.
Zu Empfehlen ist auch immer eine "Git Strategie". Davon gibt es mehrere, häufig verwendet man sogenannte Feature-Branches. Das heißt, jedes Feature (oder Bugfix) bekommt einen eigenen Branch, den du auch auf den Server pushen kannst. Nun gibt es mehrere Branches die du zusammenfügen (mergen) kannst, zum Beispiel Feature/X in den Masterbranch mergen. Meist schützt man den Masterbranch auch, so dass niemand ohne Review in den Masterbranch mergen kann. Wenn es Konflikte zwischen den Branches gibt (z.B. eine Datei wurde in zwei Branches verändert), müssen die Konflikte erst aufgelöst werden.
Nicht ganz. Durch einen gemeinsamen Ordner hast du zwar die Dateien auf mehrere Rechner verteilt, aber du hast eben keine Versionsverwaltung, weil es logischerweise nur eine Version gibt. Der Vorteil an Git liegt eben darin, dass du viele Branches hast und dadurch jeder Entwickler unabhängig von den anderen in seinem Branch entwickeln kann, also ohne sich gegenseitig zu beeinträchtigen.
Meiner Meinung gehören Git-Grundlagen zu den Grundlagen, die jeder Entwickler heutzutage beherrschen sollte. Ich selber verwende es inzwischen auch für private Projekte, auch wenn ich da alleine entwickle.
/Edit: Eine "richtige" Versionsverwaltung hast du eigentlich erst, wenn du Continuous Integration (CI) betreibst. Hier wird nach dem Mergen in Master (oder bei getaggten Commits) die Software auf einem Server komplett zusammengebaut und erhält dadurch natürlich auch eine neue Version. Wenn man das auf die Palme bringt, kann man Software so gleichzeitig auch verteilen (Continuous Delivery, CD), zum Beispiel auf einem Server deployen oder in einen Appstore ausliefern.

Es wird immer die Präsens verwendet.
Auch Präsens: "Zur Pflege der neuen Daten wird ein [...] Programm erstellt."
Kein "ist worden" / "folgte" / "wurde", sondern Präsens:
Im Anschluss wird... / Anschließend wird... / Folgend wird... Darauf folgt... Nach XYZ wird... Es wird... Es folgt... ...  

Mein Rat: belass es dabei, dass du die Prüfung bestanden hast. Warum? Bei mir was es ähnlich, die schriftlichen Prüfungen super, mündliche Prüfung versemmelt, warum auch immer (habe verkürzt, Prüfer waren mürrisch warum man überhaupt verkürzen kann, das ist nur mehr Arbeit für sie blabla. Es haben alle, die verkürzt haben, ne schlechte Note bekommen). Aber seis drum: interessiert jetzt auch keinen mehr.
Hier im Forum beschweren sich immer wieder welche über die mündl. Prüfung und wollen Einspruch erheben / vor Gericht gehen / was auch immer. Ich denke mal, das Einzige was passieren könnte wäre die Prüfung ein halbes Jahr später zu wiederholen, ggf. mit den gleichen Prüfern. Na dann viel Spaß! Bietet eher mehr Nachteile als Vorteile. 

Das von @Tiangou genannte Beispiel ist genau das, was ich meine:
Der Junior geht bis 40k, der Senior bis ca. 60k, mit Verantwortung on top vielleicht 70k oder 80k. Der Junior kann höchstwahrscheinlich Dienst nach Vorschrift machen, sich auf seine Programmierung konzentrieren und Fehler seien im verziehen. Er muss nicht halb so viele Weiterbildungen machen, kaum bis keine Freizeit investieren und hat zudem deutlich weniger Stress, weniger Kundenkontakt und keinerlei Verantwortung.

Und für all das, was der Senior oder gar Projektleiter mehr leisten muss, bekommt dieser dann 50% mehr? 100% mehr leisten für 50% mehr Brutto? Ja, es bestätigt mich: Ein grottiger Deal!
Noch grottiger wird er, wenn man sich diesen im Nettobetrag anschaut:
Netto bei 40k = ~25k
Netto bei 60k = ~35k (+ ~40%)
Netto bei 80k = ~45k (+ ~80%)
Genau das ist das eklatante Probleme mit Seniorstellen hierzulande. Ich kann mir nicht vorstellen, dass dies in den USA oder der Schweiz z.B. ähnlich gehandhabt wird. Und dann wundert man sich, dass die Eliten der Welt nicht zu uns nach Deutschland kommen.

Lustigerweise kann ich das mit meinen Erfahrungen bestätigen. Ich bin zwar kein vollkommener Tölpel in der Programmierung, aber es gab gewiss einige in meiner Berufsschulklasse, die es besser konnten als ich. Der eine hat schon über 20 Jahre programmiert (kam aus dem Ausland) und konnte echt wunderhafte Dinge mit seiner Programmierung anstellen. In der Abschlussprüfung hat er aber nur insgesamt mit einer 3 abgeschlossen, in der Projektarbeit sogar mit einer 4 - er hat sich viel zu sehr nur aufs Programmieren konzentriert und auch seine Dokumentation nur darauf ausgerichtet. Das soll natürlich nicht heißen, dass jeder der gut programmieren kann, den Rest nicht so drauf hat, sondern, wie @D-eath schon gesagt hat, die Ausbildung nicht nur um das Coden geht.

Am besten verwendet man das MVC-Pattern. Entweder selber schreiben, wobei man hier umfassende Kenntnisse in der objektorientierten Programmierung benötigt oder eben ein vorhandenes Framework wie Z.B. Laravel (gerade sehr "in"), Codeigniter oder CakePHP verwendet, wobei man auch hier OOP-Kenntnisse vorausgesetzt werden. 

Guten Morgen zusammen,
mein Beitrag ist zwar schon etwas länger her, aber ich möchte nun doch ein kurzes Feedback geben, wie sich die Sache bei mir weiterentwickelt hat. Auch weil ich diese Diskussion hier sehr hilfreich fand um mir ein wenig klar zu werden, was ich mir überhaupt für meine Zukunft vorstelle.
Ich werde Anfang nächsten Jahres eine neue Stelle als Product Owner bei einem IT-Beratungsunternehmen antreten. Das heißt, ich werde in Kundenprojekten dafür zuständig sein, Anforderungen zu analysieren, die Software zu konzeptionieren, Sprints zu planen und kommunikativ zwischen Stakeholder und Entwicklungsteam zu vermitteln. Eine ziemlich anspruchsvolle Aufgabe, auf die ich mich wirklich sehr freue.
Es handelt sich um eine mittelständische Beratung mit regionalen Kunden und die Reisezeiten sind wohl recht unproblematisch. Rahmenbedingungen sind gut, mein neuer Vorgesetzter sehr sympathisch, das Team kenne ich noch nicht, habe aber insgesamt ein gutes Gefühl.
Ich bin sehr gespannt, was da auf mich zukommt, glaube aber, hier eine Position gefunden zu haben, in der ich meine Kompetenzen gut einbringen kann und die viel Abwechslung bietet.
Ich berichte gern noch einmal, wenn ich ein paar Monate in dem neuen Job gearbeitet habe.
Einen lieben Gruß,
MacBeth1337

Da ich seit Jahren sehr viel im Webbereich tätig bin, kann ich dir sagen was gesucht wird und wo Bedarf besteht.
Ja, es gibt genug Bedarf im Webbereich. Jedoch muss man differenzieren. Machst du eher Design? Du bist jedoch kein gelernter Designer (und man sieht den Unterschied zwischen amateurhaften um professionellen Design). Du schreibst, dass du Erfahrungen mit HTML und CSS hast. Es wird jedoch schwer, dass jemand ein fertiges Design hat, das du anschließend umsetzen sollst. Es sei denn, du entwickelst mit einem Designer zusammen. Dann geht es weiter: Webseiten werden dynamisch gemacht, also zumindest solltest du noch Erfahrung darin haben, z.B. in PHP o.ä. oder zumindest in einem CMS wie Wordpress, Drupal, etc. oder einem Framework wie CakePHP, Codeigniter, Django oder sogar JavaEE und Springboot. Ein weiterer Trend geht in Richtung Angular und React ggf. auch Vue.js. Auch NodeJS-Backend (schau dir mal den MEAN-Stack an). Dann brauchst du wiederum Knowhow Datenbanken, Serveranwendungen usw. Und da hört wohl "der Spaß" ohne IT-Ausbildung für dich irgendwo auf, denn sich das alles selber beizubringen bedeutet jahrelangen Aufwand. Es geht auch nicht nur darum, die Grundlagen zu beherrschen. Wenn du bezahlt werden möchtest, brauchst du tiefgehende Kenntnisse. Niemand bezahlt dich für schlechte Codequalität, für die du länger brauchst, als ein Profi der schneller besseren Code schreibt. Ich möchte dir nicht zu nahe treten: es ist möglich. Aber es ist viel Arbeit und du solltest zumindest in einem Bereich Profi sein. Jedoch reicht dafür HTML und CSS nicht aus.
Man sollte auch nicht vergessen: trotz dass extremer Bedarf an IT-Fachkräften besteht, ist die Zeit für Quereinsteiger nicht mehr so gut wie noch vor 10 Jahren. Das heißt, eine Ausbildung oder ein Studium sind kein verkehrter Weg.