I never used it on Linux so I can’t speak to that but it’s pretty bad on Windows. It wasn’t great a couple years ago (on Windows) and it’s only gotten worse. The downward slope of the product quality seems to be steeper each year as well. It’s really frustrating to witness since they could have put out something great.

They were already sunsetting Skype, MSN Messenger was basically gone (or was it previously rolled into Skype? I can’t remember). They could have started from scratch and built a really great communication tool using all of the knowledge they gained running the aforementioned products and not carrying forward all of the tech debt and glue they had to add to make the older services work with modern architecture. But they didn’t and now the majority of the corporate world suffers relentless little pain points while using the software.

Not to mention it’s poor quality has splash damage: loss of productivity due to issues and performance, increased IT tickets, increased computer specs to run the new features MS thinks we all need despite people not asking for. All of that amounts to millions (billions?) of dollars more spent each year for products that are themselves subpar. That cost is only growing as well.

Yep 100%

Yeah the entire piece of software is just really poorly optimized, they use ambiguous language and labels, their controls are constantly in the way (when sharing), and so forth. It is objectionably a bad experience because so many fundamental things about it could be improved drastically.

Instead they needed a modern messaging application and Skype was poisoned by their handling of it so they took a bunch of individual things they had lying around and jammed them all together into a product they called Teams. If you actually look at how it works that is what they did. It’s why MS Streams is used for video, Sharepoint is used for network stores, AD is used auth, and so forth. It isn’t a single product but rather a shell of discrete things that were made to work together but clearly not originally designed in that way given the performance.

Since I just had to deal with a Teams issue, I’m going to list some reasons I dislike it. Obviously, everyone’s mileage is different and something that bothers me may not bother others. However when people complain about Teams, it’s generally because of the following:

• It’s slow. I don’t care what MS says, Teams is really slow. It is slow to start, it’s slow to load content, and it’s slow to upload content to, and it’s slow to navigate around in. This doesn’t mean it’s painfully slow, but it’s slow enough that I think about it and that means it’s too slow. There is no excuse for performance like this in 2025 unless the excuse is you’re packing as much telemetry and data collection garbage as possible into the application.
• The integrations are really clunky (and also perform poorly). For example, if I upload a 30 second mp4 file it will go into Sharepoint and be served in MS Teams through MS Stream. Think about that for a second. A video file needed to be uploaded to Teams, shipped to Sharepoint for network storage, then read by MS Streams to feed back to Teams. Just render the fucking file in Teams. This isn’t hard. With the way they have it setup, the performance is terrible, the user experience is terrible, and it’s insulting that we’re being fed this bloated garbage. For context, I’m on a fiber connection and I still see buffering issues and slow video load times only in Teams so it clearly isn’t just something on my end.
• It randomly loses the ability to connect. Everything else works including other MS products but Teams won’t connect. Within the last 2 years, there have been at least half a dozen times where I turned on my computer in the morning and everything works except Teams. After a lot of searching for a solution, the fix was to delete two registry keys. Seriously, I have to go into the registry occasionally to delete two keys that are in no way tied to Teams based on their location in the registry before Teams will connect again when this happens. What the fuck is happening that Teams relies on two obscure registry keys that aren’t even located under any MS Teams nodes. Fucking awful.
• Did I mention performance? It is worth mentioning again because of how terrible it is. It is usable and gets the job done but people have no idea how much faster this could be if the bloat was removed. Slack isn’t exactly great from a performance perspective either but (at least in my experience) it’s much better than Teams.
• I keep getting prompts about copilot in Teams which is infuriating considering I’ve declined every time and it’s still enabled and still prompts me. I don’t need AI to summarize a one-sentence chat message FFS and I certainly don’t need help writing that sentence. Stop interrupting my flow to popup messages about features I’ve already told you I don’t want to use.

The majority of the above comes down to bad design leading to bad UX and performance. Why are they using a Streams instead of rendering the video in-app natively? Because it was cheaper to just tie into their Streams service. Why is it that only Teams randomly loses the ability to function? Because for some reason it relies on a legacy registry connection key because…reasons?

There isn’t a single bad thing about MS Teams, it’s a bunch of kinda bad things that together make the product terrible. We should demand better of our software products but all leverage has been given to the people who already control these things so we’re just screwed from getting actual good software made.

Like all things in life there is balance that must be maintained. A language with few features but super detailed documentation is ultimately going to be less useful than a language with more features but not as strong documentation.

Obviously you want perfect documentation and full features but it just isn’t realistic so you have to balance things to your requirements. So I went with 5 because the balance between language features and documentation is going to change based on requirements.

Yeah, it’s like going to a restaurant and only judging the food by the restaurant’s decor. It is arguing something that doesn’t matter and most people get over it after they’ve worked in a number of languages.

It just doesn’t matter and instead adds noise to the language feedback loop for something that isn’t changing and isn’t a problem to begin with.

The main point I took away from your comment, and the thing that I think is missing in most of the other comments, is application of this concept to the real world. You nailed it. Always read the manual is a nice sound bite and something that can be flippantly thrown around to feel superior but that is terrible advice without any context.

What it should say is: Always refer to the manual.

Part of being a human is prioritizing tasks based on need and/or want. Another part is understanding your personal needs to accomplish a task. Reading a manual may provide value. Spending the 2 hours with family also provides value. If I choose the latter I can still refer to the manual when needed.

