We're more diligent about ticket descriptions these days, but we weren't always. Obviously the best is to be able to to talk to people, followed by documentation, either explicit documentation or on the ticket itself .
After that it can be useful to look at all commits that were related to the change itself. You can often piece together why something was done from looking at how the changes happened as whole, or even which parts were rewritten as requirements changed.
Another option is to talk to people in your org closer to clients. Support or client managers can sometimes have a better idea of how features are actually used, meant to be used, or what parts are more valuable than product or engineering will, especially if they're revisiting a feature for the first time in many years.
But yeah, often you can't. You're best bet then is to make sure you really understand the feature look at it with fresh eyes. Say "Well this is how it DOES behave, how do we want it to behave from here?" Actually talking to clients can be helpful here if any of them are willing to talk to you. In enterprise software, you can probably find a client who wants to shape the direction of the feature and has some strong thoughts.
You can absolutely disincentivize unethical behavior through legislation though, whether they believe it at the core of their being or not. See slavery, murder, rape, robbery, etc. There will always be loopholes people can exploit, but that doesn't mean legislating away the larger ones doesn't have an effect.
Legislation on education curriculums can also have an impact on people's core morals, though that can be tough when even concepts like "share your toys" and "slavery was wrong" can be called indoctrination these days.
A little tangential since this is more about gating white supremacist content than violence or sex, but I was on 4chan when it was being infiltrated by genuine white supremacist organizations and Russians that talked about how manly Assad was to influence teenagers interested in anime. I had people in real life to talk to about these things so I narrowly escaped the influence. Looking at the current state of the US, not everyone did. That being said, despite my hope that older people would be less prone to such influence, it doesn't always seem to be the case.
That's not really whataboutism. They're not justifying it, they're supplementing the relevant point by saying development in areas of moral controversy are quite common even in more controversial areas.
How does irrelevant information supplement the point? It's only a distraction.
Your interpretation of their post seems quite generous. They made a single statement, and didn't back it up with anything like what you are saying they did.
So it really is a whataboutism: "Whataboutism is a rhetorical tactic that attempts to deflect criticism or avoid addressing a point by responding with a counter-accusation or question about someone else or something else, often unrelated to the original issue".
"Weapons manufacturing" has nothing to do with "website creation". It is a whataboutism.
I've also read about various image hosting tools, such as apps for creating wallpapers, being overrun by pornography because communities where pornography is banned found it bypassed various automatic censors. If arbitrary image hosting is a subset of your functionality, it can be used as such.
Unfortunately the sunk cost fallacy is often rational when you consider reputational consequences of the individuals making decisions within the company.
It's pretty easy to spin an easily reversible decision as "complicated" and "a bit messy", but you'd get fired for taking a risk and wasting years.
I feel like that might be an organizational problem. At my company the designers will present their figma designs to engineering and we'll have a meeting to go through them and bring up concerns with exactly those sorts of issues e.g. "This list may actually have hundreds of entries in practice, are bullet points still right?". Then we iterate.
Took me years to finally push this culture. The designers no longer try to get away with designs that are too difficult (read: pricey) to achieve, and developers have to keep their skills sharp resulting in less blame and a more competent skillset. Then the designers and developers who thought it was part of the culture to never work together nicely were immediately noticed and shown the door.
In my experience, it is a serious problem when product people do not understand how their product actually works, even when treated as a black box with observable external behaviors and interfaces.
They knew how the product worked (they used the product) they just did not interact with devs - so they didn't really get the implementation. Their only opinions there were formed from leadership who was very biased with what they wanted to express.
We're more diligent about ticket descriptions these days, but we weren't always. Obviously the best is to be able to to talk to people, followed by documentation, either explicit documentation or on the ticket itself .
After that it can be useful to look at all commits that were related to the change itself. You can often piece together why something was done from looking at how the changes happened as whole, or even which parts were rewritten as requirements changed.
Another option is to talk to people in your org closer to clients. Support or client managers can sometimes have a better idea of how features are actually used, meant to be used, or what parts are more valuable than product or engineering will, especially if they're revisiting a feature for the first time in many years.
But yeah, often you can't. You're best bet then is to make sure you really understand the feature look at it with fresh eyes. Say "Well this is how it DOES behave, how do we want it to behave from here?" Actually talking to clients can be helpful here if any of them are willing to talk to you. In enterprise software, you can probably find a client who wants to shape the direction of the feature and has some strong thoughts.
reply