Being a compact way to describe something is very much the problem. That is exactly why people hate them. You can't just read one and know what it does, nor expect that of your colleagues. Every time I add a RegEx to the code, I have to add an explanation of what it does. Just like in code: if it needs comments to be readable, something's very wrong.

I used to be skeptical about unit testing and TDD/BDD. Mainly because it felt like it was too much work. Then 2 things happened more or less simultaneously: I got to work on a huge code base that had a 85% unit test coverage and I saw this talk by Ian Cooper/[^] The talk showed me how you can write unit tests that aren't tightly coupled to the implementation of your code, which makes them less brittle and only subject to change when your code has functional changes. The big codebase showed me that it is much easier and less risky (and will therefore be done more often) to make bigger changes and/or refactorings when you know your unit test suite will yell at you when you make a mistake.

I think this rant is more against scrum than against agile in and of itself. I also think that mindlessly implementing Scrum is a very bad idea. The scrum ceremonies (stand up, planning, review, and retrospective) all take too much time in 2-week sprints. Personally, I think that for any kind of mature product, 2 weeks to develop a shippable feature is too short, unless you can do it all in parallel, which is unlikely. Agile should be about taking the ideas that work for you, your team, and your project. And it requires that management and client understand what you're doing. As for pair programming: that is not a necessary part of agile. I never worked in a full pair-programming environment (I don't believe it would work), but pair programming sessions do yield good results, IME. It doesn't double the cost, because it's much more likely to be correct and it helps in sharing knowledge around in a team. That said, if your employer starts talking about implementing SAFe: run and don't look back.

nope. There are two possibilities 1. her butt doesn't look big in this dress => don't have to lie. 2. Her butt does look big in this dress => you can say that the dress doesn't really do her figure justice. Which is kind, polite and, important for this discussion, not a lie. (Also, I've been informed by my children that big butts are now fashionable, so the example is kinda moot :laugh: )

I have no insider information, this is purely speculation. I think these reasons are the important ones: 1. legacy software: windows has been dragging around a lot of support for legacy software. This only compounds every time they make a change. But seeing that their major target audience are enterprises (who like to see their legacy software chugging along), they can't just stop support (Apple can do this much more easily) Maybe they should have a windows version where legacy support is optional. 2. breadth of hardware. Windows has to keep running on many hardware configurations. It's impossible for Microsoft engineers to test all possible combinations of hardware. Again, Apple doesn't have this problem. 3. priority. MS' focus is on the enterprise and on Azure. This probably means that a higher budget (and, therefore the best engineers) are working on Azure and other non-Windows services.

honey the codewitch wrote:

Especially where it concerns matters of what is possible, and what isn't, and what will work, and what won't the question comes down to "Do you want honest, or nice?" The rest is just in how you deliver it.

When you really analyse this, it makes no sense. Politeness doesn't mean you have to lie, same with tact or kindness. In almost all circumstances (in Western culture, that is), there is no reason to be both honest and kind/polite/tactful. The idea that politeness inherently means that you have to lie / be dishonest is where you're going wrong.

bjoernen wrote:

If PSL96 had been implemented instead, CSS would be a lot easier. You simply express sizes of things in terms of sizes of other things.

That might work for basic stuff. Once you want to use different styles for different screen sizes, this becomes unworkable very quickly.

I don't think that 'OOP as currently conceived by many languages didn't fulfil all the promises made about it' is particularly controversial. Especially the idea that we can (or even should) model reality into classes representing things seems a bit odd in retrospect. We found ways to work around these limitations (like design patterns, not using inheritance), but the very fact that we need these things shows the limitations of the paradigm. I came from this from the other way, I learned functional programming and am now very happily merging the 2 paradigms together. (we all do, LINQ is FP) OOP does some things better, FP does others better (like concurrency), the most important thing is to keep it simple. People get hung up on reuse and abstractions, while they should be focussed on cognitive load and simplicity.

That specific json isn't really obscure. It's the one that is behind the settings screen (user tab)

Quote:

Why do so-called designers think that large areas of blank, white space is a good thing?

Of course, white space is a good thing. Walls of components and or text aren't inviting your users in. Reading on a monitor or tablet isn't the same as on paper. https://uxplanet.org/the-power-of-whitespace-a1a95e45f82b[^]

Quote:

In the good old days the key thing about displaying information on a screen was to provide such information in a compact, readable form

The reason we crammed everything on a screen in 'the good old days' was because of technical limitations, not because it was easy to use or inviting to use. Also, users usually had no alternatives, so how they felt in practice about it didn't matter. We have some of these applications at my current client. They are horrible. As for your example: I agree that that is bad UX. But it's not a good example of why whitespace is bad.

Braindead (or Dead, Alive in some places) is a great horror comedy. And his two earlier movies (meet the Feebles and Bad Taste) were similarly great if you like the genre

:thumbsup: This. This is my main problem with style guides: sometimes technology catches up and the rule isn't needed anymore.

Forogar wrote:

This caused horribly messy code

Nah. Earlier return is both much more readable and more logical too. More readable: you don't have to skip around when following a given execution path, you just follow it to its return. More logical: you don't have to keep anything you don't need anymore in mind. When the function is done with it, it's returned and doesn't add to the cognitive load anymore. The time when single exit point was a 'good practice' was, IIRC, during the structured programming days, as an antidote to goto statements.

Forogar wrote:

introduces an execution statement (return) on the same line as the "if" which is bad coding practice

Huh? why? It's only styling. I would avoid having it under the if without brackets, because that's confusing sometimes, but on the same line? No problems.

This is just a tooling problem. When writing Javascript, you always use a linter. (Even when writing Typescript, you can use Tslint) Also: don't use var anymore, use const or let. And use a transpiler if you need to support old IE versions.

You know, even in the first century AD, there where people that lived longer than 20 years. So a single person living through 55 - 66 -77 - 88 -99 - 101- 111 would not be so hard to imagine. I don't think they numbered their years like that, though, so they might not have known how special they were.

Well, when you add the 3 versions of windows, it's still the biggest group. But it's far from the monopoly it once had. And that's for all developers, not just web devs, who have a bigger non-windows bias.

It's just starting. They still have a long way to go.

Razor is nice, when you're using C# (or VB) as your backend language. But, nowadays, a lot of backend development is done in Node (JS) or in one of the JVM languages. And there are still a lot of Python (django), Ruby (Rails) and php sites too. Also, I don't think razor supports GraphQL, which might just be the next step for backend protocol. When I go to angular conferences here in Europe, I estimate that slightly more than 50% is on Mac. When I see pictures from the states, it's more like 80%

The current state of JS is that it's in flux. Very much so. There are historical reasons for that. But most of those things don't matter for your daily work. They are set-and-forget things. Why I’m Thankful for JS Fatigue. I know you’re sick of those words, but this is different.[^]

Why not asp.mvc? Well, basically because of Razor. It's not a standard. And the fact that it's still windows only, while a lot of web development is done on Linux and Mac.