- mikekchar parentAlright. If you are unable to look at any other data than the one page you have. 7,961 deaths to influenza in 2015-16. Is that the number you think will show that COVID-19 is more deadly than the flu? Because, I've got to say that I don't think that number is better for you than 23,000 deaths that the data I'm pointing to. Oh, of course there are 131,858 deaths due to pneumonia from other causes. Clearly something pretty powerful that wasn't influenza swept through that year. It's pretty strange that we keep statistics on the piddly old flu when there is something killing 20 times as many people, but is completely unidentified. I'm so glad we agreed to use this data rather than literally any other page on the CDC website!
- That data does not actually agree with any other data I can get from the CDC web pages. Where did you get the link from? Even the total death rate is nearly half of the actual total death rate reported for those years.
Here's the data I was quoting: https://www.cdc.gov/flu/about/burden/index.html
Here is 2017 from 2016 (which I believe is basically the 2016-2017 calendar year) national vital statistic report: https://www.cdc.gov/nchs/data/nvsr/nvsr68/nvsr68_09-508.pdf
If you scroll down to Table B you can see that ~2,800,000 people died, influenza and pneumonia account for 55,000 deaths. This is more than that 33,000 cases of reported influenza because not all pneumonia is caused by the flu.
The data in your link is very strange in that it implies a rate of 10% of all deaths is by pneumonia, rather than the ~2% in roughly everything else I can find on the topic. I wonder if we are losing some context here?
Here is another mortality report. Just search for pneumonia: https://www.cdc.gov/nchs/data/nvsr/nvsr68/nvsr68_09_tables-5...
Literally nothing I can find on the CDC's website matches up with the data on that report so I'm at a loss what's going on with it. It's too bad there is no text because I think we're missing something.
- According to Wikipedia, influenza causes an estimated 41,400 deaths per year. 2017-2018 was the worst in 40 years and totaled about 61,000 (though the tally has not been finalised and some people have reported it as being as high as 80,000). The number of hospitalisations for the flue in that year was estimated at 800,000 people (clearly that isn't ICU). The number of medical visits was 21 million. I have no data for how many people were confirmed to have the flu, but were not hospitalised.
COVID-19 has killed 114,148 people to date. The number of hospitalisations are only reported up to the end of May 30 and appears to be 82 people per 100,000 people in the populations (thank you CDC for such an epically terrible statistic!) That works out to about 270,000 people. I'm going to use PCR tests as a proxy for "medical visits" for the flu, but in reality they aren't comparible. There are 22 million tests that have been carried out to date. The reason I use that as a proxy is I assume that there is reason to suspect that someone may have COVID-19 if they get a PCR test, just like there is reason to suspect that you have the flu if you have a "medical visit". The last piece of information would be the number of confirmed cases which is 2,045,549. So just under 10% of the cases that were tested were confirmed to have the disease.
Of the people who were hospitalised in the worst flu year in 40 years, about 10% died. Of the people who were hospitalised for COVID-19, about 42% died (well a little higher because I'm using June 10th data for deaths and May 30th for hospitalisations). The number of medical visits for the flu was 21 million in the worst year and the number of PCR tests for COVID-19 so far is 22 million (about the same). It may be a bad assumption,
Just to sum up (and sorry for those on mobile):
Where the asterisk means my esitmate which may be completely wrong. Edit: The first line is the flu and the second line is COVID-19Tested/Visits Confirmed Hospitalised Died 21,000,000 *1,900,000 800,000 61,000 22,000,000 2,000,000 270,000 114,000But any way you slice it, I don't think the numbers work out the way you are portraying it. Corrections to the above are very much welcomed!
- I'd love to actually read the paper to see if it is reasonable. Anybody have a link? Having said that (and keep in mind that I'm in favour of wearing masks and wear one myself when I go out in public), I think it's pretty clear (as indicated in the article) that masks alone won't bring the R value below 1.
The article says, "He [Richard Stutt, who co-led the study] said the findings showed that if widespread mask use were combined with social distancing and some lockdown measures, this could be 'an acceptable way of managing the pandemic and re-opening economic activity' long before the development and public availability of an effective vaccine against COVID-19, the respiratory illness caused by the coronavirus." (emphasis mine)
Anecdotally, in Japan (where I live) there seems to be a much higher than 50% use rate and there is still need for lockdowns. However, as the article suggests, it appears that the severity and length of the lockdowns might be reduced.
The question I have, though, is if the sheer number of people with the disease in the US and UK may be an issue. In South Korea, Taiwan and Japan, the total number of active cases never really got above 10K -- so the chances of meeting someone with the disease is really quite small. Potentially (as seems to be the case in Japan) you can get away with just dealing with cluster cases and let the stragglers go -- as long as the masks are effective enough to keep transmission rates low in those situations. But if you have millions of people with the disease, many of them in large cities, I wonder if it will be as effective.
- TODO lists for which I use org mode, but you could use practically anything. I like a text editor for this rather than an app, per se, just because it keeps me in the flow. All you need is a place to jot down what you are planning to do next and to be able to arrange the order.
Usually I'll start with pretty high level ideas. If I have a story I'm working on, I'll put the description of the story in my TODO list. Then I'll think for about 5 minutes about what general things need to get done. I'll order these by some priority (doesn't really matter usually, to be honest). Then I'll start working on the first one.
Normally I need to poke into the code to really see what I have to do. I'll often add a sub-task to my first one that says, "Figure out what to do" or something like that. Then I'll do some exploratory coding for a few minutes. As I discover what needs to get done, I write it down in my TODO.
It's hard at first to stop yourself from just writing code, but pulling yourself back for the 20 seconds or so it takes to write down what you are just about to do can be surprisingly valuable. Don't censor yourself either. It's fine to guess what you need to do and then delete stuff that you realise is unnecessary later. As you are coding, any time you think, "Oh, I'm going to need X", add it to the TODO (again, difficult to train yourself to do it consistently!)
Once you get good at this, in my experience you will be quite interruptible. Any time I get distracted, or unfocussed or lack motivation, I just look at the top think on the TODO and say, "I'm just going to do that top thing". It always pulls me in.
I don't always code like this, but every time I do I'm dramatically more productive. I should always code like this, but... sometimes you want a relaxed day ;-)
- It is incredibly difficult to remember something that you don't understand. In fact, your memory often elides things that you don't understand to the point where you will swear that something never happened when, in fact, it did. Statistically speaking, repetition is required for learning, but understanding is at least as important. In fact, sometimes if you can find no meaning for something, it helps to make up a meaning (for example the use of mnemonics).
- On the other hand, true criticisms of Javascript, the language, are boring. Yeah, there are problems. You learn to deal with those problems. They aren't really that horrible. I worked with a lot of less convenient languages than JS (especially ES6, which is actually not bad). The standard library is pretty bad, but the language itself is easy enough to use that it's pretty trivial to implement what you need yourself. There are also a few pretty well written third party libraries with no other dependencies which you can use. The build environment is horrible, but not really any more horrible than some other environments I've had to deal with.
No, the real problem is that a lot of Javascript developers choose to stick hot pokers in their eyes. They don't read the code of their dependencies. They don't care how many ridiculous dependencies of dependencies they use. They refuse (absolutely refuse, to the point of calling you an imbecile if you even suggest it) to write their own tools. They choose the build tools that are the most wonky and are built on the most insane internal code -- because they don't care to ever look at that code. They look at the "box features" and say, "Oh, everyone is using that and it has all the features we want. You are crazy if you want that stupid boring thing that barely does anything (and yet works)". They don't do any planning for configuration management. They don't think about how they want to upgrade their dependencies, and especially don't dare think about inspecting the code in the dependencies. "Latest is best! If it breaks, we'll deal with it then".
Javascript is not really that bad. It really is that the community does not have a particularly good grasp on how to minimise risk in large projects. On the other hand, it's a common refrain on other platforms. While Javascript is not really that bad, other platforms are considerably better and you can get away with really poor practices for a lot longer. Not that they won't absolutely kick your ass eventually -- it's just going to be a couple of years away when you have moved to another company at a higher pay scale.
- I also have a small caveat. If you have a docker setup or a similar style of setup, if it is not obvious how to do this by hand, then you should write documentation on how to do it. Honestly, my standard is that you should have the same level of setup instructions as you would expect from a good open source project of the same complexity.
- Actually, Chinese characters did originally have a defined linear order (or, rather several schools existed IIRC). It's been a while since I looked at this, but essentially they were ordered by radical and then pronunciation, with some other tie breaker rules. Japanese word dictionaries, though, are indeed usually ordered by pronunciation. Kanji dictionaries have a variety of different orders, but most of them are ordered by radical and stroke count.
- I had to read up on the "means of production" because I had no idea previously that it often refers to the capital (both social and financial) used to produce goods. It's interesting to me that Engels says (in essence) that a worker lacks the means of production and is therefore forced to sell their labour.
But, it occurs to me that this has always been a seller's market. I have, in my naive youth, thought, "What are they going to do, fire me?" Because they might, but it's not like I couldn't another job -- probably even higher paying! What exactly is the "means of production"? Is it really the capital that pays the salary of the programmer, or... is it the will of the programmer to actually write the code? By and large, the programmer is very difficult to replace. If you take note of the incredible number of programmers that are an absolute PITA (I mean, I'm sorry but we are and ornery bunch!), how on earth do they get jobs if the capitalists are not completely desperate. In fact, the big companies even lobby the government to allow them to ship programmers in in large quantities!
So can you not finish and deploy it? I wonder... What could possibly happen?
Small print: Not responsible for loss of livelihood, and social shame that results thereby.
- Evil mode in Emacs is almost perfect. My biggest complaint is that undo works differently than vim (if anyone knows how to fix that, I would be forever grateful!) I originally used Emacs for about 20 years and then switched to Vim for a variety of reasons. I love the editing model in Vim. But for the last few years I've been using Emacs with Evil and it's been the best of both worlds.
- At the risk of being cynical, I don't think it was common to toss around incompatible definitions of open source until very recently. There seems to have been a considerable push by a number of people to dilute the meaning of open source -- in my tin-foil-hat opinion with the intent of destroying the community behind it. Free and open source software has weathered these kinds of attacks many times before and it certainly looks very similar to the kinds of things I've seen before.
I think it's a matter of people with vested interests throwing spaghetti against the wall until something sticks. We've often seen cries of "But how will programmers get paid if everything is free?", and "You don't need to modify the code as long as you can see it", and "Free and open source software is incompatible with commercial endeavours". What's new now is, "If you go with a free or open source piece of software, you are playing into the hands of the likes of Google who will gobble you up". This approach has be demonstrably far more successful than others.
From the perspective of someone who values free (as in freedom) software, I'm wary of diluting the brand of both free software and open source software. I think it only really serves the interests of people who do not value free and open source software. Given that the OSI actually has a trademark for open source, I hope they enforce it. I'm worried they don't have the resources to do so, though.
- There are definitely small and medium sized companies that follow the principles you describe. However, there are lots that do not. Trying to transition a company from "do not" to "do" is quite difficult.
Whenever I hear stories like this, I try to ask the person to imagine how the relatively good practices were born in the better company. The pressures are similar. The people are similar. There are two really big differences: the current situation of the organisation and the approach you take to move toward a better way of working.
One of the easiest ways to change culture is if everybody in the culture is unhappy. Revolution is just a suggestion away. When you look at things like the first XP project (whether you believe it was a success or not), it's well documented that they were able to use XP because they were just so sick of the thing they were doing previously.
Often this is not the case, though. Some people like what they are doing now, or doubt that another way will be substantially better. In this circumstance, I like to try to do something I call "aligning vectors" (which I'm pretty sure I stole from something that James Coplien wrote, so if so, I apologise :-) ).
Software is a team sport. When you think you have the correct way of doing something, it is tempting to go and do it. But if everybody goes off in different directions, following the ideas that they think are right, the result is that the team as a whole will certainly fail. Perhaps it won't be your fault (you walked in the right direction after all), but it hardly matters.
So what you need to do is to convince everyone to walk in the same direction. At first, it doesn't matter which direction you go. It is completely fine for everyone to walk in the wrong direction as long as you can change direction later. It is much easier to change everyone's direction after they are all going in the same direction to begin with.
This means that your first task is to align yourself with the majority - even if you disagree with it. Remember, at first you just need to get everyone walking in the same direction. That means that you need to walk in the same direction as the majority.
Next, you need to look at what other people are doing differently. If you think one person is doing something better than the others, try to align one of the others towards that person. This is where you need to be a bit clever, because not all people are equally easy to align.
In any group, there are early adopters, middle adopters and late adopters. Early adopters will try anything for giggles. Middle adopters need to have some kind of evidence that the thing is better for them to try it. Late adopters will not try it until the vast majority of people are already doing it. So your task is to find an early adopter and get them to try the better thing that someone else is doing.
Now here's the most important thing. You need to make sure that they are successful. You need to help that person and do everything in your power to see that they succeed. If they fail, it's best to say, "Oh, that was my fault (for whatever reason)", so that they feel OK about failing and will feel happy to try again with something else. If they succeed, you have to say "Oh, that's amazing! You are great!" so that they feel happy they tried something new.
Then you need to advertise the success. Once the middle adopters see the success, they will want to get a piece of the action. Encourage them gently and hopefully you will get one to bite. If you make them successful and make them look really good, then others will want to try.
Eventually you will have only the late adopters. The thing about late adopters is that they are usually very socially sensitive. They will be very uncomfortable with everyone else doing something other than what they are doing. They may complain. They may get angry (even at you). Just stay calm and suggest, "Why don't you give it a try? If it doesn't work, we'll learn something that everyone can benefit from." Usually they will, but if they don't, it is totally safe to let them do their own thing for a while.
Keep doing this (it takes a long time!) until everyone is going in the same direction (with the exception of 1 or maybe 2 late adopters). If you do a good job, everyone will trust you and will be very eager for suggestions about what to do next (because you have a history of helping them be successful). It is at this point you can introduce something new: "I don't know if this will work for this team, but in my last job we did X and it seemed to work really well".
The more success you have and the happier the early and mid adopters are, the more pressure the late adopters will put on themselves. They hate this kind of thing. They will either decide to join you, or they will quit. I've never seen another outcome (and it breaks my heart when they quit).
Anyway, I typed too much. YMMV :-)
- Not OP, but I agree completely (even though I find it hard)! Really. Never. It will never, ever give you any benefit at all to speak ill of your spouse. It will give you nothing to act unkindly. It will only cause your spouse to feel justified in doing the same.
As the other poster said, there are times when you should walk away from situations. There are healthy relationships and there are unhealthy relationships. If you honestly don't believe that the relationship can be a healthy one, it's time to leave. Especially if you are suffering from any kind of abuse in the relationship and you have unsuccessfully tried to resolve it, don't hesitate. Don't make or accept excuses. Heck, don't feel you even need to resolve the issue if you are getting serious abuse. Just leave.
There is no reason to retaliate in any way. Doing so will hurt you as well. The situation is what it is. You can explain the situation, explain your feelings and leave it at that. Or if you can't safely explain things (for fear of retaliation from the other side), then just leave without an explanation. Start the healing process immediately. Don't start a knife fight and then crawl away even more wounded.
For smaller issues, I've found (much to my dismay) that if my wife is doing something that hurts me, she is completely unaware that it hurts me. Even if it obvious to me that it should be hurtful, it's not obvious to her. If I'm snarky about it, then she is hurt. Now it is doubly hard to improve the situation. If she is not hurt, then it is relatively easy to have a non-confrontational conversation about what happened. I control all of the hurt feelings, because they are mine. If she is hurt, then I have to rely on her to work out her feelings in addition to listening to my problems. It very rarely works out well.
- From this page: https://wiki.creativecommons.org/wiki/NonCommercial_interpre... they explain that the NonCommercial part is triggered on use. I believe that the intent is that you can not use the work for commercial advantage or monetary compensation. So if you write a play using CC-NC, it would be against the license to perform that play for money. Similarly, if you have software under CC-NC, it is against the license to use it for the purpose of making money.
The problem with NC (IMHO) is that it's too loose. Everything is up to interpretation. It's clear that you don't have a license to use the software, except the CC-NC license, but I think you probably would have to go to court to really determine if the usage was "commercial" or not. For this reason, I won't touch CC-NC works with a 10 foot pole. If you get sued, you are almost certain to go to court. There is probably a good chance that an injunction will be granted while they decide whether or not the usage is "commercial". By the time it's all over, you would have been much better off not using the code. For me, this means that using CC-NC code is pretty much a gamble on whether or not someone will attempt to sue me -- which is pretty darn close to just forgetting about licenses and hoping I don't get sued for infringement.
- There is an issue on Github that is collating the problems they are working through. I've lost track of it, though, unfortunately. I've been pretty cynical about it in the past, but the last time I looked at the issue, it does look more complex than I first imagined. I wish it were higher priority, though. Hopefully somebody will remember the issue and post it here (it was from an HN post that I found it originally). Unfortunately, I'm not even sure what project it's under and there are many projects.
- According to Wikipedia, the original author does not consider COVID-19 a black swan event, so I think you must be right. However, while we know a pandemic will occur, we don't know when. Neither do we necessarily know ahead of time what measures are appropriate to take to mitigate the risk.
The aspect of the Black Swan theory where you point to the data after the fact and say, "We should have known" is very similar. For example, countries that experienced SARS and MERS where very much more prepared for COVID-19. Other countries which didn't have many problems did not prepare. This is because they didn't realise that they should prepare. For them COVID-19 was out of the blue -- a complete shock. Of course, we should have looked at the original data and if we had, we could have improved the outcomes. But we didn't have that experience and we didn't know when to expect a large problem.
The Tohoku earthquake in Japan in 2011 was similar. Earthquakes of that size hit Japan about once in 1000 years. We know it will happen. We don't know when. We don't know if it will happen in our generation. Should we prepare for it. In hindsight, yes, of course. At the time, it was a shock.
Is that a black swan event? I don't know. However, I don't think we need to have much of a distinction. Even if we should know, the fact that we don't know is all that matters. It is still a surprise.
- My job is programming, so it's hard to divorce yourself too much. However, I went something like 4 years without a cellphone plan (I had a phone, but used it as a mobile computing device). I've never really done social media (a couple of years on Facebook until I figured out what it was). Probably HN (and before it Slashdot) was the extend. But I've gone many years without anything.
In terms of communications, I think the biggest problem is other people's expectations. "Why do you have a cell phone if I can't call you?" They ask. People want to be able to demand your time almost instantly and they have no patience for other methods. If your timeframe for being contacted is a day or two, they just won't contact you.
So, if you do it, be prepared to be the one that needs to contact them. You're the odd person out. Nobody will follow your (to them) weird rules. It can be lonely if you aren't proactive.
Apart from that, I find that social media (especially HN these days, unfortunately) is just depressing. Someone has a bad day. They go on to whatever platform and release their stress by being crappy to someone else. People are depressed, they get some catharsis by unloading their depression on others.
I have to limit my time on HN. Strangely, I hang out on Reddit these days, but only on /r/cheesemaking, which is full of wonderful and cheerful people. For me, this is the key. It's not technology, it's people. The technology brings a lot of disparate people together and often pits you against them for the viewing entertainment of the crowd. Best not to go there, but it's not really technology itself.
In terms of stress levels for communications, I think setting limits for yourself is good. I'm actually very comfortable with being contacted with work. If you send me 100 emails an hour, I'm totally fine with it. Bury me on Slack, and it's OK. I have work habits that allow me to jump back and forth between my work and communication (took me 30 years to get good at it, mind you...) But others sink and I often see it. Communicate your limits and stick to it. If you only check your email once an hour, tell people and just do it. It will (usually) be fine, but you have to be consistent about it.
Again, IMHO, it's not about technology. It's about people. Choose to hang around people you enjoy and who give you energy. Draw defined boundaries for interactions that you can't handle and be consistent. This will give you the best benefit, I think.
- Interestingly (to me anyway ;-) ) I recall when I heard about the Japanese government's plans (where I live). They had a whole special about what the plan was, what the rationale was, how they thought it would go, etc, etc. I thought they were bonkers. "This is going to go down badly", I thought.
But, looking back on it, I'm pretty impressed with the results. Good foresight? Luck? Not really sure, but you can't really argue with results. As time goes on, you can see that it's a bit like surfing those huge 50 foot waves. If you can manage it, everything will be fine. If not, you are crushed. Fingers crossed.
- I agree that the comment is disingenuous, however, I believe the problem for Dyson was that the car he wanted to make was just too expensive. It's not necessarily the case that all electric vehicles are too expensive (and clearly when you look at the EVs in SE Asia, there are some pretty cheap cars). I'd be surprised if he didn't already anticipate the upfront costs. I think it's more that having made the prototype, he realised he couldn't make a product that will disrupt the market at a reasonable price and therefore threw in the towel.
- That's a good point and I'm glad you mentioned it. However, one set of circumstances is enough :-) If you do not wish to distribute the source code to other third parties, you do not need to, as long as you distribute it to your customers. I definitely could have described that better.