0x00

Vielleicht weil sie nicht viel Ahnung vom Verträge schreiben haben? Mein neuer AG hatte mir auch einen "komischen" Vertrag vorgesetzt, ich hab ihm gesagt, dass ich ~7 Punkte komisch/nicht gut/schlecht formuliert finde und dann wurden die halt entsprechend angepasst. Wenn er sich weigert diese anzupassen, dann kannst du ja immer noch absagen... Aber einfach annehmen, dass er dich übern Tisch ziehen will und deswegen absagen? Nein. Da lieber nochmal miteinander reden.

Man nimmt dich ernst, wenn du es wert bist ernstgenommen zu werden. Sollte dein Mitarbeiter (sogar wenn nur in Teilbereichen) fundierteres Wissen haben als du, dann nutze es. Frag ihn nach seinen Lösungen, hör auf seine Kritik und findet gemeinsam die beste Lösung. Es ist keine Schande als Chef weniger zu wissen als seine Mitarbeiter, allerdings sollte man sich dann auch stets die Meinung des Experten anhören und meistens auch befolgen (es sei denn es sprechen gute Gründe dagegen). Ein guter Chef muss nicht zwangsläufig ein guter Techniker sein. Was dein Alter angeht... Es gibt sicher Menschen, welche sich daran stören werden. Die Frage ist: Willst du mit diesen Menschen arbeiten? Wenn du durch dein Handeln beweist, dass du trotz deines Alters den Respekt verdienst, dann werden die Leute mit denen du zusammenarbeiten willst dich auch als Chef akzeptieren und schätzen.

Ganz einfach: Angebot und Nachfrage. Viele Leute wollen Junior-AEs mit Skills A, B und C, weil diese ihnen (finanziellen) Mehrwert bieten. Darauf kommen aber weniger Junior-AEs als benötigt werden, weswegen der Gleichgewichtspreis ("Marktwert") steigt. Wie viel diese Juniors können (relativ zu wem überhaupt?) ist erstmal irrelevant, solange sie den benötigten Mehrwert bieten! Historische und aktuelle Werte lassen sich nur schwer vergleichen. Dazu kommt, dass die Möglichkeit besteht, dass du dich damals einfach unter Wert verkauft hast. Wenn du wissen willst was XYZ (ohne es näher zu spezifizieren) verdient, dann schau doch mal in den "Wie viel verdient ihr?" Thread. Wenn du wissen willst, was DU mit DEINEN Fähigkeiten verdienen willst, dann nenn diese doch einfach. Und wenn du wissen willst ob du auf diese Stelle passt, dann kopier doch einfach ein paar Beispielausschreibungen dazu. "Die Erwartungen sind intransparent mit dem Titel der ausgeschriebenen Stelle verknüpft". Sehr schöne Formulierung und sehr wahr. Versteif dich nicht so viel auf die Titel, sondern mehr auf das Aufgabengebiet und die benötigten Skills. Namen sind Schall und Rauch, was zählt ist das Tätigkeitsgebiet. EIn "Web-Developer" hat zwar durch den Titel ein grob gestecktes Aufgabengebiet, allerdings kann das je nach Firma sehr deutlisch variieren. Entwickelt er Inhouse? Für Kunden? Macht er zusätzlich noch 1st/2nd/3rd Level Support? Welche Technologie? Was für Sprache? Ist er ein Frontendentwickler? Backend? Fullstack? In welcher Gewichtung? Macht er nur Web? Macht er auch andere Sachen? Nur eine Sprache? Mehrere? Macht er auch Deployment? DevOps? Vielleicht auch noch Design? Kundengespräche? Projektmanagement? Evtl. auch noch Scrummaster? Da gibt es vieeeel Spielraum. Ähnliches gilt für Frontend- und Backendentwickler oder auch PHP-Entwickler. Klar, da ist das schon konkretisierter, aber da gibt es immer noch sehr, sehr viel Spielraum. Stütz dich bitte deswegen nicht zu sehr auf den Titel, sondern eher auf die Tätigkeit. Der Titel beschreibt die Tätigkeit meist schon grob, allerdings gibt es da - je nach Titel - sehr viel Interpretationsspielraum. Ein Durschnittsjunior hat für mich erste Programmiererfahrungen und evtl. auch schon Kenntnisse in der geforderten Technologie. Dadurch kann er zwar noch nicht viel, aber kann doch vieles schnell lernen und einfachere und - mit Unterstützung - auch schon schwierigere Aufgaben übernehmen. Sein Alltag sind fest definierte Aufgaben abzuarbeiten, die danach vom Senior reviewt werden. Bei Fragen und Problemen kann er sich stets an einen technischen Ansprechpartner wenden. Es wird von ihm erwartet, dass er ein Grundverständnis und Lernwille mitbringt und kleinere Sachen übernehmen kann. Es wird allerdings nicht von ihm erwartet alleine architektonische Entscheidungen zu treffen oder schwierige technische Probleme zu lösen, an solche Sachen wird er langsam vom Senior rangeführt.

