
Ask HN: How replaceable are developers on a MERN stack? - chdaniel
Hi,<p>I’m a product manager learning the craft. Coming from UI&#x2F;UX design background.<p>I’m currently building a couple of products with developers who’ve chosen the MERN stack. My question is about “replaceability” — how tied am I to a front end developer on the MERN stack and how tied am I to a back end developer on this stack?<p>Which one am I closer tied to?<p>When I say replacing someone, I’m wary of the cost of switching the developer who made the app&#x2F;wrote the code with a new one: 
1. the time cost of finding them
2. time cost of them going through the previous developer’s code to understand what’s going on there
3. Money cost etc<p>As far as I understood (correct me if I’m wrong please), the point of using the React framework is that it’s all “modular” and that the cost of switching developers is lower. Would appreciate someone shedding some light on me!
======
tcbasche
Yikes. If the thing you're worried about the most is how replaceable your
staff is, there's something smelly going on ...

That said, any web developer worth their salt should just be able to pick up
any tech like Mongo or React with ease. There's enough resources out there
that wouldn't mean this is an issue.

------
quickthrower2
It's a common stack, so no more or less replaceable than any other stack such
as any other permutation of (Mongo/MySQL/PostGresql/SQL Server) +
(Express/Rails/Django/ASP.NET) + (React/Angular/Vanilla) + (Node/Ruby/Python)
etc.

React is as modular as the developers choose it to be. You can write
convoluted code in React too. React does force you into a certain way and
makes it easier to standardise, but these days with hooks and Redux and much
more there can be a lot of variation in architectural styles.

Picking what tech to use is hard. Sometimes it doesn't matter at all, just
pick what you are used to. Case in point most peoples SaaS side projects.

Sometimes it makes all the difference. If using clojure + scala + akka + kafka
+ prolog means you can crush the problem, then choose those, don't pick worse
languages for solving a given problem so you can handle people leaving.

I suspect developer replacability should never be that much of a concern in
the choice of tech, where you are even considering something esoteric for
genuine reasons.

------
afarrell
There is a fundamental conceptual error you are making here, but I can't quite
come up with a good description of it.

~~~
tudelo
I think it's kind of strange that OP's focus on the framework as the way to
determine how replaceable people are. I think unless required, most people
have basic familiarity with a framework, and are likely more familiar with the
languages that make up said framework. Any Javascript framework or stack
(outside of something obscure) is easy to learn (read: doesn't take any real
special skill) especially if there is an existing codebase that developers can
use to learn from...

------
runawaybottle
You can ask your team about the flexibility of their architecture. How easy is
the current setup such that new team members can be added, how piecemeal are
the components and apis such that tasks can be delegated.

It’s fair to be concerned that one or very few own your product implementation
(and I speak as a developer).

MERN stack is okay, but it can easily have ten other pieces that will make it
a highly specialized stack.

Things should be designed so you can rip out any of those letters. If you end
up with a convoluted UI codebase, it will cost money and time to rip the R
out.

If you don’t get the right people to setup your database right, you won’t be
able to pull the M out.

The E and N are probably the hardest to mess up amongst the letters.

Don’t add anymore invisible letters to the stack if you can avoid it (there’s
a plethora of extra stuff a typical full stack dev now days is prepared to
pull in if you search around).

------
thrwaway69
I would stay away from mongo as a database depending on what you are doing (in
almost all cases, you don't need mongo. There are better options). Tech debt
from mongo can pile up soon. Can you explain more about the product?

React is alright. Make sure to use hooks instead of classes and encourage
semantic separation. Separate by the use case of the component. Too often
people either end up with too big files doing everything or too many small
files that should just be a one file.

Use typescript and jsdocs. It will help you make less bugs and help unfamiliar
devs quickly start working.

Use something like nestjs to give structure.

Other than that, you are good to go.

------
jtchang
I think you are too highly tying a developer to a specific technology.

Asking which one you are closer tied to reveals some inexperience in your
product management role. Yes there is always a cost to finding new developers
and having them ramp up on the codebase. And some of this can be mitigated by
hiring developers who are familiar with the stack you've chosen. However the
ROI you will get hiring a good developer who needs to learn your stack is much
higher vs a mediocre developer who is familiar with your stack.

~~~
afarrell
This is broadly true, though individual-variation means it is not absolutely
true.

Hiring me to work on a PHP stack will be much less successful than hiring any
other developer is okay with PHP.

(This isn't snobbery. PHP is like gluten.)

------
kasey_junk
Had to look it up: mongo, express, react & node

One of several js everywhere stacks.

------
otras
> As far as I understood (correct me if I’m wrong please), the point of using
> the React framework is that it’s all “modular” and that the cost of
> switching developers is lower.

I think your mental model of React may be incorrect. The point of using React
is to make front end development easier and more sane, and the modularity
allows for more easy re-use and composability. Switching developers still
requires ramp-up, although a developer familiar with React would have a head
start.

------
nunez
I wouldn’t worry about it. If you know JavaScript and/or *script (any of the
more strongly-typed derivatives), going from React to Angular and back is
pretty easy. If you’re willing to be more flexible with people coming from
other languages, the db/web/ui/app stack has been a thing for a long time and
the basic premise of how it works is the same

