Hacker News Reader

Comment by ryanbrunner | Hacker News Reader

Making full stack engineers successful necessitates simplifying the "stack" they need to work with IMO. If you have Kubernetes, a complex SPA frameowrk on the front end, and a maze of microservices on the backend, it's unrealistic to expect any one developer to have mastery over all that.

However, if you use a fairly abstracted PaaS, limit use of Javascript and primarily deliver HTML from the server, and keep things in one well-organized backend service, it's perfectly reasonable for a single engineer to contribute at all levels of that stack.

I think one problem with a lot of modern tools is they haven't made programmer effectiveness and ease of use a primary motivation. People look for the best tool for the job (which is often overkill for the scale / complexity that they need to solve for), when often they're better off choosing the simplest tool for the job (which might not work forever, but works well now).

View on HN

I might agree if the expectation is that someone also has a deep understanding of infrastructure, but I'm not convinced by the rest.

I know a few exceptional software folks who have a deep understanding of React and Java backends. The problem for the most part is that it has been difficult to be a full stack engineer because of the churn of FE software frameworks. Now that React has be around for a while, it is well understood by many people and having a decade of software experience means that you can be very competent and knowledgable about both the FE and BE. My expectation is that if React stays popular and is generally similar to how it works today, we will see a lot more people be able to do both FE and BE systems.

Typically a person will still be stronger at one than the other, but they can still be great at both.

> because of the churn of FE software frameworks.

Totally this. I can do javascript. I have written a LOT of javascript in my life. I worked with jQuery, I've worked with React, I have worked with knockout and this and that and this and.

Meanwhile my backend stuff hasn't changed all that much in 10 years. Yes I learn new things, but what I know about javascript and web development has largely gone out the window.

