I would appreciate this if more front-end specialists actually had all four of the skills that the author claims separates them from full-stack devs: elegant CSS, high-performance web engineering, accessible markup, and in-depth knowledge of React/Angular/etc. I've not observed this to be true. All too often a person only knows the JS framework and doesn't know/care about any other aspect of their platform.
I Don’t Believe in Full-Stack Engineering
31–40 of 199 posts
Re: I Don’t Believe in Full-Stack Engineering
#32Completely agreed. "Full-stack" developers fall into two camps; that is the "web developers" who know enough PHP/Node/Whatever to build a CRUD app with UI, and the serious software engineers who treat front-end as an "oh whatever" afterthought. Both end up with nothing but a huge mess at scale.
I'm this way, and I don't know why. I try to avoid frontend, until I'm more or less forced into it. I can make something functional, but inevitably get grilled about my way of going about it or why I didn't use 2018x style. The fact is, I don't care. I hate every minute of it, and only learn enough to knock it out. I find myself mentally complaining every step of the way. I just don't like how the web as it is is designed, written, or fits together. I wish there was an off switch, as I know i'd be more valuable with these skills, but I'm just mentally unable to accept it.
Re: I Don’t Believe in Full-Stack Engineering
#33It depends what the organization is willing to sacrifice. If you want everything done well, then you should get specialists, or pay well for one of the rare persons who can master almost everything.
Internal software usually doesn't have to be as aesthetic on the front-end (UI) such that you can maybe sacrifice there, for example.
Sometimes you can throw hardware at poor performance if performance tuning is not a person's forte, but sluggishness may snag you at a bad time before you have time to upgrade to a more powerful box(es).
Re: I Don’t Believe in Full-Stack Engineering
#34Earlier quoted context omitted.
Web developers are not serious?
That's not my point. I'm saying that there's a difference between the full-stack generalist "web developers" who know HTML/CSS/JS/PHP/Ruby, and software engineers who build complex systems, typically in Java/C#/C++.
That attitude, as if there's no such thing as a complex system on the frontend, is a pox on the industry.
Re: I Don’t Believe in Full-Stack Engineering
#35I'm the only competent developer in our company. So believe it or not, but I'm doing it all, from tinkering in disassembled Oracle 9i JDBC driver, to planning Oracle migration to writing SQL queries, reverse-engineering stored procedures, modifying Delphi sources, writing Java code, writing Kotlin code, writing HTML, JavaScript, CSS, Objective
C, rolling out some tiny PHP website, writing brute-forcer to crack P12 private key because someone forgot password LoL. Sure, I'm not an expert in any of those fields. I don't even like most of them. Give me task to write Kotlin library (reimplementing React!) and I'd be happy sitting in the corner for the next few years. But I don't have that luxury and generally stuff I'm doing works well enough. And given our income, it's just not possible to hire few competent developers and they would do nothing most of the time anyway. But if I can do it all, I'm busy most of the time and I can have some money as well. Full stack, that is.
Re: I Don’t Believe in Full-Stack Engineering
#36The first time I touched HTML I was ~19 years ago for my middleschool's technology class, where we were to implement a very simple (and ugly) webpage.
Later, in highschool, the first real programming language I learned was Java, and I did some personal projects with that on my own.
After graduating college without any marketable skills in the height of the recession, my sister (a SWE) introduced me to Python and then JavaScript. I weighed my options and found that going into front-end development would be ideal for me; I had an eye for design and it was simple enough to begin. I learned JavaScript through-and-through, but contemporaneously I learned backend web-development (via Python, Django and Flask). When an opportunity at work opened up, I transitioned to doing backend development (of which I was already familiar from personal projects).
Having done both, I do not see why they are mutually exclusive. I think the issue is that most people who call themselves full-stack engineers do not actually fit the description; it sounds like a good thing to label oneself. I see this often with bootcamp grads who know JavaScript only, and can run their code with Node, so they believe that they are now backend developers.
To learn the backend, I built from scratch: * a simple (and crappy) ORM * a simple (and crappy) db-backed session system * a simple form-generator (similar to Django forms, for flask) * login / user handling (etc)
To learn the frontend, I built a simple single-page-application, using vanilla JavaScript.
I have worked for years doing both backend and frontend development (JS visualizations for SVG/canvas, data-heavy SPAs, backend APIs, Golang services to process data, work with AWS, docker, etc), and I doubt that I am unique. Full-stack developers do exist, though of course one only has so much time and "jack of all trades, master of none" will apply to many.
Many of these new-bootcamp grads build a simple Node web-app without realizing many of the problems (and solutions) inherent in the backend and label themselves full-stack. That's the problem; not that the frontend is somehow too difficult to master, or that the backend is somehow out of reach.
Re: I Don’t Believe in Full-Stack Engineering
#37This article is conflating junior developers with full-stack engineering. I work on the entire stack. Can I work with databases and write queries? Sure. Can I do it as well as a data architect? No. That's not what's expected of a full stack engineer. We can have meaningful, productive discussions with everyone on all parts of the stack. We'll talk with the data architect, write/tweak a query if we need to, we'll talk…
Completely agreed. I find it much easier to communicate with specialists like our DBA, or DevOps team, having at least some mid-level experience or knowledge in each different domain.
Re: I Don’t Believe in Full-Stack Engineering
#38A full stack developer is what turns into an Architect. If you cannot build, operate, tune and debug the full stack, at scale, you are not an architect.
I wouldn't agree. A building architect isn't an expert at all the trades that are required to fulfill his design; he just has a strong understanding of how everything fits together and what is/isn't possible.
Agree, and the mess is when an architect thinks they are the head and know better than everyone else. I doubt there would be a mess if the architect said let’s do x and someone said oh no y is a better approach and they lived happily ever after ;)
Re: I Don’t Believe in Full-Stack Engineering
#39I disagree with the article. It's a 1,000 word false dichotomy between Full Stack vs. Insert Specialist Here. Sure, if you're a Fortune 500 company, go ahead and hire a DBA, Cloud Architect, Backend Engineer, UI/UX Designer, Graphic Artist, Social Media Marketer, etc. You'll have a few million $ in salary overhead. It may take longer to produce a final product. BUT, it will probably be way better than a product that…
Unless your numbers are completely random just for the example, deciding to run an 1,000 hour project with 10 people is a disaster by itself. How would you involve 10 people in a short 3-4 weeks project?
Re: I Don’t Believe in Full-Stack Engineering
#40What makes you a "senior" engineer, anyway? I feel confident calling myself fullstack. I'm not going to list all of the things I have done and know how to do because honestly it would feel arrogant. But what lead to the thought process that backend and frontend developers should be separate anyways? Yes, it is complicated and time consuming to keep up with both backend and frontend development, but there's no way you…
> What makes you a "senior" engineer?
You've spent enough time designing software that you can take a vague spec, design a solution avoiding common pitfalls and following a very easy path. Then you hand back a prototype followed by a complete and maintainable solution to a happy client.
At that point, your services should no longer be _required_ to keep the product working.