A principle is something you follow blindly, something that doesn't need a judgement call, and these do exist. Stuff like "Don't use goto", "Structure your code well", "No compiler warnings" and so on.
Something like the Liskov substitution principle.
That's why modern guidelines and styleguides separate stuff into "must" and "should", and a principle is always a must.
Startups are most often not ethical either. They are often run by a wannabe dictator who does everything that benefits them, especially squeezing the employees while underpaying.
Mid-size companies usually don't have enough money to act ethical when it comes down to it.
Large size corporations only got there by not working ethically.
I worked at a small network monitoring startup. We sold devices that network operators could use to monitor their services, find problems, fix issues, that kind of stuff.
After a few years there I learned what network operators actually do with our tools: They log everything the customers do, create motion profiles, log your text messages and internet traffic and sell all that on to advertisers (it's in your phone contract somewhere burried deep in the fine print). Oh, and apparently the company also sold devices to the egyptian secret service to squash the opposition, and to a few other secret services.
So I left from there and joined a mid-sized automation tool manufacturer that makes a platform that is used to e.g. automate a theme park or to automate updates and stuff for a large retailer. Directly when I joined, the company was bought up by a huge corporation that jacked up the prices, fired a large part of the employees and squeezed everyone for money.
Then I switched to a company that makes tools to manage logistics. During the hireing process they talked about green transformation, democratization, automation, stuff like that. Turns out they use these tools to squeeze truck drivers into working for as little money as possible.
About a year ago I switched to work in the IT of a large and old retailer. You know, a company that's part of the backbone of the nation's food supply. Job security, a somewhat ethical type of business, doing something good that helps people. Well, turns out that I'm working on the marketing app and the whole point is manipulating people into spending more money for less using dark patterns.
There is no such thing as an ethical IT job that pays the bills. I purposely avoided US businesses, FAANG, gambling, health insurance and all the stuff you mentioned, and I tried to vet potential work places for ethics before joining and still I always ended with non-ethical crap because ethical IT jobs don't exist.
So I spend my free time to make open source hardware. I made a phone keyboard attachment that I know is used by at least one blind person, and currently I am making a physiotherapy game console for chronically ill kids to make their daily physiotherapy experience more interesting.
There's different types of qualifiers that you can put before words. Gramatically they work the same, but they are different.
"Rotten apples" talks about a subset of apples because being rotten is an obvious, clearly defined state and it's clear to everyone that not all apples are rotten.
When I see someone ordering chopped liver and I say "Uhg, gross liver", that's something different. It's totally possible that a person thinks liver as food in general is gross. Now it's a statement that describes all instances of liver and not just this specific plate of liver.
Toxic masculinity is originally meant as the first category: a qualifier for a subcategory of masculinity. But it's easily understood as the second category: A general description.
That issue is not helped by the fact that the definition is so loose that it's almost inexistent, plus it's frequently used as a general complaint/offense towards literally everything a man might do that this specific woman doesn't like.
And to tie this back to the beginning: it's a fighting term used to attack and divide and not to actually improve things.
I do agree with you about the "one-genderedness" of these terms. To be fair, the opposite does exist too (e.g. "hysteria"), but these terms are mostly outdated, are falling out of use and aren't actively pushed by a current ideology.
(And in regards to "manspreading": the actual issue at hand is that public spaces and especially public transport aren't designed with male proportions in mind. It's rather unsurprising that a petit woman fits into a tiny public transport seat while a large man doesn't. The actual outrage should be with public transport companies not desigining their seats wide enough to fit people, but instead we see fatshaming and terms like "manspreading" to shame people with bigger bodies.)
Ideologues won't see the obvious flaws in their logic no matter how blatant you make them.
That is certainly true, especially for people who are in fighting mode, and nowadays that seems to be everyone constantly.
A FE dev usually has JS/TS, (S)CSS, bash (for tooling scripting), often some kind of templating language, sometimes a separate language for tests (e.g. Java/Python+Selenium).
A BE dev stack that I've had at a few jobs so far: Java + Kotlin as the main dev languages, Groovy+Spock for tests, a templating language for emails, bash for tooling scripting, that abysmal templating language that helm charts use, SQL, Elastic, plus a few random single-purpose languages you need for some random tool in the stack.
If you do full-stack, add both together. And then add languages you need for hobby work.
On a regular day I easily hit half a dozen languages at least briefly. Maybe not as a junior dev, but after a few years in the industry, that's not uncommon.
Unless of course you are a C# or Swift dev, then it's totally possible to stay within your singular language-specific bubble for your whole carreer.
Tbh, that a good language can be used in a context doesn't mean it's a good choice.
Java, Python, C++, ... can run in WASM and thus in a browser, but if you need anything, all examples, all libraries and everything else will be in JS/TS. Pretty much any language in existence is better than JS/TS, but hardly any language is better for browser scripting.
So for a language to really make sense to be used in a context, you need all the supporting stuff for that too.
Compared with any modern codebase that's still tiny.
From what I can see Rollercoaster Tycoon was hand-written by a single person, so it by definition cannot be huge.
Also, the code base will likely be pretty small. If something's made to be delivered on punch cards and run on devices that measure their memory in KB or maybe MB, it's not going to be a ton of code. Even if it's pure assembly, it's going to be easier than a huge automatically generated codebase.
I think it really depends. If you do embedded/microcontroller stuff, C/C++ is often the only alternative. That's why I use C/C++ at least.
But I think any serious programmer uses half a dozen languages on a daily basis anyway.
On the other hand, women's media is also full of that stuff. Maybe not Schwarzenegger style extreme bodybuilding, but look at a women's magazine or the covers of romantic fiction books made for women. Both men and women in these types of media are overly fit and overly sexualized too.
I don't think it's specifically a gendered thing that there are people who like to look at that kind of stuff and people who reject it.
If comics were written for women they wouldn’t resemble any of this bullshit.
The person before you posted pictures of comics written for women that contain this bullshit. It's an exact answer to your statement. How is this "pretty far afaild from the topic"?
Did you forget your claim or the topic we were talking about?
Did you forget what you claimed?
If comics were written for women they wouldn’t resemble any of this bullshit.
Media created for women contains exactly this kind of bullshit, so why would comics written for women be an exception?
In fact, comics written for women contain exactly this kind of bullshit.
Have you ever seen the inside of a romantic fiction book written for women? They are just as full of this kind of bullshit, just with a lot more overt sex.
A bit late to the party, but just in case someone stumbles over this:
Check the extruder spring tension. I've seen that problem on my machine and on the machines of a few friends of mine before and it's hardly ever mentioned.
If the spring has too much tension, the gears squeeze the filament, cutting deep groves into it and creating a ton of resistance for the extruder motor. This leads to very inconsistent extrusion and can cause blockages. It can also lead to the surface of the filament being ground away, which could cause the filament to get stuck and not move, and the ground filament can clog the teeth of the extruder, which means it has less friction on the filament and can also lead to inconsistent extrusion.
If the spring has too little tension the gears cannot bite into the filament and instead tend to slip, especially in high-pressure situations, e.g. when using fast printing speeds or low hotend temperatures.
Lastly, check the extruder gears for wear themselves. Filled filament (e.g. wood filament, glow-in-the-dark filament, metal-filled filament, CF filament) can wear out the gears themselves, especially when coupled with too high extruder spring tension. Worn out gears can also lead to slips and thus inconsistent extrusion, especially when printing fast or low temperature.
Yeah, that's fair. Tbh, I'm not solid on which terms to use and I'm totally open to better suggestions. "splaining" does make sense. It fits the categories we talked about and I think it's still quite intuitive to grasp what's the difference between "explaining" and "splaining".
One thing that's kinda difficult to avoid though is people misusing these words to defend against situations where no defence is necessary.
I've seen the same thing happen with "mansplaining" before, where a new female hire would tell an experienced manager to not "mansplain" an important concept to her, so he stops explaining and she runs head-first into the problem he tried to warn her of.
In certain contexts (especially safety-related or other critical stuff) it's better to err on the side of explaining things the recipient might already know instead on the side of missing important things. For example, telling a flight attendant on a plane that they don't need to "splain" where the exits are would be kinda stupid.
To stay with the aviation example: Pilots are trained to call out and confirm everything they do. It would be quite bad if one pilot told the other one to shut up because obviously they already noticed that the other one changed the flap settings or something like that.
(But obviously all of that is besides the point which was: We need better words, and "splaining" is a totally valid replacement for "mansplaining")
And are pronounced almost the same way.
The one good principle. And I now I can see why: it was invented by people who knew their maths — type theory in this case. In lay terms it’s simple: anything you can observe about the base class, remains true of its derived classes. That way you can pretend instances of the derived classes are also instances of the base class, without any nasty surprise.
On the one hand, duh: that’s just subtyping. But on the other hand, very few type systems enforce it — Java and C++ do not. That makes it very easy to make a dumb mistake like overriding a stable sort() method, and make it not stable for the derived class.
Javas immutable lists are an example of that right in the standard library.
The super type List has mutability. When you call any of these methods in the immutable list, you get an exception.
So if you have an arbitrary List object, you have no idea whether calling any method that mutates the object will work or not.
And this is doubly bad with the linter demanding you use Stream.toList() (which returns an immutable list) instead of Stream.collect(Collectors.toList()) (which returns a mutable list).
Horrible, dumb design.
Not sure if SOLID was meant as "should". At least when I was at university it certainly was taught as "must" and a lot of coworkers of mine also treated it as "must".
But anyway, it's super old stuff. SOLID was created in 2000. That's a quarter century ago and a ton has changed since.
Even Clean Code will be 17 years old this year. It's time to revisit all that, and most of it is just not nearly as good as it looks.