Hacker News new | past | comments | ask | show | jobs | submit | d--b's comments login

Insuring companies could mandate DNA tests before setting the contract price. As they already do with blood tests and ECG.

Health insurance is not welfare - IN THE USA. With universal health care, it goes without saying that society as a whole covers for the people that are more at risk.


Not only is this a metric that doesn’t make any sense, simply floating the concept that this metric corresponds to anything in real life is harmful.

Teams are social constructs, and you simply cannot apply an algo to some observable code metric and get any kind of proper result. People leave, others step up, or don’t. End of story.

The problem with these kinds of metrics is that even if people know they are ridiculously off what they mean, some still think that the idea they convey is correct: ie. That if x people were to leave, the project would stall. That premise is simply not true.

Don’t even think about this stuff. It’s stupid. If you want to know more about these risks, talk to the team. People on the team know if anyone is irreplaceable.


> I got lucky with an investment and made a few quick millions.

Er. Go do whatever it is you want to do...


On a side note: thank you HN team for fixing the large-number-of-comments issue.

And yet, people talk about productivity all the time because they can feel it.

People say: "oh I am much more productive with C# than I am with Python".

Or: "This guy is one of the most productive engineer I know".

But the issue here is that value is subjective. But is that really a problem? "Value" is not better defined than "urgency" or "criticality", yet we prioritize tasks all the time based on the perceived urgency/criticality of task A vs task B. So in the same vein, we could assign a "value score" of project X, that would amount to something like "usefulness * difficulty * quality" (to be discussed), and define productivity as that over time spent.


The hint that productivity is perceived (subjective, qualitative), but not measured (quantitative), is good.

Productivity is argued, in the end, not demonstrated; or only within a very specific, limited framework (a very productive endeavour locally may reveal to be counter-productive on a higher or later scale).

For instance, heavily relying on fossile fuel while pushing CO2 in the atmosphere has proved very successful in a specific time frame, the past century, let's say. But if (if) that means that Earth becomes inhabitable by current life forms within the next century, from an external observer, it was rather an error, or mismanaged, so not so productive.


I think that's a good point. Say it's your company, then you need to decide if you want to build the product in C# or Python. It's going to affect productivity, but it's very difficult to say how. If you pick Brainf* of course most people can tell you productivity will suffer, but in the C#/Python example you might start building in C# since it's what you're familiar with, then have problems recruiting developers in your area a few years down the line, since most people are now doing Python (say).

Technically, your original choice might be "correct" in some ways, but who knows?

Perhaps the discussion should revolve around how we make decisions better in complex, rapidly changing environments, with limited information? It feels like we're clinging to the need for things to be predictable and measurable even when they're not, and we end up in more or less delusional discussions about which of two almost identical programming languages is better, or even tabs vs spaces :D


Perhaps this specific comparison is flawed.

It's the same as if comparing "Do we build it in Rust or TypeScript?" (not in terms of hiring pool but in terms of specific language used - picking either Python or C# will result in products with massively different grade of performance and quality).


> I know that if you go back far enough in these posts of mine, you will find some real crap in there. Sometimes that's because I had a position on something that turned out to not be very useful, or in some cases, actively harmful. This sucks, but that's life: you encounter new information and you are given the opportunity to change your mind, and then sometimes you actually do exactly that.

followed by

> So, my new position on that sort of thing is: fuck them

I always found rachel's articles (is she called rachel? Idk) way too opinionated. It doesn't get better with experience apparently.

I mean, don't "fuck them"... Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.

I, for instance. As an individual contributor, I will accept everything that is thrown at me. Yet, there are specific tasks I totally suck at, and I will slack a lot to avoid doing them. I don't like going to my manager and tell them: "I actually suck at this, and if you give this task that sounds relatively easy to anyone else, I will slack the shit past the deadline for sure." So if there was a may that my manager could learn this by himself. That would certainly help everyone on the team.

