I just can't agree with the recommendation to read the comments before articles you find online.
Critical thinking is such an important skill for everyone, not just engineers, and this habit all but eliminates it. You go into an article with a framed opinion of what it's trying to convey, and spend the time reading the article looking for confirmation of that opinion rather than thinking critically for yourself.
This might be OK in some communities like HN where people are usually pretty reasonable and the site seems fair. But it becomes a habit and can be dangerous in other places where the top comment could be paid for or manipulated without you knowing, seeding opinions and confirming them as you view the content.
Definitely read the comments. The author is spot on about the gems and lessons to be found. But do it after you've read the article, and thought about what it meant for you.
>I just can't agree with the recommendation to read the comments before articles you find online.
Your disagreement makes it sound like he made a universal recommendation for all articles in all circumstances. I didn't read it that way.
He specifically constrained his observation to staying on top of new technical developments in /r/programming and HN:
"When browsing Proggit, I recommend reading the comments before committing fifteen minutes to reading a nicely titled (or click-baited) article."
It looks like his advice meant to be a time management tool instead of a shortcut to disable critical thinking. You have several factors that lead to the comments-first-then-read-article strategy:
1) finite time -- can't possibly read every article -- must prioritize the information overload somehow
2) Sturgeon's Law -- 90% of everything is crap (e.g. clickbait titles)
3) you lack the technical background in the new and unfamiliar topic that's a prerequisite for applying critical reasoning.
>Critical thinking is such an important skill for everyone, not just engineers, and this habit all but eliminates it. [...] But it becomes a habit and can be dangerous in other places ...
I think people can be adaptive and use comments-then-article on certain websites but also use the opposite article-then-comments on other websites.
For online articles of New York Times, Washington Post, and Youtube videos... it makes more sense to consume the content and then look at the comments (or skip the comments altogether since they are often a cesspool of nonsense.) For fast-moving technical crowd-sourced article submissions -- it can be rational to read the comments first.
The comment section is pure gold for discovering contrasting opinions - which will feed critical thinking. Reading what ever article while remembering different opinions from comment section gives a really nice insight.
Totally agree about the top comments. Not that valuable and some times even misleading/manipulated/bought/nasty.
His whole point is that reading comments first is the mistake. It primes you with thoughts and opinions with little to no cognition required (recognizing they still may be valuable, but those comments will be there after your analysis...)
What we really need is to develop our own critical reading skills, how to connect dots on our own etc. I agree that seeing others comments first before starting that process might be a negative for many reasons.
Most just don't have the luxury of critically analyzing things these days at their work -- the goal is to produce as fast and as much as possible. I find reading the comment sections first helps me gauge what exactly is important in the article and what the takeaways are -- from both angles. Then I can go back to work.
The problem with that is often it gives equal credence to unequal opinions. And not everyone has the critical thinking skills and freedom from bias that they think they do. I'd argue that really nobody is able to fully remove from themselves any biases that may make them more likely to believe some comment over another.
Voting does nothing for this either, as people may upvote a popular lie or misconception, or downvote an uncomfortable truth - I used to see this happen often in the science-based subreddits when I bothered with them on reddit.
I agree. I'm very senior now, bordering on ancient (or at least in the last part of the age tail), and especially over the past 8-10 years (perhaps back to 18 years if you consider the explosion of OOP/OOD and Java to be a tagalong trend) group-think has been a serious problem in development.
The problem with group-think is that that it isn't moderate thinking that is an average of all well-informed people. It can be influenced by a few that have good design skills and say things in a way that people want to believe. I personally have just said whatever came to mind, bullshitting because I was bored, and got many karma points for comments that I'd not thought out, and have definitely seen other comments that were similar. This is especially true when you are shooting down what could be good ideas. A lot of us just like to argue for arguments' sake. Now, a lot of times that is good, but it is very important to try things out that you on your own think are reasonable and see for yourself.
For example, what if HN had been around when PhP was developed and a group of bored naysayers had shot it down because it wasn't organized enough and would promote bad practices. Those things were true- you could write bad PhP code. However, a lot of what exists today was born of people just having fun coding in PhP, and those people wouldn't have learned from their time in PhP, because it never would have come about.
There's a famous saying about it... But, anyway, it's best to have a bias into believing a well articulated comment saying something is viable or useful, and into doubting a well articulated comment saying something is not viable or useless.
Reading only the article headline, reading short comments and responding to them is good practice for bullshitting through meetings.
It's a pretty good approximation for boring meetings as you've got a small amount of overall context (article headline::meeting) and small amount of specific context (comment::sentence before your name).
Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers.
Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.
-F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)
It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway.
Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size.
Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.
What I was actually referring to was Cantrill's talk about tail -f on Solaris, and how he improved it (so that it at least handled some cases). He looked at the GNU behavior, and determined that truncation was noted, but nothing was done about it. This is true if you use -f. However, if you use -F, truncation is handled properly.
I know what you were referring to. It has already been hyperlinked; I had already referred to where M. Cantrill explained that he gave up; and as I have just explained, the people who wrote GNU tail gave up in the same way (for much the same reasons, I expect) and GNU tail does not handle truncation any more properly than M. Cantrill did. There's no doco, but there's commentary in the code observing the problem.
And as I then went on to explain, this whole idea of truncating one log file over and over is a poor one, and not the best way to do logging in the first place. So the fact that both M. Cantrill and the GNU people gave up should perhaps be viewed as stopping when an inferior mechanism is pushed beyond its limits.
Any tips/examples on trying to sell a product that provides ethical/moral benefits but very little/nothing financially?
Some friends and I were throwing around ideas on how to eliminate scalping, a practice we get bitten by. We came up with some solutions that might work, but they don't provide any financial gain for event organisers so I couldn't see them going for it.
You eliminate scalping by charging market prices, so there's no opportunity. Charging less is just a gift to the middlemen. (If you want to give that gift to the people who actually come, charge more and give a rebate inside the event, so scalpers can't collect it.)
Not sure how you're conceptualizing this that makes scalpers harmful, could you elaborate?
I understand that this is an economics problem; the ($5b?) market exists because there is significantly more demand than supply and ticket prices are not adjusted to accommodate this imbalance. Why that's the case I'm not sure. Perhaps that's another avenue to investigate for solving the problem but not what I had in mind (partly because I like affordable tickets).
Seeing scalpers as harmful is definitely an emotional response. Popular events go on sale at a set time and set price, with "equal" opportunity for any fan to get a ticket. Scalpers claim significant amounts of the tickets and resell them at 200-1000% of the face value. My friends and I often miss out on tickets only to see hundreds available on third party resale sites. It also enables ticket scammers which are a huge problem as well. Many music artists and sports teams are very outspoken about their disappointment with the industry, die hard fans waiting at the gate miss out while the person with the most cash gets in. While I can appreciate the scalpers are taking advantage of an economic opportunity, I can't help but view them as the scum of the earth and would have no issue with eliminating their practice.
The scheme I described above leads to affordable tickets, it's basically a way of enforcing nontransferability.
But at its core, disgust with scalpers implies preference for a non Kaldor Hicks optimal world.
If someone is willing to pay $X for a ticket, and you're only willing to pay $Y<$X, it is non optimal for you to get a ticket if you'd sell your ticket for less than $X.
There's no way around that fundamental fact. At some point, if there are more people who want tickets than tickets, some process needs to determine who gets them, and wishful thinking doesn't help anyone.
I don't understand how your suggestion enforces non-transferability. If the scalper pay $100 for a ticket and the ticket holder receives a $50 rebate at the event, the scalper just adds $50 to the price they resell at.
Like I said, I understand the problem exists because of the economics. But there's nothing to stop us from building a system that enforces non-transferability (through identification), and preventing resale of tickets at increased prices by third parties. It just doesn't add any value for event organisers to use this new system.
Awesome, had been planning to make something like this myself to keep track of all the gigs I get to. Nice simple UI, does exactly what I want it to. Keep it up!
Edit: Ok, two minor annoyances. Firstly, if gig details aren't found or listed for an artist, I can't manually enter the date/venue myself. Secondly, I'd like to be able to click the heading on my gig list to sort it by date/artist. Also getting errors pretty much every time I add a new artist, presumably just from overload.
As Jonny mentioned this is very much an MVP which we just finished yesterday. We do have plans to allow you manually add event details if we don't have them in the database.
Sorting of the show list is also something we have on the roadmap.
Sorry about the errors, yeah we're hitting the API limits pretty hard.
I work at a medical device consultancy, but we're mostly developing custom Class B/C devices at the bare metal level. It sounds like you'll be developing a Class A device and cost isn't a huge issue so I'd probably recommend going the Android route. Find a reputable supplier who's worked with medical devices before, and check their availability guarantee (since the production lifetime of most Android devices is short).
Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.
