For any non-trivial software project, spending time on code quality and a good architecture is worth the effort. Every hour I spend on that saves me two hours when I have to fix bugs or implement new features.

Years ago I had to review code from a different team and it was an absolute mess. They (and our boss) defended it with "That way they can get it done faster. We can clean up after the initial release". Guess what, that initial release took over three years instead of the planned six months.

I work in disability support. People in my industry fail to understand the distinction between duty of care and dignity of risk. When I go home after work I can choose to drink alcohol or smoke cigarettes. My clients who are disabled are able to make decisions including smoking and drinking, not to mention smoking pot or watching porn. It is disgusting to intrude on someone else's life and shit your own values all over them.

I don't drink or smoke but that is me. My clients can drink or smoke or whatever based on their own choices and my job is not to force them to do things I want them to do so they meet my moral standards.

My job is to support them in deciding what matters to them and then help them figure out how to achieve those goals and to support them in enacting that plan.

The moment I start deciding what is best for them is the moment I have dehumanised them and made them lesser. I see it all the time but my responsibility is to treat my clients as human beings first and foremost. If a support worker treated me the way some of my clients have been treated there would have been a stabbing.

Not strictly technical, although organizational science might be seen as a technical field on it's own.

Regularly rotating people between teams is desirable.

Many companies just assign you in a team and that's where you're stuck forever unti you quit. In slightly better places they will try to find a "perfect match" for you.

What I'm saying is that moving people around is even better:
You spread institutional knowledge around.
You keep everyone engaged. Typically on a new job you learn for the first few months, then you have a peak of productivity when you have all the new ideas. After some 2 years you either reach a plateau or complacency.

Not everything needs to be deployed to a cluster of georedundant K8s nodes, not everything needs to be a container, Docker is not always necessary. Just run the damn binary. Just build a .deb package.

