mikekchar · HackerTrans

Alright. 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!

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

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):

    Tested/Visits   Confirmed   Hospitalised   Died
     21,000,000    *1,900,000    800,000      61,000
     22,000,000     2,000,000    270,000     114,000

Where the asterisk means my esitmate which may be completely wrong. Edit: The first line is the flu and the second line is COVID-19

But 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!

mikekchar

6 年前議論

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 ;-)

mikekchar

6 年前議論

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).

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

Quite a lot of Japanese people seem to recognise characters less by their shape and more by the stroke connections, in my experience. No matter what the tool used to write it, legibility really requires writing the characters in the correct order for the most part.

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

Not the OP, and it's definitely not my style, but some people really like taking classes. They love the environment and energy that a university life gives them. I've known one or two people who have spent decades just taking classes (and accumulating degrees).

mikekchar

6 年前議論

To be fair, it is very common for Forth programmers to redefine the interpreter as they go. You literally change the language in your program. That's a very different expectation for other kinds of languages.

mikekchar

6 年前議論

You are my hero!!!!

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

Surely the Trump campaign's response should be to claim that they are not infringing. This should put the video back up, according to DMCA rules. I'm not really familiar with Twitter's DMCA work flow. Do they not allow the user to challenge the claim?

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

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 :-)

mikekchar

6 年前議論

It's never been useful in my experience, but I'm certainly interested to hear your experience.

mikekchar

6 年前議論

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.

mikekchar

6 年前議論

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.

コメント