Re:When hiring developers, have the candidate read existing ...
by turminal on Saturday April 16, 2022 @03:26AM
(#31050378)
The projects listed bear very little resemblance to a typical software project.
Re:When hiring developers, have the candidate read existing ...
by olliej on Saturday April 16, 2022 @06:17AM
(#31051181)
How do they differ?
Re:When hiring developers, have the candidate read existing ...
by beckingz on Saturday April 16, 2022 @09:50AM
(#31052309)
They're actually good.
Though the size and risk of a project do materially matter. If chrome ships a bug, that'll cause an impact on billions of people potentially, where as the typical software bug will impact a few hundred or dozens of people?
Re:When hiring developers, have the candidate read existing ...
by olliej on Sunday April 17, 2022 @03:52AM
(#31059279)
The way the code quality of webkit built up was by introducing a review gate. Chrome inherited its review gate from webkit, because it had established a much better track record for code quality.
The way you get any project to be "actually good" is by adopting methods to ratchet quality. Early WebKit did not have the same strict rules it has today, and we suffered because of that. Introducing review + test for every change rule was introduced, and the frequency of regressions dropped dramatically.
I'm sorry, what?
Review is a gate for everyone, and is a sign of basic project maturity. WebKit, Mozilla, Chrome, LLVM, Linux, etc are all review gated projects. No change is landed - can be landed - without review. If you're questioning the strength of those teams I cannot imagine what your team would need to have on it??