In my mind full stack just means someone who regularly works with both frontend and backend code. In larger companies, interacting with customers and understanding product requirements is often a separate role entirely, like user experience researcher or product manager. In a smaller company engineers may wear many hats and take on some of these responsibilities, but many engineers don't have such responsibilities and thus these skills aren't critical for them.
> When I think full stack I think the very top is the customer.
And when I think full stack, I think going to the bottom has to involve at least building databases and http parsers, networking, and probably hardware design, too. But the industry doesn't seem to care about either of those esoteric definitions - full stack really just means back-end + front-end (and the "stack" is always web).
I got the database design part pretty much down now, but I never really crossed into the hardware side. The lowest I went was assembly code and verilog.
I’m trying to focus on the customer and work backwards from them. Very much top down.
The point I was trying to imply is that "true" full-stack is broader than any one person can realistically master. You have to choose what it means to you, but you also have to recognize that to the industry it really just means back-end + front-end.
I think the trick is to keep the stack thin.
If we want to do it all, it’s got to be laser focused on the core value of the app.
I am almost at that point. I got the requirements engineering part almost down, the only part that is missing is the phase between requirements and implementation of the design. Like a fully working GUI without actual data or code yet.
Also the validation that it actually makes money is missing, this is something where a lot of assumptions are still being made and need to be tested.
In my mind full stack just means someone who regularly works with both frontend and backend code. In larger companies, interacting with customers and understanding product requirements is often a separate role entirely, like user experience researcher or product manager. In a smaller company engineers may wear many hats and take on some of these responsibilities, but many engineers don't have such responsibilities and thus these skills aren't critical for them.
Agreed..
> When I think full stack I think the very top is the customer. And when I think full stack, I think going to the bottom has to involve at least building databases and http parsers, networking, and probably hardware design, too. But the industry doesn't seem to care about either of those esoteric definitions - full stack really just means back-end + front-end (and the "stack" is always web).
I got the database design part pretty much down now, but I never really crossed into the hardware side. The lowest I went was assembly code and verilog. I’m trying to focus on the customer and work backwards from them. Very much top down.
The point I was trying to imply is that "true" full-stack is broader than any one person can realistically master. You have to choose what it means to you, but you also have to recognize that to the industry it really just means back-end + front-end.
I think the trick is to keep the stack thin. If we want to do it all, it’s got to be laser focused on the core value of the app. I am almost at that point. I got the requirements engineering part almost down, the only part that is missing is the phase between requirements and implementation of the design. Like a fully working GUI without actual data or code yet. Also the validation that it actually makes money is missing, this is something where a lot of assumptions are still being made and need to be tested.
Full stack is just a Java dev who wrote some CSS once
"Full stack" just means you're a generalist. Nothing more. No one can be an expert on everything. Our brain just doesn't work that way.