Re:Why is the LinkedIn app almost half a gig?
by trog on Wednesday March 27, 2024 @02:49AM
(#39836282)
Your post sort of boils down to me as "be annoying and measure stuff all the time" or "hope you get lucky". I think there's a middle ground in there but it's too easy to err on one side or the other ad a methodology and then get stuck - either you're ruled by OKRs and playing games with metrics and juking the stats all day, or you're shooting blindly in the dark with no direction or accountabilities.
Re:Why is the LinkedIn app almost half a gig?
by ninkendo on Wednesday March 27, 2024 @06:34AM
(#39837413)
Or you can trust your engineers to know where the quality issues are (they live in the code base all day) and trust that when they say fixing something is important, and that they can make a logical case for it, that it should mean something.
Quality doesn’t come from metrics, it comes from giving a shit.
This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature.
The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)