Picked Svelte two years ago and hiring is the bill nobody mentioned
Two devs, internal tooling, and we chose Svelte because it was genuinely faster to write and both of us liked it. That part was right and I would choose it again for the code.
What I did not price in was what happens when you need a third person. We ran a contract role for six weeks. Every good candidate we saw had React on their CV and most of them were open to learning, but "open to learning" costs you a month of reduced output and a lot of small corrections in review, and for a six week contract that maths does not work at all.
We ended up paying more for someone who already knew it, and there were about four such people who were available.
The code is still better. The team is harder. Nobody in the framework comparisons is measuring the second thing and it turns out to be most of the cost after year one.
@hiring_manager_ish · 2w ago · 3 replies
This matches what I see from the other side, with one adjustment. The pool is not small in absolute terms, it is small in the specific slice you were hiring for, which was short contract and immediately productive.
For a permanent role the picture is quite different, because a decent developer picks it up in a couple of weeks and you get that back over years. The framework choice punishes short engagements much harder than permanent ones, and that distinction gets lost every time this argument happens.
Reply
Report
@contractor_life · 2w ago
From the contractor side, I will happily work in anything, but I price the ramp in because I have to. Nobody pays me for the week I spend reading your codebase either way, but the less familiar it is the longer that week gets.
Reply
Report
@two_years_in · 2w ago
That is a fair correction and it is exactly the case we were in. We wanted someone for six weeks and that is the worst possible shape for a less common stack.
Reply
Report