Muss mich den anderen anschließen. 1. Niemand kann in die Zukunft schauen 2. Es sind andere Sachen wichtiger als Gehalt (auch Weiterbildung -> direkter Einfluss auf zukünftiges Gehalt) 3. 48k sind zum Einstieg unrealistisch (allerdings nicht unmöglich). Allerdings sind 48k nach 1-3 Jahren durchaus realistisch.

Interessante Idee. Die Berufsschule als Parameter habe ich so noch nie gesehen. Das rechne ich doch gleich mal nach. Im Fazit: eine Fachkraft kann gewinnbringender sein als ein Azubi - es kommt aber immer auf die Parameter "Stundensatz", "Lohn" und "Anzahl fakturierbare Stunden" an. Allerdings muss erwähnt werden, dass ein Unternehmen natürlich mit dem Stundensatz eines Azubis weniger Risiko eingeht. Wenn mal nicht genug Aufträge reinkommen verliert das Unternehmen weniger Geld mit dem Azubi als mit der Fachkraft. Zudem könnten ja dann die Projekte (theoretisch) genau so liegen, dass ein Azubi genauso viele fakturierbare Stunden wie eine Fachkraft schafft. Wenn nicht genug Aufträge reinkommen kommt das nur auf die Lage der Auftrage an. Dann bringen die (theoretischen) 60 Tage mehr die die Fachkraft arbeitet auch nichts. Wenn man das Umfeld jetzt aber mal umkehrt und sagt ein Unternehmen kann unendlich viele Aufträge ranschaffen können für die Kosten für eine Fachkraft 3 Azubis eingestellt werden. Die dann natürlich auch 3x 160 Tage schaffen und nicht 1x 220 Tage. Ein Grund für die Fachkraft hingegen wäre der höhere Stundensatz. Eine Fachkraft kann man leichter mit einem höheren Stundensatz berechnen, allerdings kommt es hier ganz auf die Transparenz des Betriebs an. Ich kann mir gut vorstellen, dass Ausbeuterbetriebe auch gerne mal einen Azubi als Fachkraft fakturieren. TLDR: Kommt drauf an. Ich denke jedoch, dass Ausbeuterbetriebe aufgrund des geringeren finanziellen Risikos eher zum Azubi greifen werden. Aber eine interessante Überlegung. "Azubi fährt mit eigenem Auto alleine zum Kunden" hat halt doch immer so einen bitteren Beigeschmack.

In der Berufsschule? Da ist gar nichts "relevant" in dem Sinne dass nichts im die Prüfung mit einfließt. Abgesehen davon, dass die Fächer in jeder Schule andere Namen tragen... Es sind die Abschlussprüfungen relevant. Wenn du verkürzen willst, dann schau dir diese an. Wenn du die mit den Lehrplänen der Fächer abgleichst sollte dir relativ schnell klar werden was relevant ist und was nicht. Ganz generell: Alles was mit IT und Elektrotechnik zu tun hat ist relevant. Dazu noch einfaches Englisch + der WISO Teil. Allerdings sind nicht unbedingt alle Teile eines Fachs relevant. Wir hatten z.B. den Aufbau einer Demokratie in Deutschland in Sozialkunde - sowas kommt nicht dran. Aber am besten du machst dir selber ein Bild davon. Alles was irgendwie direkten IT Bezug hat (Programmierung, Netzwerktechnik, IT-Systeme...) würde ich auf jeden Fall nachholen! Selbst wenn du einige Klassenkameraden hast, die vielleicht der Meinung "Wozu brauche ich IPv6 als AE" sind, sowas ist immer gut zu wissen. Denn wenns dann dochmal in der Prüfung rankommt ists Geschrei immer groß...

