What to Know Before Debating Type Systems (2008) - <AUTHOR> https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ <comment><USER2> Chris Smith - who wrote the original piece years ago - added a current prologue to the text. I think part of it is an excellent summary so I quote this part here:

> If pressed for an answer, though, yes I still do believe in the central > conclusions of the article. Namely:

> That "static typing" and "dynamic typing" are two concepts that are > fundamentally unrelated to each other, and just happen to share a word.

> That "static types" are, at their core a tool for writing and maintaining > computer-checked proofs about code

> That "dynamic types" are, at their core, there to make unit testing less > tedious, and are a tool for finding bugs.

> That the two are related in the way I outline: that one establishes lower > bounds on correctness of code, while the other establishes upper bounds, and > that questions about their real world use should come down to the > possibility and effectiveness of addressing certain kinds of bugs by either > computer-checked proof, or testing.

EDIT: When I wrote this comment the post linked to Steve Klabnik's 'reprint' of the temporary lost original article. Currently it links to the original. The 'reprint' missed the prologue.

<comment><USER3> Doesn't hold water, imo. If dynamic and static typing were really independent concepts, then why are languages only one or the other, never both? I explained my take on dynamic versus static typing here:

[https://stackoverflow.com/a/28096079](https://stackoverflow.com/a/28096079)

> The primary difference between static and dynamic languages, in my view, is > this: in static languages, expressions have types; in dynamic languages, > values have types.

Read the rest of the answer for more details in the context of Julia, which, as a dynamic language with a sophisticated type system, really crystallizes the distinction.

<comment><USER4> Given algebraic type (as in Haskell - data List a = Nil | Cons a (List a)), you can have static type verification (map :: (a -> b) -> List a -> List b) and dynamic dispatching for situation in concrete part of a program:

      pairwiseReduce :: (a -> a -> a) -> List a -> List a
      pairwiseReduce f (Cons a1 (Const a2 as)) = Cons (f a1 a2) (pairwiseReduce f as)
      pairwiseReduce f as = as

We fix the type, but concrete instantiation of a type may vary in run-time, so we pattern-match: the list can have at least two elements (first case) and we reduce them and the rest of the list or it has less than two elements and we leave it as it is.

I took my time and read about Julia's type system. It is really the worst from both worlds: it does not allow for tagged unions (like List I declared above), it does not allow for adhoc polymorphism (1+2 gives error for floating type and evaluates for integers), there are no type classes (that adhoc polymorphism thing) and, thus, no good guarantees for whatever substitution for GADTs Julia has. And it also has inheritance which makes type inference exponentially harder in simple cases.

So I urge you to take your time and read about Haskell's type system. It really allows you to have static and dynamic types and vary their presence and utility as you see fit.

<comment><USER5> ML Style constructors are not particularly idiomatic, but you can write basically the same thing in Julia:

        struct Cons{T, S}; head::T; tail::S end
        pairwiseReduction(f, a::Cons{T, Cons{S, Tail}}) where {T,S,Tail} = Cons(f(a.head, a.tail.head), a.tail.tail)
        pairwiseReduction(f, a) = a

([https://github.com/thautwarm/MLStyle.jl](https://github.com/thautwarm/MLStyle.jl) if you want the syntax) but that's somewhat beside the point.

I think the primary problem here is one of terminology. Take Stefan's quote from the post you're responding to:

> The primary difference between static and dynamic languages, in my view, is > this: in static languages, expressions have types; in dynamic languages, > values have types.

There is a clash in terminology here. People coming from a static languages background would use the term "tag" for what dynamic languages people call a type. There isn't really a super good word in the dynamic languages world for what static languages people call a type, and the word type is generally re- used, since the distinction isn't as important (generally there is an embedding of the tags into the type system, so using "type" for both can be sensible). I'm gonna adopt (my best interpretation of) the static languages terminology here for this comment.

Some languages have both types and tags. The biggest difference then between static and dynamic languages are which of the two is primarily dispositive (in the sense of determining the semantics of the language). In dynamic languages, the tags are, in static languages the types are. This choice has deep seated implication for the kind of programs that can be written and the behavior of the program.

In fact, you sometimes end up in situations where static languages have multiple tag systems (but generally only one type system) and dynamic languages have multiple type systems (but generally only one tag system). In julia, the tag system is primary, but we have a very rich type system that is embedded in the tag system by parametricity and is used for dispatch. This type system is constructed in such a way that the subtyping relationship is induced by tag system (for types T, S, (T <: S iff for all values v s.t. tagof(v) <: T, tagof(v) <: S)) [1]. You basically want to choose a decidable type system that satisfies this constraint, but is at the same time sufficiently expressive to be useful for what people want to do.

We also have another, larger type system that is used for inference judgements, but that is generally transparent to the user. It is in principle possible to type check over any of these type static system, but type checking is not part of the semantics of the language.

The problem with statements like "Julia's type system does not allow for X", is that it presumes that the type system having some feature is a pre- requisite for having the corresponding functionality. So while Julia's type system does happen have support for unions (and universally qualified unions), the significance of that is for dispatch, not for whether the language can have expressions that can take on values of different tags.

In any case, I can assure you that many people working on Julia are well familiar with Haskell's type system. Hopefully I was able to convince you that there is at least something interesting about the way Julia's type system works.

[1] I should credit the Northeastern PL group for the term "tag-based semantic subtyping" here to describe this notion ([https://github.com/julbinb/ftfjp-2019/blob/master/paper/mini...](https://github.com/julbinb/ftfjp-2019/blob/master/paper/minijl- ftfjp2019.pdf)).

</comment></comment></comment></comment><comment><USER6> > Fallacy: Dynamically typed languages provide no way to find bugs

>

>A common argument leveled at dynamically typed languages is that failures will occur for the customer, rather than the developer. The problem with this argument is that it very rarely occurs in reality, so it's not very convincing. Programs written in dynamically typed languages don't have far higher defect rates than programs written in languages like C++ and Java.

Having written software for paid work in both Java (static typing) and JavaScript (dynamic typing), I agree. A statically typed language does not improve the quality of the software that gets written, assuming equal skill in both languages.

The kinds of bugs that get caught by a static type system are also caught by a good suite of automated tests, where every test is written _before_ the production code that makes it pass.

The article doesn't mention refactoring, but this is where a static type system really shines. The ability to refactor an entire code base with confidence at the click of a button is extremely useful and the thing I miss most when using dynamically typed languages. You can get some of that with modern editors, but it's just a pale shadow of what you get with static typing.

<comment><USER7> > The kinds of bugs that get caught by a static type system are also caught by > a good suite of automated

This is correct in theory, but to get the same benefit you'll need to write _all_ the tests that the static language would guarantee. That's both relying on the programmer being always correct and that they think the time writing those tests is worth it.

<comment><USER8> Stating typing you have to explicitly opt out of, and automated tests you have to go to quite some effort to explicitly opt into, and most teams I've been on have been quite poor at this opting in.

</comment></comment></comment><comment><USER9> Posted at least 20 times but here are the discussions:

2015: [https://news.ycombinator.com/item?id=9777485](https://news.ycombinator.com/item?id=9777485)

2011: [https://news.ycombinator.com/item?id=2093926](https://news.ycombinator.com/item?id=2093926)

2009: [https://news.ycombinator.com/item?id=849726](https://news.ycombinator.com/item?id=849726)

As for year, 2008 is an upper bound ([https://web.archive.org/web/20080802234250/http://www.pphsg....](https://web.archive.org/web/20080802234250/http://www.pphsg.org/cdsmith/types.html)), so we'll put that above unless someone finds it earlier.

<comment><USER10> Super offtopic, but I'm curious why y'all haven't taken the dev time to implement even primitive dupe detection/reposting/re-linking on HN.

Writing scripts to do repetitive human tasks is sort of hacker 101 isn't it?

<comment><USER11> I suppose it's because reposting is not considered an issue if some time has passed since the last submission

<comment><USER12> Given that the same articles come up over and over again, and attract upvotes and comments, it seems clear that the userbase gets value out of reposts.

Perhaps the HN software should turn the knob the other way, and automatically repost old links which got a lot of attention previous times.

<comment><USER13> I think I'm comfortable with the minimal amount of algorithm in my news feed, and let humans drive the rest.

</comment></comment></comment></comment></comment><comment><USER14> My background is php and then javascript. My first experience with 'types' was learning that apparently javascript's implicit type conversion was not normal and actually pretty bad. That made sense to me.

Then I learned about explicit types via TypeScript, and that made sense to me too, although I could imagine how this could explicit typing could get in the way of my prototyping, small projects, or REPL-driven development.

Now, a few years later, and having learned a bunch of new languages, both explicitly and implicitly typed, I'm mostly wondering why I'd go for anything that isn't _gradually_ typed as an ideal approach.

I get the impression that the core discussion is explicit vs implicit (correct me if I'm wrong), and I can see how in some cases enforcing explicit typing is worthwhile, but for most of the work I actually do, it seems like the best solution is something gradual and flexible. Typescript, or perhaps some (improved) version of Elixir/Erlang's Dialyzer, or Clojure's spec: flexible enough to allow for said prototyping, small projects, and REPL-driven development, but gradually rigid enough to be useful when things grow larger and more solidified.

<comment><USER15> _> I'm mostly wondering why I'd go for anything that isn't gradually typed as an ideal approach._

In some ways, gradual or optional types give you the best of both worlds. You aren't obligated to submit to the whims of the type checker when you don't want to, but you can elect to get the safety of types where it matters. You can get the brevity of dynamic typing and the safety of static types.

But, in other ways, they give you the worst of both worlds. If you have any sufficient fraction of typed code in your program, then you will feel pressure to structure even the untyped parts of your program in ways that play nice with static typing. Some API design choices are more "typable" than others, and having static types at all discourages you from some interesting API choices.

In order to play nice with untyped code, most gradual and optionally typed languages are deliberately unsound. There are holes in the type system that can't be closed. That means compilers cannot rely on types for optimization purposes.

You end up with the rigidity of static types and the performance of dynamic types.

<comment><USER16> I wonder if coming from the other way would be acceptable for fans of dynamic typing.

Instead of adding types gradually to a dynamic language (like Typescript sorta does with Javascript), we could add type-checking features that enable a kind of "statically-checked duck typing". Complete inference (like Elm, Crystal or Haskell) gets you halfway there – most of the time you don't have to write method/function signatures.

Then add structural typing like Extensible Rows [1] or Elm Records [2], or something that type-checks based on the structure instead of classes, and it allows you to have the compile-time type-checking of Interfaces or Generics/Templates without the extra typing. Then you can add explicit generics/templates later if you want.

Both Crystal and Elm get very close to that for me, but not 100%. I honestly think that this is a safer bet than gradual typing that could lead to very similar results, but I don't know how feasible or acceptable to mainstream programmers this is.

[1] [https://github.com/tomprimozic/type- systems/tree/master/exte...](https://github.com/tomprimozic/type- systems/tree/master/extensible_rows)

[2] [https://elm-lang.org/docs/records](https://elm-lang.org/docs/records)

</comment></comment></comment><comment><USER17> It's quite interesting seeing the polarization of people's opinions on type systems. I have friends who adamantly argue that static types slow them down and prevent them from adapting quickly. On the flip side I have friends who claim they cannot write code without static types and that JavaScript is unusable.

When really, both styles have their value. Static types are very useful and do provide some nice safety. However, static types can also be quite annoying and force you to acquiesce to the type system. You have to learn to "speak" types, which can be very tricky. There's a joy that comes with the freedom of no static types.

<comment><USER18> > You have to learn to "speak" types, which can be very tricky. There's a joy > that comes with the freedom of no static types.

If you struggle with "speaking types" then that's an indication that you don't understand the domain of values your code works with. Having a solid plan for exactly what shape your data can take is empowering, not restrictive. To some extent, certain restrictions provide greater freedoms in the sense that you can make more accurate assumptions about your data without needing to perform a bunch of run-time checks or write hundreds of unit tests to ensure your code works in all possible situations.

<comment><USER19> Most often in imdustry, you _have_ to begin any complex project without a deep understanding of your domain values, because that understanding only comes iteratively. In my experience, the biggest drawback of static typing is that it forces you to design your types when you still don't have enough knowledge, and changing it later is painful.

<comment><USER18> > In my experience, the biggest drawback of static typing is that it forces > you to design your types when you still don't have enough knowledge, and > changing it later is painful.

I 100% understand where you're coming from, but I view this as an _advantage_ of static type systems. The "pain" is you having to go through your code and make sure that you change your usages of given types to match the new definitions, right? This is forcing you to make sure your code is still correct with respect to the types.

Most dynamically-typed languages let you skip this part, but this causes you to lose clarity. Is your old code still correct? Or is it just _mostly_ correct? Are there new unexpected edge cases being introduced that you didn't bother to go check on due to faulty now-outdated assumptions?

Changing your types is a pain, I agree. But programs are just about data transformations, and types are representations of the shape of those data. Changing your types without changing every part of your program that touches those types inherently means that your program is now running on invalid assumptions. Sometimes it works fine, but I think it is better to _know_ it's fine than to just say "Well, it seems to work in most cases."

<comment><USER19> The risk you describe is real, but good testing coverage lowers it in a way that I find way more efficient than static type checking. When I have that good coverage - which for me means the full pyramid of testing, not just unit tests - I almost never find that problem.

Refactoring when you change your understanding of the domain can be a lot of work also when you have dynamic typing and lots of tests, but if the tests are well designed, I rarely feel that as painful as it was when I felt I was battling with the type system.

PS: my main experience with static typing was with c++, it's possible that more modern type systems could have improved the situation.

</comment></comment></comment></comment></comment><comment><USER20> As someone working in dynamic languages for years, I've noticed a certain trend in arguing about type systems.

People will ARGUE about the benefits of compile-time checking.

However, when people point to concrete benefits, they tend to point to TOOLING communication. (e.g. IDEs supplying functions/variables that provide the necessary type) during writing.

Rarely do they notice these two are not the same thing.

I'm not in a place to say which is objectively correct (I'm both biased and without the right kind of data), but I've seen this distinction come up time and time again. I think it's the most interesting part (also the only part that is interesting) about typing disputes.

<comment><USER21> > Rarely do they notice these two are not the same thing.

Types enable better tooling. That's why people mention tooling when types come up.

<comment><USER20> My point being that when I ask why static is better (from people arguing that), they'll talk about compile-time checks, they won't talk about the tooling.

When I ask them to show me examples, they don't point to bugs that were prevented by compile-time checks, they'll point to how they find it easier to write code because the IDE suggests things.

<comment><USER16> I think it's hard to point to "bugs prevented by compile-time checks" because of the nature of type-checking.

I could just say that every time the compiler refuses to compile my code due to a type error a bug is averted. Typos, wrong method signatures, interfaces not implemented correctly. All those things had the potential to be bugs. Small, detectable and perhaps even non-breaking, but it's still good to catch them early on.

And of course, most of the time a good enough test suite would catch them. But having the compiler warning you is so much faster! And much more reliable too, because I'm not perfect and sometimes I make mistakes in my tests.

</comment></comment></comment></comment><comment><USER22> There is an argument that a static type system is a set of built in unit tests, that you can activate by adding a command word in a particular position.

And that the test harness on code in a dynamic languages is a domain specific compiler.

The problems come when you want to turn off specific type tests for a particular bit of code because it is deliberately bending the rules (I see this a lot in Go), or the domain specific compiler you've built isn't comprehensive in its coverage not just of lines of code, but the structural complexity of the code.

</comment><comment><USER23> I recently implemented a simple object system [0] using only closures and macros in a Lisp-dialect [1] I'm working on.

One thing that struck me is how little it bothers me that objects look like functions from the outside, and that any callable value could be used in their place.

It helps that the whole thing is quarantined in a separate library and that objects live in a separate namespace. And that it rests on top of a strongly typed environment.

Judging a type system outside of its context based on some arbitrary check list is pretty useless from my experience.

[0] [https://github.com/codr7/g-fu/blob/master/v1/doc/functional_...](https://github.com/codr7/g-fu/blob/master/v1/doc/functional_objects.md)

[1] [https://github.com/codr7/g-fu/tree/master/v1](https://github.com/codr7/g-fu/tree/master/v1)

</comment><comment><USER24> > I give the following general definitions for strong and weak typing, at > least when used as absolutes:

> Strong typing: A type system that I like and feel comfortable with

> Weak typing: A type system that worries me, or makes me feel uncomfortable

What is he talking about? Is he trying to make a point? I always understood the difference to be mostly about implicit type conversions. I think weak- typing is also likeable.

<comment><USER25> I think he's trying to say that "strong-typing", in practice, _as used by some speakers_ implies a static type system. And when used by other speakers does not imply a static type system.

</comment></comment><comment><USER26> Note that the original is back up again now (at new location). Linked in first paragraph.

<comment><USER27> Thanks! We've updated the link from [http://blog.steveklabnik.com/posts/2010-07-17-what-to- know-b...](http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-before- debating-type-systems).

</comment></comment><comment><USER28> For some languages it's more about providing features for the IDE and less about providing features for the language itself. It's probably the main reason Microsoft started working on TypeScript for example.</comment>


Launching a Startup in a Day - <AUTHOR> http://www.forbes.com/sites/rajatbhageria/2017/01/13/can-you-build-a-startup-i-a-day-i-tried-and-heres-what-happened/#36f81ed77a54 <comment><USER2> Great write-up. There is truly no better way to learn about starting a business than actually starting one, no matter how small and simple it may be.</comment>


Building a nuclear reactor at home – from scratch - <AUTHOR> http://3.14.by/en/read/building-nuclear-reactor-at-home

<comment><USER2> It's an April fools joke, as described in the forum

Edit: see the second post: [http://3.14.by/forum/viewtopic.php?f=10&t=1396](http://3.14.by/forum/viewtopic.php?f=10&t=1396)

<comment><USER3> These guys make a real Tritium betavoltaic battery [http://www.citylabs.net/](http://www.citylabs.net/)

I bet if you had enough tritium keychain fobs, you could power something via a solar panel though.

</comment></comment><comment><USER4> Interesting that fusion is dismissed so quickly - the Farnsworth-Hirsch fusor is probably the most common DIY nuclear reactor. (It is of course a net energy sink.)</comment>


Ask HN: Docker for newbies?  - <AUTHOR>

If I've been programming for less than a year should I worry about Docker? <comment><USER2> Docker is a useful tool that solves problems you likely don't have yet. It wouldn't hurt to learn docker, but I'd say don't worry about it.</comment>


What Rock Climbing Taught Me About Engineering - <AUTHOR> http://flatiron.engineering/culture/2017/06/14/What-Rock-Climbing-Taught-Me.html <comment><USER2> This is a really stupid article, painfully trying to find a connection between 2 activities in an attempt to sound insightful. Just climb, and don't try to pretend you are a monk finding divine insight in unlikely places.

And also, if you're writing design documents for trivial features, I'm glad I don't work at your company.

<comment><AUTHOR> Designing software related to healthcare / electronic medical records requires more thoughtfulness than other kinds of development.

<comment><USER3> And probably less than some others.

</comment></comment></comment><comment><USER4> Having never been rock climbing before - how hard is it actually to get into?

I suppose it really depends on where you live (the author mentioned using climbing to get out of the gym, but I think that's the only place I ~could~)

<comment><USER5> I've been a gym climber for about ten years, never felt any urge to take it outdoors. Great community, very easy to get into, addictive as hell.

In fact, my local bouldering gym has a co-working space, I set up with my laptop and jam out in javascript all day, with periodic breaks for climbing. It's great. One of the gyms around here even has a weekly "startup night."

Personally, I'm partial to bouldering, where the walls top out at about 12-16 feet, and there are no ropes (18-24" padded floors for accidental landings), so I can do it without a partner.

<comment><USER6> Wow, that sounds like the perfect set up, yet I've never heard of anything like it. Where is this place?

<comment><USER7> I know of a great one in Boulder and another in Denver. ;) Also the top rope gyms often times have sections like this around here, in my experience as a novice it can be hard to find problems(routes) that are easy enough for me to solve.

<comment><USER8> Are you talking about bouldering problems or top rope problems?

If you're talking specifically about top rope problems, a great way to up your game is to gain a reputation as a really good belay partner. It sounds weird, but spending time on belay teaches a whole lot about tempo. In my experience (I'm a mediocre climber), tempo is the biggest thing that separates novice climbers from mediocre climbers.

Otherwise, climbers tend to be extraordinarily friendly people. If you're stuck on a problem, feel free to ask someone for beta (advice on a problem). There is some etiquette involved (ie - don't ask someone who is on belay), but as long as you're humble, you will find climbers who will help you solve problems you once thought were insurmountable.

<comment><USER7> Most of the top rope gyms have challenging bouldering problems for my skill level since it really isn't their focus so it was hard to learn without doing the same problem over and over. Which was why I was recommending going to a gym that focuses on bouldering if you want to learn it. Just more fun stuff to monkey around on.

As for being helpful, I couldn't agree more. The culture is much nicer and more inclusive than any other sporting group I have seen.

</comment></comment></comment></comment></comment></comment><comment><USER9> The site appears to refuse scrolling after my ad blocker prevents a pop up from appearing...

Providing article text here, in case others run into the same issue.

\---

In the past five years, rock climbing has ridden high atop the wave) of newly expanding fitness activities, and distinguished itself as a hip way to stay in shape. Climbing has lured people of all backgrounds and professions, and created communities of enthusiasts who are eager to break the monotony of the traditional gym. Routes up the climbing wall have a wide range of difficulty grades, and require a type of physical problem solving that is absent from weight training. In fact, even climbing terminology reveals that problem solving is a core part of the culture. Paths up a wall are often referred to as "problems", different types of hand and foot holds have specific, technical names, and the <e...](https://en.wikipedia.org/wiki/Glossary_of_climbing_terms">Glossary) of Climbing terms Wikipedia page has hundreds of terms that I've never even heard of. It is no surprise to me that so many technically-minded people have adopted climbing as a hobby.

I think climbing has more to offer than helping you get ripped. Since I began climbing in college, I've learned a lot about problem solving from observing other climbers, thinking critically about my own technique, and receiving great advice. Moreover, many of these lessons have reverberated with elements of our engineering culture at Flatiron. In this post, I'll lay out a few observations from climbing that have made me a better engineer, and detail how Flatiron has built processes and adopted](https://www.flatiron.com/values">adopted) values similar to those of rock climbing.

Strive to preview the route

Some of the best climbers spend several minutes before each section of a climb looking ahead at how they might overcome the next set of problems. They estimate how much effort the section will require, create a plan for navigating the holds, determine what gear will be required, and importantly look for the next place to rest and reassess.

When I started climbing - much like when I started working as an engineer - I had a thoroughly naive planning process. I would walk up to a problem, throw myself onto the holds and head right up until I found myself stuck and confused. By watching other climbers, I have developed an appreciation for planning and estimation. Investing more time up-front towards thinking about the nuances of a problem can reveal new ways of solving it that may be drastically simpler and reduce technical debt in the long run.

At Flatiron, "design documents" are one way that we structure planning and estimation without sacrificing velocity. Engineers may write a design document for anything from a small feature to a large system, with the goals of planning out a solution, communicating with other teams, and soliciting 30%) feedback. Writing design documents, even for seemingly trivial features, has forced me to think through my plans more rigorously. Sometimes, a design document leads me to change my approach to a problem all together.

Be self-critical

In climbing, as in life, the difficulty of a problem can be mitigated by implementing a more effective technique. I have often spent twenty minutes failing to get more than half way up a route only to watch another climber casually climb the whole thing forward and backwards by making a slight alteration to my approach. Strength is certainly a factor in some cases, but more often, the other climber has a better sense of technique - shifting her weight gradually and using holds in non-intuitive ways.

Watching the elegant technique that other climbers employ to solve certain problems has inspired me to be self-critical of my methodology. Over time, being self-critical has helped me develop the intuition to recognize when I powered through a move to compensate for sloppy technique, and how I could have solved a problem differently.

Being vocally self-critical is actually one of our core values at Flatiron. This value can manifest during a monthly retro, an incident post-mortem, or even on a casual whiteboard design session. I am always impressed by how my colleagues are able to avoid getting attached to their ideas and ask "what are the drawbacks of this design?" The culture of vocal self-criticism has helped us re-visit stale processes and designs when we otherwise may have accepted the status-quo.

Design human-proof protocols

Climbing can be a dangerous activity. There is an undeniable risk in being held 50 feet above the ground by harness and rope, secured by nothing but your trusty college buddy. This risk multiplies when you leave the gym and head outdoors, where you must set up anchors and tie knots on your own, rely on your teammates, and navigate uncertain holds.

In order to mitigate this risk, the climbing community has developed a variety of safety protocols with the goal of human-proofing the activity as much as possible. Critical climbing gear like carabiners almost always have a safety, such as a foolproof locking mechanism. Load bearing anchors are often set up with 2x or 3x redundancy. Most importantly, even the simplest activities that require communication have a defined checklist or set of commands. For example, the belay](https://en.wikipedia.org/wiki/Belaying#Communication">belay) protocol defines precisely how to communicate as one teammate secures the other while ascending a wall.

Rock climbing is undoubtedly safer because of protocols that avoid human mistakes. Learning about climbing protocols has helped me realize the value of automation and checklists for engineering operations. One protocol that has helped me avoid countless mistakes is Flatiron's culture of creating on-call and deployment playbooks. Our playbooks have been a safety net for me during my first months in the on-call rotation; they have helped us on-board team members quickly and expand our bus-factor;) and they have served as documentation for various systems and their dependencies. A culture of playbooking aggressively has helped us work towards our goal of being able to easily train our own replacements and strengthen our resilience as a team.

 Climbing has helped me learn a great deal by overlaying physical and technical problem solving. I'm grateful to the many mentors I've had at the climbing gym, and also to the great mentors at Flatiron!

<comment><USER10> Can you please put that in a pastebin.ca and provide the link, rather than the whole article text?</comment></comment>


Childhood Gender Dysphoria: An Endocrinologist's Evaluation of I Am Jazz - <AUTHOR> http://www.thepublicdiscourse.com/2018/04/21220/ <comment><AUTHOR> "I Am Jazz contains both false information and very troubling omissions. Children who are experiencing gender dysphoria will likely be harmed by this book, as will children who do not have the condition."</comment>


Washing Machine for Men - <AUTHOR> https://medium.com/ux-ui-readings/b6f927bbb538

<comment><USER2> Not sure why "for Men" matters. A better washing machine UI in general would probably be beneficial to anyone using it (assuming that the temperature and speed differences actually make a difference in the outcomes).

</comment><comment><USER3> I fnid the fact that because you didn't learn how to use a washing machine you assume your entire gender is somehow lacking this skill. I learned how to wash closed using a washing machine when I was in middle school. I learned all the various settings on the machine as how they effect everything from stains setting in your clothes to how they effect the water and energy bills. It takes like two minutes to figure out what the settings are on your washing machine, and once you do it once you find the almost every washing machine in existance has the same interface.

As a final note if you presented me with your interface I would be unhappy because I ( like most adults ) change the settings on my washing machine based on whats going into it and you have now removed that common interface and replaced it with a non customizable and frankly stupid interface.</comment>


It is an interesting concept but why are efficient houses ugly as sin? - <AUTHOR> http://www.rocioromero.com/

<comment><USER2> I actually really love the rocio romero designs. I find them modern but not cold and impersonal. They aren't even that unusual on the continuum of modern architecture. Great big windows, efficient layouts, and reasonably inexpensive.

Ugly is the more expensive, HUGE houses that crop up on subdivisions around america with cheesy granite everywhere.

</comment><comment><USER3> _"... why are efficient houses ugly as sin? ..."_

I can think of a number of reasons

\- kit form means (some) pre-construction

\- simpler shapes and consistency means easier and faster construction

\- form follows function

Would I buy one?

If I did the building has no verandas so I'd cook in summer. No sloped roof (increasing surface area slightly) for water collection, solar heating & power. High roof means lots of heating in winter but great in summer. Not much on the materials (insulation, windows) are listed so I can't tell how thermally efficient the building or what footprint it leaves. One thing I notice is the building does not integrate well into the surroundings. Geography does play a part as well and coming from 34 degree southern latitude with mild winters and hot summers.

I ascribe my architectural appreciation to watching Kevin McClouds (<http://en.wikipedia.org/wiki/Kevin_McCloud> ) UK, Ch4 show, Grand Design ( [http://www.channel4.com/4homes/ontv/grand- designs/houses/ind...](http://www.channel4.com/4homes/ontv/grand- designs/houses/index_archive.html) ) every Thursday night on the tube. If you ever get the chance to watch the _Grand Design_ series, do so.

In each episode, McCloud dissects the process of people constructing/re- constructing buildings into their own houses. Asking questions on how to improve construction. Critiquing the building process such as construction, financing, management and execution. The analogy to constructing software applications is obvious.

</comment><comment><USER4> That sort of crap has been around for a long time. It features the grimmest of the grim socialist/faux intellectual German taste in things. Severe, cold, cheap, right-angled, colorless, inhuman, inhumane, and above all efficient.

<http://en.wikipedia.org/wiki/Bauhaus>

The best take down that I'm aware of is here:

<http://www.tomwolfe.com/Bauhaus.html>

<comment><USER5> Bauhaus crap? Uh, please at least recognize the influence on design.

"Severe, cold, cheap, right-angled, colorless, inhuman, inhumane, and above all efficient."

Yes, exact. Its own kind of beauty.

</comment></comment><comment><USER6> Looks way better to me than the average McMansion.

</comment><comment><USER7> This is cool timing. I go to NCSU, and just last night we had a paneled discussion with Charlie Rose about sustainability in the future; one of the men on the board was Thom Mayne, a noted architect who's doing work on sustainable buildings (though mostly office buildings).

One of his key themes from the talk was about how it used to be that design (making buildings artsy) and efficiency (in an energy sense) used to be kind of divided in the architecture world, particularly when he was a student. He said that there has been a major paradigm shift and a merge in the two philosophies.

For examples, check out the Phare Tower that he's working on. The entire tower is optimized for using natural light and airflow, rather than artificial light and air conditioning.

<http://en.wikipedia.org/wiki/Phare_Tower>

He had some other awesome examples, but I don't know where to find them.

</comment><comment><USER8> Many good things look ugly to people at first, because their instincts steer them away from the unfamiliar. If you find yourself thinking, "this is objectively good, but ugly", give it a little time.

Unfortunately, much of what is called modern design isn't objectively good at all; it only looks the part, to people who don't pay attention. Villa Savoye, probably the most famous example of modern residential architecture, didn't meet even the most basic requirements of being a good house--it failed to keep out the elements.

</comment><comment><AUTHOR> I should clarify what I meant in a larger than the title field. Ok so this house is incredibly efficient in energy and space use and I really like the design of the interior. You would think then that it would also blend well with the landscape and not stick out like a sore thumb. However all you see from the outside is is a rectangular box that you only get to pick the color of. I just think the exterior lines are a bit harsh and out of place for something that is otherwise so well designed.

<comment><USER9> so all it needs is some rounded corners?

<comment><AUTHOR> something to let it interact with the lot its placed on...

</comment></comment></comment><comment><USER10> Because they are built by people who think houses are a sin. Compare the idea of electric "punishment cars". (<http://www.teslamotors.com/about/company.php>)

</comment><comment><USER11> Let me stop ou there buddy. the rocioromero house are very nice, elegant and open. You can truly tell that this house is designed to let you breath. Seriously all the extra we are adding to house is to personalize them. Why? Why trying to be so freaking different. I am a victim of that problem as well, we need to all relax and spend less on material crap

</comment><comment><USER12> People think ugly == trendy?

<comment><USER9> different == trendy

<comment><USER12> So then different == ugly?

<comment><USER9> not necessarily, I disagree with the assertion that ugly == trendy. And different of course doesn't always equal trendy..

In the end, these things are really hard to pin down.

<comment><USER12> A more serious answer... I believe that concepts like this are often of an "unusual" design as a way of capturing your attention and forcing you to really look at the package.

Current "normal" housing designs are capable of being highly efficient with (relatively) minor visible changes. However a super high-eff house that looks like any other house won't have the same punch that a high-eff house that also looks like an architectural innovation would have.</comment></comment></comment></comment></comment>


DoD Guide to Detecting Agile BS - <AUTHOR> https://www.forbes.com/sites/stevedenning/2019/09/22/how-fake-agile-at-dod-risks-national-security/#23725c678fa8 <comment><USER2> Direct link: [https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB...](https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF)

Much love to whoever wrote this paragon of clarity and brevity.</comment>


US Congress recommends to policy makers to get acquainted with blockchains [pdf] - <AUTHOR> https://www.congress.gov/115/crpt/hrpt596/CRPT-115hrpt596.pdf <comment><AUTHOR> After a comprehensive analysis of the current state of regulations, the ecosystem, and potentials, Joint Economic Committee Report recommands: \- Policymakers and the public should become more familiar with digital currencies and other uses of blockchain technologies, which have a wide range of future application. \- Regulators should continue to coordinating with each other to guarantee coherent policy frameworks, definitions, and jurisdictions. \- Policymakers, regulators, and entrepreneurs should work together to ensure developers can quickly deploy blockchain technology to protect Americans from fraud, theft, and abuse, while ensuring compliance with relevant regulations. \- Government agencies at all levels should consider and examine new uses for blockchain technology to help make the government function more efficiently.

<comment><USER2> At the end of the day, government is made up of people... And people can't help but be interested in cryptocurrencies and blockchain technology. That's how I explain this doc which I couldn't really have imagined being published this soon even a few years ago.</comment></comment>


What really happened at Ma.gnolia and lessons learned - <AUTHOR> http://factoryjoe.com/blog/2009/02/16/what-really-happened-at-magnolia-and-lessons-learned/ <comment><USER2> Discussion starting over at earlier submission: <http://news.ycombinator.com/item?id=483320></comment>


Google to require 2-step verification in the future - <AUTHOR> http://www.androidauthority.com/google-2-step-verification-207450/

<comment><USER2> Suppose a traveller lands in another country and tries to check his GMail on the hostel's computer. This trips GMail's security, and requires mobile verification. He doesn't have a SIM card with a local data plan, so he doesn't get the alert and can't verify the request.

The beauty of 2-factor auth as currently implemented is it doesn't need network access from your authenticating device to function.</comment>


Heptio Authenticator – Using AWS IAM to Authenticate to a Kubernetes Cluster - <AUTHOR> https://github.com/heptio/authenticator/blob/master/README.md <comment><USER2> Author here, happy to answer questions.</comment>


MacOS Sierra Code Confirms Thunderbolt 3 and 10Gb/s USB 3.1 in Future Macs - <AUTHOR> http://www.macrumors.com/2016/08/24/macos-sierra-code-thunderbolt-3/ <comment><USER2> I just want to see a higher end Mac Mini that's closer in specs to the higher end iMac... Going all the way to Mac Pro just isn't going to happen, and I don't want an integrated screen.</comment>


Show HN: I built a web-based iMessage interface - <AUTHOR> https://github.com/CamHenlin/iMessageWebClient

<comment><USER2> "I would really like some pointers or assistance from people with more experience using private frameworks as I believe it could lead to more reliable and interesting uses for iMessages in the future."

I think you're either not understanding what private frameworks are for or what "reliable" means.

<comment><AUTHOR> I think you misunderstand how unreliable using AppleScript is :)

To sum up the linked project, the app.js is actually capable of launching a new chat with an intended recipient through use of private frameworks, so I'm not completely lost in the sauce

<comment><USER3> I think one of his points is that in some cases private frameworks can be modified in new updates and the changes can go undocumented. So reliability will just about always be in question.

</comment></comment></comment><comment><USER4> On a bit of a tangent, I'd love to see a fully reverse engineered iMessage client - along with Skype, Hangouts, WhatsApp, Snapchat, and all the other mobile messaging apps du jour. What happened to the old days when you could get a single open source client, for Linux if you wanted (today, perhaps the equivalent would be the likes of Firefox OS and Tizen), with reverse engineered implementations for all major IM protocols?

Okay, that's partly a rhetorical question. I know that iMessage and Skype are both powered by highly obfuscated code - the latter for more than a decade! Skype seems it's been decently reverse engineered in the last few years, though, and there are or were some iMessage clients for Android, although I think they were using Macs on the backend (maybe some day I will help with properly reverse engineering it). But never mind those two; I've heard many of the other messengers are no better protected than the ones of the 90s, yet I haven't seen any attempts to write unified clients. Why is that?

<comment><USER5> Whip out an HTTP debugging proxy and I'd imagine you could get pretty close to unpacking Skype's API in less than a day. It uses the Bond protocol, which is easy enough to deserialize, and some tricks to verify that the message being sent is really the one that should come after the last one that was sent.

I didn't get as much time as I would've liked to play with it so they may have more tricks waiting, but it looked simple enough from an hour or so of tinkering.

</comment></comment><comment><USER6> I've always wondered whether something like Buffer could work for iMessage delayed sends. Seems like this could be a step toward that if you can provide everyone with their own secure virtualization of iMessage.

<comment><AUTHOR> Yes that's definitely what I'm working towards! I think there are countless uses for iMessages that working on these types of projects will open up in the future

</comment></comment><comment><USER7> Very cool. Particularly nice work making it a web interface (I think I saw the previous ncurses-style version on here a while back?)

(On a side note, I think we used to hang out in the same IRC channel 10+ years ago? #spacespider?)

<comment><AUTHOR> Yes, we did hang out on IRC! Good times!</comment></comment>


The myth of self help has replaced religion (translated from Swedish) - <AUTHOR> http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=sv&ie=UTF-8&u=http%3A%2F%2Fwww.svd.se%2Fkultur%2Funderstrecket%2Fmyten-om-sjalvhjalp-har-ersatt-religionen_3318636.svd&act=url <comment><USER3> And a sorry replacement it is.

In his Institutes John Calvin argues that knowledge consists chiefly of two things: knowledge of ourselves and knowledge of God. When we dispensed with God we thought we'd finally found the key to human happiness: freed from the constraints of ancient superstition we'd usher in a golden age of human flourishing. What we got instead was an unimaginable amount of human barbarism, empty, meaningless pleasure seaking (ala Brave New World) on the one hand and an oppresive, omnipotent police state (ala 1984) on the other. Ours is a decadent culture, post- and anti- everything, which no longer stands or believes in anything.

We were supposed to get Star Trek, what we got instead was the Walking Dead.

This is the paradox of happiness:

> Happiness cannot be pursued; it must ensue, and it only does so as the > unintended side effect of one's personal dedication to a cause greater than > oneself or as the by-product of one's surrender to a person other than > oneself. - Viktor Frankl

Man was never meant to worship himself, as Augustine says:

> You have made us for Yourself, and our hearts are restless until they find > their rest in You.

And CS Lewis:

> Aim at Heaven and you will get Earth 'thrown in': aim at Earth and you will > get neither.

<comment><USER4> Those are pretty fancy conclusions to draw from the fact that one's brain is wired for religion, in the same way it is wired to make you jump if something that could be a snake moves in your field of vision, or to think that one's luck will change.

We have a inherited a lot of propensity toward various delusions from our ancestors. Sometimes we can make a decision not to wallow in them. Are you sure it is a morally defensible position to, even tacitly, encourage such delusions?

</comment></comment><comment><USER4> It's interesting that this particular article should bubble up at HN. You only have to look at all the self-help and New Age gurus clogging up PBS and the top of the Amazon best sellers to realize that a huge number of people got stuck somewhere between realizing that religious beliefs are unlikely to be real and accepting that their consciousness is an emergent phenomenon.

The honest try to get the masses un-stuck. The dishonest and evil people exploit them or justify a tawdry and easy elitism through this situation.

<comment><USER5> The HOnest?

Tawdry easy elitist much?

<comment><USER4> Am I less honest than a "spiritual advisor?" More elitist than a Straussian?

</comment></comment></comment><comment><USER6> Actual book referenced - Stephen Briers "Psychobabble: Exploding the myths of the self-help generation"

[http://www.amazon.com/Psychobabble-Exploding-myths-self- help...](http://www.amazon.com/Psychobabble-Exploding-myths-self-help- generation-ebook/dp/B00AN4XVZY/)

</comment><comment><USER7> I wish I understood this translation:

"Against "self-esteem" Briers wants to make the concept of "self-esteem", meaning that they have no basis for their self-image, that you act in order to feel satisfied with their effort.

"If it were possible to wait for the man himself would come into a room," wrote British writer Rebecca West, "so there are not many of us who would feel his heart swell with anticipation when we heard the handle is pushed down."

It is a black and provocative image, but maybe it can be taken as the basis for our efforts to improve ourselves, trying to be such that one feels a thrill of joy when that door opens"

<comment><USER8> Norwegian here.

I can't really translate your first quote, but a better translation of the second one is:

" 'If it were possible to wait for one-self to enter a room', the British author Rebecca West wrote, 'then there is not many of us who would feel their heart swell in expectation when we heard the door-handle being pushed down.'

This is a dark and provoking image, but perhaps it can be taken as a starting point for our struggle to improve ourselves: to attempt to become such that one feels a thrill of joy when that door is opened."

<comment><USER7> Thanks. That makes much more sense.

</comment></comment></comment><comment><USER9> Sounds about right.

</comment><comment><USER10> To be more accurate, the myth of self-help has replaced the myth of religion.

</comment><comment><USER11> The article is about the pseudo scientifical life advice that is popular. There is not much about religion. After a spammy first half a book is discussed which sounded interesting.

Religion is generally just not discussed in Sweden, which is the most non- religious country on the planet. It is considered a bit embarrassing to discuss faith, like your toilet problems or something. (At least Sweden used to be the leader. The statistics might be different after the large immigration wave.)

(This service provided for anyone trying to use translate.google.com :-) )

<comment><USER12> I like that attitude. Someone wrote religion is like genitals - its ok to have it, be proud of it, use it, but just don't go waving it around in public.

<comment><USER13> The same is true of any advice, generally. Giving people diatribes on all that's wrong with Windows and all that's right with Ubuntu doesn't produce many converts, and probably gives Ubuntu a bad name. But if someone says "I hate Windows, because it's expensive and made by Microsoft" then it would be entirely appropriate for me to talk about Ubuntu.

I'm that way with religion. I don't walk up to people outside the station telling them to repent, but if someone told me they were having a hard time in life right now, I might suggest coming to church with me one Sunday.

<comment><USER14> You caused me some cognitive dissonance. Why does the latter strike me as offensive, but the former doesn't? My reaction to the latter is "preying on the vulnerable". The former is also, so is the reason that only the latter offends me is that I'm an Ubuntu using atheist?

</comment></comment></comment></comment><comment><USER15> "Self help" is a vague term, but they tend to be rooted more in New Age concepts than in Western monotheism. New Age concepts tend in turn to be linked to Eastern religions or spiritual practices. So no, I don't think that self help books have filled the void of Western religions. It might be only in the existential questions that they answer, but then again, the Buddhist idea of an "afterlife" is very different from the typical Christian one, and has a very different appeal.

(I think that this is more of a Maslow's Hierarchy kind of thing. But oh well.)

Perhaps the typical self help consumer is too wide-eyed and expects too much of life. It might also be that they are turning to un-scholarly, unlicensed authors because no established science or human institution has been able to give them the kind kind of knowledge that they want. In such a case, these psychologists in this article might be wise to think of their professions monumental failure to inspire confidence in the general population. If psychology had found results that were relevant to the common person, I expect them to have been incorporated into the common vocabulary. Instead, psychology is not associated with anything that a _healthy_ person might be in need of; only the 'crazy people'. Of course these psychologists think that self help is too optimistic, when the field has historically been so pre occupied with illness (how old is 'positive psychology', again...?).

We might know how a good life is lead, but there is no authority, currently, on _how_ to achieve it (taking into account human motivation and all that). Some will turn to bestselling authors because, really, having sold a lot of books is about as good of a mark of quality in this field at this point. Then perhaps start to proclaim that we are all ONE, because _quantum physics_. What these might have in common with the archetypical religious person is wishful thinking.

These people should consider just giving up on this whole self help thing, anyway, as there are simpler alternatives. Our understanding of the world - <USER2> least the world outside of ourselves - is so well understood that we can use this as a sleeping pillow. Gone are the days when a rationally inclined mind would have to also be a philosopher, in order to fill in the gaps where the obvious models of the world don't make sense. Now, you can just 'like' "I fucking love science' on Facebook, make the occasional off-hand joke about homoeopathy, and you're safely in the in-crowd of modern, pseudo intellectual rationalists. "If I can't see it, I don't believe it" is as simple as "If there is no study about it, I don't believe it". What these people have in common with the archetypical religious person is close-mindedness.</comment>


Ask HN: Highest paying remote companies? - <AUTHOR> I have 10 years of FAANG experience (Senior SWE). I'm looking to move closer to my family and my current team isn't very remote friendly so I'm looking for a change. What should I be looking for? <comment><USER2> You can have a look here: [https://docs.google.com/spreadsheets/d/1TLJSlNxCbwRNxy14Toe1...](https://docs.google.com/spreadsheets/d/1TLJSlNxCbwRNxy14Toe1PYwbCTY7h0CNHeer9J0VRzE/edit#gid=1279011369). Found my last comapny in that list, 10/10 would do again.

<comment><USER3> Resource unavailable for me. Can you please re-paste?

<comment><USER4> Link working for me, think its getting hugged to death though as I got a google "read only cached version"

</comment></comment></comment><comment><USER5> Bear in mind many US companies that are looking to hire remotely only want employees to be based in US... So your experience will be different based on where you want to live.

The most important job boards seem to be [https://weworkremotely.com](https://weworkremotely.com) and [https://remoteok.io](https://remoteok.io). Many jobs posted on the monthly "Who is hiring?" Hacker News post are for remote positions. A few years ago I built an index of "Who is hiring?" posts with a search by location and technology: [https://hnhiring.com/search?locations=remote](https://hnhiring.com/search?locations=remote)

Edit: given you're FAANG you might find facet useful: [https://www.facetdev.com/](https://www.facetdev.com/)

<comment><USER6> I always wonder what is the reason that they ask for US-based. One possible reason I've heard is that it makes taxes and certain laws easier for them to follow, in which case it sounds like more a matter of being a US citizen rather than actually living in the US. Another reason I've seen is that they still want you to be available to come into the office every so often, which would be a different story.

Are there any people here who are US citizens but living abroad that have applied to these companies? What was the response?

<comment><USER7> Health care is another consideration. Many insurance companies are (in practice) US only or even subset-of-US only. That's been one of the hurdles for us when we hire remotely (which is generally of the form "excellent current employee wants to move and we want them to keep working for us")

<comment><USER8> That shouldn't really be a criteria, since at least in Europe there's no such thing as having your employer provide a healthcare plan for you.

<comment><USER9> Not the case in Germany, as I understand it.

</comment></comment></comment></comment></comment><comment><USER10> Pro tip: if you make pay your only consideration, you may end up pretty miserable. Often companies pay very high because they burn through employees, and are otherwise a nightmare to work for for a variety of reasons.

(Even worse, you can get stuck in these golden handcuffs as your expenses catch up to your income, leaving you in a cycle of one miserable job after another)

<comment><USER11> Good pay at least makes such positions more tolerable. Getting paid poorly in a bad company is far worse, I assure you.

<comment><USER12> The corresponding choice would be getting paid poorly in a good company. If we're doing extremes, you can get paid well in a good company too.

<comment><USER13> It is a false dichotomy of course, and pretty much every job is somewhere in the middle of the spectrum. You can also do a lot personally to endure a bad job if you decide the pay is worth it, but if your life is nothing but your job then a bad job means a bad life.

</comment></comment></comment></comment><comment><USER14> Docker. They made me an offer of around ~210k base + options for a Senior Software engineer a few months ago. Fully remote! I ended up passing on it for different reasons on it though.

<comment><USER15> 210k base? This probably needs another topic, but is this normal for bay area companies recruiting at senior engineer level now?

<comment><USER11> OP provided no context. So I'll fill in the blanks: Ex-FAANG engineer got an offer at Dropbox. Dropbox needs to be competitive, so made an offer around 200k + full remote. FAANG in bay area pays 200-300 for senior total comp, so it was probably a salary cut for OP. If you're Joe Blow in the middle of the US, you are probably not going to get a similar offer unless you're already on a similar wage.

<comment><USER16> > FAANG in bay area pays 200-300 for senior total comp

FAANG pays 200-300 total comp for _new_ grads, these days. My new grad friends who land at Facebook and Google are getting 140-160 base salary, 70 or 80 in bonus, and around 80 to 100 in RSU vesting in the first year. Pay is bonkers right now!

<comment><USER11> Okay, in that case OP was probably taking an even larger paycut :).

</comment></comment></comment></comment></comment><comment><USER17> Basecamp without a doubt, if this interview of their CEO is anything to go by:

> We're taking home lots of money every year. We're paying our employees > incredibly well. We pay them top 10 percent salaries in the industry, San > Francisco rates, even though we're not based in San Francisco. We have > amazing benefits. We have all these things because we're independent.

[https://www.recode.net/2019/1/23/18193685/venture-capital- mo...](https://www.recode.net/2019/1/23/18193685/venture-capital-money-kills- business-basecamp-ceo-jason-fried)

<comment><USER18> Sounds great but not really practical advice. They rarely hire nowadays, also it gets more complicated with matching of their open positions with your resume.

</comment></comment><comment><USER19> Hi there! Someone shared this list last week. [https://docs.google.com/spreadsheets/d/1Sr0vy3eDn2fcEhxOdkPv...](https://docs.google.com/spreadsheets/d/1Sr0vy3eDn2fcEhxOdkPv0BjsWBR7JntDJqRM6_hyjbE/edit?usp=sharing)

There are Remote Open Engineering Positions right now. You can check them there.

</comment><comment><USER20> Have you done full remote before? If you don't have significant experience in managing yourself and the fact that you will work alone most of the time, I suggest you not to look just for money, but instead look for a company with a culture which suits you. If they give you just a big paycheck to cover up the shit that you will have to do for them, there is a high chance that you will burn out and no amount of money will help you.

</comment><comment><USER21> It will be very rare to find companies publicizing high-paid remote offers. They would get swamped with the the wrong applicants.

I'd go for well-established US companies which use something you are an expert in. Then I'd try to pull a remote deal out of the negotiation.

</comment><comment><USER22> What kind of experience have the people here had when applying for remote positions? Did you guys find it difficult to get a remote job (that you enjoy!)?

When I was last looking for a job, I applied to several remote positions in the hope I might get one but was unsuccessful in all of them. In general, I found it a lot more difficult compared to the local companies I spoke with. I don't think it's anything to do with my experience, but I suppose you are competing with the world rather than your local area.

<comment><USER5> It's more difficult than finding local jobs. Supply/demand does not work in your favor.

Edit: Besides many companies look for previous remote experience. So it's hard to get a remote position without having had a previous remote position.

<comment><USER23> You are right that getting a remote job is probably more difficult than finding a local one. OTH the existence of remote jobs market definitely works in your favour in some situations because you simply have more choices.

Fo example, I am a machine learning scientist / engineer currently based in Prague. The ability that I would be able to easily find a remote job definitely increases my negotiation power which would other way be quite limited in Prague because there are not as many great local options in my field here.

<comment><USER5> You're right. As an individual looking for a remote job you also have many more options than if you focused in local jobs. And I would definitely recommend anybody not living in a major tech hub to get a remote job.

</comment></comment></comment></comment><comment><USER24> Did you check inside your company. E.g. Google gives a lot of freedom to people with 10+ years with them and I know at least one other company in the same area, which did it with even less. So might not be the worst idea to look for something remote friendly in your current company.

</comment><comment><USER25> Wouldn't Basecamp ([http://basecamp.com](http://basecamp.com)) be one of the top people. They pay within the top 10% of salaries comparing to SV/SF salaries, and pretty much the whole company is a remote team.

</comment><comment><USER26> Check out [https://www.flexjobs.com](https://www.flexjobs.com). They have tags and other criteria that help you find ads by keyword, schedule, full/part time, featured employers, etc.

</comment><comment><USER27> Http://www.Basedremote.com is another doc list with remote companies

<comment><USER27> [http://basedremote.com](http://basedremote.com)

<comment><USER28> Opened the first company in the list and saw this very depressing ad : [https://www.crossover.com/job-front-end-software- engineer?ut...](https://www.crossover.com/job-front-end-software- engineer?utm_campaign=AvailableJobs)

<comment><USER27> yes, I wonder what is the deal with crossover. It looks like some slave- developer plattform... But then for a dev in eastern europe or asia a permanent position with 30k/y is better than most local positions? But might also be wron about this...

<comment><USER29> In Italy a junior dev gets 28k$/year so I think even western/southern Europe may be interested.

</comment></comment></comment></comment></comment><comment><USER30> "Basecamp doesn't employ anyone in San Francisco, but now we pay everyone as though all did": [https://m.signalvnoise.com/basecamp-doesnt-employ-anyone- in-...](https://m.signalvnoise.com/basecamp-doesnt-employ-anyone-in-san- francisco-but-now-we-pay-everyone-as-though-all-did/)

</comment><comment><USER31> GitHub but certain locations are restricted

</comment><comment><USER32> Looking for probably 50-66% of your current salary. You only need to pay remote employees competitive local rates, not the inflated FAANG rates. And someone in the Bay area needing a comparatively high salary is going to lose out to a similarly scored candidate in Adelaide.

<comment><USER33> I think this is generally true for average developers, but this probably doesn't apply for a senior engineer with 10 years of FAANG experience. They will be able to command a Silicon Valley salary anywhere in the world. But only if they work remotely for a SV company. You're probably not going to get this kind of salary if you work remotely for a company based in the UK, Canada, or Australia.

It's also true that many companies try to get away with cost-of-living adjustments, but you can find plenty of companies that don't do that. So they can just keep looking until they find a great offer.

<comment><USER34> Problem with paying employees too much, especially freelancers means that they just wont put the hours in.

Why would I work 40hrs @ $100 when I can do 10hrs @ $400?

<comment><USER33> When you hire a remote employee for a full-time job, you're usually expecting them to put in at least 40 hours per week. People will often take that job because they value the stability, want to work with a good team, want to work on an interesting problem, or there are significant stock options at an early- stage startup.

When you're a contractor, you can earn a lot of money for short-term projects, but it gets a bit boring after a while. You're more of a mercenary with no long-term interest in the project. I've also found that the projects are usually very dull. If you join an existing project as a freelancer, then the code quality is often very poor and there can be a lot of technical debt. (YMMV.)

So sometimes it's nice to join a team and have a vested interest in the project, as a co-founder or an early employee. (I've been a freelancer working 10 hours per week for the last few years, but I'm now thinking about a full- time remote job at a startup.)

Consulting is fun, but if you're going to take it seriously (e.g. paying off the mortgage on a house and saving for retirement), then you have to put in a ton of hours over a few decades. That means working on a lot of really boring and tedious projects (and maybe a few interesting ones.) I'd much rather join some startups and get a few "lottery tickets", or build my own projects and support them with part-time consulting work.

<comment><USER35> While i have little experience on the remote side of things....i can assure you that working for The Man at an office in a conventional, non-remote way, also takes "a few decades" to pay of a mortgage, save for retirement, etc. ;-)</comment></comment></comment></comment></comment>


Ask HW: is this Normal? - <AUTHOR>

Whenever i drink coffee ,after 5 minutes i always start feeling  sleepy. Within 1-2 hrs i kind of lose my  concentration to the extend i cannot focus properly and then i'm forced to sleep.Is this normal? Is there anyone out there having similar experiences? <comment><USER2> I used to often wake up early, have a cup of coffee, and then fall back asleep for an hour or two. But the caffeine in coffee still had the normal stimulatory effect at other times.

Now I drink very little caffeine, but I still have that nighttime sleep pattern -- 5.5 hours asleep, 1.5 hours awake/alert and up, 1.5 hours asleep, and then I'm awake and refreshed and ready for the day.

</comment><comment><USER3> Happens to me all the time. I don't know if it's physical or psychological but I have what I call a paradoxical reaction to caffiene - it puts me RIGHT to sleep.

Also, it's not the sugar, at least in my case, because I don't use any. I'm diabetic and well aware of hi- and low-blood sugar symptoms. This is different at least for me.

</comment><comment><USER4> Some quick searching and skimming turned up this article:

[http://www.chicagoreader.com/chicago/how-does-caffeine- affec...](http://www.chicagoreader.com/chicago/how-does-caffeine-affect- nervous-system-health-research/Content?oid=875717)

</comment><comment><USER5> when I eat a big meal or lots of sugar.

<comment><AUTHOR> maybe it could have been sugar in the coffee or something.</comment></comment>


Epic vs. Apple: Order Granting in Part and Denying in Part Motion for TRO [pdf] - <AUTHOR> https://www.courtlistener.com/recap/gov.uscourts.cand.364265/gov.uscourts.cand.364265.48.0.pdf <comment><USER2> This seems like the predictable outcome. Epic knew Fortnite would get banned when they started this; Apple is innocent until proven guilty, so no court will force Apple to reinstate Fortnite unless Epic wins its antitrust suit. But similarly, Apple's subsequent, second threat to ban Epic from doing other lines of business via macOS tools (e.g. Unreal Engine development) seemed excessive compared to other app bans, and seemed clearly an attempt to use their power to shake down Unreal customers as retaliation for the dispute.

I'm not surprised that Epic started this: they want their game store on iOS, and the only way that happens is via an antitrust lawsuit — and you can't bring an antitrust lawsuit unless you show evidence of harm (aka, lost Fortnite sales). Epic wanted Fortnite to be banned so that they could sue Apple.

I'm curious why Apple escalated, though. It seemed to me like they were playing into Epic's hand: they're currently under multiple antitrust investigations by the US and the EU, and using their market power on iOS to corral developers on macOS seems like a pretty obvious violation, and a novel one: when they banned XCloud from iOS, for example, they didn't also ban MS Office from running on Macs. Why would they try to do it now? When I first saw it I wondered if Apple knew something we didn't (since Epic would pretty obviously attempt to contest this in court), and that Apple was playing its own 4D chess game against Epic, secure in the knowledge that the court wouldn't grant the injunction on the macOS tools. But... Now it just looks like a fit of pique? Apple had already banned Fortnite when it issued the second threat to ban Unreal; the second threat ended with them getting nothing (the court prevented them from following through) and left looking like monopolists during the antitrust investigations. I don't get it.

<comment><USER3> >you can't bring an antitrust lawsuit unless you show evidence of harm (aka, lost Fortnite sales)

I thought the point of antitrust is that it brings harm to the consumers and not just some lesser company?

<comment><USER4> The harm to consumers is the higher price that they have to pay. Epic didn't just keep the 30% all for themselves, they lowered prices.

<comment><USER5> They lowered prices as part of a calculated stunt. If Apple is suddenly turning over 20% of the purchase price to devs, why would the devs lower the price when they're getting an extra 20% at the same price point?

<comment><USER6> This is the correct take. Generally speaking, the prices set by Epic before this stunt likely approximated the highest price which didn't reduce aggregate spending.

</comment></comment></comment></comment></comment><comment><USER7> Some choice sections:

 _"...On Thursday, August 13, 2020, Epic Games made the calculated decision to breach its allegedly illegal agreements with Apple by activating allegedly hidden code in Fortnite allowing Epic Games to collect IAPs directly. In response, Apple removed Fortnite from the App Store, where it remains unavailable to the date of this Order. Later that same day, Epic Games filed this action and began a pre-planned, and blistering, marketing campaign against Apple... "_

 _"...The Court finds that with respect to Epic Games' motion as to its games, including Fortnite, Epic Games has not yet demonstrated irreparable harm. The current predicament appears of its own making... Epic Games admits that the technology exists to "fix" the problem easily by deactivating the "hotfix." That Epic Games would prefer not to litigate in that context does not mean that "irreparable harm" exists..."_

 _"...Epic Games moves this Court to allow it to access Apple's platform for free while it makes money on each purchase made on the same platform. While the Court anticipates experts will opine that Apple's 30 percent take is anti- competitive, the Court doubts that an expert would suggest a zero percent alternative. Not even Epic Games gives away its products for free..."_

Ouch.

Separately, the aspect of Apple pulling keys for the developer (e.g. Unreal Engine) platform access was granted a preliminary injunction. Which seems reasonable.

I guess Epic has a couple days to decide whether to give in or not: _" Fortnite's next season starts on Thursday, August 27, 2020, and will require an update of the game to play."_

<comment><USER8> "...Epic Games moves this Court to allow it to access Apple's platform for free while it makes money on each purchase made on the same platform. While the Court anticipates experts will opine that Apple's 30 percent take is anti- competitive, the Court doubts that an expert would suggest a zero percent alternative. Not even Epic Games gives away its products for free..."

Apple is arguing as if accessing their platform for free was a crime. This makes sense, since they have costs associated with reviews, code signing and distribution. But that is of their own making. Walled gardens should be outlawed.

<comment><USER9> It being a walled garden is the only way I'm willing to trust it for accessing all my account recovery emails, my 2FA SMSes, my bank details, and the sensor package that can listen to everything I do while GPS tracking me and monitoring my heart rate and gaze if I happen to be holding it where I can see the screen.

Of course, that doesn't mean I like being stuck with an American cultural hegemony that says sexual content is forbidden, or that needs an encryption export licence from the USA government for apps written by non-Americans for non-Americans, and which still demands annual reporting to the US government for using https.

I'm happy with any walls that meet basic security standards, but I do want _a_ wall, even if it would be nice to choose _which_ wall.

<comment><USER10> The walled garden is not what protects your email, 2FA SMSes or bank details. The OS sandboxing and permissions system do that. The two are often conflated, but the two concerns are orthogonal really.

Heck, you could easily imagine a system where software distributed outside the app store can only access a subset of perms if security is such a concern, and that'd still be less anti-competitive

<comment><USER11> Due to the way iOS works (dynamic dispatch) private APIs can _only_ be prevented through an App Store review process.

And many of those APIs can be used to extract enough information to fingerprint the device, determine your location or steal your data e.g. accessing the list of WiFi networks or browser history.

So no. The two concerns are very much related.

<comment><USER12> > Due to the way iOS works (dynamic dispatch) private APIs can only be > prevented through an App Store review process.

That's complete nonsense.

Dynamic dispatch has nothing to do with the ability or not of a program to access API. Dynamic dispatch is the selection at runtime of the correct version of a polymorphic function. Obviously, you can sandbox programs written in languages using dynamic dispatch.

<comment><USER11> Be curious how you plan to prevent access to Apple's private APIs in Objective-C, which uses dynamic dispatching, without breaking existing code.

I am sure Apple would love to know how you've managed to solve this.

<comment><USER13> sign existing code.

<comment><USER9> They do, this is an argument about how they decide when it is OK to sign that code.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Key quotes:

"the Court observes that Epic Games strategically chose to breach its agreements with Apple which changed the status quo"

"However the showing is not sufficient to conclude that these considerations outweigh the general public interest in requiring private parties to adhere to their contractual agreements or in resolving business disputes through normal, albeit expedited, proceedings."

"Epic Games and Apple are at liberty to litigate against each other, but their dispute should not create havoc to bystanders."

</comment><comment><USER15> I'm pretty sure this is the outcome Epic was expecting.My impression is that they don't want their stunts to affect the developers using Unreal Engine, but they're OK with Fortnite being off the App Store if they can win a concession for things like a smaller cut or even getting their EGS onto iOS.

</comment><comment><AUTHOR> Related case: [https://www.courtlistener.com/docket/15721902/cameron-v- appl...](https://www.courtlistener.com/docket/15721902/cameron-v-apple-inc/) \-- please use the RECAP browser extension if you access any of these filings ( [https://free.law/recap/](https://free.law/recap/) )

</comment><comment><USER16> Ooph. I'm betting that Epic was expecting to get to stay on the app store during the trial. That's an expensive difference. I would guess that Epic will retract its change and ask to be relisted on the app store (and if that doesn't happen, seek rapid redress in the court, since this TRO decision explicitly lists Epic's ability to be reinstated as a rationale for why there is no risk of irrevocable harm).

<comment><USER17> I don't think Epic is making that much money from Fortnite on iOS to actually care, I think they are using Apple because a) its an easy target and if they win the ruling can be expanded to other platforms too where they currently make the most money on and b) while they aren't a major source of revenue now Epic probably has bigger plans for mobile centric games down the line.

Basically now it's the best time for them to do it, Apple is a huge target and they can gain industry support, Fortnite is big enough that even the average judge, jurist and jury member is likely aware of it and right now they stand to lose very little financially from not being on iOS while the potential future gains are insane.

<comment><USER16> It's possible that revenue has fallen off, but it appears that Fortnite Mobile revenue has been at least $500 million per year. If this trial goes on for two years, that's potentially a billion dollars in lost revenue. [https://sensortower.com/blog/fortnite-mobile- revenue-1-billi...](https://sensortower.com/blog/fortnite-mobile- revenue-1-billion)

<comment><USER17> Those estimates are utterly out of touch with reality to the point of being a straight fabrication.

Fortnite brought Epic £1.8b in revenue for 2019, there is no way that 25% of that came from iOS based on actual player data and experience, if their iOS revenue is 10% of the total I will be in shock.

<comment><USER18> The US is disproportionately iOS compared to the entire world, and especially US teens (I've seen estimates of something like 90%). iOS, the US, and US teens are all disproportionately important to digital sales. Although the US is 10% of TikTok's user base, it provides 50% of TikTok's revenue, nd from Charli D'Amelio on down the most-followed TikTok accounts are almost entirely American. That's why everyone expects TikTok's US (and possibly global) operations to be soon sold; the US is the tail that wags the dog.

<comment><USER17> US is the majority of revenue sure, but there is no way that so much comes from iOS the cross platform play numbers don't back this up you can't just extrapolate from hypothetical app download figures.

The US is about 80% of Fortnite's but the majority of the players are on consoles not mobile. The 80% figure will change drastically when China grants epic permission to monetize the game as the vast majority of their players are in China.

<comment><USER19> I also imagine Epic made these kinds of calculations before trying to take on Apple.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> It seems some of the decision hinged around this fact from the article: "self- inflicted wounds are not irreparable injury".

I wonder if there could have been a better sequence of events (e.g. sue first rather than sneaking it in)?

<comment><USER4> I don't think that would have changed anything. The court still wouldn't have granted Epic special permission to break App Store rules before the lawsuit is resolved. Epic isn't in a worse position for trying it. Unless Apple refuses to let them back in after reversing the payment changes, in retaliation for filing a lawsuit. In which case I think the court should intervene.

</comment></comment><comment><USER21> Does anyone find this whole situation very anti-consumer?

Two billion dollar tech companies have started a slap fight, both have claimed its for the benefit of their customers/users but in reality its about their own personal bottom line.

The gaming forums filling up with pre-teen twits willing to cheer lead for their respective megacorp is thoroughly depressing to look at.

</comment><comment><USER22> ..."What was striking about all of these apps is that only three of them functioned primarily on an iPhone; in the vast majority of cases Apple was demanding in-app purchase offerings for functionality that was largely not dependent on an iPhone:"

[https://stratechery.com/2020/rethinking-the-app- store/](https://stratechery.com/2020/rethinking-the-app-store/)

</comment><comment><USER23> Not sure if somebody did that bet. So I just put it here. I think the best outcome could be when Apple be forced to allow bigger number of devices under TestFlight - which is the way to install apps not from AppStore. Apple would probably charge extra for that like $1 per device. No virtual goods outside of apple payment system, same 30%.

<comment><USER24> The best outcome would be for Apple to allow alternate stores into iOS, like Cydia.

</comment></comment><comment><USER25> TL;DR: Apple is prevented from revoking Epic's developer credentials, as they have threatened to do, at least until this plays out in court. Fortnite is still off the App Store for the duration. A schedule is outline for next steps in the legal case.

</comment><comment><USER26> This seems fair. Although Epic should separate its Unreal business from Fortnite to avoid these in the future.

<comment><USER11> You have to remember Epic has planned this all pretty carefully from the start.

They benefit from being able to play the "if you ban us, you also ban all of the little mom & pop game developers" sympathy card.

<comment><USER9> That sounds like Epic abusing its "monopoly"[0] on game engines.

[0] in the same sense that Apple is a monopoly on smartphones, hence the air- quotes.</comment></comment></comment>


The Happiest People Don't Let Their Minds Wander, According to a Harvard Study - <AUTHOR> http://www.inc.com/quora/the-happiest-people-dont-let-their-minds-wander-according-to-a-harvard-study.html?utm_source=pocket&utm_medium=email&utm_campaign=pockethits <comment><USER2> >the keys to happiness lie in mastering the mind, and not in changing external factors in our lives.

I'm sure not wondering where your next meal will come from or if your home will be leveled by ordiance today can help with that.

<comment><USER3> In the military I was in a variety of life threatening situations (both forward deployed and in garrison), and I was quite happy. The most interesting realization came when in water training, where there were times I honestly felt like I was in mortal danger. I was ok with it and still enjoyed life. Eh, maybe I'm a weird one though, I always found humor in it.

<comment><USER2> I'm not saying people can't find happiness in those situations (in fact civilians in those situations are often amazingly upbeat all things considered).

I just mean the bit about external factors almost implies external factors barely affect happiness is silly, external factors are also a large part of happiness.

<comment><USER4> I don't think they are saying external factors don't/can't affect happiness. I think they are saying that manipulating external factors is an inferior strategy for improving happiness.</comment></comment></comment></comment>


Matti Makkonen, Finnish pioneer of texting tech, has died - <AUTHOR> http://www.bbc.com/news/technology-33324708

<comment><USER2> I am not sure how true this is but I remember reading an article about SMS and initially it was designed for network operators to send diagnostic information. It was designed to use the same transport as signalling - when no signalling information was being sent - you could send a SMS - so essentially was free for the operator to provide.

In the beginning it was thought that only technicians would utilize SMS messaging [0]? The 'public' would all be using pagers to get their text. Turned out to be the opposite. And a nice markup on each SMS sent still lines the coffers for the operators.

0: [https://en.wikipedia.org/wiki/Short_Message_Service#Initial_...](https://en.wikipedia.org/wiki/Short_Message_Service#Initial_concept)</comment>


The solution to just about everything: Working less (2016) - <AUTHOR> https://thecorrespondent.com/4373/the-solution-to-just-about-everything-working-less <comment><USER2> The facts that are presented in this article are very interesting, but I find that there is a gap between the facts presented and the conclusions drawn in this and other "we should work less" articles. Maybe around 40 hours a week is an optimum for humans who want to have a balanced life and time to consume products to keep the economy going?

There are also other factors, such as people concentrating ever more in cities, driving up the cost of housing, making living in many cities only marginally affordable for most low-paid workers.

There's so many variables to consider, but I'd like to read a real economists view on these things.</comment>


Urinating frequently at night, sleeping little and 100 doctors can't tell him - <AUTHOR> https://www.washingtonpost.com/ <comment><USER2> Submitted earlier, works:

[https://news.ycombinator.com/item?id=21044390](https://news.ycombinator.com/item?id=21044390)

</comment><comment><USER3> This link is not correct.

<comment><USER4> ... and 100 doctors can't tell him</comment></comment>


Show HN: Creating and Monetizing chat bots just got easier with ChatterOn - <AUTHOR> http://www.chatteron.io/monetization-radbot.html <comment><AUTHOR> Hello everybody,

I'm Adit, the founder of ChatterOn.

At ChatterOn we help thousands of developers build chat bots on a daily basis and in the recent past we noticed that many developers were complaining of the lack of monetization options.

We decided to do something.

We proudly announce the first ever Chat bot development platform, that helps developers build and Monetize their chat bots powered by RadBots. So now, not only can you create chat bots, but also earn money in a few clicks on the ChatterOn platform. It is the easiest way of making money from your chat bots - no coding, one-click integration and relevant, targeted advertisements for your end-users.

We believe that monetization for chat bots is a very important step for the whole ecosystem to evolve because now developers across the globe can spend quality time on building products without worrying about monetization.

We at ChatterOn are constantly innovating and have lined up multiple partnerships to help you monetize your chatbots!

I'm online for the whole day. Please ask me anything! Your comments, suggestions and questions are most welcome.

</comment><comment><USER2> What platforms are supported ? Interested to see how this plays out in the market.

<comment><AUTHOR> We support Facebook Messenger as of today.

Our team is working hard to extend the integrations to Kik, Telegram, Skype, Line, website, apps, etc.

Keep watching us for updates.

</comment></comment><comment><USER3> Will ads be textual form or in UI form?

<comment><AUTHOR> Currently we support UI form of Advertisements.

But soon, we will support Event-triggered Contextual ads also. Imagine this - No banner, no text ad that comes in the way of what you actually want, just event-triggered suggestions. For eg. You book a dinner date at one of your fav restaurants on Yelp bot. After the booking, the bot subtly asks, whether you'll be driving or taking a cab. If you are taking a cab, it will refer you to a cab service and use the data from the on-going chat. No redirection.

I think that's the future. Event - triggered conversational advertisement.</comment></comment>