catwind7

just learned about the "great filter", very interesting. I think it does mean that our observation tech is not good previously - it also sounds like if we did start observing life, the fact that we have yet to be visited / colonized by that life form means only re-affirms the unlikelihood of interplanetary travel..

according to [wikipedia](https://en.wikipedia.org/wiki/Great_Filter):

> So by this argument, finding multicellular life on Mars (provided it evolved independently) would be bad news, since it would imply steps 2–6 are easy, and hence only 1, 7, 8 or 9 (or some unknown step) could be the big problem.[4]

gotcha. I also get the feeling that GP was more interested in being right vs actually knowing how to get the emitter to emit assembly. It felt like the followup was just gonna be ... well WHAT ABOUT BINARY?

i think you succeeded in communicating your thoughts and feelings in spite of the metaphor.

there are plenty of documentation in the form of tutorials on for nearly every aspect of every programming language I can think of. I think it's important to keep in mind that we all learn differently and sometimes one explanation can make no sense while another makes a lot of sense.

That said, I think I get your frustration in that sometimes the process of _finding_ the explanation that clicks for whatever your question is (how to emit assembler?) can be really painful because all the explanations are shallow.

However, I don't think it's fair to take that frustration out on the writers (I got the impression you were, but maybe you weren't and just felt like venting). I for one encourage engineers to write if no for no other reason than to better cement their own understanding.

I do wonder, though, if maybe there's some improvements we can make to how we filter / search for long-form technical articles outside of google so that the content is more relevant

there's certainly equivalent assembler, but depending on the architecture you're targeting this can be a pretty monumental task. Even a single function call can be north of a hundred lines or something (i'm making this up :D )

I guess that's why we have things like LLVM that allow you to generate intermediate representations that get converted to a bunch of different instruction sets

nand2tetris is a great course that shows you how to design a computer from the chip level, build an assembler, and write a high level language + compiler that eventually produces the assembly code for the machine architecture _you_ built. I highly recommend it.

so what if it is?

i know what the bike shedding metaphor is and frankly you're stretching it a bit because all this person is trying to do is educate and they're not even saying this is the only way to do it.

seems odd to pull out the bike shed metaphor for every case there's an abundance of technical articles on a subject matter. There's lots of tutorials on for loops in X language. Do you consider that bike shedding?

this seems a bit like a false dichotomy - I don't think that's how the software industry is structured. Maybe it's how companies with dev teams in _certain_ industries are structured. I've even had managers in the past who did deep work in addition to doing some of the more logistical work of project planning / story breakdown and it's almost a basic expectation that a senior engineer be hands on with the most complex, business-critical systems

I agree if companies don't have non-management tracks for experienced engineers. That does result in the environment you're talking about in about the worst way where your most experienced eng's are unhappy / hate managing and inexperienced eng's are stuck with bad managers

> not understanding something — or having a bug in your thinking — bothers you a lot.

I find this to be true for nearly all of the best co-workers I've had. I think this is the same reason people enjoy debugging software. It's the computer telling you that there's a bug in your thinking

yeah, this hits home for me because my team just spent a couple of years trying to get a product right and now it's on the verge of being replaced.

I think I've typically associated that mantra with pure software companies, so it's surprising when a company does this with rockets

i agree. I think this is why I find companies like tesla and spacex exciting. They seem to have set up incentive structures that encourage _both_ quick execution and innovation (which requires deep understanding). One thing he's said that really struck me is that it's _really_ difficult to produce innovation if you tie punishment to failure. People tend to be conservative if they are punished / think they will be punished harshly for trying and failing. But if you want to innovate, failure has to be an acceptable outcome

hopefully we see more companies go in this direction

oh my god this is so cool. I just played a round of C.S in my browser. still letting that sink in.

hey thanks for catching that - turns out leaving out the protocol in markdown causes makes it a relative url. fixed.

thank you for this. We will be checking this out!

yeah so I have a user-agent generator that uses a random (valid) agent for each request.

that, combined with cookies enabled, still didn't seem enough to get around the anti-robot barrier 100% of the time. 20% of the time, I get stopped.

My guess is that they must do some kind of pattern matching on their end that kicks for some sets of requests but not others? But maybe it's not that sophisticated and I'm just missing something else in my headers

I actually did notice that issue, even with using a stateful client like mechanize. Sometimes I had to scrape > 5 times in order to get through the "anti robot" page.

Other times, I get no issue at all. It's weird - maybe they're doing some pattern matching on request metadata on their end?

Not an advertisement for amazon prime :) These are free with prime, not free for non-subscribers

I'm actually going to be cancelling my prime membership, which is another reason I wanted to see what I could watch for "free".

Author here.

The list (both on my post + the google sheet) should be correct now - I underestimated how many different releases of the SAME movie title there are ...

Thanks all for catching the mistakes.

i'm fixing this list ... just realized a few bugs in the code. sigh

updated the list. Thanks for the catch! sorry about that. I'm using an `in` keyword which just checks substrings ... that I meant to change. Woops

oh I need to try that - I had this feeling that there was a more stateful version but for ..... some reason ... reaching for a new dependency felt easier at the time haha. Thanks

To be frank, I'm not sure. I'll probably always keep a basic features free and have a price for integrations. What do you think about that?

I built this mainly to solve a problem I run into often: finding a time that works for me and a stranger (usually on a different timezone) to pair program. Usually it involves me walking someone through a problem that they posted online and the logistics of trying to find a common time is usually painful.

It's a pretty specific problem so it's possible that few of you will have interest in using this, but any feedback is welcome nonetheless.

oh yeah that makes more sense i misread it as water but they meant lava. woops

very interesting! could someone explain why the hot water would lead to deep, cold water being brought to the surface? I thought hot water is less dense than cold water. Wouldn't it just sit on the surface for a long time?

Or is there just such a large amount of this extremely hot water that the mixing overtime generates movement across the board?

haha yeah that was a fail :D thanks for pointing it out!!

see my point #2

> 2) I have to because i'm having integration problem

i'll prob go to the docs first and source code last. that said, my point isn't "avoid looking at source code". It's "I don't seek out source code of libraries for the purposes of learning".

if i'm trying to get stuff done, i don't give two shits how a third party tool wrote its fancy functions. that's the point of abstraction.

and most of the time, when i'm using third party tools i'm just trying to get shit done.

yeah i think that's a fair question. i think while the extreme programming community may define it as a practice with a particular set of guidelines, ultimately it's about working effectively with another programmer.

sometimes that means bucking the rules of whatever the methodology prescribes and doing what works for your team.

for example: xp people tend to suggest frequent pair rotations in order to spread knowledge (faster?). I know half my team, though advocates of pair programming, would be pretty unhappy with that given the costs of context switching.

maybe some people will point at that and say we're not really pair programming /shrug

a lot of this depends on the dynamics of the team.

i don't think pair programming necessarily means typing 100% of the time. I get a ton of value in tackling a very ill-defined task with another member of my team, especially in the design / architecture phase where I find that a lot of engineers tend to over-think and over-engineer a task.

i don't want to discount your experience tho - i def. have moments where i absolutely do not want to pair, but i do think it's a practice that is super context (team) sensitive

i generally avoid looking at other peoples code unless 1) it's written for teaching purposes and aims to teach a concept I want to learn or 2) I have to because i'm having integration problem

I think looking at well-written code is a great way to learn best practices, but I think it's quite hard to do that in practice and probably not the best way.

there's a lot of garbage code out there and even if the code is good, often times you find that it's super out of date (using an old ass version of a language) or the logic is pretty obfuscated by unessential (to you) backwards-compatability / cross-platform compatability checks.

there's also a great deal of context around the intent of blocks of code that you don't have when looking at open source code in isolation in the example you gave. Some lines might seem like nonsense until you read the PR and understand the tradeoffs made at that point in time.

> That is a UX problem right?

Ah yeah - I do recall author making that distinction ("user" UX teams vs operator UX teams).

> I especially want to emphasize tools for your Customer Support staff. These are rarely prioritized, but they imho have a far better RoI and customer satisfaction impact than any UX change you can do. CS are operators.

That's a good point. Right now my team does give tools to CS related staff but you're right they're not prioritized, the UX is horrible (b.c it's "designed" by developers who were tired of having to troubleshoot themselves), and devs get pissed / act surprised when the CS people dont use the tools the "right" way.