Can’t make it worse than Huffman already has. After the API nonsense most mods who are still there should’ve left. I don’t know how most continue to do Reddit’s work for free after the way Huffman talked about us all. He made it clear how much he despises the community and the complete lack of respect he has for the people who run all the subs
I also don't "need" nor "depend" on hacker news to live. We're talking about websites like they are vital to living, that's not real. They are not. The closest thing to a website someone actually "needs" might be a government website (to report or file taxes maybe) or a bank website (assuming no brick and mortar locations near you). Let's not use words like "need" and "depend" to mean much lighter things like "is convenient" and "frictionless".
Well who are you? Why should they trust you to actually complete a task and not dump unfinished work on them when your contract is up?
The manager didn't do the work to figure out what a contractor should do before hiring one. Why would they expect that org to plan the exit if they didn't plan the entrance?
I mean, they hire me for a reason, whatever that may be. I want to do a good job and carry out the task because I want to get hired again by them or whatever agency is pimping me out. I've seen a lot of shit and that's my value. Whether or not the team wants to help me succeed is their political thing. And that's not invisible to management either.
You're not looking at it very empathetically. You're disregarding the concerns I floated, you expect the team that feels underwater to now stop everything to reshuffle the work scheduling to fit in a wild card all while you're calling them bad and replaceable.
I mean it really sounds like you're not on their side at all. It's their job to help you succeed, apparently. From what you've said already, you don't care about the project either. You're happy to waste time and money. It sounds like they're right not to trust you.
If he was hired to do a job, its not on the team to "trust" him.
Its to incorporate him as a resource. I'm sorry but speaking strictly from a productivity standpoint, we're not here to be empathetic, we're here to deliver value to the organization.
If I'm a manager of a team thats struggling and now also sabotaging additional resources, because they havent got the right warm and fuzzies, I'm going to be looking to have some difficult conversations. I'm also going to be very critical of anyone who floats a lack of "trust" as the blocker without some concrete evidence to justify it.
Whatever concerns they might have is not for the contractor to address. They are between them and their own management who deemed them unable to deliver sufficiently.
Well this is all highly hypothetical but my point is that there are valid reasons to not entrust a contractor, who is only around temporarily, with long standing features. Not because they are nefarious but because they, by definition, will not own the feature ultimately.
Resistance is also not the same as sabotage. My assumption is that everyone is acting in good faith from their own perspective. An immediate issue I see that the contractor was brought in because folks were looking at the calendar and not the tasks. Now the team is being pushed to carve out tasks. If shovel ready tasks are identified first, almost certainly, things go smoother. You're not context switching everyone. Its far less chaotic.
What you seem to not understand is empathy is going to move the team forward and deliver. Jumping to bad faith immediately is likely not the fastest way to a solution. If someone is struggling, its useful to understand why and address those problems. Its often not because they're bad.
That's not at all what I'm saying and I don't know where you're getting that from. I'm not trying to stop anyone. I'm trying to be an extra paddle. I'm happy to do nothing iff I try to help but get boxed out. I have no problem just riding in the boat and saying "hey, there's rocks up there" or "This seam looks leaky, maybe patch it". I'm not here to fight people or egos.
Just because concurrent design, QA, research etc push out the Gantt chart doesn't mean your meeting isn't useless.
In fact, deep pipelines don't even need to have bottlenecks to take time. Even still any given meeting could still be a waste of time depending on the meeting.
Async/await implementations usually also come with a runtime to handle the work scheduling as well as manage thread context. You can say that you can do that with just threads and callbacks but that's also essentially implementing async/await.
reply