156 karma · joined June 14, 2017
I agree though that employers have naturally more negotiation power in the vast majority of cases.
But does that mean that it is not worth doing?
For these fundamental reasons economics is “hard”, but I argue that it is still worth doing because economic policies have a big impact on people’s lives, and partial understanding is better than nothing.
I’d just keep in mind that there are no guarantees that kids will share our passions, even with the best approach. Humans are complex systems - it is very hard (and you would need need a lot of data) to make any general statement about things like this.
(What would you say if your employer or client demands to pay a bit less after signing a contract with you?)
Also in the EU, having a monopoly is not illegal (as long as it was obtained fairly) - abuse of monopoly power is.
Surely being a monopolist means you are subject to additional rules, no doubt about that.
A fully unrestricted phone might have cost more (because it is not cross subsidized by App Store profit), so it is unfair to demand full functionality at the subsidized price.
Telegram should rather make a convincing argument why Apple should be considered a monopolist, which is not clear to me given the overall <30% market share of Apple in the phone market.
The change introduced by the 2006 PAEA impacts however the funding of health care benefits of retirees, which have to be funded at 100%. This is not required of private sector companies.
Additionally, to build up this future retiree health benefits fund, a very front loaded schedule of about $5.7B yearly between 2006 and 2016 was chosen. In fact, the USPS was not able to fulfill this schedule and defaulted on multiple payments.
Best source I have found: https://fas.org/sgp/crs/misc/R40983.pdf
> If a plan is fully funded, the minimum required contribution is the cost of benefits earned during the year.
The USPS however, needs to fund not only the current year’s expenses, but also all expenses for the 50 following years. No one else needs to do this.
It seems that most observers agree that this is not the case, so it is unclear how you came to the exact opposite understanding. E.g. https://www.bloomberg.com/opinion/articles/2018-04-04/congre... mentions
> The law requires the Postal Service, which receives no taxpayer subsidies, to prefund its retirees' health benefits up to the year 2056. This is a $5 billion per year cost; it is a requirement that no other entity, private or public, has to make.
Unfortunately it is not that simple.
For one, it relies much on hypotheses about internal though processes, which makes it basically unfalsifiable. Then the author is in my view shooting himself in the foot with the bowling analogy, namely by describing how he noted that he didn’t improve anymore and went to ask a colleague for advice. How would the same not be possible or even likely for the “expert beginner”?
All of this is much more easily and briefly explained by motivation - for many people in technology, technology is simply not a passion! For them it is just a tool and like also the article mentions, there are few reasons in many companies to spend more time on perfecting your craft - in fact, it might be strictly worse than building career-enhancing relationships. This is especially true as someone not in a technical position is often not able to assess the quality of the output.
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
Despite the chosen solution on SO - and from how the question is stated, it is clear that the asker only wanted confirmation -, sudo has its uses, even if is not perfectly secure (especially with the default configuration).
I suggest a more sensible approach for all security-related discussions: All systems have vulnerabilities, but some improve your security posture.
> [All] technical challenges [...] will not be magically solved by using microservices
Is the key statement of your article, then you should really consider adding a lot of nuance or not publishing it at all.
Let's assume that everything is political. We could certainly argue that every concept and every thing created by human is in some way political.
But then what? If everything is, what does it mean for a thing to be "political"? That concept has simply become empty and useless.
I am fully on board with the overall sentiment of the article that there is some irreducible complexity that one cannot avoid. Often it comes straight from the business domain or entity the code is modelling, and then, sure, you cannot make it any easier, otherwise you are not solving the problem and users will be unhappy.
However, then the author goes too far: > Accidental complexity is just essential complexity that shows its age.
You can absolutely add heaps of unnecessary complexity; in fact, this is almost surely what you will get by attempting to cover every possible future use case and evolution scenario, or to cater to every minor aesthetic concern (e.g., "I need to be able to replace my cloud provider / DB / message queue / user notification medium / etc by changing just one line!").
It takes humility to admit that getting the balance "right" from the start is difficult, and often the only way to improve is to accept some badness now and revisit the decision later with more information.
The quote however seems to be saying that we (as software engineers) always get it right, just later things change and our choice does not appear right anymore. This mindset is counterproductive, as admitting flaws is the first step to improve.
To be specific, I mean comments a) that point out a flaw in an argument, often on narrow technical grounds, b) where a charitable reading of the original argument indicates that the writer would very likely have been aware of this flaw, c) that do not provide a revised version that would be correct.
To me, such comments come off as dismissive - even insulting -, and because of this they almost never result in a good discussion.
Most often, such comments are also facile: It is easy to point out facts that hold in edge cases, but in software, as in every engineering discipline, any real world decision involves trade-offs. And as a practitioner, I find it very useful to learn how others have made trade offs on real world problems, exactly because edge cases are often not informative. Whoever comes forward to discuss their solution on such problems deserves praise, because they know that their decision is necessarily not perfect, and can be criticized. A good critique then amends the original statement to provide a better solution instead of dismissing it because it is not universally applicable.
This is not about pedantism (which is itself a highly subjective insult that never does any good) - a good comment on a minor point can be enlightening with the right context, and when respecting the original context.
I do not think this kind of destructive behavior is currently well covered by the HN guidelines, so here is a proposal of what I would add (@dang)
"If you want to point out an incorrectness in a statement, do not assume whoever made the statement was not aware of it - this often comes off as dismissive. Instead, attempt to provide a synthesis of the original statement and your criticism that would be correct from your point of view."
Using this guideline, here is how I would rephrase the examples from the article: - "Garbage collectors work in many cases, but I have spent many hours dealing with dangling memory reference issues, so in this and that case I recommend instead..." - "Note that TLS does not provide sufficient protection against nation state adversaries because... If you have to deal with this threat scenario, I recommend ..." - "In performance critical scenarios, you can avoid paying the cost of bounds checking as long as you..."
I cannot comment on the specific point raised here, it’s been a while since I read Milgram’s book, but I remember that many different experimental conditions have been tested, and I don’t think that picking out a single one of them and reinterpreting some minute aspect changes the overall significance.
Moreover, if you’re in the sorry situation of being on the receiving end of some punishment ordered by an authority figure, like the “learner” in the experiment, does it really matter that whoever doles out the punishment, does so not because of an explicit order but because he is being coaxed in various ways to obey?
One key point of the experiments is that the overseer has no formal authority over the teacher at all, and the fact that a lab coat and some easy psychological conditioning steps are sufficient to make over half of the population obey should give anyone food for thought.
Skipping a few steps of thought here, but my conclusion is that we are all being groomed to obey authority figures – the “con” aspect is not decoupled from that; it is one of many mechanisms that are used to exert control. What Milgram showed is a practical consequence of that process.
I wonder if there is some hidden irony, because it appears to me that we sometimes assume that everyone else has a simple and straightforward job that we could probably automate.
If you introduce new dependencies, or the latest free monad transforming framework when there was none, then I’d be wary as well.
I have this article printed out in a drawer for these cases: http://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax...
With DAX, Microsoft has extended the PivotTable model (instead of the relational model), and they deserve full respect for trying something new in this space.
Is it a simpler model? I kinda like it, but don’t think it is simpler.