5 ms·

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 f

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).

magic_hamster 4y ago
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.
- dec0dedab0de 4y ago
  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.
- ryanbrunner 4y ago
  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?
zepolen 4y ago
> 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?
- CodeSgt 4y ago
  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.
  - zepolen 4y ago
    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.
    - CodeSgt 4y ago
      I didn't say it was impossible, just very difficult.
      - drewcoo 4y ago
        The word was "unrealistic."
      - ryanbrunner 4y ago
        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.
mjfisher 4y ago
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.
ishjoh 4y ago
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.
- calvinmorrison 4y ago
  > 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.
  - ryanbrunner 4y ago
    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.
    - calvinmorrison 4y ago
      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.

magic_hamster 4y ago

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.

dec0dedab0de 4y ago
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.
ryanbrunner 4y ago
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?

zepolen 4y ago

> 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?

CodeSgt 4y ago
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.
- zepolen 4y ago
  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.
  - CodeSgt 4y ago
    I didn't say it was impossible, just very difficult.
    - drewcoo 4y ago
      The word was "unrealistic."
    - ryanbrunner 4y ago
      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.

mjfisher 4y ago

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.

ishjoh 4y ago

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.

calvinmorrison 4y ago
> 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.
- ryanbrunner 4y ago
  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.
  - calvinmorrison 4y ago
    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.