Every company I've ever worked for (contract or perm), everything has been correlated. If they use shit software, they're wanky about the budget (no you can't have a new keyboard ha ha ha), they have rigid processes (Scrum Master! everyone use this big board of tasks!), HR has a stick up their arse ("have you looked at section 1.7.a of the document surrounding...), etc.
Whereas at the places that are decent, it's like it all just clicks. Tell us what equipment you want, give us reasonable updates on the work you're doing, take sick leave if you're ill, general atmosphere of trust. Go in, get shit done, go to the pub, go home, fuck your wife/husband.
It's like some sort of cancer that everything just infects everything else with mediocrity. I've had zero counterexamples, everything is good or everything is shit, no in-between.
This is probably just a general principle though. Sports teams, friendship groups, companies, whatever. You have to trust each other but also aggressively remove mediocre elements or eventually you're just swimming in a pile of shit.
In my experience, at least on macOS, Teams is about the least bad piece of Microsoft programming that I’ve had to deal with.
There are still some things that I think Teams does better than Slack, and some things that Teams does better than Zoom or any other video conferencing software I’ve used.
Yes, I would prefer to lead a Microsoft-free life, both professionally and personally. But Teams is probably the last piece of Microsoft code I would complain about.
I can’t speak for what it’s like on any other OS, however.
> But Teams is probably the last piece of Microsoft code I would complain about.
Really? I mean, even if you're restricting yourself to user-facing software, vscode doesn't prompt any hatred, and quite a lot of users have always seemed to like Outlook. Teams doesn't appear to be in the same league.
I have never used vscode, but I can tell you that I hate it purely because Microsoft produced it. They do not get a free pass after all of the flagrantly evil shit they did trying to stop the rise of Linux. None of their products can be trusted, because Microsoft cannot be trusted.
I'm highly sympathetic to that position, but it isn't useful in distinguishing between various Microsoft solutions, which was the topic of this subthread.
Teams has been an awful experience for me on MacOS:
1. There's plenty of times I open the app and just see a blank screen in the chat window, I have to click away or close the app to get it to work again
2. There was a weird issue where I would get access to their internal debugging menus
3. Sometimes I paste an image and the image disappears. I get an error that they "lost my image". I'm not even sure how that is possible
4. Sometimes a single message will completely fail to load. Just recently this even happened with a code snippet
5. Scrolling a conversation loads in messages too slowly, and if you scroll back all you see are placeholder messages. It makes trying to find something in an old conversation incredibly frustrating
6. I never found the search to produce useful results
I would take Slack over Teams any day. The only Microsoft software I like is VSCode
We use slack extensively. Unfortunately, slack is designed for the use case where you can easily plug in third party or first party slack apps to provide a massive array of functionality that is not natively built into slack.
Guess what happens when you are functionally prevented from using virtually all third party or even first party slack apps, just because there is so many months and years of friction to get them through the approval process? And that’s assuming you can ever get them through the approval process?
No, workflows are not sufficient. Not even within the same galaxy of sufficient.
> In my experience, at least on macOS, Teams is about the least bad piece of Microsoft programming that I’ve had to deal with.
I concur. I think it’s fine for small group and individual communication. My opinion…it’s way better than Skype and probably on par with Slack for direct communication. I think where it fails spectacularly is trying to integrate its file sharing to one drive. This seems to be half baked and some evil product manager’s weird notion to try and eliminate a logical hierarchical file system design that has served us pretty well for the last 60 years.
I thought about my experiences and especially the sentence "everything is good or everything is shit, no in-between." doesn't really hold up. I can see that often, many things are good or many things are bad, but there are usually at least a couple of things that are really good.
Company uses shit software, are wanky about the budget and have slow HR? They have great flexibility in working hours, you're not stressed about progress, you get great freedom in how to implement things.
Company gives you slow hardware, sends you too many emails and makes you jump through hoops? The colleagues are great, they have good food and you get to work on interesting projects.
I kinda wish it was black and white, as it would make it a lot easier to sort out the companies that are subjectively shit. For me, it has usually been a mixed bag, with one or a few show stoppers that eventually made me move on. While there often has been a great deal of correlation, the mediocrity didn't infect _everything_.
I work at a place that does everything you admire in the “just clicks” hardware paragraph, but our software selection process l is absolute garbage and has delivered many years of abysmal experiences for staff.
So, if you hate e.g. Teams, don’t work for someone that uses Teams without being prepared to buckle down and bear it. There’s no harm in turning down a job because they use Teams. It’ll look odd and you might not be considered in a future application as a result, even if they switch away from Teams, because “which chat product do we use” can seem a small thing to hiring managers and to other engineers. But having used terrible software, I certainly wouldn’t fault someone in a hiring context. Better they walk away than be noisily resentful.
I work at a place that does everything you admire in the “just clicks” paragraph, but our software selection process for corporate tools is absolute garbage and has delivered many years of abysmal experiences for staff.
That said, if you hate Teams, don’t work for someone that uses Teams without being prepared to buckle down and bear it. There’s no harm in turning down a job because they use Teams. It’ll look odd and you might not be considered in a future application as a result, even if they switch away from Teams, because “which chat product do we use” can seem a small thing to hiring managers and to other engineers. But having used terrible software, I certainly wouldn’t fault you in a hiring context.
Scrum is terrible and an abomination of what agile was supposed to be. Arbitrary sprints with perverse incentives that reduce taking riskier long term bets and prevent any sense of ownership for engineers. Works fine when you have junior engineers but competent professionals are much better served but ditching this crap.
I felt the same way when I had scrum imposed on me by an incompetent person. I have since come back around and implemented scrum myself to track some stuff I’m working on. It’s good for details.
I had this same experience by proxy and myself was very skeptical. I had asked people around me what they thought about scrum and almost universally people were unclear on what it was supposed to do for them and for each person there was a different complaint.
I read some books on it and overall surveyed it and found that in each of these cases they weren't really doing scrum and were never told why they'd be doing each part because no one bothered. I implemented scrum with my team after explaining exactly what benefits we wanted out of it (for the team mainly, but it also helps stakeholders) and it's a lot better than the pseudo-agile unstructured work we had before at the very least.
We're a part of the planning process, we know the basic motivations behind the things we're doing (user stories' "... so that..." section) and a much clearer picture of when a feature is done (acceptance criteria), our time evaluations are the only ones that matter and have nothing to do with some manager's idea of when something ought to be done.
I'm sure we'll adjust things as time passes and we recognize deficiencies, but I'm pretty happy with even the basic things we get out of it and some of our team members who were previously not happy with scrum are saying it's much better when you know why you're doing these things and when you actually do key parts of the process and don't rip out important bits.
I’ve worked with plenty of senior engineers who prefer it too. As I said in my own reply, I personally don’t. But I don’t think it’s right to frame it as determined by experience level. I do think, like OP, it’s good to prioritize finding team fit where there needn’t be conflict over things like this.
Edit: also, universally rejecting tools/processes is just as much a rejection of Agile principles as adopting them blindly. The whole idea is to choose what works for people doing the work.
Scrum Master with capitals means that someone bought a course and that someone is probably in management, not product. All of Agile with capital comes from a distrust of management against their engineers, that management knows better how the engineers should be spending their time than they do.
To be fair, agile with lowercase does have some really good ideas in it. It’s the distrust that’s a problem, not the system that gets chosen.
It works really well for some, and really doesn’t for others. I’m in the latter camp, and my colleagues have generally been pretty evenly split. That said, as sibling reply said, “Scrum Master” can carry a lot more meaning than practicing Scrum… and I’d add that it can carry a lot more meaning than the role as a term too.
I won’t go on the whole rant about Agile cargo-cult stuff. I’m sure there’s more of it already posted, there certainly is plenty to be had around the net. But yeah, a lot of people hate Scrum. If you want a sincere personal take on why it doesn’t work well for me, I’m happy to share my take.
Probably not with Scrum, but with the Scrum Master. Scrum has a set of tools that helps managing teams and they guy is probably forcing everybody to do those things, because that's his role (or else, he wouldn't be needed).
Agile teams should be able to choose whatever tool fits them. Pair programming or stand-up meetings is not working or people are not satisfied? Scratch that off for now and try again later or in a different way.
Every company I've ever worked for (contract or perm), everything has been correlated. If they use shit software, they're wanky about the budget (no you can't have a new keyboard ha ha ha), they have rigid processes (Scrum Master! everyone use this big board of tasks!), HR has a stick up their arse ("have you looked at section 1.7.a of the document surrounding...), etc.
Whereas at the places that are decent, it's like it all just clicks. Tell us what equipment you want, give us reasonable updates on the work you're doing, take sick leave if you're ill, general atmosphere of trust. Go in, get shit done, go to the pub, go home, fuck your wife/husband.
It's like some sort of cancer that everything just infects everything else with mediocrity. I've had zero counterexamples, everything is good or everything is shit, no in-between.
This is probably just a general principle though. Sports teams, friendship groups, companies, whatever. You have to trust each other but also aggressively remove mediocre elements or eventually you're just swimming in a pile of shit.