Clever framing of the authors own biases. I'd argue that for at least some of these, the opposite behaviour would be the true sabotage.
Simple sabotage for software (2023)
11–20 of 83 posts
Re: Simple sabotage for software (2023)
#12The 'Hiring' section needs an update: ask Leetcode hard-level problems, and demand to witness enlightenment and an optimized solution in under 30 minutes. Uncertainty and doubt shall not be tolerated.
Re: Simple sabotage for software (2023)
#13The major thing that springs to mind here is I've never seen a compelling reason to believe that the original CIA suggestions actually worked. In my experience workers like that exist naturally and organisations are great at just sidelining them. I think in that section the CIA was just writing a listicle that sounded good [0]. The way to cripple a company is to get bad people promoted into management and have them o…
You can do far far worse than naive optimizing for profit. Optimizing for *REPORTED* profit.
People learn very quickly to manipulate the reporting, modeling, and accounting.
Just less than two decades ago we had the entire financial system lending massive amounts of money to the worst possible borrowers and REPORTING massive profits.
Re: Simple sabotage for software (2023)
#14Mandatory RTO, tech teams first.
Re: Simple sabotage for software (2023)
#15About 60% of that list checks out for a place I worked at.
Re: Simple sabotage for software (2023)
#16It's cute, but in quite a few industries, a lot of these are driven by outside e.g regulatory forces that have proven to be necessary ("written in blood" etc), so the better question to ask is how many of these process encumberments can be streamlined e.g with paved road approaches.
Security and compliance benefit heavily from this approach, and I'm sure it can be extended elsewhere as well (architecture reviews etc).
Re: Simple sabotage for software (2023)
#17Clever framing of the authors own biases. I'd argue that for at least some of these, the opposite behaviour would be the true sabotage.
Let’s make a committee to discuss! we need all the key players involved, so let’s invite all of dev and QA, ~60 people for an hour long discussion?
Re: Simple sabotage for software (2023)
#18> Make sure production environment differs from developer environments in as many ways as possible.
I feel like this, in some capacity, is borderline inevitable in the modern architectures with a bunch of external services, or at the very least will 100% require that your devs are connected to the Internet all the time to be able to do anything, vs systems that are 100% self hostable.
Or even just running a complex Kubernetes cluster with a service mesh and other solutions on the test/staging/prod infra vs loosely mapping to more lightweight options locally, unless you have a super beefy setup. And even then, if everything is split into multiple separate services far enough, you just won't be able to run everything locally, meaning that you need to use some of the components from shared dev environments which will inevitably lead to stepping on each other's heels.
Once you go past something like Docker Compose for local environments, things can go sour.
Re: Simple sabotage for software (2023)
#19In a web context, I was thinking this when I checked out the web site of the Electronic Frontier Foundation (EFF) [1]; why would they use a thin, small typeface with light gray color on a bright/white background which makes the text less appealing to read? It must be subtle sabotage from within!
(Some may counter this with Hanlon's razor [2]; Never attribute to malice that which is adequately explained by stupidity.)
Re: Simple sabotage for software (2023)
#20I left Microsoft a year ago because the group I worked for checked pretty much every one of the items on this list. It was wildly unproductive.