This entry was edited (10 months ago)
in reply to hex

Also, get randomized. If you have anything else, do that instead. Only work on whatever evil thing if you are explicitly asked to prioritize it above everything else. Then, if you're asked for anything after that point, drop the evil thing and take whatever new request. Add several days of delay for "task switching" when asked to come back.

One reason to feign compliance is so that the task doesn't get assigned to someone who might actually do it.

in reply to hex

Schedule meetings to discuss requirements. Assign difficult tasks to known incompetents, or people known to be over-worked. Put every subroutine in its own container linked with the most difficult networking possible. Demand IPv6 for the entire project.
Document nothing. No comments in code, use obscure function and variable names, which you can reuse for different purposes from one routine to the other.
Schedule another meeting where you revisit and question past decisions.
This entry was edited (10 months ago)

hex reshared this.

in reply to okanogen VerminEnemyFromWithin

Did I forget security? It's important! Make sure SELinux is set on Max. Make ip table rules for specific ports from specific ip addresses. If you require certs, make sure they expire every month (or less) and require a difficult process to renew. SSH by key only, which are force rotated every two weeks, and of course only from certain ip addresses.
in reply to hex

No wild cards, and each expires at a different time or day.
Here's another, underprovision EVERYTHING. Especially storage, and then turn off logrotate. Oh the fun when nothing works because it can't write to disc.
If you create logs for your process, make sure they are as useless as possible (oh my God I'm living my own #Sysadmin trauma) also, no dates or times, or if you do, choose one that is different from the system setting (aggghhhhhhh).

hex reshared this.

in reply to okanogen VerminEnemyFromWithin

Even better, make sure some log files save a time in local, one in UTM, and one, NOT AT ALL.
If you ever do have to deliver "Evil Product" these elements will make it almost impossible to use or admin.
Also? These containers. Make some Debian Sid, some Fedora, some Centos, some Ubuntu, if you can cram some process on Windows server, even better. Hopefully scraping input from an Excel spreadsheet with tons of links.
in reply to Travis F W

@travisfw is someone told me half of people above middle management in any major company was trying to tank the company by using this strategy, I'd have a hard time arguing otherwise (both from internal experience and external observations).

This shit is invisible because it's already happening... Only thing is that most of it comes from the top and everyone below mid managers spend at least half their energy trying to fix it.

in reply to hex

I am riffing a bit off this. I actually think both should probably be used together. It can be valuable to push back, and it can be valuable to undermine. Choose your path wisely based on how you read the situation.

sauropods.win/@futurebird/1138…

Edit: and if you boosted mine, you should probably boost this too.


If you work with a database and are asked to alter the table structure to comply in advance for citizenship or gender categorizations it's really important to NOT do it.

"The governor is concerned about all this stuff they want us to update our record keeping so we store both gender AND biological sex."

"We need fields to store the country of origin of people's parents."

If you don't have the power to rebuff this yourself, ask for help. At minimum ask for help online anonymously.

This entry was edited (10 months ago)

BadWoof reshared this.

in reply to hex

1. Get good at SQL 2. Find out how long backups are kept for 3. Decouple the data change from the code change 4. Push the data change first, and have it corrupt the new fields are needed (maybe by setting defaults or polluting other parts of the records). 5. Bundle the code change with unrelated changes, and keep having the other changes fail QA 6. Wait until the uncorrupted backups have been purged 7. Push code change.

hex reshared this.

in reply to swachter

“These specs aren’t clear. I need to see full wireframes with every corner case covered before I can possibly start to implement this.”

Parcel out your corner cases into as many distinct inquiries as possible. Stretch them out as long as possible. Do you really need to send that email or slack to get clarification right now? It can probably wait an hour. Or a day.

Does your team communicate on slack? Not you! You like email. Does your team communicate on email? Not you! You like synchronous meetings with every possible stakeholder. EVERY stakeholder.

Ooh, better spend some more time on that documentation.

Doesn’t this code need a refactor? It probably needs a refactor.

Have we considered the security and legal implications of this? We should probably get sign off from Security and Legal on these specs before we start work.

in reply to swachter

Sensemaking variable names? No.

Variables that do the opposite of what the name implies? Yes.

Many variable names that are almost indistinguishable from each other? Yes.

Variable names that use “1” and “l” and “0” and “O” as often and as inconsistently as possible? Yes.

Code reviews should take forever. And not find all the problems. If they do find all the problems, make more problems when you fix those problems. Or don’t fix them all and make it go through another round of code review.

This entry was edited (10 months ago)
in reply to Lien Rag

@lienrag

I've never seen a date with the month spelled out as a 3 letter abbreviation in any other context. Because it was from the Coast Guard I assumed that DD-MON-YY was a specialty format designed for saying a date into the radio on a ship with a screaming loud storm going on.

Since it was mixed into a database with other more usual date formats I called it "demon-year".

@Hex

in reply to hex

If not working remotely, it's a health and safety breach if your working conditions do not have working toilet facilities.

Plaster of Paris should never be put down toilets or sinks, it hardens very quickly and causes blockages that can require expensive plumbing. If some amount of it is put down a sink or toilet at the end of a business day on a Friday, there is no doubt that Monday and Tuesday the working conditions would not be fit.

Health and safety is important.

This entry was edited (10 months ago)

hex reshared this.

in reply to I am Jack's Lost 404

@float13 if you are rolling your own crypto, it's important to make sure the code is very obfuscated, otherwise it will be easy for the attacker to understand what it's doing. It should be really hard to even figure out that there's crypto in there. If automated tooling can detect that you're using crypto to give you advice, then it needs to be hidden better.
in reply to hex

@guyjantic alternate view/approach: having the confidence to firmly and politely say “no”, backed up with reasons and evidence, is a career super-power. It only comes with experience, but you go epic level when you unlock it.

Those reasons and evidence can incorporate cost, complexity, security, privacy, organisational reputation, regulations, time to deploy, and many more. Investigate all the reasons and have notes

Then say no

in reply to Gary Parker

@WiteWulf @guyjantic some people absolutely should do this. I think it depends a lot on how much social and political capital you have in an org. If you have enough, then use it. There's a lot of value in other people seeing someone just flat out refuse.

It can inspire others. It can stop such requests in the future. It's great. For a lot of organizations, that can be enough to snap them out of compliance.

Also, some organizations are built to do evil things and anyone who resists that will be filtered out. We need people in those organizations making sure they *can't* do as much evil as they otherwise would. That is also valuable. We all work at different places, and everyone has a place.

in reply to hex

it's definitely a use case that requires foundation-shaking changes to the code base, like switching from oop to functional paradigm, and probably adopting a new coding language that's been around for all of two weeks. (It'll solve so many problems down the road, it's that good!) For reasons, it really is necessary for the compiler to rewrite parts of the code to be compiled, which only make revision history slightly less useful. Important stuff should absolutely be kept in your IDE config and nowhere else. And don't limit yourself to accented latin in variable names: unicode arrows, punctuation, letter-like symbols, etc. belong in class and function names, redundant and mismatched constants, etc. too (sparingly -- you're sane and competent, and this is a legitimate need for Roman numerals).

