> "I keep begging people to have conversations in public channels... Guess what, devs refuse to do that."
So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.
On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.
> "Many cultures don’t allow for someone to say bad things about their coworker"
Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.
> "If you have better metrics or management skills than what everyone in the world has figured out"
This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.
Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.
With this attitude you will grow a very specific kind of team. They will be very productive according to your metrics, fiercely loyal, and lethal to anyone who doesn't fit in. However, $diety help you if you ever need to innovate.
While this all falls under the same product umbrealla, I'm of the opinion that the intractable problems around Siri have more to do with the lack of nuance in the underlying APIs.
Starting a specific album at a specific song, for example... well Siri handles it, to a point, but it has to interface with Spotify, and there you hit a wall of hot garbage, along with the sequencing and process-management/integrity issues of integration software. Garbage meets a money fire, in other words. High cost, brittle, constantly changing, glue code that is mostly depending on third parties also requires session management? Not a winning product formula.
Sprinkle in some inhuman HCI nightmares like not pausing speech appropriately when reading an album title and you've got a recipe for an expensive turd that annoys your customers, oh my, by a lot.
Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control.
If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience.
Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
> Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.
Ouch. Usually the ones writing very aggressive comments filled with attacks on stereotypes are the ones with anxiety problems :) You are fighting with the windmills. I do make estimates, and I'm usually better than many at it. It doesn't mean that the others like my estimates.
Also, you didn't even understand what I'm saying. TL;DR: You need to allocate a considerable amount of time on analyzing the task to make the estimate (around 10% of the time it'd take to solve it). I also take a jab at people injecting workarounds for the sake of keeping it in the estimated time and failing.
A metaphor I heard once, second hand from a neurologist, was that of making a stress stew. You add in the elements slowly over time into the pot -- barometric pressure, painful perfumes, an odd sleeping position, some traffic, marital issues, whatever -- and then at some ill-defined point it crosses a threshold into being a proper stress stew (ie a migraine).
Sending official letters to the local government isn't spam, and generally not a waste of time.
People with cognitive issues, issues typing, language or presentation issues, LLMs provide a massive improvement in how they are percieved and recieved by the other side. Also, immigrants or people with langauge issues aren't quite as disadvantaged and don't need to use excess time translating or risking an embarrasing misstatement. It's a night or day accommodation tool in the right circumstances.
I think it's just such a clear business-razor because of the cloud: can I take my app and spin up a bajillion cheapo servers with no licensing costs using that stack?
If the answer for .Net was 'no' then there are meaningful domains where people would just jump ship in a second. Research, academia, teaching, and certain government areas pop to mind. Keeping Linux support, because of that server dominance, is a core concern for them.
There's also the context to consider: if I'm scanning someone elses' code in an unfamiliar subsystem, there's a high chance there is a bug or something time critical. Not the time for extra annoyance and work.
Finding code that suddenly zigs where all the rest of the systems code zags takes extra mental overhead. It's annoying, and misleading. All too frequently bugs are coupled to such style violations, adding extra frustration around such misleading code.
> All too frequently bugs are coupled to such style violations
That's a really good point actually. Style violations can make the code look like it does something that it doesn't, `if (a=b)`, missing curly brackets in C/C++, missing semicolons in Javascript, mismatched brackets, etc. An autoformatter can make it more obvious when you've done something wrong.
Parler ignored repeated notices of TOS violations from Amazon, were given a chance to address their frequent TOS violations and incomplete enforcement of TOS violation notices, and came back with a very weak plan while still ignoring specific TOS violations AWS had notified them of.
Parler had ample time. They ignored warnings, they did not address their TOS violations. Then their contract was terminated, and AWS is helping them migrate after the fact. Parler displayed an ignorance of the law and how web hosting works.
Web companies that repeatedly violate the TOS of their hosts deserve to be at the mercy of their failover plans. That responsibility is borne by the web company, not the host.
That you brought that interview up at all guarantees you didn't listen to it.
Abigail Shrier is very supportive of transgendered people, and conveyed in some depth her numerous interviews with medical health professionals who provide aspects of gender reassignment and agreed with their unequivocal experience that it's helping people.
Her book is specifically about statistically aberrant behaviour in small groups of female teens that show atypical behaviour compared to normal transgendered people that are being given hormones and life altering treatments with minimal oversight, often to their lasting detriment.
So, stop begging. Managerial directives come as orders, not pretty-please requests. Also, stop letting your subordinates refuse you. They are your reports, you are approving their money, that can change if they aren't doing their jobs. Fire one for ignoring policy, and their attitudes will change.
On the tech side, clarify that you want all project comms logged and searchable for onboarding and auto-generating documentation as well as identifying technical hotspots where investments in refactoring can save the team time. Whatever. What gets measured gets done, if you are trying to spy on everyone, this is a bad way. Do it if it has value.
> "Many cultures don’t allow for someone to say bad things about their coworker"
Managers in any culture, and especially across cultures, are tasked with learning those cultural sensitivities and then working around them pragmatically. You have identified a problem. That is the start of solutions, not the end of them.
> "If you have better metrics or management skills than what everyone in the world has figured out"
This kind of attitude isn't productive at finding genuine answers, and might be obfuscating the problem.
Lots of people have figured out better metrics and management skills than the local application suggests. It's not the advanced esoteric stuff that is missing, it's the basics.