Für mich sind die folgenden 3 Sachen wichtig. Wenn ich keinen Zugzwang habe müssen alle drei erfüllt sein, damit ich mich ernsthaft irgendwo bewerbe. 1. Ich muss die Leute bewundern für die und mit denen ich arbeite. (Ist leider schwer einzuschätzen, wenn man sich irgendwo ohne Kontakte bewirbt) 2. Ich brauche den Freiraum Sachen so zu machen wie ich sie für richtig halte und eine Diskussionkultur die stets sachlich ist und immer das Ziel verfolgt die beste Lösung zu finden (und nicht du machst das weil Chef XYZ will das so!!!!) 3. Ich brauche ein Themengebiet in dem ich noch viel zu lernen habe und Personen von denen ich lernen kann. Wenn ich von niemandem lernen kann bin ich vermutlich in der falschen Firma. Und wenn ich mich in meinem Themengebiet schon so gut auskenne, dass ich nichts (oder nicht mehr viel) lernen kann, dann sollte ich entweder mein Themengebiet wechseln oder mich selbstständig machen. Wenn die drei Sachen gegeben sind ist mir auch der Rest (Geld, Urlaub, Arbeitszeiten) nicht so wichtig. Nichts finde ich schlimmer als nur für Geld zu arbeiten.

Da würde ich mich nicht von abschrecken lassen. Es gibt einige Firmen, die keine große Onlinepräsenz haben. Das muss aber erstmal nichts Negatives sein. Die Firmen betreiben halt ihr Marketing über andere Kanäle. Ich fange demnächst auch in so einer Firma an. Ich würde am deiner Stelle einfach mal hingehen und mir das ganze ansehen. Wenns dir nicht gefällt kannst du immer noch absagen. Kann aber auch gut werden - trotz fehlender Onlinepräsenz.

Wenn das so ist bescheißen 99,9% aller Azubsi. Wie viele Azubis halten eine Probepräsentation vor ihrem Ausbilder, wie viele Dokus werden gegengelesen und die Azubis bekommen Feedback danach? Und wie viele Ausbilder geben halt doch ein wenig Feedback zum Projekt?