I think in my experience what has traditionally been a challenge straddling the front-end and backend sides of a full stack developer in a SPA + backend API world is not the complexities of the technologies (it's not uncommon for backend developers to have a workable understanding of React and vice versa), but the sheer amount of 1st party code to deal with when working in both areas.

I'm working on turning around a site that's been up and steady for about 5 years. there's no less than 6 different various 'helper' 'foundation' libraries, helper libraries, utility libraries, libraries that don't get used anymore. All interpolated into a mess.

This whole thing is developed by some rotating cast of developers on contracts, who have no interest in maintaining anything long term, and so its just piled up and piled up. Technical debt doesn't exist when you will leave the project for the next guy.

Anyway... we're making progress against it slowly but it's really frustrating because our website is loading so much crap and untangling it takes forever. Half of me wants to throw the whole thing out.

I've been thinking in a similar direction lately. A lot of the more effective practices historically assumed that a single unit of value end-to-end was deliverable by a single engineer (with supporting QA and review, etc.)

The reason those single stack skills diverged into specialisms is because the results were better, especially beyond a certain scale. An SPA done right provides a much more responsive and rich user experience than forms and a full page reload. A DevOps engineer can create a system to deploy quickly, in a reproducible manner and safely when compared to copying a bunch of files over to some servers (and provisioning those servers manually too).

I don't think it's sustainable though, for a large set of use-cases common to everyday web and app development. Having separate front end and back end roles requires maintaining a minimum of two projects instead of one, defining and maintaining an API, managing co-ordination between different developers and understanding how to split scope boundaries between technology and people. It's lot of extra communication both for people and machines. It's more difficult on a management level as well - separate recruitment streams, different evaluation mechanisms, parallel promotion ladders, resourcing headaches, etc.

Now we have the benefit of knowing what's required to compete in the modern landscape, I think we'll start to see the return of a new set of frameworks and runtimes which give 90% of the benefits of separate FE/BE/DevOps roles whilst allowing a single engineer to focus on application development. I'm thinking of things like Elixir's Phoenix LiveView, and eventually frameworks that compile a single codebase to WASM for the browser whilst providing seamless integration with the backend.

It seems like an economic inevitability; anything that lets people ship value more quickly and efficiently has to win out in the end.

The "right" solution vs "right now" is a lifelong dilemma for developers. If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up.

For some annoying reason though, we can't really predict the future and a lot of small, never-meant-for-greatness projects due pick up momentum and need to grow. Then you're in a world of pain. Hope for the best, prepare for the worst, I guess.

If you don't expect your project will have a long shelf life, it might be easier to accept parts in the stack that aren't going to scale. But if your project has prospects for the future, putting in the time to create a solid foundation will pay dividends when the moment comes to scale up.

I have services that were supposed to last 3 months that are still running 6 years later, with a firedrill every 6-18 months when requirements change without warning. I've also spent months working on things that were meant to last years, that never made it to production because the product owner changed their mind.

My general rule is to assume everything will last forever, and organize my code with maintainability and changes in mind. But also to deploy the simplest way possible and scale only when needed.

For sure it's definitely not a simple question where the answer is "right now" all of the time, but my overall point is that at least with modern trends in development, we way overcorrect for "right".

A couple of things that help me when considering this question:

- Is it really a question of "right" vs. "right now"? Is there a genuine compromise with choosing the simpler option? In my experience there often isn't. Using server rendered HTML vs. a SPA for some types of applications isn't going to result in a poorer UX. Using a slower language might be fine forever if raw language execution speed isn't your bottleneck (it rarely is IMO).

- Is it more expensive to do what's best for later later? I think this is especially relevant for dev ops questions. Moving to a Kubernetes setup is going to be just as expensive in the future as it is right now, so it's better to delay that cost for when you actually need it.

- How likely is it that you're going to know what is going to require a more robust solution now? Do you know what the service boundaries of your microservices are going to be? Do you know which portions of your app are going to be scaling concerns?

> If you have Kubernetes, a complex SPA frameowrk on the front end, and a maze of microservices on the backend, it's unrealistic to expect any one developer to have mastery over all that.

Why?

I spent a couple years at a place where everyone was expected to be a master of everything including Kubernetes, and handle customer support.

Absolutely nothing of value was accomplished. By the time a person started to get decent at Kubernetes and frontend and backend and support they would find a better job with more realistic expectations.

So we basically we were paying people to learn for a year, then they would leave.

Why is it unrealistic to expect a single doctor to have mastery in every medical specialty?

Why is it unrealistic to expect a school teacher to be able to teach every single subject?

Because in these fields, along with software development, there's too much breadth of material to sufficiently explore the depths of all of it. Having the breadth and depth of experience required to have mastery in every bit of minutia is a even slightly complex webapp is enormously difficult to obtain and maintain for a single person.

> Why is it unrealistic to expect a single doctor to have mastery in every medical specialty?

Full stack doesn't mean everything.

And actually all the doctors are doctors first, so they know everything about medicine, except they are not specialized in all the medical specialties.

Which is rarely a requirement in medicine.

Brain surgery or conjoined twins separation isn't that common, but an highly specialized surgeon is perfectly capable of curing common diseases just like a cardiologist can perform common surgery, such as appendicitis.

Full Stack means that you can get things up and running, not that you know everything of everything.

Yeah fair enough, I'd agree with that assessment and I think that definition of "full stack dev" makes it a much more attainable target.

I disagree. It just takes time and practice.

Someone can master a subject in 5+ years if they do it everyday. A fullstack dev with 20 years experience can master all those stated and more and I know fullstack devs (granted not many) than can maintain entire apps like this.

> Someone can master a subject in 5+ years if they do it everyday.

The problem is that all of these are moving targets. You don't master DevOps in 5 years and then you're done forever (same with backend and front-end development), these are constantly changing fields that require continually honing your skills.

Just chiming in this looks basically like my day-job.

I'm a fullstack dev who is often our devops/kubernetes lead. I'd say over 50% of my day is around DevOps tasks, but I'm likely to write an API or hone a frontend animation as well. I contribute on all parts of our microservice based kubernetes government application, but do skew to the devops side where the rest of my teams' experience is lighter. I can write iptables or webpack configs, I can implement OAuth or modify bezier curves for animations, and frequently do it all at my job. I have just over 10 years of professional experience but have been programming longer.

I didn't say it was impossible, just very difficult.

A lot of how to interpret this article is from the context you're viewing it in. You, personally, can be a full-stack developer with complex stacks if you're working at it. If you're someone who's building a team, requiring deep knowledge of all tiers is going to make it incredibly hard to hire in terms of both people who have all those skills, and more importantly people who want to use all those skills.

The word was "unrealistic."

Reply on news.ycombinator.com