hex reshared this.

in reply to hex

thanks for this post.
Just all the horrible ideas in here and the sheer creatitvity, I love it!

Especially the date thing, oh boy. youtu.be/-5wpm-gesOY
This should be one of the spots where you should let the requirements be lax. Yes, your solution needs to cover the entire human era, you never know. You will find excellent rabbit holes to spend your time in.

hex reshared this.

Unknown parent

mastodon - Link to source

hex

@IcooIey I'm only comfortable talking about this because I'm no longer in the US, I'm currently on disability, and even if neither of those were true I don't build things that could be used in that way anyway... And honestly, some of the things I used to get asked to do are so absurd I'm not sure I could do more damage by not simply complying anyway, so there's no value in malicious compliance for me.
in reply to hex

There are a few different version of the sabotage manual in PDF linked from this thread too, but in case you want to download an epub, Gutenberg also has it...

gutenberg.org/ebooks/26184

in reply to hex

This entry was edited (10 months ago)

reshared this

in reply to Now at @aj@gts.sadauskas.id.au

in reply to Now at @aj@gts.sadauskas.id.au

This entry was edited (10 months ago)

reshared this

in reply to "Musty Bits" McGee

@arichtman @ajsadauskas
Could be therapeutic to work back through it for the collective good this time?

Taking notes here. I've got the (time-limited, but still) privilege of unemployment as this begins, so my food money isn't entirely dependent on needing to comply with the software industry bullshit that will no doubt kneecap Canada as well. But there's room for all of us to find at least a small digital or procedural spanner for the works.