Hier musst du zwischen zwei Fragen unterscheiden: "Muss ich alle Klassen im Namespace öffentlich machen?" und "Muss ich die Klasse public machen obwohl Getter und Setter der Property schon public sind?". Zur ersten Frage: Nein. Du musst nur alle Klassen public machen, auf die du von außen zugreifen willst. Willst du nur von intern zugreifen muss die Klasse nicht public sein. Zugriff von außen schließt allerdings auch Zugriffe auf Methoden und Properties mit ein. Wo wir dann bei der zweiten Frage wären: Wenn eine Klasse nicht public ist, können alle Methoden und Properties public sein, du kannst trotzdem nicht von außen zugreifen. Wenn eine Klasse public ist, heißt das im Umkehrschluss aber nicht, dass du auf alles von außen drauf kommst. Sondern nur auf die public Properties und Methoden. Es muss also sowohl die Klasse als auch deren Methode public sein, wenn du auf die Methode zugreifen willst. Selbiges gilt für Properties. Ein paar Beispiele: // Internal class, du kommst nicht von außen drauf. internal class MyInternalClass { // Internal Method. Das "internal" hier hat keinen Effekt, da bereits die Klasse internal ist. // Jeder in dieser Assembly kann sowohl auf die Klasse als auch auf die Methode zugreifen. internal void SomeInternalMethod(); // Public Methode. Das "public" hier ist ebenfalls unnötig, da das "internal" der Klasse limitierend ist. // Das "public" signalisiert zwar theoretisch, dass du von außerhalb der Assembly auf diese Methode zugreifen, aaaaaber: // Du kannst nicht auf die Klasse von außerhalb der Assembly zugreifen! // Und da die Methode nur über die Klasse aufgerufen werden kann (MyInternalClass.SomePublicMethod()), kommst du von außen nicht auf die Methode. // Trotz public access modifier! public void SomePublicMethod(); } // Public class. Du kommst von außerhalb drauf. public class MyPublicClass { // Public Method. Da sowohl die Klasse als auch die Methode public sind kommst du von außen drauf. public void SomePublicMethod(); // Die Klasse ist zwar public, aber nicht die Methode! // Du kommst zwar auf die Klasse, kannst diese Methode aber nicht von außen aufrufen! internal void SomeInternalMethod(); } Wenn du Access nach außen limitieren willst musst du folgendes beachten: 1. Die Klasse die den Access bereitstellt muss public sein. 2. Der Getter muss ebenfalls public sein. 3. Die Klasse die du exposed muss auch public sein (so blöd es klingt!). Du kannst keinen public Getter für eine internal class haben. Der Getter einer Property (oder der Return Wert einer Methode), darf nur Objekte einer Klasse zurückgeben, die mindestens die selbe Visibility hat wie der Getter bzw. die Methode. Ein Internal Getter der eine public Class zurückgibt ist okay. Ein public Getter der eine internal Class zurückgibt nicht! Sonst würdest du ja ein Objekt zurückgeben, was eigentlich in dem Scope (außerhalb der Assembly) nicht exisitieren darf. Nun kannst du aber dennoch den Access limitieren. Die Klasse auf die du den Access limitieren willst muss zwar public sein, aber deren Methoden und Properties nicht! So kannst du die Klasse nach außen nur mit den Methoden und Properties exposen, die du auch nach außen geben willst. Ein weit verbreitetes Beispiel wäre z.B. so eine Klasse: // Class muss public sein, da außerhalb der Assembly mit ihr gearbeitet werden muss! public class MyClass { // Public property mit public getter und internal setter. // MyInteger kann also von außerhalb ausgelesen, aber nur von intern gesetzt werden! public int MyInteger { get; internal set; } } So kannst du deine Daten vor Modifikation schützen oder verhindern, dass Methoden aufgerufen werden, von denen du nicht willst, dass sie aufgerufen werden. Eine solche Methode kann z.B. auch der Konstruktor sein. Wenn du den Konstruktor auf internal setzt kannst du nur innerhalb der Assembly Objekte dieser Klasse erzeugen - während du trotzdem außerhalb mit ihr arbeiten kannst. // Public class. Exposed über Property SecretClass. public class ExposerClass { // Public Property erlaubt Access auf SecretClass. // AccessClass kann von außen geholt (und theoretisch auch gesetzt) werden, allerdings ist der Ctor der SecretClass internal. // SecretClass Objekte kann man also nur innerhalb dieser Assembly instanziieren. public SecretClass { get; set; } } // Class muss public sein, da sie über eine public Property exposed wird. public class SecretClass { // Ctor ist internal, damit man diese Klasse nur innerhalb dieser Assembly instanziieren kann. internal SecretClass() } Erstell eine neue Solution. Dann kopier deine zwei Projektordner in den Ordner der Solution, die Projektordner sollte auf der selben Ebene wie die .sln Datei sein. Das ganze sollte dann in etwa so aussehen: SLNFolder MySln.sln ProjectA ProjectA.csproj (Other files from your projects - for example the .cs files) ProjectB ProjectB.csproj (Other files from your projects - for example the .cs files) Dann öffne die Solution und klicke auf "Add existing project". Da fügst du nun die .csproj Dateien der zwei Projekte hinzu. Nun sollten beide Projekte in der Solution sein. Randnotiz: Wenn du eine neue Solution erstellst wird meist ein leeres Projekt miterstellt. Das kannst du einfach löschen

Was ist denn der Kontext des gesamten Zeugnisses? Gut? Durchwachsen? Dann kann man so einen Satz schon einmal hinterfragen. Das ist eine Interpretation. Man kann ihn aber auch deutlich negativer auslegen. Wenn er negativ gemeint war - shit happens. Wenn allerdings nicht, dann sollte er imo entsprechend umformuliert werden. Deswegen: Nachfragen!

Inkl. der Peripherie? Bin ich der einzige, der das komisch findet? EDV? Ernsthaft? Typo oder steht so wirklich im Arbeitszeugnis? Schnarchnase. Wieder Typo? Bin ich der einzige, der über allerseits und dieses stolpert? Oder liegt das daran, dass ich Bayer bin? Ich hätte eher mit einem "allseits" und einem "dies" gerechnet. Ansonsten was schon gesagt wurde: 2, weil Superstlativ fehlt. Das das Unternehmen dein Ausscheiden sehr bedauert ist auch noch positiv zu werten. EDIT: Ansonsten das, was @Graustein sagt. Auf jeden Fall mal nachfragen was mit "ruhig und überlegt" gemeint ist und die Typos (sollten sie so im Arbeitszeugnis stehen) korrigieren lassen.

Grundsätzlich ist deine Herangehensweise goldrichtig. Du musst deine Assembly (deine Klassenbibliothek) in das entsprechende Projekt laden und dann noch den entsprechenden Namespace referenzieren. Allerdings kann es sein, dass du dann deine Klassen immer noch nicht nutzen kannst. Die braucht nämlich noch den korrekten Access Modifier: public. Falls deine Klassen mit "public class" beginnen haben sie den Access Modifier "public", was in deinem Fall der richtige ist. Wenn deine Klassen jedoch nur mit "class" beginnen wird der default Access Modifier "internal" verwendet. In diesem Fall (oder wenn du sonst einen anderen Access Modifier außer public verwendest) solltest du diesen auf public ändern. Allerdings musst du den Access Modifier nur für die Klassen ändern, die du auch außerhalb deiner Assembly (deines Projektes) aufrufen willst. Wenn du die Klassen A und B in deiner Bibliothek hast, aber nur A von außerhalb aufrufen willst, muss auch nur A den public Access Modifier haben. B kann ihn zwar haben, braucht ihn aber nicht. Selbiges gilt für Methoden. Willst du eine Methode einer Klasse von außerhalb deiner Assembly aufrufen müssen sowohl die Klasse, als auch die Methode den public Access Modifier haben! Wie hast du es denn im Moment gelöst? So wie ich das verstanden haben hast du zwei seperate Projekte (und auch zwei Solutions? Oder gar keine Solutions?), die du aber nur in Kombination nutzt? In diesem Fall wäre die eleganteste Lösung beide Projekte in einer Solution zu kombinieren. Dann kannst du auch einfach die Referenz zu deiner Klassenbibliothek mit Add -> Add Project Reference hinzufügen. Man kann ein Projekt auch kompilieren und dann die kompilierte .dll referenzieren, allerdings hat diese Variante einen entscheidenden Nachteil: Wenn du deine Klassenbibliothek veränderst musst du jedes Mal daran denken diese wieder zu kompilieren, damit die korrekte Version in deinem anderen Projekt verwendet wird. Wenn du jedoch beide Projekte in der selben Solution kombinierst musst du nur die Solution bauen wodurch automatisch alle Projekte kompiliert werden. Dadurch hast du stets die neuste Version deiner Klassenbibliothek in deiner Konsolenanwendung.

Du willst Videoschnitt lernen? Kannst du denn schon was? Wenn es dir rein um den Lerneffekt geht würde ich eher für mich ein wenig privat Üben. Wenn du dann halbwegs gut bist, kannst du deine Dienste auch auf Fiverr anbieten. Ich denke wenige werden jemanden ohne Erfahrung einfach ihr Videomaterial anvertrauen. Selbst wenn es nichts kostet. Wer auf Fiverr o.Ä. unterwegs ist will das schon eher professionell gemacht haben. Wenn dir einfach das Material fehlt dann nimm doch einfach ein paar Minuten von deinem Lieblingsvideospiel auf. Daran solls nicht scheitern. Mail ist natürlich wie gesagt schon die beschissenste Art sowas hin und her zu schicken. Denke das wird eher auf Links zu GDrive o.Ä. hinauslaufen. Ich weiß nicht ob Fiverr eine eigene Cloud hat, ich bezweifle es aber. Ich weiß nicht ob das noch aktuell ist, aber afaik können Videodateien durchaus Viren enthalten. So kann bspw. der Codec infiziert sein. Wenn dieser dann ausgeführt wird (z.B. wenn du das Video abspielst), wird der Virus auch ausgeführt. Allerdings würde ich das Szenario "Jemand beautragt einen Cutter mit einer infizierten Videodatei um dann deren PC zu hacken" schon als eher unrealistisch einstufen. Falls du das anders siehst sind das hier größtenteils gute Ratschläge: Dem würde ich allerdings noch zwei Sachen hinzufügen: Mach dir KEIN OneDrive oder GDrive Konto, sondern lass dir die Videos linkbasiert freischalten. So kommst du ohne Konto drauf, musst dich also in deiner VM auch nicht anmelden. Wenn du kein Konto hast kann auch keines gehackt werden. Das bringt mich auch schon zum zweiten Punkt. Damit die VM wirklich effektiv ist, solltest du da nichts tun außer die Videos entgegennehmen und bearbeiten. Alles was auf deiner VM gespeichert wird kann natürlich auch gehackt werden. Also im Optimalfall nirgends anmelden.