I am not very proud of that particular aspect of my psychology, but you know, that's the way it is. I'm highly capable in other aspects, so I don't think my employment is questionable in any way. There is just this specific psychological thing that maybe a tool could help fixing.


I like that Rachel has clearly expressed opinions.

What I love is that Rachel is aware of them, revisits, and explains why a new opinion has been formed.

being able to say "I was wrong, because" followed by "here is my new opinion based on what I have learnt" is much more valuable than opinion disguised as fact.

Knowing _why_ an opinion has changes is often very valuable.

> Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.

Maybe, but what the article points out is that slapping a metric on something and saying "this is performance" leaves you with a massive quantisation error. If you have a simplistic metric, then people will optimise for it, often simplistically.

The other thing the article points out is that "peer feedback" is often not a useful way to help people. If you were to put your point about those specific tasks in your own feedback, or someone wrote it about you, it would form an indelible mark on your record. Because it'll probably be the only tangible and actionable bit of information, you manager will overindex on that.


I agree. It is always commendable to face the realisation that our previously held actions or opinions are limited. Even more so to do so publicly with the hope the experience can help someone else.

On the other hand, we are told that these previous actions were actively harmful. Perhaps given this some degree of apology to those that might have been impacted would be in order.

The final sentence of the article is quite illuminating. I wonder whether that would have changed were the metrics useful in identifying relative work performance.

It's a courageous and commendable article either way.


Why would you though?

Differentiating by hand is not difficult at all, and graphing a curve and its derivative is a really good way to teach what a derivative actually is.

Integration is harder, obviously, and it is a pain point for sure. Even the idea that an integral is the area under the curve is clearly not trivial to students.

But I don’t see a clear benefit trying to avoid integration. Integration is more difficult, so it should be pointed out as such, but then it’s still really useful to know how to do it…


Maybe marijuana getting a lot stronger plays a role here? I for one could smoke a joint while I was a teen, but nowadays the stuff makes me super sick every time, like the last two times I had to lie down and ended up barfing before getting better.


I am all for nostalgia and stuff, but one item I don't miss is the cassette.

These things failed all the time, the tape would get stuck in annoying places, and then you'd end up with 10 meters of tape to try and rewind without tying a knot, and the tape was screwed anyways. Ugh.


Like with all analog media, what you get out of cassettes depends heavily on the actual media you use, as well as the equipment. Tape getting stuck or unwound doesn't really happen with quality decks, and the fun part is those are much more affordable nowadays.

And as far as the quality goes - well, audio quality was a solved problem a few decades ago. Since then, it's only getting worse. Cassette cannot be better than a well mastered vintage vinyl or CD. It is better though than a YouTube video listened over Bluetooth on crappy headphones, which seems to make most people happy these days. It can, importantly, also sound better than a lot of modern vinyl.


It's mostly dependent upon tape quality and deck quality. With a good deck and good tapes, it was extremely reliable. Cheap tapes and cheap decks OTOH were a nightmare.


Same! My dad laughed at me for getting into vinyl - he remembered it as scratchy and irritating. Cassettes are nostalgic, for sure. I used to sit for hours waiting for whatever song to come on the radio so I could record it for future enjoyment. That was pretty cool.

I expect at some point CDs will see a renaissance like vinyl and cassettes. I'm here for that one. CDs were really the high-water mark of enjoying music to me.


You must have had very bad luck because I used cassettes non-stop for decades and have never had this happen.


I wrote a 64-bit clock that would just flip one bit on a 64-square grid every tenth of a second. I was kind of happy that at some point in maybe a few billion years, that clock would show a smiley face or something like that.

This is also how I got to read about Beckett-Gray codes. Needless to say I didn't find a 64-bit Beckett-Gray code, though I did try a little bit.

The thing ran in Flash, so, that's that.


The deadline for YC's W25 batch is 8pm PT tonight. Go for it!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: