I’m pretty sure that 5 is a feature because the button that moved is usually replaced with a clickable ad.

Sounds like SAP.

I think that there is always an implied design requirement of the program shouldn’t crash.

There’s a setting on the phone app to block notifications when you’re active on the desktop. It works well for me.

I don’t think that I get meeting notifications on my teams on desktop either so they just come up in outlook.

There are people in my org that always start with a “Hi” and then send each sentence as a new message. Very irritating.

The idea is that you can have more data online than you can fit on your computer.

It makes sense for SharePoint when there can easily be enough data to cause space problems on employee computers.

It doesn’t really make sense for it to be the default for personal OneDrives though.

I think that the main difference is that developers tend to test for success (i.e. does it work as defined) and that testers should also test that it doesn’t fail when a user gets hold of it.

I have worked with some excellent testers but I have also worked with a team that literally required us to write down the tests for them.

To be fair, that wasn’t their fault because they weren’t testers. They were finance people that had been seconded to testing because we didn’t have a real test team.

The current team is somewhere in between.

I wish our test team was like that. Ours would respond with something like “How would I test this?”

This is very frustrating! I get so many requests from customers asking why we returned response code 400 when we gave a description of the problem in the response body.

I remember when our company split up and we had to give them the source code of some older versions that they still used. We couldn’t do that because the repo was corrupt meaning that we couldn’t access some older revisions. We had no problems using it day to day so nobody noticed which meant that all backups were also corrupted.

It’s not the mechanism of branching that I prefer.

It’s the fact that Mercurial tags the commit with the name of the branch that it was committed to which makes it much easier to determine whether a commit is included in your current branch or not.

Also, Mercurial has a powerful revision search feature built in which I love (https://www.mercurial-scm.org/doc/hg.1.html#revisions).

It’s definitely up with Git in my opinion. I much prefer the branching in Mercurial.

It’s certainly very offensive to lump it in the same band as SVN and TFVC.

The only reason that we stopped using Mercurial is that Microsoft used Git in Azure DevOps. I still wish that they’d supported Mercurial instead of or as well as Git.

I really liked Mercurial too. It was much easier to follow branches to find out if a branch included a commit.

And worse than all of those options is Visual Sourcesafe.

We don’t get that lag but we do frequently get it when the camera doesn’t work for somebody.

I really can’t understand the separation between teams, channels and chats. We almost never use anything other than group chats.

I think that whether it needs plugins or not to do the job isn’t really relevant.

You can develop software in a large number of languages including writing the code (with intelligent code completion), building it, committing it to source control and running and debugging it.

If it didn’t use plugins to do that then it’d huge and take ages to start up.

Microsoft SQL Server is most commonly set up as case insensitive in my (limited) experience (it does support case sensitivity too).

I used to work on an old DOS product and we didn’t have a debugger so we used to have a DEBUG command line argument with

if (DEBUG) printf(“debugging”);

to try to see what was happening and the number of times that code alone fixed the problem was scary.