It drives me crazy when people double-down on some distinct thing (always read the manual) and then preach that it should always be the case or apply to all situations. There is a concept of diminishing returns and people should teach how to figure that out rather than blast out a good sound bite. Let people identify what works for them and be respectful of that. I’m not sure why that is such a hard concept for people.

This is what crossed my mind. This seems like the kind of thing we all know would be nice but enforcing it is going to be really tricky.

What happens when one identical twin gives deep fake permission? The other implicitly has it created as well despite not giving permission. That is just what I thought of in 20 seconds, I am sure there are plenty of other examples.

It will be interesting to see how the enforcement goes with this. I suspect it will primarily be used in small one-off cases and not something at large.

We talked about this in my software engineering course back in 2001. Surely we can start acting on these finding a quarter century later right? Right?? Joking (I guess?) aside, this really should be taken more seriously.

For the most part it is just soul crushing to constantly be interrupted but people legit die because of software errors due to these kinds of things. You think someone who has 30 minutes free a day to do code reviews for a whole team is going to do a good job, regardless of their intention?

Software is driving cars, flying planes, scheduling trains, pretty much everything in modern life. Yet we are fragmenting our codebases, micromanaging to the point of focus and productivity loss, and to make up for that we are trying to leverage ai tools that were rushed to market. Buckle up folks, we are in for a bumpy ride.

This and justifying the cost of office space are the reasons.

Just because we can do everything in C and Assembly doesn’t mean it is a good idea or that we should.

It makes sense, you aren’t telling sql server how to do something, you just tell it what you want and it figures it out. You aren’t even doing procedural stuff at that point.

I like the RAD tools being qualified as 4GLs as I haven’t really thought of them that way but again it makes sense.

Also screw PowerBuilder. I am sorry if anyone in this thread likes it…but it is seriously awful.

Edit: Before people jump me, I do know that you have some influence over execution plans with join orders, hints, etc… but by and large you don’t tell SQL Server how to do it’s job.

Giving them your settings provides them (and anyone they sell it to) with more insight about you and how you use their software. This is valuable data and it kind of drives me crazy that articles refer to this as a free option. It isn’t free. It’s Microsoft pricing something low enough to get sales from middle of the road people, while being high enough that a lot of users opt into the backup option. It’s a poorly veiled attempt to extract more of you for their training, their ad sales, or their targeted sales.

This person obviously has their own way of doing things that works for them and that’s great. Some of his views are patently absurd though. This is mostly commenting on his reasons against using a forge and not a comment that he should do something differently.

Trust

100% fair and I think this is the main take-away from the blog post. If you don’t trust something, don’t use it. Full stop, the post could have ended there and been fine. But then it goes on to say:

You get a workflow imposed on you

You mean like forcing people to use email to submit pull requests to your self-hosted git repos? It doesn’t matter what you are doing, if you are working on an open source project you are going to have workflow limitations. This is arguing a fallacy.

In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system.

Nothing is forcing you to use these features so just don’t use them. Plenty of teams use 3rd party tools but host their code in a forge site. Having options available to you automatically is not the same thing as being forced to use them. If it was, JIRA wouldn’t exist because everyone would use github/gitlab/whatever’s built-in issue tracking and project management.

The majority of the post comes across as someone who just doesn’t like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don’t exist.

Trust is 100% the main reason not to use a forge site and all the other things cited are superfluous and/or very subjective.

I think the 3 points are decent guidance in general but I feel you probably should have included some examples of when it doesn’t make sense to follow them. Like everything in life, the actual realization of something is more complicated and we should provide guidance that speaks to nuances that might affect design/implementation decisions. It’s something I think we lost (or the loss accelerated) within the last 15-20 years. Now everything is “you have to do this or you’re terrible at programming” and the nuances are lost as the entire thing is framed in a way to try to grab attention/views. I don’t mean to imply you’re doing that here, just a general observation that articles and videos on programming rarely include more nuanced things.

Anyways, I agree with the overall content of the post but felt I’d provide some counter examples for each point. Admittedly they may not be the best but calling out something like them I think would be worth doing so readers have a wider view of the topic and can make more informed decisions.

Point 1: This is great general advice; be consistent with your names. However, it’s simply not feasible in certain situations. Are you building a data access library? You’re going to need dynamically named things. Maybe your system has thousands of tables (yes it happens, the real world is messy). I would much rather work on a system that uses dynamic names which enforces naming consistency than deal with some switch statement covering hundreds/thousands of things. Not only would the code be cleaner and easier to deal with that way but it would have the added benefit of running everything through the same naming logic and therefore helping with name consistencies.

Point 2: Name consistency is important (see end of above) but don’t force it when it doesn’t make sense. If you have two distinct systems/services that each operate in different domains but share some underlying data source. Maybe the enrollment service calls something an enrollment but the billing system calls it a line item. The freedom to name things appropriately for how they’re used is important and should be another tool in your belt. It also helps business users/managers/etc… and programmers have a shared understanding of domain terminology/requirements/etc…

Point 3: I’d agree for the most part and this is generally great advice. Sometimes it makes sense to go hierarchical. For example human readable configs can benefit from hierarchical structures since we like to process information by grouping things. I’d rather just have a json or yaml section called DataSources than have to repeat the “datasources.datasource1.name”, “datasources.datasource2.name” and so forth for every single datasource defined in the config.

I think the points you made are great. We should use them when appropriate though and knowing when it’s appropriate or not is something we should try to teach along with the rules themselves.