(Disclaimer: yes, all those things can have merit and reasons. Doesn't mean you have to shove them into everything.)

Cleaning, organizing, and documentation are high priorities.

Every job I've worked at has had mountains of "The last guy didn't..." that you walk into and it's always a huge pain in the ass. They didn't throw out useless things, they didn't bother consolidating storage rooms, and they never wrote down any of their processes, procedures, or rationals. I've spent many hours at each job just detangling messes because the other person was to busy or thought it unimportant and didn't bother to spend the time.

Make it a priority, allocate the time, and think long-term.

This is a non technical hill but it is applicable to my technical career. The hill is that REMOTE WORK WORKS. I am so frustrated that so many businesses are going back to hybrid or full RTO.

React sucks. I'm sorry, I know it's popular, but for the love of glob, can we not use a technology that results in just as much goddamn spaghetti code as its closest ancestor, jQuery? (That last bit is inflammatory. I don't care. React components have no opinionated structure imposed on them, just like jQuery.)

Is there anybody on Lemmy that isn't a software engineer of some description? No? Anyone?

Weird i haven't seen this one yet: the cloud is just someone else's computers.

They should stop teaching the OSI model and stick to the DOD TCP/IP model

In the world of computer networking you are constantly hammered about the OSI model and how computer communication fits into that model. But outside of specific legacy uses, nothing runs the OSI suite, everything runs TCP/IP.

I fucking hate AI in HR/hiring. I try so hard not to spread my personal data to LLMs/AI ghuls and the moment I apply for a job I need to survive I have to accept that the HR department's AI sorting hat now knows a shit ton about me. I just hope these are closed systems. if anyone from a HR department knows more, please let me know

Transparency + blur + drop shadow is peak UI design and should remain so for the foreseeable future. It provides depth, which adds visual context. Elements onscreen should not appear flat; our human predator brains are hardwired and physiologically evolved to parse depth information.

the hill i am willing to die on is: FUCK AI. I'll be dead before I let it write a single line of code.

Okay, I'm pretty late to the party, but here we go. My field is illustration and art, and especially color theory is something that a lot too often is teached plainly wrong. I think it was in the 1950s when Johannes Itten introduced his book on colortheory. In this book, he states that there are three "Grundfarben" (base colors) that will mix into every color. He explained this model with a color ring that you will still find almost anywhere. This model and the fact that there are three Grundfarben is wrong.

There are different angles from where you can approach color mixing in art, and it always depends on what you want to do. When we speak about colors, we actually mean the experience that we humans have, when light rays fall into our eyes. So, it's actually a perceptual phenomenon, which means it is actually something that has small statistical differences from individual to individual. For example, a greenish blue might be a little bit more green for one person or a little more blue for the other.

Every color, however, has its opposite color. Everybody can test this. Look into a red (not too bright) light for some time and then onto a white wall. The color you will see is the opposite. They will cancel each other out and become white / neutral.

Ittens colormodel, however, is not based in perception. In this model yellow is opposed to violet, which might mix to a neutral color with pigments but not with lightrays. But even that doesn't work a lot of times. I mean, even his book is printed in six colors, even though his three basecolors are supposedly enough to print every color..

In history lot of colormodels have been less correct course. What is so infuriating is that in Ittens case, he just plainly ignored the correct colortheory that already existed (by Albert Henry Munsell) and created his own with whatever rules that he believes are correct.

Even today, this model and rules are teached at art schools and you can see his color circle plastered all over the internet.

Tldr: Johannes Ittens colormodel is wrong, even though it's almost everywhere.

(Added tldr)

Cognitive behavioral therapy/dialectical behavioral therapy are not the universal cure for everything and they need to stop being treated as such

A plain text physical password notebook is actually more secure than most people think. It's also boomer-compatible. My folks understand that things like their social security cards need to be kept secure and out of public view. The same can be applied to a physical password notebook. I also think a notebook can be superior to the other ways of generating and storing passwords, at least in some cases.

1. use the same password for everything: obviously insecure.
2. Use complex unique passwords for everything: You'll never remember them. If complex passwords are imposed as a technical control, even worse if you have to change them often, you'll just end up with passwords on post-its.
3. use a password manager: You're putting all your eggs in one basket. If the manager gets breached there goes everything.

Any tolerance on a part less than +/- 0.001 isn't real. If I can change the size of the part enough to blow it out of tolerance by putting my hand on it and putting some of my body temperature into it then it's just not real.

Workplace safety is quickly turning from a factual and risk-based field into a vibes-based field, and that's a bad thing for 95% of real-world risks.

To elaborate a bit: the current trend in safety is "Safety Culture", meaning "Getting Betty to tell Alex that they should actually wear that helmet and not just carry it around". And at that level, that's a great thing. On-the-ground compliance is one of the hardest things to actually implement.

But that training is taking the place of actual, risk-based training. It's all well and good that you feel comfortable talking about safety, but if you don't know what you're talking about, you're not actually making things more safe. This is also a form of training that's completely useless at any level above the worksite. You can't make management-level choices based on feeling comfortable, you need to actually know some stuff.

I've run into numerous issues where people feel safe when they're not, and feel at risk when they're safe. Safety Culture is absolutely important, and feeling safe to talk about your problems is a good thing. But that should come AFTER being actually able to spot problems.

Dynamic typing sucks.

Type corrosion is fine, structural typing is fine, but the compiler should be able to tell if types are compatible at compile time.

IT restrictions should be much more conservatively applied (at least in comparison to what's happening in my neck of the woods). Hear me out.

Of course, if you restrict something in IT, you have a theoretical increase in security. You're reducing the attack surface in some way, shape or form. Usually at the cost of productivity. But also at the cost of the the employees' good will towards the IT department and IT security. Which is an important aspect, since you will never be able to eliminate your attack surface, and employees with good will can be your eyes and ears on the ground.

At my company I've watched restrictions getting tighter and tighter. And yes, it's reduced the attack surface in theory, but holy shit has it ruined my colleagues' attitude towards IT security. "They're constantly finding things to make our job harder." "Honestly, I'm so sick of this shit, let's not bother reporting this, it's not my job anyway." "It will be fine, IT security is taking care of it anyway." "What can go wrong when are computers are so nailed shut?" It didn't used to be this way.

I'm not saying all restrictions are wrong, some definitely do make sense. But many of them have just pissed off my colleagues so much that I worry about their cooperation when shit ends up hitting the fan. "WTF were all these restrictions for that castrated our work then? Fix your shit yourself!"

Professionally: Waterfall release cycle kills innovation, and whoever advocates it should be fired on the spot. MVP releases and small, incremental changes and improvements are the way to go.

Personally: Don't use CSS if tables do what you need. Don't use Javascript for static Web pages. Don't overcomplicate things when building Web sites.

Ebikes are motorbikes, not bycicles.

Not saying they aren't fun or useful at times, but they shouldn't be treated as a bicycles.

I don't care if the motor engages using a button, twist grip, your feet or twitching your nose, it is a motor and exceeds your natural body power.

There are a load of things in IT where using a processor is the wrong choice, and using an FPGA instead would have made a lot of problems a non-issue.

If you don't understand that development, security, and operations are all one job you will constantly make crap and probably point at some other team to make excuses about it, but it will be actually be your fault.

Programs have to run. They have to be able to change to meet needs. Implementing working security measures is one of those needs.

The amount of times I've had to slap devs hands that wanted to just disable security or remind security that just shutting it down is denial of service is crazy. If it can't deploy or is constantly down or uses stupid amount of resources it's also worthless no matter what it looked like for split second you ran on on the dev machine.

The next patch isn't going to fucking fix it if no one that writes patches knows about the damn issue. Work arounds are hidden technical debt and you have to assume that they will fucking break on some update later. If you are not updating because it breaks your unreported workarounds you will get ignored by the devs at some point, and they are right in doing so.

If you depend on something communicate with the team that works on it. We can send a fucking petabyte of info around the world and to the moon and back before some people write a fucking Ticket, email, or even a IM. Look dumb and asking the stupid question rather than being an actual idiot and leaving something broken for the next decade. We're all dumb, it's why we built computers, get over it and just talk to people. If you really struggle with, don't just communicate, try to over communicate, say an obvious thing now and again just to keep the dialogue open and test that you really on the same page.

That's my rant/hill borne from ulcers supporting crappy IT orgs and having to overcome my own shortcomings to actually say something in channels where things can actually change and not just griping in private about it.

Maybe not technical, but teaching is weird.

If people aren't having fun/engaged they're not learning much. People don't care how much you know until they know how much you care. It's so frustrating to come across someone who writes the standards you're supposed to follow and they are the most boring and fake teacher you've experienced.

People are idiots and it's the designers' duty to remove opportunities for an idiot to hurt themselves up and just short of impacting function.

Technisation and standardisation are good for the EMS sector.

The whole "it was better when we could do what we want and back then we had only real calls with sicker people and everything was good" is fucking aweful and hurting the profession.

Look, you fucking volunteer dick, I know you do this for 10 years longer than me (and I do it for 25 now),but unlike you I did it full-time and probably had more shifte in one year than you had in your life. Now my back is fucked because back then there was no "electrohydraulic stretcher", no stair chair, the ventilator was twice as heavy (and could basically nothing), the defibrillator weighted so much we often had to switch carrying it after two floors up.

And we had just as many shit calls,but got actually attacked worse because the shit 2kg radios were shit and had next to zero coverage indoors, and so had cellphones which led to you being unable to even call for backup.

And of course we had longer shifts,needed to work more hours and the whole job market was even more fucked.

"But we didn't need this and that,we looked at the patient". Yeah,go fuck yourself. MUCH more people died or took damage from that. So many things were not seen. And it was all accepted as "yeah, that's how life is".

So fuck everyone in this field and their nostalgia.

If people used a language that actually leverages the strengths of dynamic typing, they wouldn't dislike it so much.

I encourage every programmer to build a Smalltalk program from the ground up while it's running the entire time. It really is a joy

Electric vehicles are not a solution for environmental problems, not now at least, they pollute when building the batteries and, unless nuclear energy is widespread, they will be powered by coal/gas making them pretty polluting. They will be a solution only when we have cleaner energy available.

Bonus: people should stop being lazy and learn to setup a server infrastructure instead of using "the cloud". Your data are safer, you save money and give less power to gargantuan cloud companies.

if you're using modern fabrication techniques, a couple 10uf mlcc capacitors in small packages are just as good as traditional decade capacitors (10uf,1uf,0.1uf) for decoupling in pretty much every situation, and you need to worry about less varieties on your bill of materials