* Mine was discovered super super early, on a scan related for something else
* This was actually so early that it didn’t make sense to operate. The main treatment for testicular cancer is orchiectomy, i.e. total removal of testicle
* If you find a lump, it is by definition much bigger than mine was, and the above doesn’t apply. But if you find a marginal, tiny spot on an incidental ultrasound, ask a doctor about what sizes are risky and consider a second opinion.
* I had something called a frozen section sample. They take the testicle out of the body, but leave it attached. They quickly biopsy part of it. If cancer, remove. If not cancer, put back in. I had this, it was cancer, but I’m nonetheless glad I did. My lesion was so small even then that it plausibly wasn’t cancer
* I had a seminoma. They grow slow, and are benign. It took three years to have a notable changes. If yours is growing faster than that, the odds are much higher it is cancer and a worse kind. Most benign masses are stable and tiny.
* Bank sperm before the operation! You may find fertility significantly impaired. My FSH went through the roof after the operation and my sperm count is like 0.01% of normal. Probably still viable with IVF, but almost zero. I likely had viable sperm before based on the normal fsh
Please don’t be pigheaded about this with your doctor. I did have cancer after all. But I plausibly didn’t, and my urologist recommended waiting + a frozen section sample. This is common in big centers for incidental detection, less common in hospitals that don’t see too many orchiectomies.
Ha! Same here. But don’t stop at 34. I had it at 40. Found it because of that post. They say I could have walked with it for much longer as it was the extremely slow one (there are at least two types). No side effects further; just a tiny lump.
> This guy has gone to the zoo and interviewed all the animals. The tiger says that the secret to success is to live alone, be well disguised, have sharp claws and know how to stalk. The snail says that the secret is to live inside a solid shell, stay small, hide under dead trees and move slowly around at night. The parrot says that success lies in eating fruit, being alert, packing light, moving fast by air when necessary, and always sticking by your friends.
His conclusion: These animals are giving contradictory advice! And that's because they're all "outliers".
> But both of these points are subtly misleading. Yes, the advice is contradictory, but that's only a problem if you imagine that the animal kingdom is like a giant arena in which all the world's animals battle for the Animal Best Practices championship [1], after which all the losing animals will go extinct and the entire world will adopt the winning ways of the One True Best Animal. But, in fact, there are a hell of a lot of different ways to be a successful animal, and they coexist nicely. Indeed, they form an ecosystem in which all animals require other, much different animals to exist.
> Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
>The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.
> I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.
> The "contrarian dynamic" is that HN threads (and internet comments generally) are largely propelled by people making objections. Cunningham's Law touches on this [1].
The objections come in waves. In the earliest stage of a thread, they tend to be rapid negative reactions to the article. It's not that these are a community consensus, it's that they're the fastest reactions to feel, and the fastest comments to write—especially when the topic is provocative, when most of us are reacting from cache [2].
> Then a second wave of objections is generated by the first wave. Readers come to the thread, see the comment section dominated by those initial 'triggered' responses, and feel some version of surprised-shocked-dismayed at how the commenters all seem to be reacting in that way. This propels them to write defenses of the article, often carefully expressing more moderate or balanced views than the first wave—but they probably wouldn't have been motivated to post anything if there hadn't been the first wave of comments to object to!
> These second-wave comments tend to get more upvotes, perhaps because more people tend to share the more moderate view, but also because those comments tend to be more reflective [2] and therefore better written.
> This explains why the top comment in a thread so often begins (ironically) with "Wow, I can't believe the comments here"—or from the current thread: "All of these comments make me think HN has never interacted with a 5 year old" [3]—followed by a defense of whatever those objections were objecting to. Eventually you get objections to the objections to the objections—which reminds me of the line "My complication had a little complication" from Brazil [4], and also epicycles.
I'm not sure if I'm surprised that dang didn't touch on to mention downvotes as an even more rapid "contrarian dynamic" mechanism; wouldn't it be nice if downvotes had a little more friction, effort required for the action - like qualitative text from the downvoter as to why a comment is being downvoted to then allow OP the opportunity to clarify or expand on their comment - "to be more reflective and therefore better written"? The downvote-comment doesn't have to be identified as being a downvote-comment, showing up as a regular reply.
That added cost/friction may also act as a filter for lazy readers/skimmers or those misinterpreting what's said at first glance, and therefore if forced to include some critical text response along with their downvote then OP and other readers can begin to get to the bottom/foundation of the distaste, giving OP at least some guidance as to why someone/people are downvoting - arguably a valuable learning/crowdsourcing moderation tool/mechanism.
I feel the added cost of time and mental effort for downvotes would add a great balance.
I wonder if there's any value in having a post to HN be, in effect, a "Draft", with a timeout of (say) half an hour. You write it up, but you have time to reconsider and edit before it "goes live" and you're (at least psychologically) committed. Perhaps you have to come back after half an hour and officially approve it? This is starting to sound like work :-)
A dramatic solution, assuming this phenomena is something to be abated, is to simply remove replies. Why does every internet community by default have a feature that steers us to negativity and confrontation. I often find myself scrolling past the replies on here anyway to find the next comment that may be unique, useful and well-thought - not just an objection or tepid agreement to something that’s already been said.
Usually people who design interaction spaces know something about human behavior, spectrum of personality types/needs, social psychology, group dynamics etc and then design the space.
But what has happened in the tech world, is obviously the reverse.
All kinds of contrived/arbit spaces have been created and then behavior of the lab rats within are studied.
This is a poor model of Hacker News comment phenomena. It requires all this extra complexity in the theory (comment “waves” and “triggered” reactions, highly generic stereotypes of whether a responder is reflective and thoughtful, and whether this correlates with moderate opinions).
From an Occam’s Razor point of view, this is a very poor theory, and I’d even go further and suggest it indicates unfair bias on the moderators’ part to implicitly subscribe to this judgment about early / quick responders.
A competing, much simpler theory is that Hacker News, like everything else on the planet, is tribal and political. People add comments to support their tribe, and people use upvotes to support their tribe, while they use FAQ & guideline legalese, downvotes, shadow bans and timeout periods to punish opposing viewpoints and tribes they don’t like.
I think the reason people look past this much simpler theory that comports much better with the evidence is that they want to protect a false sense that Hacker News is democratic and tolerant of unusual views, but it so deeply isn’t.
One of my favorites is a super-long one by a user named bane, about three solutions to speeding up computing: (1) "high" (more RAM, CPU), (2) "wide" (more machines), and (3) "deep" (refactoring), which is what he recommends first. More than once he has rewritten something that was running slowly even on the latest and greatest architectures (perhaps partially because of that), to running on a single machine, even an old personal computer. He reminds us that a modern computer, with its solid-state drives, gigabytes of memory, and multicore gigahertz processors, can take on many large problems, if you just stoop to give the problem a decent amount of attention first, https://news.ycombinator.com/item?id=8902739
Interesting it also involves graph processing, which Bane's comment did. The point is that distributed graph processing frameworks were mostly parallelizing their own overhead, not solving the problem, which could be done on a single machine!
Reminds me of this recent comment on Chuck Moore, of Forth fame, building his own technology stack right down the hardware and squeezing it for performance.
My advice is to lower the value of ideas. A lot of time people think, "If only I had a good idea I would be successful". You will see other people saying things like, "Buy my good idea!". But really, good ideas are a dime a dozen. Good ideas, bad ideas... it actually doesn't make much difference. What makes the difference is execution and timing.
For things that take a long time, timing is essentially random. The world is chaotic. Had I known everyone and their dog would be locked down in their houses for months on end, I would have built something to cater to them. But of course, there is no way to know. I find it amusing that just before the pandemic there was a thread on HN talking about overvalued unicorns and Zoom was up near the top of the list. What would need to happen to make Zoom a household name, people asked?
To be successful, really what you need is execution and to have the patience to wait until what you are doing is relevant. Of course there is the fear that it will never be relevant. However, if you accept the thesis that the good idea is not valuable in itself, then you realise that it is not really valuable to pivot without a really good reason. A good idea that is never relevant is just as worthless as a bad idea that is never relevant. However, even a bad idea that is executed very well and ready when the opportunity arises can be successful.
This one struck me for its tongue-in-cheek levity, credit to haroldgibbons:
My "aha" moment was realizing most of my ideas and most apps out there are complete garbage. Not needed. Damaging, even. 99.9% of all of it.
For example, most "cutting edge" web apps are better off as PHP monoliths. Facebook was a PHP file for a long time. But most apps in general should never make it past being shell scripts, which are better off staying as spreadsheets or better - text files which are better off as pieces of paper whenever possible. And all paper is better off left as thoughts whenever possible, and most thoughts should be forsaken.
For me, it's this comment (https://news.ycombinator.com/item?id=9224) that argued Dropbox wasn't useful and was going to fail. Both the comment and its replies (by Drew at the time when Dropbox wasn't known) really get to me because they remind me to keep an open mind to other people's ideas and have conviction in my own ideas even if there are people who doubt them.
It's very short and not at all in-depth, but this was my favorite comment. It was one of the greatest troll shutdowns I've ever seen: https://news.ycombinator.com/item?id=35083
In that thread the pg - cperciva exchange is exemplary. cperciva is concise and blunt, someone else suggests softening his delivery, and pg replies "actually, if someone is wrong about math you probably should tell him so."
The best part is, he ended up being justified in his self confidence. He was talking about his company Tarsnap, which still seems to be going strong 13 years later, and now has Stripe as a customer.
This reply to a comment about how taking an action on moral grounds might be bad for business:
> Yes, doing the right thing often is dangerous and earns you hatred from other people doing bad things who love the freedom of hiding amongst a herd of other equally guilty people.
> The reason we have so much respect for people who take stand and do what they believe is right is because doing so is so hard. That doesn't mean you shouldn't do it.
I'll probably remember this quote for years to come.
Burnout is caused when you repeatedly make large amounts of sacrifice and or effort into high-risk problems that fail. It's the result of a negative prediction error in the nucleus accumbens. You effectively condition your brain to associate work with failure.
Subconsciously, then eventually, consciously, you wonder if it's worth it. The best way to prevent burnout is to follow up a serious failure with doing small things that you know are going to work. As a biologist, I frequently put in 50-70 and sometimes 100 hour workweeks. The very nature of experimental science (lots of unkowns) means that failure happens. The nature of the culture means that grad students are "groomed" by sticking them on low-probability of success, high reward fishing expeditions (gotta get those nature, science papers) I used to burn out for months after accumulating many many hours of work on high-risk projects. I saw other grad students get it really bad, and burn out for years.
During my first postdoc, I dated a neuroscientist and reprogrammed my work habits. On the heels of the failure of a project where I have spent weeks building up for, I will quickly force myself to do routine molecular biology, or general lab tasks, or a repeat of an experiment that I have gotten to work in the past. These all have an immediate reward. Now I don't burn out anymore, and find it easier to re-attempt very difficult things, with a clearer mindset.
For coders, I would posit that most burnout comes on the heels of failure that is not in the hands of the coder (management decisions, market realities, etc). My suggested remedy would be to reassociate work with success by doing routine things such as debugging or code testing that will restore the act of working with the little "pops" of endorphins.
That is not to say that having a healthy life schedule makes burnout less likely (I think it does; and one should have a healthy lifestyle for its own sake) but I don't think it addresses the main issue.
Thanks for sharing this. Right now I'm burnt out beyond words, having delivered a phase of a huge project, followed by upper management actions that make me feel extremely devalued and dehumanized.
I've already written a list of personal development tasks for the three weeks' leave ahead - I need to up-skill, then find a new employer - which I'll restructure into little wins.
This makes a lot of sense, and chimes with my gut feel based approach of following up a long and difficult bit of work with some quick wins or bug fixes before thinking about starting anything else big.
I've referred to this comment a couple of times in discussions with people I've worked with. It is a great example for many problems of old code bases.
To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation.
> Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.
> The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.
> If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.
Seeing someone else bravely telling their story and account how the biggest tech company mistreated them during an interview too...going as far as trying to steal/patent their work without their consent they demoed during their interview.
I had been telling my very similar story here of my experience for a few years, then to see another say same thing with email evidence was vindicating.
Around that time and maybe before more and more negative posts about said company started and have continued to appear on Hacker News. So her story along many other things going on I believe helped highlight they do evil/aren't to be trusted per the image they once sold.
Overall I'm glad she had the courage to post her experience and in turn help other dreamers/innovators (what my aim was) to not trust this tech company and highlight they are the opposite of the mantra they sold to the public.
[+] [-] saboot|5 years ago|reply
So I did, found a lump, and because I found it early it was removed with no further issue. So that's definitely one of my favorite comments!
https://news.ycombinator.com/item?id=7120102
[+] [-] tcthrowaway|5 years ago|reply
* Mine was discovered super super early, on a scan related for something else
* This was actually so early that it didn’t make sense to operate. The main treatment for testicular cancer is orchiectomy, i.e. total removal of testicle
* If you find a lump, it is by definition much bigger than mine was, and the above doesn’t apply. But if you find a marginal, tiny spot on an incidental ultrasound, ask a doctor about what sizes are risky and consider a second opinion.
* I had something called a frozen section sample. They take the testicle out of the body, but leave it attached. They quickly biopsy part of it. If cancer, remove. If not cancer, put back in. I had this, it was cancer, but I’m nonetheless glad I did. My lesion was so small even then that it plausibly wasn’t cancer
* I had a seminoma. They grow slow, and are benign. It took three years to have a notable changes. If yours is growing faster than that, the odds are much higher it is cancer and a worse kind. Most benign masses are stable and tiny.
* Bank sperm before the operation! You may find fertility significantly impaired. My FSH went through the roof after the operation and my sperm count is like 0.01% of normal. Probably still viable with IVF, but almost zero. I likely had viable sperm before based on the normal fsh
Please don’t be pigheaded about this with your doctor. I did have cancer after all. But I plausibly didn’t, and my urologist recommended waiting + a frozen section sample. This is common in big centers for incidental detection, less common in hospitals that don’t see too many orchiectomies.
[+] [-] tluyben2|5 years ago|reply
[+] [-] SwiftyBug|5 years ago|reply
[+] [-] slazaro|5 years ago|reply
[+] [-] yholio|5 years ago|reply
[+] [-] gigatexal|5 years ago|reply
[+] [-] aleem|5 years ago|reply
> This guy has gone to the zoo and interviewed all the animals. The tiger says that the secret to success is to live alone, be well disguised, have sharp claws and know how to stalk. The snail says that the secret is to live inside a solid shell, stay small, hide under dead trees and move slowly around at night. The parrot says that success lies in eating fruit, being alert, packing light, moving fast by air when necessary, and always sticking by your friends. His conclusion: These animals are giving contradictory advice! And that's because they're all "outliers".
> But both of these points are subtly misleading. Yes, the advice is contradictory, but that's only a problem if you imagine that the animal kingdom is like a giant arena in which all the world's animals battle for the Animal Best Practices championship [1], after which all the losing animals will go extinct and the entire world will adopt the winning ways of the One True Best Animal. But, in fact, there are a hell of a lot of different ways to be a successful animal, and they coexist nicely. Indeed, they form an ecosystem in which all animals require other, much different animals to exist.
https://news.ycombinator.com/item?id=469831#up_469940
[+] [-] jakelazaroff|5 years ago|reply
> Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
>The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.
> I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.
https://news.ycombinator.com/favorites?id=jakelazaroff&comme...
[+] [-] dgellow|5 years ago|reply
https://news.ycombinator.com/item?id=24215601
> The "contrarian dynamic" is that HN threads (and internet comments generally) are largely propelled by people making objections. Cunningham's Law touches on this [1]. The objections come in waves. In the earliest stage of a thread, they tend to be rapid negative reactions to the article. It's not that these are a community consensus, it's that they're the fastest reactions to feel, and the fastest comments to write—especially when the topic is provocative, when most of us are reacting from cache [2].
> Then a second wave of objections is generated by the first wave. Readers come to the thread, see the comment section dominated by those initial 'triggered' responses, and feel some version of surprised-shocked-dismayed at how the commenters all seem to be reacting in that way. This propels them to write defenses of the article, often carefully expressing more moderate or balanced views than the first wave—but they probably wouldn't have been motivated to post anything if there hadn't been the first wave of comments to object to!
> These second-wave comments tend to get more upvotes, perhaps because more people tend to share the more moderate view, but also because those comments tend to be more reflective [2] and therefore better written.
> This explains why the top comment in a thread so often begins (ironically) with "Wow, I can't believe the comments here"—or from the current thread: "All of these comments make me think HN has never interacted with a 5 year old" [3]—followed by a defense of whatever those objections were objecting to. Eventually you get objections to the objections to the objections—which reminds me of the line "My complication had a little complication" from Brazil [4], and also epicycles.
[+] [-] loceng|5 years ago|reply
That added cost/friction may also act as a filter for lazy readers/skimmers or those misinterpreting what's said at first glance, and therefore if forced to include some critical text response along with their downvote then OP and other readers can begin to get to the bottom/foundation of the distaste, giving OP at least some guidance as to why someone/people are downvoting - arguably a valuable learning/crowdsourcing moderation tool/mechanism.
I feel the added cost of time and mental effort for downvotes would add a great balance.
[+] [-] chris_st|5 years ago|reply
[+] [-] jorgesborges|5 years ago|reply
EDIT: suddenly aware of the irony
[+] [-] op03|5 years ago|reply
But what has happened in the tech world, is obviously the reverse.
All kinds of contrived/arbit spaces have been created and then behavior of the lab rats within are studied.
[+] [-] claudeganon|5 years ago|reply
[+] [-] MaxBarraclough|5 years ago|reply
[+] [-] mlthoughts2018|5 years ago|reply
From an Occam’s Razor point of view, this is a very poor theory, and I’d even go further and suggest it indicates unfair bias on the moderators’ part to implicitly subscribe to this judgment about early / quick responders.
A competing, much simpler theory is that Hacker News, like everything else on the planet, is tribal and political. People add comments to support their tribe, and people use upvotes to support their tribe, while they use FAQ & guideline legalese, downvotes, shadow bans and timeout periods to punish opposing viewpoints and tribes they don’t like.
I think the reason people look past this much simpler theory that comports much better with the evidence is that they want to protect a false sense that Hacker News is democratic and tolerant of unusual views, but it so deeply isn’t.
[+] [-] combatentropy|5 years ago|reply
[+] [-] chubot|5 years ago|reply
You can have a second computer once you’ve shown you know how to use the first one.
–Paul Barham
Scalability! But at what COST?
https://www.usenix.org/system/files/conference/hotos15/hotos...
http://www.frankmcsherry.org/graph/scalability/cost/2015/02/...
Interesting it also involves graph processing, which Bane's comment did. The point is that distributed graph processing frameworks were mostly parallelizing their own overhead, not solving the problem, which could be done on a single machine!
[+] [-] postit|5 years ago|reply
[+] [-] MaxBarraclough|5 years ago|reply
https://news.ycombinator.com/item?id=24469625
[+] [-] cpach|5 years ago|reply
[+] [-] higerordermap|5 years ago|reply
[+] [-] tootie|5 years ago|reply
[+] [-] ivars|5 years ago|reply
My advice is to lower the value of ideas. A lot of time people think, "If only I had a good idea I would be successful". You will see other people saying things like, "Buy my good idea!". But really, good ideas are a dime a dozen. Good ideas, bad ideas... it actually doesn't make much difference. What makes the difference is execution and timing.
For things that take a long time, timing is essentially random. The world is chaotic. Had I known everyone and their dog would be locked down in their houses for months on end, I would have built something to cater to them. But of course, there is no way to know. I find it amusing that just before the pandemic there was a thread on HN talking about overvalued unicorns and Zoom was up near the top of the list. What would need to happen to make Zoom a household name, people asked?
To be successful, really what you need is execution and to have the patience to wait until what you are doing is relevant. Of course there is the fear that it will never be relevant. However, if you accept the thesis that the good idea is not valuable in itself, then you realise that it is not really valuable to pivot without a really good reason. A good idea that is never relevant is just as worthless as a bad idea that is never relevant. However, even a bad idea that is executed very well and ready when the opportunity arises can be successful.
[+] [-] chaorace|5 years ago|reply
My "aha" moment was realizing most of my ideas and most apps out there are complete garbage. Not needed. Damaging, even. 99.9% of all of it.
For example, most "cutting edge" web apps are better off as PHP monoliths. Facebook was a PHP file for a long time. But most apps in general should never make it past being shell scripts, which are better off staying as spreadsheets or better - text files which are better off as pieces of paper whenever possible. And all paper is better off left as thoughts whenever possible, and most thoughts should be forsaken.
https://news.ycombinator.com/item?id=24397272
[+] [-] howon92|5 years ago|reply
[+] [-] AlchemistCamp|5 years ago|reply
[+] [-] CapriciousCptl|5 years ago|reply
[+] [-] narwally|5 years ago|reply
[+] [-] anderspitman|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] szhu|5 years ago|reply
> Yes, doing the right thing often is dangerous and earns you hatred from other people doing bad things who love the freedom of hiding amongst a herd of other equally guilty people.
> The reason we have so much respect for people who take stand and do what they believe is right is because doing so is so hard. That doesn't mean you shouldn't do it.
I'll probably remember this quote for years to come.
https://news.ycombinator.com/item?id=23534277
[+] [-] superasn|5 years ago|reply
Burnout is caused when you repeatedly make large amounts of sacrifice and or effort into high-risk problems that fail. It's the result of a negative prediction error in the nucleus accumbens. You effectively condition your brain to associate work with failure.
Subconsciously, then eventually, consciously, you wonder if it's worth it. The best way to prevent burnout is to follow up a serious failure with doing small things that you know are going to work. As a biologist, I frequently put in 50-70 and sometimes 100 hour workweeks. The very nature of experimental science (lots of unkowns) means that failure happens. The nature of the culture means that grad students are "groomed" by sticking them on low-probability of success, high reward fishing expeditions (gotta get those nature, science papers) I used to burn out for months after accumulating many many hours of work on high-risk projects. I saw other grad students get it really bad, and burn out for years.
During my first postdoc, I dated a neuroscientist and reprogrammed my work habits. On the heels of the failure of a project where I have spent weeks building up for, I will quickly force myself to do routine molecular biology, or general lab tasks, or a repeat of an experiment that I have gotten to work in the past. These all have an immediate reward. Now I don't burn out anymore, and find it easier to re-attempt very difficult things, with a clearer mindset.
For coders, I would posit that most burnout comes on the heels of failure that is not in the hands of the coder (management decisions, market realities, etc). My suggested remedy would be to reassociate work with success by doing routine things such as debugging or code testing that will restore the act of working with the little "pops" of endorphins.
That is not to say that having a healthy life schedule makes burnout less likely (I think it does; and one should have a healthy lifestyle for its own sake) but I don't think it addresses the main issue.
link to comment: https://news.ycombinator.com/item?id=5630618
[+] [-] not_the_nsa|5 years ago|reply
[+] [-] noneeeed|5 years ago|reply
[+] [-] nullsense|5 years ago|reply
[+] [-] non-entity|5 years ago|reply
[+] [-] McKayDavis|5 years ago|reply
https://news.ycombinator.com/item?id=24360449
[+] [-] dlkmp|5 years ago|reply
I've referred to this comment a couple of times in discussions with people I've worked with. It is a great example for many problems of old code bases.
[+] [-] ffpip|5 years ago|reply
On Catering to the privacy crowd- https://news.ycombinator.com/item?id=24123463
Users of peanut butter shouldn't have to think about whether it contains glass and razors - https://news.ycombinator.com/item?id=20634128
On Telegram seven years ago - https://news.ycombinator.com/item?id=6949814
Indian Govt blocks a PHP project for terrorism and anti national content - https://news.ycombinator.com/item?id=8820378
On Show HN:Dropbox - https://news.ycombinator.com/item?id=9224
Did you win the putnam? - https://news.ycombinator.com/item?id=35079
[+] [-] onekorg|5 years ago|reply
To avoid network congestion, the TCP stack implements a mechanism that waits for the data up to 0.2 seconds so it won’t send a packet that would be too small. This mechanism is ensured by Nagle’s algorithm, and 200ms is the value of the UNIX implementation.
> Sigh. If you're doing bulk file transfers, you never hit that problem. If you're sending enough data to fill up outgoing buffers, there's no delay. If you send all the data and close the TCP connection, there's no delay after the last packet. If you do send, reply, send, reply, there's no delay. If you do bulk sends, there's no delay. If you do send, send, reply, there's a delay.
> The real problem is ACK delays. The 200ms "ACK delay" timer is a bad idea that someone at Berkeley stuck into BSD around 1985 because they didn't really understand the problem. A delayed ACK is a bet that there will be a reply from the application level within 200ms. TCP continues to use delayed ACKs even if it's losing that bet every time.
> If I'd still been working on networking at the time, that never would have happened. But I was off doing stuff for a startup called Autodesk.
> John Nagle
https://news.ycombinator.com/item?id=9048947
[+] [-] ananthrk|5 years ago|reply
[+] [-] shakethemonkey|5 years ago|reply
[1] https://news.ycombinator.com/item?id=11959139
[2] http://www.righto.com/2016/10/inspired-by-hn-comment-four-ha...
[+] [-] dshacker|5 years ago|reply
[+] [-] tptacek|5 years ago|reply
https://news.ycombinator.com/item?id=9282104
Followed closely by 'tzs on Missile Command:
https://news.ycombinator.com/item?id=6228350
[+] [-] yellowstuff|5 years ago|reply
https://webcache.googleusercontent.com/search?q=cache:7Ms9oq...
[+] [-] saeranv|5 years ago|reply
[+] [-] tome|5 years ago|reply
[+] [-] paul7986|5 years ago|reply
I had been telling my very similar story here of my experience for a few years, then to see another say same thing with email evidence was vindicating.
Around that time and maybe before more and more negative posts about said company started and have continued to appear on Hacker News. So her story along many other things going on I believe helped highlight they do evil/aren't to be trusted per the image they once sold.
Overall I'm glad she had the courage to post her experience and in turn help other dreamers/innovators (what my aim was) to not trust this tech company and highlight they are the opposite of the mantra they sold to the public.