Live data from Hacker News

I don't want to be a full-fullstack developer

artur-martsinkovskyi.github.io

61–70 of 88 posts

Re: I don't want to be a full-fullstack developer

#61
post #48

> Fullstack is interesting because is seems to be almost unique to the software engineering field. Other fields mostly have more division of labour, you don’t expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids. What about GPs? Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together). Personally I lo…

Architectural coherence is such an important part of software design. I agree with your point completely—you need specialists for deep, specific problems, but you also need people with a view of the entire system.

Great point, and I think it relates to the market need for a "full-stack developer", an all-around generalist who understands (more or less) the entire stack and areas of endeavor.

It also made me think how, typically, the problem with "design by committee" is that it's often a mere collection of specialists, without the necessary generalists (those with an understanding of architectural coherence, system-level thinking) with the power to tie it all together.

I think the reason why many great software projects are created by an individual or a small team, is that coherence and consistent vision across the system.

Re: I don't want to be a full-fullstack developer

#62
post #18
post #16

Earlier quoted context omitted.

The problem that I have seen is most companies don't want to pay a skilled full-stack developer what they are worth. They think $100k is the going rate and unfortunately a lot of junior developers are calling themselves full-stack and jumping at that salary. Then the lines get blurred and the true value of a full-stack developer gets diminished.

> They think $100k is the going rate Okay. So get a different job.

But it is the going rate for senior developers in fly over states.

Re: I don't want to be a full-fullstack developer

#63

Earlier quoted context omitted.

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.

Can you stream multiple releases in parallel instead of doing them in series? E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to…

Assuming no slowdown from all the context-switching (a generous assumption), and equal sized features, splitting the team would make the high priority feature take twice as long to deliver.

Re: I don't want to be a full-fullstack developer

#64

An early stage startup probably doesn’t have enough money to hire specialists, and doesn’t have the workflow down to make optimal use of them even they could afford someone in every position. At that scale you need one or two people who can do everything - probably they won’t do the best job of everything, but they’ll get your company off the ground. Once a company starts scaling up they’ll find that they need someon…

Totally this. The difference is not "full-stack" vs "specialist" so much as "early/small company employee" and "corporate employee".

In small/early companies, there's just a few people. The same tasks need to be done (someone has to design the database, ensure the SSL certs work, and get that checkbox looking good in Firefox). But there's less people to do it.

"full-stack" in this sense means someone who is prepared to roll up their sleeves and solve whatever problem presents itself. It might not be the best solution, and a specialist can almost certainly do a better job, quicker. But it works for now, and moves the product on to the next step.

Corporate employees can be true specialists, because there's enough work and enough team to allow them to be. But this comes with an additional required skillset: corporate communication. To be an effective member of a large team requires a communication mindset that is completely different from the "roll up your sleeves and get it done" mindset of the small/early organisation.

I'm a small/early organisation guy - I can't stand corporate communication, and love rolling my sleeves up and getting it done, whatever "it" is. I know people who are totally the other way; they just want to focus on crafting amazing UI's, or designing perfect databases, and shudder with horror at having to deal with the "full stack" in all its nightmarish complexity. They're comfortable dealing with lots of meetings and reports in return for being allowed to do their one thing.

Re: I don't want to be a full-fullstack developer

#65
post #8

Agree with all your points, but in my experience, early-stage startups require full-stack competency due to rapidly changing priorities and a small team.

Generally they don’t require the entire team to be full stack. But being able to flip priorities from 2:1 to 1:2 front end vs backend is often necessary to maintain velocity between milestones. Prettying up the interface is a lot of work. So is scaling up your backend for the new customers your facelift just got you. In a small place having a third of your team being full stack takes a lot of stress off the planning…

Agree 100% on that, I didn't mean to imply startups want a team full of generalists. But engineer #1 likely has to be full-stack. As you say, once you have 3+ engineers, a mix of full-stack and domain experts can ease planning challenges.

Re: I don't want to be a full-fullstack developer

#66
post #41

> you don’t expect the dentist to cure your heart and neurosurgeon to fix your hemorrhoids. That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery. If you think it is, you might lack some understanding of how things work. Tbh., whenever someone hails the specialization and how their particular field is so special, I hear them saying "I really do not want…

> That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery.

I'm not a neurosurgeon, or a dentist, but this doesn't strike me as true. Front-end dev uses totally different tools and languages, and a different set of design principles, than back-end dev. It didn't use to be this way, but it definitely is now. There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.

Re: I don't want to be a full-fullstack developer

#68
From my experience, as a backend engineer develops more frontend/javascript skills, the solutions tend to become more intertwined. We now have some parts of our app where you couldn’t change the tiniest detail in a view method, without thinking about how that’s going to break client side. I’m not sure that’s moving in the right direction.

Re: I don't want to be a full-fullstack developer

#69

Earlier quoted context omitted.

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.

My two cents: you don't need "full stack developers", but you also don't want "front end developers" and "back end developers". You want people who can play either role (and many more) as needed, but with training friction in between.

I think of it as T-shaped developers who have the attitude that they can learn what is necessary, have a culture of collaboration that reduces the friction of learning, and still allow people the ability to shine in code.

I think of my teams as "primarily front end" and "primarily API/back end."

Many people would call that "full stack." Some would call a developer like me "full stack" as in my career I've been a backup sysadmin, Db (pl/sql) dev, back end, front end, and a few other things as needed. But at any one time, I can really only be proficient in two of these - everything else decays.

Re: I don't want to be a full-fullstack developer

#70

Earlier quoted context omitted.

Last release, I was unbalanced on the back end. This release is different. The work changes. Do I lay people off and rehire each quarter based on business need? (No.) do I tell business we can’t do more valuable work while less valuable work is happening? I have a budget as a manager. I can’t always just hire more.

Can you stream multiple releases in parallel instead of doing them in series? E.g. release A has 75% back-end, release B has 75% front-end. You can have front-end devs finish their work on release A and then start on release B before release A is out. (Though, obviously, not that simple. You'll need at least one front-end dev to stay on release A to solve integration issues, and you'll probably need a back-end dev to…

The best way I've learned to build working software is to have a group working together driving at the delivery of it rather than organizing a series of handoffs. Not only do people have context switching concerns at the task level, but teams and organizations have context switching concerns: more tasks in progress mean more organization thrashing and things drop on the floor.
Post reply on HN