4 ms·
First: it's all about reducing latency. Split the work, implement in parallel then you'll ship in "half" the time. Second: Good developers are hard to find. Ba
by radicalbyte 11y ago
First: it's all about reducing latency. Split the work, implement in parallel then you'll ship in "half" the time.
Second: Good developers are hard to find. Backend requires both good CS background (algorithms, security) as well as development skills. Frontend requires some feeling for design and can tolerate poor development skills.
- gkoberger 11y agoFirst: Read the Mythical Man Month Second: Don't insult front-end developers. I do both back and front, and I find front-end to require much more skill. Nobody notices if a backend feels slightly off, but it's very obvious when an interaction was built by someone who isn't a great front-end programmer. Both sides are necessary and difficult in their own way; they just require different skillsets.
- StavrosK 11y ago> Nobody notices if a backend feels slightly off Oh you'll notice it in three months, when you have to write that new feature.
- gkoberger 11y agoI was talking about end users, although having to rewrite bad code is true for both front- and back-end.
- madeofpalk 11y ago> First: Read the Mythical Man Month Actually, that refers to adding more resources to _an already late project_. It explicitly mentions that starting out with more resources can speed up development. In saying that, 9 women can't make a baby in one month.
- radicalbyte 11y ago> First: Read the Mythical Man Month I have, it's a brilliant book. Helped me greatly during my career. However it's about scaling an already broken (and late) project in a very naive way. Luckily we've learnt a lot since then - and it turns out that decomposing the problem into 4-6 person chucks and optimizing for minimum dependencies is a good strategy to close-to-linear scalability :)
- dllthomas 11y ago"However it's about scaling an already broken (and late) project in a very naive way." If that's all you remember of it, you really need to reread it (and I find myself mildly skeptical that you did in the first place - although it could very well be that it's been long enough you thought those ideas were elsewhere). The title - and Brooks' Law - is about that, but the book covers a whole lot more. Including discussions of approaches to decomposing problems into <10 person chunks and optimizing for minimum dependencies.
- eyko 11y ago> Frontend requires some feeling for design and can tolerate poor development skills. It seems you're assuming front end developers are usually designers with some coding skills, or developers with some design skills, and neither is the case. A fairly complex app will most definitely have designers and developers in their front end team. I think the main reason for the separation is domain knowledge. You may have a lot of experience designing real time APIs, but no experience with web technologies. I've worked with a lot of good developers that still don't get HTTP status codes or the basic principles of REST APIs, but they're good developers nevertheless. And perhaps that's why the role of the full stack developer has become now more popular.
- radicalbyte 11y agoWe're talking about web developers, so what I'm saying is broadly true. Native development - and cutting edge web-based development - is a different beast. You start needing knowledge of threading, messaging, various architectural patterns etc. I'm actually recruiting for such a developer now - someone who wants to be top specialized front-end developer. They're just extremely hard to find (if you're interested in working on a complex SPA and are in, or want to move to NL, drop me a line! You don't need to speak dutch!). You're right about domain knowledge: there is just too much that you need to know to be able to be an effective "full stack" developer for anything approaching a complex system.