I agree with everything you’re saying, but even speaking specialist to specialist, or say to a group of specialist colleagues who might not be working on exactly what you’re working on, you still often simplify away the technical parts that aren’t relevant to the specific conversation you’re having, and use specific language on the parts that are, because that inherently helps the listener to focus on the technical aspects you want them to focus on.

If you’re communicating with another scientist about the actual work you’re doing then sure there are times when you need to be specific.

If you’re publishing official documentation on something or writing contracts, then yes, you also need to be extremely speciific.

But if you’re just providing a description of your work to a non-specialist then no, there’s always a way of simplifying it for the appropriate context. Same thing goes for most of specialist to specialist communication. There are specific sentences and times you use the precision to distinguish between two different things, but if you insist on always speaking in maximum precision and accuracy then it is simply poor communication skills where you are over providing unnecessary detail that detracts from the actual point you’re trying to convey.

Their literal entire first paragraph is about scientists doing it.

No, I’m talking about engineers and scientists communicating with project managers, designers, lawyers, business people, and the many many other people who work in the same industry but do not have technical backgrounds.

It is for a white collar job where most people have degrees.

Eh I don’t really agree, depending on how simple you’re talking. Bags within bags, or dumbing things down to a grade school level, then sure, there are topics that can’t be described succinctly.

But if you’re talking about simplifying things down to the point that anyone who took a bit of undergrad math/science can understand, then pretty much everything can be described in simple and easy to understand ways.

Don’t get me wrong, I’ve seen many people at the top who can’t, but in every case, it’s not because of the topics’ inherent complexity, but either because they don’t actually understand the topics as well as they may seem, or because they lack the social skills (or time / effort / setting) to properly analogize and adjust for the listener.

You’re literally just describing this meme.

When you don’t know shit you think it should be simpler, when you slightly understand it then you end up using technical terms because you know those terms apply and aren’t confident enough to replace them, and then once you know enough you get confident just describing everything as bags within bags.

Code signing should be done though.

You can disagree with Apple’s approach that maintains them as the only signing authority, but, at a fundamental level, code signing is the only way to distribute an executable and have the user be able to trust who authored it (and thus what’s in it).

The SOLID principles are just that principles, not rules.

As someone else said, you should always write your code to be maintainable first and foremost, and extra code is extra maintenance work, so should only really be done when necessary. Don’t write an abstract interface unless multiple things actually need to implement it, and don’t refactor common logic until you’ve repeated it ~3 times.

The DRY principle is probably the most overused one because engineers default to thinking that less code = less work and it’s a fun logic puzzle to figure out common logic and abstract it, but the reality is that many of these abstractions in reality create more coupling and make your code less readable. Dan Abramov (creator of React) has a really good presentation on it that’s worth watching in its entirety.

But I will say that sometimes these irritations are truly just language issues at the end of the day. Java was written in an era where the object oriented paradigm was king, whereas these days functional programming is often described as what OO programming looks like if you actually follow all the SOLID principles and Java still isn’t a first class functional language and probably never will be because it has to maintain backwards compatibility. This is partly why more modern Java compatible languages like Kotlin were created.

A language like C# on the other hand is more flexible since it’s designed to be cross paradigm and support first class functions and objects, and a language like JavaScript is so flexible that it has evolved and changed to suit whatever is needed of it.

Flexibility comes with a bit of a cost, but I think a lot of corporate engineers are over fearful of new things and change and don’t properly value the hidden costs of rigidity. To give it a structural engineering analogy: a rigid tree will snap in the wind, a flexible tree will bend.

Honestly, it’s fucking exhausting.

Cynicism is not cleverness and it is not informedness, it’s just reactionary bullshit that makes you sound edgy online.

Again, no, because that’s not a resolution, that’s a pixel density at a set distance.

While I get your point, this is an article, not a whitepaper.

If someone says something that is obviously not a thing, like ‘the perfect resolution of an analog painting’, then it means the author probably didn’t actually understand what they read and so you shouldn’t trust their interpretation of the underlying news.

That’s not a resolution, that’s a pixel density at a set distance. It’s also arbitrary on Apple’s end, not actually a meaningful universal measurement.

To demonstrate the efficacy of the tiny screen, the researchers reproduced The Kiss, a famous artwork painted by Gustav Klimt. The image was shown in perfect resolution on the screen, which at approximately 1.4 x 1.9 mm was 1/4000th that of a standard smartphone.

This makes me doubt the author of the article’s credibility. What exactly is the “perfect resolution” of a hand painted piece of art?

The underlying paper is published in Nature which adds more credibility to its significance but an article that presents none of the limitations, drawbacks, or broader industry context that might hold something like this back isn’t adding much. What was the colour depth? Refresh rate? Is it thrown if the external light shifts and changes? How many children have to be sacrificed to the machine gods to produce it? Etc. etc.

deleted by creator

+++ I cannot stress this enough.

Programmers tend to get over obsessive about DRY code because it seems like it should be easier to maintain fewer functions and writing less code should be easier right? But it tends to ignore the actual subtle differences between the different consumers of that abstraction, and that leads to massively branching functions that couple unrelated parts of the codebase together. These then become impossible to read and change without worrying about breaking something else.

When I was at Thoughtworks (Martin Fowler’s current company), we were also taught the rule of three for refactoring, and were taught to always optimize your code for readability and maintainability first and foremost. Refactoring and improving easy to read/maintain code is always relatively trivial, by nature of it being clear, concise and decoupled, and that can be done once you have a reason to do so (i.e. performance issue etc), so there’s no point over optimizing for anything else up front.

This talk from Dan Abramov (one of the lead devs of React) does a really really good job explaining some of these issues and is entirely worth the full watch/listen (do it on company time, it’s professional development):

https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebasets

Huh, TIL, I didn’t realize they kept the gateway servers in Python.

I literally do that professionally, and I’m telling you that brackets are inarguably better.

You are used to whitespace; I have literally spent months refactoring and upgrading a react frontend and a python backend and am telling you that brackets are a single character and far more predictable, and then your IDE / Linter / Formatter can reliably use them to fill in the perfect indentation and whitespace.

My first professional language was Python, but I have since tried a half dozen others and would never choose to go back to a whitespace based language unless there was a good reason.

No, it’s not. It was rewritten in Facebook’s version of PHP when they bought them.

Or you know, TypeScript, Go, C#, Java, Swift, etc. etc.

Python isn’t great at anything except for having a lot of data science libraries already written for it.