From a technical perspective: Ignoring leaves the loop open. I don't know:
- if you ignore it on purpose
- or if you don't want to solve it or
- or if you don't have time or
- or if you just missed it
...
That's when I would re-send the message or do something else. A Win-Win would be sending a small "won't-fix" or whatever.
Often that's what you want! Maybe I don't want to reject your bug report outright, maybe I'll get around to it in a few weeks or months or years. Or not, I dunno.
I've had my own issues and bugfix PRs on small projects ignored, that's fine. Nobody should ever have the expectation of a response on that kind of project.
Uh hard. First, maybe don't buy companies with bad technical debt, just start from scratch? And always prefer two experts to 10 juniors in the beginning even if you move more slowly at first. I don't know what would have worked well in that particular situation, but if I were to do it again and could influence the original team, I'd use Clojure. I believe the immutability and control of side effects would have been more of a benefit than types. That was where the real problems came from, dynamic ability to create out-of-sight side effects and alter data in unexpected ways all over the damn place. Clojure's immutability plus spec would have been way better.
As a doctor, your primary job is to make sick people healthy, not to make healthy people more healthy.
This is why you want to have a high compliance, meaning that the sick person does what the doctor recommends. This is mostly caused due technical or behavioral complexity.
You can increase compliance by reducing complexity. At the same time, the accuracy decreases.
Example:
High Accuracy / High Complexity: "Do not eat frugugle, fergerio, flululu and fnyvoo." Why low compliance? Because the behavioral complexity is very high, especially for sick people:
1. Find the food ingredients list.
2. Loop over the ingredients list and compare the current item with the "do not eat"-list.
3. Make a decision for every ingredient, if this is in the list ("frugugle" is on the list, but one ingredient is "fruguglelase", what's my decision?)
Lower Accuracy / Lower Complexity: "Do not eat products with more than 3 ingredients." Why higher compliance? Because the behavioral complexity is lower:
1. Find the food ingredients list.
2. Count the amount of ingredients.
3. Make a decision after reading max. 3 ingredients.
IMHO it's easier to start with the second approach, because you make progress faster, and keep the momentum going.
This whole argument strikes me as very silly. If I want to eat healthy foods badly enough to change my diet and check the ingredients every time I buy something, I'm not going to want to oversimplify it to the point of near meaninglessness by adopting a rule like "3 ingredients or fewer." I'm perfectly capable of learning what ingredients to avoid.
And if I'm sick, and there are clinical details that are important to my treatment, then I'm absolutely not going to be satisfied with a low-accuracy simplification.
Hey everyone, Michael, the creator, here. I have a lot of accounts, Linkedin, Twitter, Github and so on. Companies ask for my Linkedin and Github. Friends ask for my Twitter and Instagram. When I want to share one of these accounts, I have to go to the specific site, find the URL and copy & paste it.
So I built an app to create shareable, digital accounts cards I can send to people. It has only links to accounts, no unnecessary information. And it is customizable to the recipient. No signup needed.
Hey everyone, Michael, the creator, here. I'm an introverted guy, I love to be alone and do my things. Therefore I often forget to keep in touch with friends. Weeks later the person comes to my mind and it feels odd to reach out then.
To solve this uncomfortable situation, I've built an app that gives my an overview when I last contacted a specific friend. Because I think other people also struggle with this pain and could benefit from my app, I love to share it.
I would love to hear your feedback: features you would like to see, bugs you experienced, general ideas about it.
