That's sarcasm, it probably also wasn't actually Funny. Nothing about what they said suggests they didn't subsequently look into why their tests missed the issue
That's exactly how I treat publishing my own OSS now (probably on a smaller scale though).
I had started by hoping (almost assuming) people would be amazed at how useful my library was. But mostly they didn't notice it, or (and this was harder to accept): didn't even recognize or understand the issues it was addressing in the first place.
5 years later, the issues are generally much better understood in android world, but still. I know some teams are using it, but it's probably not that many.
So publishing it has just become a hobby, it's something I can be proud of, it works nicely, I often use it (or the knowledge gained while writing it) to speed up whatever I'm doing and make my life easier. I also publish articles about said issues, and they seem to be helpful to the people that read them, and I enjoy explaining things I understand.
I'm not on the engineering manager track, and I hope to be programming until I retire, so I'll probably just keep supporting it.
If I had any advice for the OP I'd say set your expectations at: personal pride in doing a good job
(I'm definitely not the best person to dispense any kind of marketing advice anyway)
Gitx is great for that on a mac, but every time I set up a new MacBook I have to hunt down the latest repo / build. It keeps getting abandoned and then forked and continued, and then abandoned again...
I do TDD in one specific case, and it's always a unit test. Very occasionally I will need to write a function or a small class do some complicated logic that I'm too lazy or stupid to work out how to do. I do know exactly what the results should look like though, including all the possible edge cases.
Anyway, for those situations, I write a large number of tests cases, covering every reasonable scenario, plus a bunch of unreasonable scenarios.
Then I write a half-assed implementation that fails on several tests, and I keep hacking about until more of the tests pass. Once they all pass, I stop. Even if at that point I have no idea why that particular version of the code completely works.
It's nasty I know, but sometimes it's the quickest way to a robust implementation
These stats are only useful if we know how many people get dementia in the first place.
What are the chances of a random control group of 14 over 85 year olds also not getting dementia?
If it's very common, and you would usually expect 7 of them to develop dementia, then 0 cases in the test group is potentially impressive. If it's quite rare and you would usually expect only one of the control group to get dementia, then it's not that impressive that the test group had 0, and easily down to chance
Who is this news org, why should we trust them? A cursory look at their content suggests we shouldn't.
It's easy, all you need to do is spot the term "Russiagate", in this case the "gate" is being used to suggest that Russian influence in American politics is a fake news story (which it definitely isn't, see Muller report)
It basically talks about how Sussman's work on the Alfa Bank story (about how there was a relationship between Trump and a Russian Bank) was accused of fabrication and was lead by the Clinton campaign, as described by research from the FBI. (You can read the judicial document in its original form here: https://www.justice.gov/sco/press-release/file/1433511/downl...) Although the title is quite polemical and should have been toned down if it were to adhere to HN standards, I think it is a valuable news story and shouldn't be shrugged off as just "fake news".
"In six out of seven countries — all but Germany — Tweets posted by accounts from the political right receive more algorithmic amplification than the political left when studied as a group."
That reminds me of when I was at university in the 90s, a favourite trick was to set MSWord's auto correct on the communal computers to change the word "the" to "wanker". People would arrive with their floppy disks, print out their assignments ready to hand in and then notice (or fail to notice) a page full of wankers. Hilarity ensued (...mostly)
Yes a lot of people like to be the person who says what the "best practices" are (even or maybe especially if they've just made them up) it sounds much more impressive than "I like to do it this way"
> my project manager asks me why we're not using sequential IDs, and I say it's a best practice according to the documentation, he'll happily accept that answer even if neither of us understand why it's a best practice.
I have to say, I think I would be happier with an answer like "because it avoids hotspotting according to the bocs"
This limits the applicability of the "don't use sequential IDs" rule to where it actually helps.
Otherwise, the rumour spreads, and later you find teams doing huge damaging work arounds to avoid using sequential IDs, in contexts where hotspotting is totally irrelevant (perhaps because they are not even using Firestore) all blissfully unaware, because they they think they are following "best practice"
I've seen this happen so often in large companies, the words "best practice" let people abdicate their professional responsibility to _think_ and it's quite dangerous IMO
