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.

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.

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.

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.

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.

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 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.)

give me a job or im dead how about that hill

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.

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.

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

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

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.)

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.

Modern PLCs are indistinguishable from IPCs with an RTOS and there's no reason I shouldn't be able to use a proper language for them - with a stdlib and external library support. But manufacturers defined the term and have the industry hostage so you have to buy semi functional libraries and can't use git, unit testing or other automation.

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.

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.

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

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.

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.

Do not power law fit your process data for predictive models. No. Stop. Put the keyboard down. Your model will almost certainly fail to extrapolate beyond the training range. Instead, think for at least two seconds about the chemistry and the process, maybe review your kinetics textbook, and only then may you fit to a physics-based model for which you will determine proper statistical significance. Poor fit? Too bad, revise your assumptions or reconsider whether your "data" are really just noise.

Always run qNMR with an internal standard if you are using it to determine purity. And, as a corollary, do not ignore unidentified peaks. Yes, even if it "has always been that way".

DOE models almost certainly tell you less than you think they do, especially when cross-terms are involved, or when the effects are categorical, or when running a fractional factorial design...

There is no goddamn reason to continue to use magneto ignition in aircraft engines. I've been a Rotax authorized service technician for 13 years, I have never seen the digital CDI installed on a Rotax 900 series engine fail in any way, and you've still got two. Honestly I believe a CDI module is more reliable and less prone to failure than a mechanical magneto. The only reason why we're still using pre-WWII technology in modern production aircraft engines is societal rot.

AI is a fad and when it collapses, it's going to do more damage than any percieved good it's had to date.

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.

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

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.

Software engineering: Don't script stuff! Seriously, just stop, it's a huge waste of everybody's time. I don't fucking care if you think mygitwrapper.sh is the bomb. I want you to know your git commands by heart or just learn to use the damn history on your terminal.

Scripting is only allowed if it's part of the project's infrastructure. Stop faffing about.

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!"

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

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.

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.