in reply to hex

I think the best way to do this is with how tickets for the tasks as created.

1.Give the tickets you make the lowest priority possible in Jira.

2. Label all of the tickets as Technical Debt (they will never get done)

3. Know your Kanban Boards and set the tickets to trickle to the bottom.

4. Try to have the ticket target the most arcane and oldest/outdated micro service your company has. You know, the one everyone is too afraid to even look at.

in reply to hex

I like the energy... but I do have one point that I think could be done better/ should be done differently

Step 01 is never "agree"

Step One is always a dismissive, half assed "I heard you and I'm already creating a delay" type of malicious compliance 😉

"Oh... ok?"... can you send me something on that detailing what they're looking for?... Thanks!"

THEN... move on to "I forgot about it"

and also... start looking for your next gig while making this go as poorly as possible for whatever 'toxic enabler' bullshit the people who wanted this are trying to pull

hex reshared this.

in reply to hex

My simple favourite is horribly misnamed variables. Store the debit in a variable called "credit", altitude in one called "eastness", the user name in "isThisBob", the password in "isloggedIn". If you don't have control of the DB schema, create aliases on your SQL queries to match.

Another fun one would be more useful if it wasn't too obvious in the code, but it's great to stick in a library:

if (rand(0, 1000000) == 1) {
someresult = someresult * 1.02
}

in reply to hex

Also, no-one ever gets fired for creating incomprehensible database schemas.

Always make sure to use the least useful key for each table and use many, many tables. Make sure column names are nearly the same in different tables, but do wildly different things. Be creative about data types. Numbers can easily be stored as strings, just saying.

Create lots of documentation for all of this mess, but make sure to spread it out. Some google docs, some wikis, some text files, all 90% complete.

hex reshared this.

in reply to hex

also and before doing anything else that could be an implementation, ask for UX to give their input. Even better ask for UX research, ask how will the new thing impact the user experience, how will they interact with it. Ask to have it explained, documented, mock-up, in user flows etc. Try to make friends with the UX and UX Research teams and let them know that they want you to implement a feature that isn’t designed, with no user consideration.
in reply to hex

Im UseNet, dem ersten öffentlichen Kommunikationsforum im Internet, galt die "goldene Regel": Alles, was länger als ein Bildschirm ist, wird nicht gelesen.Das waren damals 40x80=320 Zeichen.

Wenn du auf Mastodon postest, solltest du dies bedenken.

Ich habe deinen Post versucht zu lesen, aber es ist ein Schwall von Wörtern, und die anscheinend wichtige Information ist in einer Abkürzung versteckt.

Also habe ich nichts verstanden.

Bitte fasse dich kurz, konkret und verständlich.

This entry was edited (10 months ago)
in reply to Bredroll

@Bredroll you know, a lot of people say "agile" and they don't know what it means. If you want to do agile correctly, you really need to make sure every member of the team is trained. There's a lot of terminology, and you really need to use is totally correctly so no one is confused. If people don't know what it means, they really need training.

Some people pick and choose between bits of agile and bits of XP. That really means you need to know both, inside and out, in order to keep doing waterfall with a Kanban board correctly.

in reply to AniMerrill, a.k.a. Ethan Merrill

@AniMerrill there are open LLMs and closed ones. The open ones you can run locally and you can know how they work (given enough knowledge). The closed ones are black boxes, so you can never know or trust what they're doing.

Some LLMs, like Gemini, seem to isolate sessions so they couldn't leak data to other sessions. But there's no real way of knowing unless you're reverse engineering them. It's valuable to use human feedback to improve responses, so there are incentives to do things that would leak data. And, of course, all questions are monitored and, I assume, given directly to law enforcement if anything unusual is detected.

Basically, don't put anything into an LLM that you don't want to be made public.

in reply to okanogen VerminEnemyFromWithin

@Okanogen DOGE is a bit different though. Only congress has the legal authority to create something like DOGE, so all operations are illegal. DOGE is a coup with no legal backing. Even the illusion of compliance is bad.

The only correct response to DOGE is"fuck you, make me!" Make them find someone with a gun, then follow this advice *only* if they can.