Wouldn’t he only be lazy if he’s not doing anything else more productive instead?
He gets payed to do a specific job, and does it the best way possible given the constraints. I don’t see how you find lazyness in that.
The customer simply isn’t willing to pay the extra time for it to be optimized, and he ain’t doing it for free.
I don’t know which job you do, but do you spend a lot of voluntary overtime just to do things the customer isn’t even asking or paying for just because you think it’s better?
Wouldn’t he only be lazy if he’s not doing anything else more productive instead?
Of course not. It’s rather easy to see how one can choose to be lazy and not do hard work while being “productive” doing easier tasks. But this isn’t about the dev, it’s about the culture.
He gets payed to do a specific job,
Again, stop thinking I’m calling the dev lazy, you’re completely missing my point.
and does it the best way possible given the constraints. I don’t see how you find lazyness in that.
This is the laziness. The constraints imposed by management to get new features out the door at the expense of making their existing features work better is a hallmark of the current development era.
I’m not even going to respond to the last bit because it’s entirely irrelevant to (and completely misunderstands) the point I’m making.
Can you then give me your definition of “lazyness”
The dictionary just gives me “the quality of being unwilling to work or use energy; idleness.”
And i don’t see it anywhere in this situation. They’re asked to do a job a certain way (or for management, to make sure it happens in a certain way), and they do that to the best of their ability.
Could they do it better from an performance/software engineering standpoint if they had infinite time/budget? for sure. But that’s not the world we live in.
And i don’t see it anywhere in this situation. They’re asked to do a job a certain way (or for management, to make sure it happens in a certain way), and they do that to the best of their ability.
Nah, I’m sick of trying to get you to understand that it’s not the person I’m talking about, but the mentality of management through the whole process. I don’t know if you’re just not reading the words I write or what, but I’m not willing to keep repeating the same point to a wall
In a way I understand him, the culture is too one sided in its values.
There isn’t a balance or a good middle ground. If you appreciate irony, it’s too optimised for “features”. For which I generally agree.
So the people upholding these values are too lazy to find the balance.
As an aside, every Dev I know would love to endlessly iterate and improve a single thing. So I understand finding that balance isn’t easy either.
The “optimized for features” bothered me a bit of concept.
I think i now narrowed it down on how i see it: It’s optimized for predictability, and lack of need of really skilled people.
Real optimization requires real skill, and is inherently unpredictable. You can aim high, but how achievable it is, isn’t always clear up front.
But the current way, makes software engineering more predictable, and hiring also, you just need average programmers who can more or less use frameworks the way they’re intended, and that’s enough.
It’s just planning for what you know is predictable, and you can actually promise to your customers. And it does kind of suck, but from an economic/business sense, i can kind of understand it…
Wouldn’t he only be lazy if he’s not doing anything else more productive instead?
He gets payed to do a specific job, and does it the best way possible given the constraints. I don’t see how you find lazyness in that.
The customer simply isn’t willing to pay the extra time for it to be optimized, and he ain’t doing it for free.
I don’t know which job you do, but do you spend a lot of voluntary overtime just to do things the customer isn’t even asking or paying for just because you think it’s better?
Of course not. It’s rather easy to see how one can choose to be lazy and not do hard work while being “productive” doing easier tasks. But this isn’t about the dev, it’s about the culture.
Again, stop thinking I’m calling the dev lazy, you’re completely missing my point.
This is the laziness. The constraints imposed by management to get new features out the door at the expense of making their existing features work better is a hallmark of the current development era.
I’m not even going to respond to the last bit because it’s entirely irrelevant to (and completely misunderstands) the point I’m making.
Can you then give me your definition of “lazyness” The dictionary just gives me “the quality of being unwilling to work or use energy; idleness.”
And i don’t see it anywhere in this situation. They’re asked to do a job a certain way (or for management, to make sure it happens in a certain way), and they do that to the best of their ability.
Could they do it better from an performance/software engineering standpoint if they had infinite time/budget? for sure. But that’s not the world we live in.
Nah, I’m sick of trying to get you to understand that it’s not the person I’m talking about, but the mentality of management through the whole process. I don’t know if you’re just not reading the words I write or what, but I’m not willing to keep repeating the same point to a wall
In a way I understand him, the culture is too one sided in its values. There isn’t a balance or a good middle ground. If you appreciate irony, it’s too optimised for “features”. For which I generally agree. So the people upholding these values are too lazy to find the balance.
As an aside, every Dev I know would love to endlessly iterate and improve a single thing. So I understand finding that balance isn’t easy either.
The “optimized for features” bothered me a bit of concept.
I think i now narrowed it down on how i see it: It’s optimized for predictability, and lack of need of really skilled people. Real optimization requires real skill, and is inherently unpredictable. You can aim high, but how achievable it is, isn’t always clear up front. But the current way, makes software engineering more predictable, and hiring also, you just need average programmers who can more or less use frameworks the way they’re intended, and that’s enough.
It’s just planning for what you know is predictable, and you can actually promise to your customers. And it does kind of suck, but from an economic/business sense, i can kind of understand it…