Ask Lemmy

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.

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.

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

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.

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

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

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.

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

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

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.

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.

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

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

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.

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.

Take the time to do it right the first time but also don't waste time if it doesn't add value.

Having a process is great but if the process exceeds the value then the process not only harms profit margins but also erodes morale. If the reason a process exists is to counter bad behavior then it's an employee problem not a process problem.

Open office floorplans are a terrible idea!

Work from home shouldn't be considered a given based on the job tasks but a privilege and benefit extended to those employees that have shown the discipline and reliability to work from home. But the in office requirement shouldn't be forced on everyone just to satisfy a "butts in seat policy" or a managers insecurity.

Your favorite AI enabled LLM does a very, very good job of simulating language tests based on previous tests and there's no reason at all not to use it to study and prepare.

Abilify is a beautiful long term maintenance med but wholly inappropriate for an acutely agitated and combative patient.

Snapshot tests suck. That's a test that stores the dom (or I guess any json serializable thing) and when you run the test again, compares what you have now to what it has saved.

No one is going to carefully examine a 300 line json diff. They're just going to say "well I updated the file so it makes sense it changed" and slap the update button.

Theoretically you could only feed it very small things, but if that's the case you could also just assert on what's important yourself.

Snapshots don't encode intent. They make everything look just as important as everything else. And then hotshot developers think they have 100% coverage

I hate Rust's syntax.