woud420

There's nothing stopping you from applying for Daybreak for OpenAI / Unsure which program Anthropic has. But yes, you do have to share your identity and I can see how that is a blocker for some.

+1 on all of this, it is similar to the pattern I see emerging as well. For example I have open-sourced (let's be honest, it's just my personal tooling of taste) a repo on gh to try and formalize these things. I'd rather not share out of mostly imposter syndrome but essentially it's a scaffolding tool ala "create-react-app" for the stack I generally use.

Part of that is to create standardized "docs/{architecture, decisions, contracts, operations}" folders that my harness recognizes in my repos to have a better sense of where was it.

Glad others are converging towards similar ideas!

Yes, that's my point :)

It's not just a stored prompt, you can attach re-useable scripts to them to offer more determinism. ex: a script that validates that a PR follows exactly the template you want, with a max of N lines per entry.

The more determinism you have, the more consistent you can be and the more leverage you can build. (yes I understand that skill calls are non deterministic).

That's your experience and it's valid. For me documentation AND comments have been useful on occasion.

The core thing that I agree with is that comments (or docs) can get stale and not follow what is actually being executed. The way I work with it is by being structured, consistent and follow standards. Unfortunately for me, not all developers follow the same guidelines.

Code can "lie" too.

```auto a = 65535 + 1``` will give you a different answer depending on the architecture. You can then decide.. oh don't use auto or don't use c++ or whatever and have standards... like the standard you set for yourself "disallow comments from my LLM".

A comment is just a summary of the code in an abstraction that's easier to follow. Let's say you have a simple function which would produce an almost as large comment, yes obviously useless. If the function is large enough, yeah summarizing it as a comment is a good idea.

Now you might say, don't write huge functions. Sure I agree, but most codebase or teams are not super disciplined enough. So comments are a compromise.

tl;dr : https://charlielabs.ai/how-it-works/ and https://docs.charlielabs.ai/daemons

to get started, look at https://docs.charlielabs.ai/installation, but essentially

1) signup with your github login

2) install the CharlieCreates GitHub App on the repos you want Charlie to work in

3) create an issue, tag @CharlieHelps to help you create your first daemon!

the daemon will run on the charlie runtime and follow the watch / schedule conditions you set in your DAEMON.md file

full disclosure: i am part of the engineering team behind this.

Just to be clear, that salary is prevailing wage which is usually lower than the actual salary you're getting (does not include RSUs or stock on top of that). In my case the difference was about 30 to 40% lower.

>To be able to even consider to move there I would need a salary bump of 3x-5x. No way this will ever happen.

You'd be surprised. Granted it was over a period of 4 years, but I did hit that 5x.

You mean this C++ code?

  std::vector<std::pair<std::string, int>> s;
  s.push_back({"a", 1});
  s.push_back({"b", 2});
  s.push_back({"c", 3});

I mean let's compare apples to apples here.

I'm unsure as how you would identify people across apps using cookies but.. okay.

Considering that Mobile is about 50% of web traffic and that cookies are not very useful on mobile as well as ITP, I would say fingerprinting has been a very practical in building user profiles.

Yes RVO is one case where the compiler will do it automatically.

I think copy initialization of an object will have the same will apply copy elision as well to result in the same performance, but I'm not entirely sure.

>complaints about lines for the men's room after lunch? Spoiler alert: (non-contract) employees of big tech companies encounter those too.

Interestingly enough, that's one of my biggest complaint working @ Bloomberg.

I did mean insincere :). Thanks

While I agree that some Makefiles are terrible, I disagree that make is absolutely horrendous. It's sort of what you do with it; it's a copy paste garbled mess, of course it'll be terrible but you can make the same argument about maven, sbt and quite a few other build systems.

On another note, besides C legacy (memcpy, printf, malloc, etc.), could you point me towards something that is not type safe in C++ (preferably post C++11)? I find the argument a little bit disingenuous after claiming rust is type safe (you can do the same kind of non type safe magic with the unsafe keyword).

Interesting! I only knew of one person back then but I guess they started building a team under him. I mean it does make sense, Montreal has plenty of AdTech talent.

That's a very important point. I moved from Montreal to NYC a couple of years back and one thing I definitively miss is the food scene. Not that NYC is bad by any metric but Montreal just has an amazing food scene.

I don't think AppNexus has offices in Montreal, just a few remote people. But besides that the list is spot on.

Without getting in the history of the parent poster, he's not wrong. H1B is a temporary (non-immigrant) visa which allows dual intent. Yes, most people on dual intent visas eventually petition for a green card but I think it's unfair to qualify his post as "junk knowledge". Same thing with L-1A and O-1.

Source : https://www.uscis.gov/working-united-states/temporary-nonimm...

I wasn't clear enough and I apologize. You can use cookies but they will only be within the context of a singular app's browser. For example, suppose that you use two web browsers on your Desktop, Chrome and Firefox. If you visit xyz.com on FF, some cookie information will most likely be stored. However, if at a later time, you visit the domain on Chrome, it will not have access to the same cookie store.

This becomes important in the context of third party cookies that want to track you across apps. Hence why cookies are not a reliable method of identification on mobile.

Hope this clears it up. :)

Considering you cannot use cookies for mobile traffic, it's understandable that most firms are moving away from it. Fingerprinting and device IDs have been common for a few years and I don't think it will go away any time soon.

I mean it's not fair to add property taxes if you're not gonna do the same but you do have a valid point.

It's way different if you're in Alberta (flat provincial tax) vs NY than for example Quebec (biggest tax burden in North America) vs FL for example. Those things do need to be considered.

In my case, the difference between Quebec and <insert any state> was a no brainer.

Yup. I'm also canadian that also moved down the US. That describes my experience perfectly. While rent also easily tripled (from Montreal to NYC) I can say I now manage to save what I'd make gross in Canada, with a better quality of life.

They haven't for most cases but to be fair, even if the publisher would respect DNT, it doesn't mean that the ad-server at the end of the line or any of the other partners will.

1) Advertising

2) A lot. Publishers relying on clickbait to generate money. Advertisers creating invasive ads with autoplay sound and video. Ignoring do-not-track requests as part of the industry (even if some technology providers respect DNT, it seems like a lot don't). Malware. A lot of useless metrics. Bandwidth usage. Etc...

3) Micro-payments vs delivering content only when an ad has been seen? Validating content delivered through exchanges. A better way to anonymize data used for tracking? Smaller ads. Honestly, I'm not too sure, there's probably a lot that can be done but I feel the industry did too little too late.

Just a note, looking at the way most companies I've been involved with handle RF testing, it still feels like some electrical engineering is at a premature stage also.

Testing a transistor is the equivalent of testing an if statement. Both are trivial. The difficulty comes from testing multiple of these components acting in sync. Let's be honest, it's sometimes not worth the return on investment to test outside of your requirements.

If software has potential to injure someone, I would hope that it's been tested to similar specifications that hardware is tested on.