Letzte Woche bei ShopTalk sprachen Dave und ich mit Mandy Michael und Lara Schenck. Mandy hatte gerade den provokanten Beitrag verfasst „Gibt es einen Wert in Leuten, die kein JavaScript schreiben können?“, was unsere Unterhaltung bestimmte. Lara interessiert sich ebenfalls sehr für dieses Thema, da sie eine web-affine Person ist, die einen Job sucht, sich aber selbst als Nicht-Einhorn auf dem Spektrum einordnet.
Teil dieser Diskussion drehte sich um Jobtitel. Wenn es einen universell akzeptierten und verwendeten Jobtitel gäbe, der bedeutet, dass Sie speziell in HTML und CSS geschult sind, und es einen Markt für diesen Jobtitel gäbe, gäbe es wahrscheinlich überhaupt kein Problem. Den gibt es aber nicht. „Webentwickler“ ist zu vage. „Frontend-Entwickler“ bedeutete das vielleicht früher, wurde aber weitgehend von JavaScript vereinnahmt.
Tatsächlich könnte man sagen, dass keiner von uns einen genau perfekten Jobtitel hat und die Branche insgesamt Schwierigkeiten hat, sich auf eine Reihe von Jobtiteln zu einigen.
Lara hat ein Repository erstellt mit der Absicht, all das zu durchdenken und zu diskutieren.
Wenn es bereits ein Spektrum zwischen Design und Backend-Entwicklung gibt und Frontend-Entwicklung der Ort dazwischen ist, ist Frontend-Entwicklung vielleicht, wenn wir hineinzoomen, auch ein Spektrum
Ich mag die Idee von Spektren, aber ich stimme auch einem Kommentar von Sarah Drasner zu, in dem sie erwähnte, dass dies den Eindruck erweckt, man könne nicht beides gut beherrschen. Wenn Sie ein Punkt genau in der Mitte dieses Spektrums sind, sind Sie zum Beispiel nicht so gut in JavaScript wie jemand auf der rechten Seite.
Dies könnte wahrscheinlich mit etwas anderer Datenvisualisierung (vielleicht der Größe des Punkts) oder, Gott bewahre, mit Fähigkeitsbalken behoben werden.
Wichtiger noch: Wenn Sie sich wirklich für die Diskussion darüber interessieren, hat Lara den Issues-Bereich genutzt, um dies zu eröffnen.
Letztes Jahr begann Geoff ebenfalls, über all unsere Webjobs als Spektrum nachzudenken. Wir können unsere Jobs in Teile zerlegen und sie auf unterschiedliche Weise auf diese Teile abbilden.
Siehe das Pen Web Terminology Matrix von Geoff Graham (@geoffgraham) auf CodePen.
Siehe das Pen Web Terminology Venn Diagram von Geoff Graham (@geoffgraham) auf CodePen.
Das kann uns sicherlich helfen, unsere Welt ein wenig zu verstehen, hilft aber nicht wirklich beim Thema Jobtitel. Es ist unwahrscheinlich, dass wir Leute dazu bringen werden, Stellenbeschreibungen zu schreiben, die eine Datenvisualisierung dessen enthalten, was sie suchen.
Jeff Pelletier hat einen Versuch mit Jobtiteln gemacht und sie auf drei reduziert.
Frontend-Implementierung (Responsive Webdesign, modulare/skalierbare CSS, UI-Frameworks, Living Style Guides, Progressive Enhancement & Barrierefreiheit, Animation und Frontend-Performance).
Anwendungsentwicklung (JavaScript-Frameworks, JavaScript-Präprozessoren, Codequalität, Prozessautomatisierung, Tests).
Frontend-Operations (Build-Tools, Deployment, Geschwindigkeit: (App, Tests, Builds, Deploys), Fehler-/Log-Überwachung und Stabilität).
Obwohl sich diese für mich nicht ganz wie *Titel* anfühlen und die Umwandlung in etwas wie „Frontend-Implementierungsentwickler“ nichts ist, das sich durchsetzen würde.
Cody Lindleys Frontend Developer Handbook enthält einen Abschnitt über Jobtitel. Ich werde ihn nicht vollständig zitieren, aber es sind
- Frontend-Entwickler
- Frontend-Ingenieur (auch JavaScript-Entwickler oder Full-Stack-JavaScript-Entwickler)
- CSS/HTML-Entwickler
- Frontend-Webdesigner
- Web-/Frontend-Benutzeroberfläche (auch UI) Entwickler/Ingenieur
- Mobile/Tablet Frontend-Entwickler
- Frontend-SEO-Experte
- Frontend-Barrierefreiheits-Experte
- Frontend Dev. Ops
- Frontend-Test/QA
Beachten Sie den umstrittenen Titel „Full Stack“, zu dem Brad Frost sagt:
Meiner Erfahrung nach bedeutet „Full-Stack-Entwickler“ immer „Programmierer, die Frontend-Code schreiben können, weil sie müssen und es ‚einfach‘ ist“. Umgekehrt ist es nie.
Dennoch fühlen sich diese weitgehend gut an. Und doch seltsamerweise, fast so, als gäbe es sowohl zu viele als auch zu wenige. Denn während es hier eine gute Abdeckung gibt, aber wenn man Spezialisierungen abdecken will, könnte man auch Performance, Content-Erstellung, Analyse und mehr hinzufügen. Je mehr man hinzufügt, desto weiter entfernt sind wir davon, Dinge festzulegen. Ganz zu schweigen davon, wie schwierig es wird, wenn Menschen diese Disziplinen überschneiden, wie sie es fast immer tun.
Nun ja.
Vielen Dank, dass Sie diese Diskussion fortsetzen. Sie wird vielleicht nie enden, aber zumindest ist sie da draußen für Leute, die nicht verstehen, wie kompliziert das alles ist.
Ich meine nicht, jemandem auf die Füße zu treten. Aber ich habe das Gefühl, Titel und diese Art von Etikettierung sind ein sehr amerikanisches Phänomen.
Nirgendwo, wo ich je gearbeitet habe, gab es eine sinnvolle Titelbezeichnung für irgendjemanden, und es ist mir egal, was auf Ihrer Visitenkarte steht.
Gibt es etwas, das ich nicht „verstehe“?
Es geht nicht um Visitenkarten, es geht mehr um Stellenangebote und Vorstellungsgespräche.
Ich denke, die Idee ist, dass man sich *etwas* nennen muss. Ich meine, es ist offensichtlich wichtig, ob auf Ihrer Visitenkarte „Frontend-Entwickler“ oder „SEO-Experte“ steht. Also hat der Titel eine gewisse Bedeutung.
Aber in Bezug auf die Aufteilung eines einzelnen Themas (in diesem Fall Frontend-Entwicklung) liegt das Problem bei den Annahmen, die jede mit sich bringt.
Wenn wir uns für „Frontend-Entwickler“ (FED) für jede frontend-bezogene Stelle entscheiden, werden alle davon ausgehen, dass jeder FED alles macht, einschließlich JavaScript, Barrierefreiheit, SEO und vielleicht sogar Design. Aber das stimmt einfach nicht. Und es ist wichtig, denn wenn Sie jemanden einstellen, könnte es irreführend sein, wenn Sie sagen, Sie seien ein FED, aber kein JavaScript schreiben oder kein Design machen. Oder wenn sie davon ausgehen, dass Sie auch SEO machen, Sie es aber nicht tun.
Also sagen wir jetzt Dinge wie „HTML/CSS-Entwickler“ oder „JavaScript-Ingenieur“ usw., um sicherzustellen, dass es klar ist. Ich meine, ich freue mich zu hören, dass es an den Orten, an denen Sie gearbeitet haben, kein Problem war, aber ich denke, es wäre ein größeres Problem im Einstellungsprozess oder für Freiberufler, die verschiedene Aufträge für verschiedene Kunden erledigen.
Erstens bin ich mir nicht sicher, ob Sie den Podcast gehört haben oder nicht, aber dort werden die Gründe ausführlicher erörtert. Wenn Sie ihn nicht gehört haben, ist das in Ordnung.
Der Hauptgrund für Probleme mit Jobtiteln in den USA oder allgemein ist, dass die Bedeutung von der ursprünglichen Absicht abgewichen ist und Sie sich daher nie ganz sicher sind, was der Arbeitgeber will. Wenn Sie Ausschreibungen für Frontend-Entwickler sehen, bedeutet dies normalerweise jemanden, der gut in React, Angular oder einem anderen JavaScript-Framework ist. Es bedeutet nicht unbedingt jemanden, der in HTML/CSS versiert ist, was es früher war. Sie finden selten, wenn überhaupt, eine Ausschreibung für jemanden, der in HTML/CSS/JS (interaktives JS, nicht Framework-JS) versiert ist.
Ich denke, es ist sowohl ein Problem mit der Klassifizierung/Benennung von JavaScript als auch mit der Benennung von Titeln. JavaScript hat sich so weit im Spektrum über das hinaus entwickelt, was es jemals sein sollte. React, Angular, Ember und Vue sind nicht wirklich vollständig im Frontend, aber auch nicht im Backend, sie liegen irgendwo dazwischen und berühren beide Welten. Ich denke, wir sollten die großen Frameworks als Middle Stack neu klassifizieren, und dann könnten die Jobtitel für Middle-Stack-Entwickler sein, die sich zwischen Frontend und Backend unterscheiden. Ja, ich weiß, dass Middle Stack nicht sehr kreativ ist, aber es ist beschreibend, aber wir können einen besseren Namen finden.
Ich glaube nicht, dass es jemanden gibt, nun ja, die meisten, denen ihr Titel wirklich wichtig ist, nachdem sie den Job bekommen haben, sondern vielmehr, wie die Stellenangebote den Jobtitel klassifizieren, weil die Bedeutung so vage geworden ist und von der ursprünglichen Absicht abgewichen ist.
Ich habe studiert, um Grafikdesigner zu werden, und wurde dann zu einem „Web-Typ“ und meine Kollegen nannten mich „theCSSguru“, also benutze ich diesen Namen sogar in meinem Lebenslauf, aber meine Jobtitel haben sich über 10 Jahre je nach Unternehmen verändert und weiterentwickelt. Dies sind die Titel, die ich für die gleiche Art von Job hatte: Grafikdesigner, Webdesigner, Kreativdirektor, Webentwickler, Frontend-Entwickler, Lead Frontend-Entwickler und UX-Entwickler. Ich frage mich, was mein neuester Titel sein wird? Ich habe den zusätzlichen Vorteil, dass ich Grafikdesign-Fähigkeiten habe, also vielleicht „Lead Frontend UX Designer/Developer Director“. Ja, das gefällt mir. LOL
Wo würde ich hineinpassen? Ich arbeite in einer Digitalagentur. Bachelor in IT, Einblicke in PHP / Java. Aber täglich mache ich „HTML, CSS, Responsive und WordPress Theming.“
Ich bin ziemlich Junior und verstehe die JS-Syntax.
Irgendwie bin ich immer noch erstaunt, dass die Anwendungsentwicklung auf der Datenebene immer aus der „Full Stack“-Diskussion herausgelassen wird. Ich stimme zu, dass die überwiegende Mehrheit der „Full Stack“-Behauptungen stark übertrieben ist. Es scheint jedoch, dass die meisten Diskussionen, die ich auf Twitter/Podcasts/Blogs finden kann, sehr stark auf die „verbraucherorientierte“ Webentwicklung ausgerichtet sind. Ich bin seit mehreren Jahren Berater in der Versicherungsbranche und habe an einer Reihe von Webportal- und Business-Management-Plattformen gearbeitet, die hauptsächlich browserbasiert waren, aber eher Intranet als Internet. Obwohl ich relativ neu in der Entwicklerwelt einer frontend-lastigen SPA bin, habe ich in früheren Rollen oft Teams von Datenanalysten, SQL-Entwicklern (das bedeutet keine Select-Statements), Systemintegration / ETL-Entwicklern, Business Intelligence / Datenvisualisierungs- und Berichtslösungentwicklern betreut. Im Unternehmensbereich gibt es meiner Meinung nach tatsächlich einen nahezu zutreffenden Begriff für „Full Stack“, aber es wird entweder Solution Architect oder Technical Architect, je nach strategischer oder taktischer Planung. Jemand in einer DBA- und/oder SQL-Entwicklungsrolle ist für den Aufbau datenzentrierter kritischer Systeme in vielen größeren Unternehmen unerlässlich. Ich füge hier nur weitere Gedanken hinzu, aber nur, um darauf hinzuweisen, dass es keine vollständigen oder einheitlichen Definitionen von Titeln/Rollen gibt. Ich teile gerne eine Handvoll anderer Beispiele aus der Praxis, wenn jemand weiter diskutieren möchte.
Ich halte dies für ein sehr wichtiges Thema, obwohl zwei Seiten der Geschichte zu beachten sind. Es stimmt, dass das Web anspruchsvoller geworden ist und JavaScript/Programmierung zu einem Problem geworden ist, bis zu dem Punkt, dass es in vielen neueren Arbeitsabläufen erheblich umständlicher wäre, HTML und CSS als eigene Angelegenheit zu trennen. Auf der anderen Seite ist dies definitiv eine Branche, die versucht, Menschen in Kategorien zu stecken, anstatt individuelle Talente zu suchen und sie kreativ einzusetzen. Es geht nicht wirklich um Titel, denke ich, sondern mehr darum, ob man in einen akzeptierten Eimer fällt. Leider ist HTML/CSS stetig aus diesen akzeptierten Eimern verschwunden.
Das ist eine echte Schande, wie hier und in Laras Artikel beschrieben. Ich habe wahrscheinlich eine ähnliche Entwicklung durchgemacht wie Lara und sogar Chris hier, und wahrscheinlich viele andere, da ich in den späten 90ern als Grafikdesigner angefangen habe, der mit Dreamweaver ein wenig gefährlich umgehen konnte. Das entwickelte sich zu CSS, als CSS groß wurde, dann Joomla, Drupal und WordPress, als sie groß wurden. Ich denke, selbst in dieser Phase hatte ich einige ziemlich beeindruckende Kenntnisse, die sicherlich nicht als Programmierung bezeichnet werden konnten, aber ich konnte *etwas* erledigen! Und es war nicht schwer, Arbeit zu finden, weil ich ein Auge für Details hatte. Aber dann, etwa 2013-14, als JavaScript populär wurde und das Web anspruchsvoller wurde, wurde handgefertigte CMS-Arbeit viel weniger lukrativ. Zu diesem Zeitpunkt wusste ich, dass ich entweder den Prozess des Erlernens von Programmier- und CS-Kenntnissen komplett beginnen, mich auf UX konzentrieren oder das Web aufgeben musste. Ich habe mich für ersteres entschieden. Es war unglaublich harte Arbeit. Ich habe buchstäblich 40-80 Stunden pro Woche damit verbracht, Bücher zu lesen, Tutorials zu machen und Übungsprojekte zu erstellen. Das Problem war, dass ich nicht früh genug angefangen habe. Die Branche hatte sich bereits verändert, und die meisten Unternehmen kümmerten sich nicht um meine (ziemlich guten) HTML/CSS-Kenntnisse, wie sie es noch ein paar Jahre zuvor taten. Die Arbeit hat sich inzwischen endlich ausgezahlt, aber ich habe eine erstaunliche Menge an Diskriminierung erfahren, als ich noch lernte.
Die Sache ist, obwohl ich einen langen Weg zurückgelegt habe und jetzt Full-Stack-Arbeit mache und viel zuversichtlicher bin, spüre ich immer noch den Schmerz dieser paar Jahre, in denen mich so viele Unternehmen/Leute abgelehnt haben, immer wieder, weil ich noch nicht stark in JavaScript war. Ich weiß zweifellos, dass es möglich ist, eine gute CSS/HTML/allgemeine Web-Person (die zumindest ein bescheidenes JS-Wissen hat, damit sie nichts vermasselt) einzusetzen, wenn man sein Team richtig strukturiert. Ich glaube nicht, dass es ein Akt der Gnade wäre, ich glaube, jedes Mal, wenn man Talente richtig einsetzt, ist es gut für das Team. Das Problem ist meiner Meinung nach einfach: Dinge in Eimer zu stecken und sich an die Formel zu halten, ist der einfache Ausweg. Das Problem ist, dass Menschen nicht so funktionieren. Sie sind keine Eimer!
Ich sehe keine Möglichkeit, meinen Kommentar zu bearbeiten, aber ich wollte nur hinzufügen, dass ich denke, die Hauptironie der Situation für HTML/CSS-Leute, die eine Umstellung auf Programmierung machen, ist, dass man rein nach dem beurteilt wird, wo man sich bisher mit CS und Programmierung befindet.
Wenn Sie 20 Jahre allgemeine Webentwicklungserfahrung haben, den HTTP-Lebenszyklus vor 15 Jahren verstanden haben, wissen Sie besser als der Backend-Typ, wie man CSS richtig strukturiert, kennen die Browser-Tricks, haben unzählige anwendbare Lektionen für jede Entwicklungsaufgabe gelernt und verfügen über eine gute allgemeine Arbeits- und Testdisziplin... fast nichts davon spielt in den meisten technischen Interviews eine Rolle. Sie neigen dazu, sich zu konzentrieren und Sie rein nach Ihren rohen Programmierfähigkeiten zu beurteilen. Oft geht es um Ihre Fähigkeit, akademische Codepuzzles zu lösen, die Übung erfordern (da sie in der realen Welt selten nützlich sind). Ich kritisiere gute Programmierfähigkeiten absolut nicht, es ist nur so, dass ich glaube, dass ihnen ein künstliches Gewicht verliehen wird und es etwas mehr Spielraum für verschiedene Arten von Talenten geben sollte. Insbesondere angesichts der Tatsache, dass es viele gute Leute in der Branche gibt, die auf einem anderen Weg zu ihrem Ziel gelangt sind als ein CS-Absolvent.
Danke für den Artikel. Für jemanden wie mich, der gerade Arbeit sucht und gleichermaßen leidenschaftlich für die Papier-Skizzen/Mockup-Hälfte und die HTML/CSS/Basic-JS-Hälfte ist, war dies eine kathartische Lektüre. Es scheint, als ob jeder nominell an Leuten interessiert ist, die beides können, aber Frontend-Webentwickler-Positionen suchen nach Angular/React und erwähnen keine Designfähigkeiten, und UX/UI-Design-Positionen wollen meist nur eine „Vertrautheit mit HTML/CSS“.
Wie denken wir über UX/UI-Entwickler?
Es lohnt sich, den Begriff „T-förmiger Mensch“ zu erwähnen. Das bedeutet, dass Sie zu vielen Dingen fähig sind, aber in einer Sache tiefes Wissen haben. Zum Beispiel bin ich sehr erfahren mit Frontend-Entwicklung, das wäre mein „tiefer“ Teil, aber ich habe auch 5 Jahre im Backend gearbeitet, 2 Jahre nur damit verbracht, SQL in Hibernate-Abfragen umzuschreiben und Endpunkte in einem Service zu erstellen. Ich habe auch 1,5 Jahre UX-Arbeit gemacht, Wireframes erstellt und Interaktionsdesign gemacht. Auch gerade bei der Arbeit mache ich seit ein paar Wochen DevOps-artige Arbeit und das gefällt mir auch. Ich bin in Frontend verliebt, aber ich habe kein Problem, mich an der Backend-Entwicklung zu beteiligen, wenn sie anfällt. Ich finde, dass „T-förmig“ die beste Darstellung der Fähigkeiten einer Person ist. Ich weiß, dass es Graubereiche gibt, wie bei allem, was es gibt :)
Es stimmt, dass Leute, die aus dem Design kommen, tendenziell besser in CSS als in JavaScript werden, während Leute, die aus einem Informatik-Hintergrund kommen, dazu neigen, sich auf richtige Programmiersprachen zu konzentrieren, einschließlich JavaScript. Es gibt jedoch einige Backend-Leute, die großartig in CSS sind (z. B. Rachel Andrew). Es gibt auch viele großartige JavaScript-Entwickler, die überhaupt kein Backend machen (obwohl sich das mit der steigenden Popularität von Node ändert). Ich glaube nicht, dass es hilfreich ist, es als Spektrum zu betrachten. Ich würde sagen, die Mehrheit der Frontend-Jobs beinhaltet überhaupt kein Design. Ich implementiere nur, was Designer mir geben.
Ich begann 1999 mit dem Erstellen von Websites. In den letzten 17 Jahren habe ich Websites mit verschiedenen Kombinationen aus HTML, CSS und JS/jQuery erstellt. Die Titel meiner Positionen waren „Web Builder“, „Web Designer/Developer“, „Web Developer“ und „Frontend Developer“.
Im Rahmen dieser Arbeit musste ich viel Zeit auf Browser- und Gerätekompatibilität, Anzeigekonsistenz und UI/UX-Design verwenden. Die Ergebnisse müssen typischerweise in allen Browsern, auf allen Geräten konsistent funktionieren und angezeigt werden (insbesondere bei der Erstellung von Dingen für globale und „Fortune“-Marken).
Nachdem ich so viel Zeit mit dem Erstellen von Websites aus PSD-Dateien verbracht habe, kann ich schnell Fehler in Design-PSD-Dateien erkennen, die aus der Unerfahrenheit des Designers und mangelndem Wissen beim Erstellen von Websites in HTML und CSS resultieren. Ich kann JS und jQuery schreiben, sicherlich mehr als viele „UI/UX-Entwickler“ können oder jemals schreiben würden, aber nicht so viel (oder so komplex) wie ein Backend-Entwickler schreiben kann.
In jeder Rolle, die ich für all meine Arbeitgeber ausgefüllt habe, hat sich jeder brillante Backend-Entwickler (oder Programmierer, wenn Sie dieses Etikett bevorzugen), mit dem ich zusammengearbeitet habe und der etwas im Frontend tun musste, meine Hilfe geholt, um Probleme in der Präsentationsschicht zu beheben. Manchmal sind die Probleme, die ich beheben helfe, Layout, manchmal Browserkompatibilität oder Verwirrung bei Elementzuständen, aber am häufigsten bezieht sich das Problem auf die Spezifität von CSS-Selektoren oder die Kaskade selbst – Vererbungsprobleme.
In den letzten zwei Jahren habe ich nach einer Entlassung freiberufliche Beratungsarbeit geleistet, aber auch Vollzeitstellen gesucht, was mich zum Thema zurückbringt: „Was ist ein ‚Frontend-Entwickler‘ im Jahr 2017?“ Gemessen an den Angeboten, die ich auf beliebten Jobportalen sehe, ist ein Frontend-Entwickler ein Full-Stack-Entwickler mit Schwerpunkt auf Anwendungsentwicklung.
Ich habe miterlebt, wie die Nuancen von Browser- und Gerätekompatibilität, Layout und UI-Design von den Backend-Entwicklern, mit denen ich zusammengearbeitet habe, die als „Full-Stack“ gelten, aber hauptsächlich im Programmierbereich (js, php, C#, jsp usw.) tätig sind, nicht gut verstanden werden.
Und doch gibt es scheinbar endlose Stellenangebote von Personalvermittlern, die von einem Bedürfnis besessen zu sein scheinen, nur „Einhorn“-Entwickler für alle Positionen im Bereich „UI/UX“ und „Frontend“ einzustellen. Noch schlimmer als das Problem „Alle Entwickler müssen Einhörner sein“ sind die Frontend-Entwickler-Positionen, die alle „typischen“ technischen Anforderungen auflisten, mit der zusätzlichen Anforderung, dass dieser Frontend-Entwickler auch Grafikdesign-Erfahrung in Form von DRUCKPRODUKTION haben muss.
Ich hatte zwei kürzliche Vorstellungsgespräche, die beide GROSSARTIG liefen, bis sie jeweils mit unerwarteten Fragen endeten. Im ersten Vorstellungsgespräch, das als „Frontend-Entwickler“-Stelle ausgeschrieben war, waren die Leute, die mich interviewten, sichtlich zufrieden mit meiner Erfahrung und meinen Fähigkeiten und dem, was ich für das Frontend beitragen konnte, und dann fragten sie mich, ob ich ein Full-Stack-Entwickler sei. Sie waren enttäuscht, dass ich nur ein „Frontend-Entwickler“ war, und ich war enttäuscht, dass unsere Zeit völlig verschwendet war, weil jemand eine Stelle ausgeschrieben hatte und dann die Bewerber für eine ganz andere Stelle interviewt wurden – sie hätten ihre Enttäuschung (und meine) vermeiden können, als sie die Anzeige geschaltet haben. Das zweite Vorstellungsgespräch war ähnlich – alles gut in der Frontend-Kapazität, bis die Anforderung „Oh, übrigens, wir brauchen Erfahrung mit Printdesign für alle Arten von Druckmedien“ endlich erwähnt wurde.
Lustige Zeiten.
Ich bin in den letzten Jahren überraschend zufrieden mit „Frontend Software Engineer“. Es deckt die jüngsten Schritte ab, die ich in die Anwendungsentwicklung unternommen habe, und lässt mich etwas Backend-Erfahrung zugeben, ohne den Eindruck zu erwecken, ich würde versuchen, „Full-Stack“ zu sein.
Es ist wirklich ganz einfach.
Frontend bezieht sich auf jede visuelle Darstellung von Inhalten in einem User-Agenten für menschliche Interaktion.
Backend bezieht sich auf den Zugriff, die Speicherung und die Verarbeitung von Daten, um Informationen für Menschen oder Maschinen bereitzustellen.
Operations bezieht sich auf die Implementierung der Plattform für Entwicklung, Test und Deployment.
Die verwendeten Technologien sind nebensächlich, sie ändern sich mit der Zeit. Gestern war es „c“, Cobol und ein Textterminal oder Drucker, dann war es Visual Basic und Java und Farbmonitore, heute ist es JavaScript und HTML/CSS über Desktop und Mobile. Morgen eine KI-API.
Am Ende ist es nur sinnvoll, wenn am anderen Ende eine Benutzerin sitzt.
Wenn Full-Stack-Entwickler Backend-Entwickler sind, die Frontend-Code schreiben können, was sind dann Frontend-Entwickler, die einen Server mit SaaS oder Express für ihre App erstellen können, wenn sie müssen?
Sie haben richtig vermutet, dass meine Beschreibungen nicht als Titel, sondern als Eimer von Verantwortlichkeiten und die sie beschreibenden Rollen gedacht waren. Ich denke, die minimale Anerkennung, dass auf Organisationsebene Raum für Spezialisierung besteht, sollte ein Ziel sein. Die Titel selbst sind weniger wichtig.
Ich denke, jemand sollte eine Web-App daraus machen.
Halten Sie es einfach
Kreuzen Sie alle Dinge an, die Sie aus einer Liste tun können;
die App schlägt Ihnen einen passenden Jobtitel vor.
Für jemanden wie mich wäre das extrem nützlich, da ich Schwierigkeiten habe, einen guten – auch nur einen anständigen – Jobtitel zu finden.
Ich bezeichne mich selbst als „Digital Designer“, überlege aber, das „Digital“ wegzulassen, da es heutzutage fast jede Bedeutung verloren hat.
Ich meine, heute kann man nicht mehr nur eine „Visitenkarte“ oder ein „Logo“ entwerfen. Man muss über Branding als System nachdenken, also ist „nur für Druck“ keine Sache. Daher ist „nur für Digital“ auch keine Sache.
Außerdem entwickle ich Websites in PHP mit Laravel und WordPress. Also fühlt sich selbst „Designer“ einschränkend an.
Vielleicht „Designer & Entwickler“? Ich weiß nicht.