3 ms·

It's interesting this focus I see lately on "full stack developers", which, to me, is just somebody who knows how to write applications. I don't work with peop

It's interesting this focus I see lately on "full stack developers", which, to me, is just somebody who knows how to write applications. I don't work with people who can't do the whole thing. So having a "generalist" team doesn't sound like anything special, even though I'm aware this is an odd thing in the corporate world. Remember that on each project each person is supposed to be stretching their skills, so a "generalist" team, to me, is just a bunch of guys that each, if necessary, could pull off the entire project with enough work. Having said that, what I usually do is have folks decide what they want to deep-dive in. Maybe the UI guy has always wanted to take a few months to learn the back-end. Or maybe the all-around guy wants more time tweaking DevOps. Let them "specialize" in that, but still rotate stuff around. Projects should be learning experiences. Love the pairing idea, especially for tricky problems. The thing that I think befuddles me is that all of these skills are useful to all of the pieces of the app, no matter what your temporary "specialty" is. If you're doing back-end, you're going to be automating a lot, perhaps writing an half-assed UI to do some testing and system status. If you're on the front-end, you'll be automating testing, and so forth. I think even if you specialize, you need all the development skills for a full application, all of the time. Otherwise you're going to be sucking wind compare to another team. So yes, this is a "getting out of the other guy's way" problem, but in practice it's not a very difficult one, especially if you communicate well and rotate stuff around.

__--__ 13y ago
> I don't work with people who can't do the whole thing. So having a "generalist" team doesn't sound like anything special, even though I'm aware this is an odd thing in the corporate world. Where do you work? and are you hiring? I haven't met a company (even a startup company) that would prefer to hire a generalist over a specialist. At every startup I've worked at, being a "generalist" means you fill whatever position hasn't been hired for yet. I typically spend a few months in a specific job role and shift to a different one whenever a specialist is hired. My preferred method of working is the same as the OP's: I like implementing whole features from start to finish. In my 10 years of experience, I've been able to do that in exactly one job and it only lasted 6 months before the product was finally sunset.

__--__ 13y ago

> I don't work with people who can't do the whole thing. So having a "generalist" team doesn't sound like anything special, even though I'm aware this is an odd thing in the corporate world. Where do you work? and are you hiring? I haven't met a company (even a startup company) that would prefer to hire a generalist over a specialist. At every startup I've worked at, being a "generalist" means you fill whatever position hasn't been hired for yet. I typically spend a few months in a specific job role and shift to a different one whenever a specialist is hired. My preferred method of working is the same as the OP's: I like implementing whole features from start to finish. In my 10 years of experience, I've been able to do that in exactly one job and it only lasted 6 months before the product was finally sunset.