2 ms·
If not blatantly obvious, I was being flippant. You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not see
by dogleash 5y ago
If not blatantly obvious, I was being flippant.
You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not seeing that.
Like anything in software projects, the path of least resistance will get you to the quality floor. Trivially actionable advice doesn't exist because it will become part of the quality floor. That's just the evolution of software.
That doesn't mean there isn't actionable advice that's low on the learning curve. But like others skill, there is an unavoidable learning curve, it also takes time to apply the skill, and choosing when to apply it is a skill in and of itself. That's just life in development.
I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done. And the state of affairs is that performance is very frequently sacrificed, leading to a pretty damn sorry looking status quo.
- johnnyanmac 5y ago>If not blatantly obvious, I was being flippant. Poe's law is in effect. I've seen that sentiment elsewhere and even in this post espoused unironically. It happens quite often in these circles unfortunately. >I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done. there isn't, but there is something wrong when you question the quality of a developer over it, while not understanding their constraints on knowledge, time, scope, and overall goals. It's just very presumptuous and I've never seen a justified case to shame someone as such. Promote good practices, educate on bad ones. You can do this without such attitude as "git gud" which targets devs directly (which may not be something you said, but it is said often enough that I feel a need to address it).