bhuga
I got a custom domain. I still host it on google, because I know how impossible it is for small companies to have a reasonable program to deal with insider threats. Because of that, I think only one of the giant companies can realistically provide secure email. And the google app suite is great. Now that I pay for google workspace, there's support and appeals available, and if they ban me anyway, I still control the domain and can regain access to everything.
I have not been able to delete the old address, even after 3 years. There are some things like Google Fi that can only use a non-workplace google account. Very, very rarely, I still get an email that matters on it. But I got to the point where I could stop checking it in about 2 months, and now I look at it about once a week quickly, more out of habit than anything else.
The switch was annoying, but not "hard". It was worth it.
In a project where I already have a lot of linting brought into the editor, I want to be able to reuse that linting in a headless mode: start something at the CLI, then hop into the IDE when it says it's done or needs help. I'd be able to see the conversation up to that point and the agent would be able to see my linting errors before I start using it in the IDE. For a large, existing codebase that will require a lot of guardrails for an agent to be successful, it's disheartening to imagine splitting customization efforts between separate CLI and IDE tools.
For me so far, cursor's still the state of the art. But it's hard to go all-in on it if I'll also have to go all-in on a CLI system in parallel. Do any of the tools that are coming out have the kind of dual-mode operation I'm interested in? There's so many it's hard to even evaluate them all.
I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.
Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much as possible. And as per my earlier comment, setting up a fresh VM can be quite expensive in terms of developer time if test data needs to be configured.
As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when creating a new dev server. These devs tend to re-use their servers until our company-wide max age. Others, to be fair, spin up a new machine for every branch, multiple times per day, and spinning up a new VM might not be burdensome for them.
Our laptops don't receive connections, but even if they could, folks go on leave and turn them off for 9 months at a time, or they don't get updated for whatever reason, or other nutty stuff.
It's surprisingly common with a few thousand of them out there that laptop management code that removes old versions of a tool is itself removed after months, but laptops still pop up with the old version as folks turn them back on after a very long time, and the old tool lingers. The services the tools interact with have long since stopped working with the old version, and the laptop behaves in unpredictable ways.
This doesn't just apply to hypothetical VMs, but various CLI tools that we deploy to laptops, and we still have trouble there. The VMs are just one example, but a guiding principle for us been that the less that's on the laptop, the more control we have, and thus the better we can support users with issues.
They do, but I can see those changes if I'm helping debug, and more importantly, we can set up the most important parts of the dev processes as services that we can update. We can't ssh into a VM on your laptop to do that.
For example, if you start a service on a stripe machine, you're sending an RPC to a dev-runner program that allocates as many ports as are necessary, updates a local envoy to make it routable, sets up a systemd unit to keep it running, and so forth. If I need to update that component, I just deploy it like anything else. If someone configures their host until that dev runner breaks, it fails a healthcheck and that's obvious to me in a support role.
> Just to be clear, I think it’s interesting to have a healthy discussion about this to see where the tradeoffs are. Feels like the sort of thing where people try to emulate you and buy themselves a bunch of complexity where other options are reasonable.
100% Agree! I think we've got something pretty cool, but this stuff is coming from a well-resourced team; keeping the infra for it all running is larger than many startups. There's tradeoffs involved: cost, user support, flexibility on the dev side (i.e. it's harder to add something to our servers than to test out a new kind of database on your local VM) come immediately to mind, but there are others.
There are startups doing lighter-weight, legacy-free versions of what we're doing that are worth exploring for organizations of any size. But remote dev isn't the right call for every company!
I don't think there's confusion. I only have total access when the VM is provisioned, but I need to update the dev machine constantly.
Part of what makes a VM work well is that you can make changes and they're sticky. Folks will edit stuff in /etc, add dotfiles, add little cron jobs, build weird little SSH tunnels, whatever. You say "I can know versions", but with a VM, I can't! Devs will run update stuff locally.
As the person who "deploys" the VM, I'm left in a weird spot after you've made those changes. If I want to update everyone's VM, I blow away your changes (and potentially even the branches you're working on!). I can't update anything on it without destroying it.
In constrast, the dev servers update constantly. There's a dozen moving parts on them and most of them deploy several times a day without downtime. There's a maximum host lifetime and well-documented hooks for how to customize a server when it's created, so it's clear how devs need to work with them for their customizations and what the expectations are.
I guess its possible you could have a policy about when the dev VM is reset and get developers used to it? But I think that would be taking away a lot of the good parts of a VM when looking at the tradeoffs.
> What’s the size of the cloud instances you have to run on?
We have a range of options devs can choose, but I don't think any of them are smaller than a high-end laptop.
* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.
* Big investments into bazel.
* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".
* Local dev has laptop-based state that is hard to keep in sync for everyone. Broken laptops are _really hard_ to debug as opposed to cloud servers I can deploy dev management software to. I can safely say the oldest version of software that's in my cloud; the laptops skew across literally years of versions of dev tools despite a talented corpeng team managing them.
* Our cloud servers have a lot more horsepower than a laptop, which is important if a dev's current task involves multiple services.
* With a server, I can get detailed telemetry out of how devs work and what they actually wait on that help me understand what to work on next; I have to have pretty invasive spyware on laptops to do the same.
* Servers in our QA environment can interact with QA services in a way that is hard for a laptop to do. Some of these are "real services", others are incredibly important to dev itself, such as bazel caches.
There's other things; this is an abbreviated list.
If a linux VM works for you, keep working! But we have not been able to scale a thousands-of-devs experience on laptops.
They absolutely did! It was getting companies to agree to skipping straight to the onsite after a 15-minute recruiter call.
This lets you skip the back-and-forth of screen scheduling and result chats. In turn, that saves weeks of time during a job search, and allows you to have all of your onsites within a short time period, and then and offers come in within a much narrower window of time. You can make apples-to-apples comparisons about which role you might take that way, so it's a much lower cost for a much greater payoff to spend a few hours interviewing with a company you weren't thinking of to see if it's a fit.
In my mind, this was the absolute killer feature. I am still at a Triplebyte job 7 years later that impressed me via their onsite, and I would not have thought to apply if they had not been on TripleByte's skip-to-the-onsite list.
The unit of survival is not the individual or the species, but the gene. Genes maximize their survival by combining via sexual reproduction with other genes over time. Any one combination of genes will be out-competed over time.
The reason for honest aging signals is that a gene survives longer by getting out of the way of its offspring's combinations with other, newer genes. Sexual reproduction is the only way to get access to new phenotype features.
It's not service for the collective. Hanging around in one individual is the genetic version of vendor lock-in.
This mindset goes back to the AT&T antitrust breakup. It was decided that phone companies would not be allowed to reject each other's traffic, because the larger ILEC's (incumbent local exchange carrier) would find reasons and excuses to cut off the CLEC's. This would be more or less a death penalty to those businesses, and the ILEC's had exactly zero reason to want the CLEC's to exist at all, so there was a lot of fear and rulemaking to prevent this.
Fast forward 30 years and the details have changed, but the mindset is largely the same. The fear is still quite real, and that's why phone spam isn't treated like email spam. If i.e. verizon cuts off incoming calls from a random CLEC in a midwestern state, that business is just over, done, that's that. It would be impossible to restore the business after your customers left, which they would do more or less instantly; there's no court remedy that would fix it. Great pains are taken to ensure that such an action is legitimate.
The rules are oriented around the idea that the ILEC's were evil antitrust actors, and the plucky CLEC's are the competition we need to protect from big ILEC's heavy hand. In a world of spam, that mindset is backward. And that mindset is changing, but because of the reasonable concerns, it's taking longer than we expect.
> since a small minority of human drivers cause the vast majority of incidents
It's tough to find anything relevant on DDG or google, they come up with information about racial disparities in traffic stops...can you link anything to read about this?
Curiously, from the article, copyright infringement is not alleged:
> As a final note, the complaint alleges a violation under the Digital Millennium Copyright Act for removal of copyright notices, attribution, and license terms, but conspicuously does not allege copyright infringement.
Perhaps the plaintiffs are trying to avoid exactly this prior law?
That is to say, you have code prompts here, let Copilot fill in the gaps, and rate that code. Is there a study that uses the same prompts with a selection of programmers to see if they do better or worse?
I'm curious because in my testing of copilot, it often writes garbage. But if I'm being honest, often, so do I.
I feel like Twitter's full of cheap shots against copilot's bad outputs, but many of them don't seem to be any worse than common errors. I would really like to see how copilot stands up to the existing human competition, especially on axes of security, which are a bit more objectively measurable than general "quality".
* What's one thing you'd change about <company X>?
* Tell me about the last time you worked past 7pm.
* How surprised were you by your last performance review?
* When's the last time you referred a friend to <company X>?
* Tell me how the last incident you responded to went.
* Tell me about a time you were able to work on something you identified and selected.
* What question is always tough to answer as an interviewer at <company X>?
The one I liked asking as a candidate was: It's 2 years from now, and <company X> has failed. What happened?
I got some good real talk about that one, and some smoke and mirrors. It was a good baloney extractor.
I think an important thing is to ask interviewers to pick a concrete instance of a thing you're interested in, such as poor work/life balance, and talk about the most recent one. It's easy to say "oh, we have great work life balance," but that's different for everyone, and frankly it's just too easy to gloss over. Ask them why they worked late the last time they worked late.
For example, with your question:
When interviewing perspective employees, does the entire team participate in the interview process and make a hire / no hire decision as a team?
I'd instead ask:
Had you talked with the most recent person who joined your team before they were hired?
A quick summary is in https://www.apnews.com/d6a3852a6dd34a8c90a5a1acc0d0afaf, but that's just scratching the surface.
It was a design decision that all type annotation arguments be named as opposed to positional. As one example why, it makes the error messages better. You can always say "You're missing a type declaration for parameter 'foo'" as opposed to "You have four positional arguments and 3 types".
We could probably still bikeshed our annotations inside the `sig { ... }`. I'm not sure we'd make constants with unicode like BigMap‹Address→Account› for generics, though, how do you even type that? :)
We had them as hashes for a while, but it meant that code in all sigs was loaded as the code was loaded, even if runtime typechecking was disabled. We were forced to load all constants in any signature in a file, an effect which cascades quickly. It had a big impact on the dev-edit-test loop.
For example, if we're testing `method1` on `Foo`, but `method2` has a sig that references `Bar`, we'd have to load `Bar` to run a test against `method1`.
Now sigs are blocks and lazy, and we pay that load penalty the first time the method is called and a typecheck is performed.
In this case, your example is not valid syntax, which violates this rule. Not that I personally could tell you why the parser makes a distinction here, but it's at least part of the reason :)
irb(main):010:0> foo {a: "b"}
SyntaxError: (irb):10: syntax error, unexpected ':', expecting '}'
foo {a: "b"}
^
(irb):10: syntax error, unexpected '}', expecting end-of- input
foo {a: "b"}
^
from /Users/bhuga/.rbenv/versions/2.4/bin/irb:11:in `<main>'
irb(main):011:0> foo {params(a: "b")}
NoMethodError: undefined method `foo' for main:Object
from (irb):11
from /Users/bhuga/.rbenv/versions/2.4/bin/irb:11:in `<main>'
irb(main):012:0>
From the abstract: Commitment to hiring criteria prior to disclosure of the applicant’s gender eliminated discrimination
I'm sure there are many sitautions where training is less effective, but the hiring example is well supported.
Most training to overcome unconscious bias is about defining criteria before you see a candidate. If, before you view resumes, you've written down "We want someone with a master's degree and 4 years of experience in field X," you're much less likely to pass over a qualified resume, regardless of the candidate's personal characteristics.
I disagree that 'minimal changes to existing code' is a good goal for a Ruby parallelism solution. The large Ruby codebases I have dealt with have gigantic hacks to get around the GIL: complex fork management systems, subprocess management, crazy load-this-but-not-that systems for prefork memory management to optimize copy on write, and probably more. Parallel tasks in Ruby are a nightmare to work with.
Changing existing code _should_ be a goal of any Ruby parallelism solution. If we can't get rid of this kind of cruft, what are we even doing?
I still love Ruby, but I want go-style channels, not apologies for the GIL.
The products are garbage, but most of the prices are already pretty good. When you realize the prices are for two at the cost of a review, they're even better.
I still get emails trying to give me free stuff to change a one-star review I left a year ago for a one-ear bluetooth earbud.
On the other hand, I don't see how you can buy quality on Amazon anymore. I've started shopping on niche sites for things that I want to work, and I'd never buy expensive electronics. The risk of a counterfeit is just too high.
Serialization is not the hard part.
The semweb community was obsessed with ontologies and OWL and schemas and taxonomies. If we can just break the problem down enough, the logic went, then systems will be able to infer new data about the world. But it never worked out that way.
Eventually you just have to write some code. If you have to write code anyway, all the taxonomies and RDF in the world aren't helpful (indeed, they're almost certainly the least efficient way to model the problem). You just scrape the pieces of knowledge out of whatever JSON, HTML, or whatever else and glue them together with the code. You don't need the all-knowing semantic web, you just need a .csv of whatever tiny piece of it you care about.
I have a distinct memory of trying to sell someone on the startup I was working on, a SPARQL database. I was pitching RDF as a way to model the problem, but eventually the person I was pitching just said "well, we can just outsource the scraping to our eastern european devs and put it all in one big table." I had a kind of "oh my" moment where I realized that the startup was never going to work: in the real world, you just write code and move on. Taking part in the great semantic knowledge base of the world doesn't matter and isn't needed.
The other end of semweb, the "machine-readable web", more or less came to pass. schema.org, opengraph, and that sort of thing did 99% of what the semweb community wanted at 5% of the effort. The fact that all of that data is not in one giant database doesn't really matter to anyone; you rarely care about more than 2 or 3 web pages at once.