51–60 of 91 posts
Kind advice to everyone willing to share their write ups: avoid Medium. I can’t read the article because of the signup wall. It is cheap and easy to set up a blog on your own custom domain.
In situations like these, Bypass Paywalls extension for Firefox comes really handy! Especially in combination with uMatrix and uBlock Origin.
Kind advice to everyone willing to share their write ups: avoid Medium. I can’t read the article because of the signup wall. It is cheap and easy to set up a blog on your own custom domain.
> It is cheap and easy to set up a blog on your own custom domain True. But you can defeat all of Medium's annoying features by just disabling JavaScript.
"You can create a 10-minute email" you say. True, and a lot of people do while also a lot of people simply don't want the book that much.
Kind advice to everyone willing to share their write ups: avoid Medium. I can’t read the article because of the signup wall. It is cheap and easy to set up a blog on your own custom domain.
I think it’s a choice to monetize your writings. Medium doesn’t force you to put your stuff behind a paywall. We need to stop blaming Medium and realize the authors wanted to monetize.
> Security and reliability are more likely to go wrong in the seams between components. That means literal integrations, but it also means organization seams. Elon said the best part is no part. Parts between systems, interfaces/valves/pumps/APIs/whatever, are often modelled not after what makes the most sense for the final system or product but often follows the organisational structure of the people making the syst…
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. ConwayEarlier quoted context omitted.
> It is cheap and easy to set up a blog on your own custom domain True. But you can defeat all of Medium's annoying features by just disabling JavaScript.
While true, I'd say a lot of people just won't even bother. I've seen people refuse to download whole books because they needed to put in email. "You can create a 10-minute email" you say. True, and a lot of people do while also a lot of people simply don't want the book that much.
“Before you can make things better, you have to stop making them worse” Incredibly great advice. Especially when trying to resolve an already broken situation.
Notable failures both personally experienced and famous usually involve great amplifications of the issue resulting from attempts to fix, often with increasingly urgent and hasty actions.
Earlier quoted context omitted.
I do think that, and (to paraphrase The Mythical Man-Month) I also think that it would be great to work on a small and focused team with a clear mandate and no legacy stakeholders to worry about. So do we all, but those circumstances are not usually available. The interesting parts start to pop up when you need to make difficult choices. Good managers with a technical background are scarce and therefore not usually a…
A good manager doesn’t need to be technical as they are a managing people. That is the hard part. Not tech.
Also, you’re going to be manipulated and hoodwinked by the managers around you who are technical.
Lastly, the engineers you’re managing are going to laugh at you behind your back.
I’ve seen all of this happen before.
> Security and reliability are more likely to go wrong in the seams between components. That means literal integrations, but it also means organization seams. Elon said the best part is no part. Parts between systems, interfaces/valves/pumps/APIs/whatever, are often modelled not after what makes the most sense for the final system or product but often follows the organisational structure of the people making the syst…
This is just an instance of Conway's Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway
Yes, and if different parts of an organization don't communicate, then the systems they develop / procure will often be stovepiped.
I have seen this in a UK civil service acquisition organisation, that even lacked consistent shared engineering guidance for the different teams. They did at least approximately follow the same acquisition guidance so there were commonalities with how they approached industry and managed the bidding process.
Earlier quoted context omitted.
Notable failures both personally experienced and famous usually involve great amplifications of the issue resulting from attempts to fix, often with increasingly urgent and hasty actions.
Yes, the adage should be "changes for the better start with changes for the worse."