Wer sagt, dass 34k damals Marktdurchschnitt waren? Wer sagt, dass die Marktsituation damals mit der heute vergleichbar war? Wer sagt, dass Gehälter inflationsbereinigt gleich sein müssen? Wer sagt das? Ich hörte da einst Legenden von Altverträgen aus den 90ern, die vom Gehalt her bis heute noch nicht (wieder) erreicht worden sind... Der einzige Faktor, der die Gehälter festsetzt ist Angebot und Nachfrage. Inflation hat da nur wenig mit zu tun.

Grundsätzlich gibt es alle möglichen Charaktertypen in der IT. Die Besseren haben meiner Erfahrung nach aber schon eine erhöhte Frusttoleranz (eben nicht sofort kapitulieren), sind offen für Neues und haben das Bedürfnis die Sachen zu verstehen. Nicht nur das WIE, sondern auch das WIESO. Das sind aber Sachen die dich generell im Leben weiterbringen, nicht nur in der IT. Und auch in anderen Berufen. Aber das Gute ist: Kann man alles lernen

Einmal 10h != Jeden Tag 10h Ich mach auch mal gerne 10h+, aber dann halt an nem anderen Tag nur 6...

Denke es geht um die Screenshots. Da ist die Größe ja nicht fest vorgegeben.

Besser zu klein als nicht gewertet!

Ein Ausbildungsgehalt ist auch nicht dazu gedacht seinen Lebensunterhalt damit zu bestreiten. Das ist für Leute die gerade mit der Schule fertig sind und höchstwahrscheinlich noch bei den Eltern wohnen. Wenn man sich in einer anderen Situation befindet gibt es diverse Hilfen die man beantragen kann. Desweiteren sollte das Azubigehalt kein Grund sein wieso man einen Beruf ergreift oder nicht ergreift. Fachinformatiker haben auch nicht die besten Ausbildungsgehälter, da gibt es Berufe die das deutlich übertreffen. Und was soll dieser unnötige Seitenhieb gegen die Studenten?

Nicht überragend, aber grundsolide (Annahme 28-30 Urlaubstage). Für die 8 Monate absolut ausreichend.

Von den Leuten mit denen ich Kontakt hatte war der O-Ton auch: "FI ist besser". Einige haben den dann noch hinterhergeschoben, andere haben so eine Stelle gefunden, aber es war klar rauszuhören, dass sie rückblickend lieber den FI gemacht hätten. Vielleicht ist der ITA einfach nicht sehr schwer, aber @Whiz-zarD war an einer Schule die schwer war. Was allerdings nicht den ITA per se schwer machen würde sondern einfach nur diese spezielle Schule.

@myluridWie ich sehe hast du seit 2 Jahren den Operative Professional. Hast du das Gefühl, dass er dich weitergebracht hat? Würdest du ihn wieder machen?

Da wir hier den Grundsatz Hilfe zur Selbsthilfe wertschätzen: Woran scheiterts denn? Hast du schon irgendwelche Lösungsansätze? Irgendwelche Ideen?

Ich hab in der Ausbildung nur Backend gemacht und lerne jetzt erst Frontend. Andere haben in der Ausbildung beides gemacht. Kannst du machen wie du willst. Wenn dein Chef dir das ambietest, du dich bereit fühlst und Bock darauf hast! Do it! Wenn nicht, lass es bleiben. Ich will allerdings anmerken, dass es nie schadet mal ein wenig in andere Themengebiete reinzuschnuppern. Nimm alles Wissen was du bekommen kannst mit. Wie @bene98schon sagte: Spezialisieren kann man sich später noch. Das einzige Szenario wo ich dir nicht empfehlen würde ins Frontend zu springen ist wenn du das Backend noch nicht "genug" verstanden hast (genug darfst du hier selber für dich definieren). Generalisierung und ein breites Wissensspektrum ist zwar schön, aber wenn du in jedem Bereich nur Halbwissen aufweist bringt das dich auch nicht weiter. Zweifel ob man dem Frontend gewachsen ist ist kein Grund es nicht zu lernen. Zweifel ob das so eine gute Idee ist wenn man das Backend noch nicht verstanden hat hingegen schon.