Experienced Devs

3956 readers

1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

snowe@programming.dev

jmk1ng@programming.dev

drewsiferr@programming.dev

Opinion about full-stack web app teams? (programming.dev)

submitted 1 year ago by tinker_james@programming.dev to c/experienced_devs@programming.dev

9 comments fedilink hide all child comments

What is your opinion about full-stack teams? I'm referring to teams where the desire is for every member to competently contribute at every point in the stack.

Do they work?
What has been your experience?
Does team size and/or experience level inform your opinion?
Do you notice an increase/decrease in quality?
Do you notice an increase/decrease in team and product cohesion?

you are viewing a single comment's thread
view the rest of the comments

[–] soloner@lemmy.world 6 points 1 year ago* (last edited 1 year ago)

As a full stack I feel capable of serving as an architect on a team. I am not sure if I could feel that way if I only honed in on one area.

So I think at least one full stack (architect) kind of person on a team is certainly beneficial.

As far as an entire team of full stacks? I'm sure that would be effective but it may cost a lot of money to have all that talent, where perhaps some tasks could have been done by a non-FS. Also there is the issue where specialization is needed in a certain area, and FS usually don't offer that.

So I don't think it would be a mistake, but it may not be as optimal as having a mixed bag where you have a handful of full stacks and then some dedicated FE and BE folks.

To answer your questions:

Do they work: yes

My experience: I'm biased, but I prefer working with full stacks because they get the "big picture" more often. This does translate to a smoother development flow most of the time.

Team size/xp: yes. I work with 2 other full stacks, and then we have some dedicated data engineers, a dedicated FE, and a dedicated data analyst.

Increase/decrease in quality: almost certainly there is a decrease on the FE side because full stacks are thinking about everything. Oftentimes the FE will get "good enough" and we'll move on. I've seen dedicated FE people put a lot more care and attention than I would. However, for the BE I haven't noticed any decrease in quality vs a dedicated BE.

Actually to address the FE quality issue we've arrived at a process whereby the FS builds the full experience and gets it looking mostly good and completely functional, then we pass it off to our dedicated FE person to polish. The polish involves making things look better, responsive, accessible, and ensure legibility. These are things I could do as a FS, but I prefer to lean on the dedicated FE person so I can move onto other things. It's a system that works really well tbh because the FE person doesn't have to start from scratch or think about the programming as much, and the FS can still get the FE development done without time sinking the nitty gritty. It's a win-win.

Increase/decrease in product cohesion: full stacks intrinsically keep the stack cohesive, and that to me is part of the main benefit (see earlier statement regarding the architect role). This translates to the product as features are developed. Often we get a more maintainable system than if a BE and FE got together to agree on an API interface, both may be making concessions to the other that a full stack could work through in their own head and sort out quickly and more effectively.