Certifications and compliance regimes are what got us into this mess in the first place.
854 karma · joined July 27, 2022
Certificates are ~useless in tech. I've encountered way too many candidates who have a bunch of certificates but don't actually understand anything they're supposedly certified in. They just memorized enough to pass the exam.
> Maybe it's possible to graduate from college with a CS degree without being able to solve fizzbuzz? So you need to check they can program despite their qualifications? IDK though.
Yes. It's astonishing how many CS grads simply don't understand programming.
That's preposterous. You're going to spend hundreds of hours working together. 4-5 hours is extremely reasonable to make sure it's a good mutual fit.
Of course, it shouldn't be 4-5 hours for all candidates. The last hour spent should have a pretty high conversion rate to offer.
But 4-5 hours for hired candidates is completely standard.
> A candidate cannot be doing 4-5 hours for an interview process just to hear a no at the end. Successful job hunts need to have many irons in the fire at once and if each one is taking 4-5 hours there's only so much you can realistically take on
This is a toxic attitude. If you "spray and pray" then refuse any actual interview processes then you're never going to get a great job.
Every job I've gotten came from identifying a dozen or so opportunities up front and going deep on them.
The entire article is just the whimsical fantasies of someone with no understanding of market reality.
L5 at Google is $372k which is enough to get to CoastFIRE after a decade.
He even links to it from his resume.
His problem is that he thinks L10 is the benchmark to compare against, when the vast, vast majority of engineers (including many with decades of experience) would never make it to L10.
His resume even confirms this[0], because he seemingly thinks the appropriate level at FAANG would be L10 which is extremely rare. There is a 0% chance that his experience would level him that high.
The entire article can be chocked up to a massively inflated sense of entitlement.
Are you really so self-centered that you can't imagine anyone doesn't care?
I'll raise my hand and say I personally am happy to trust Zed and am fine with auto-installing whatever binaries they propose.
I do think it's reasonable to have an option for people with different security postures, but don't assume you speak for everyone.
I don't understand the obsession with calling all skills "technical" though. Why do you feel that need?
> We often dismiss skills that are not societally valued by pretending they are not skills.
The truth is that "non-technical skills" are valued far more than technical skills. The people who run our world didn't get there from "technical" skills.
Non-technical skills are less legible so it's harder to deliberately practice them and there are many people running around in non-technical roles who are simply not good at the role. Tons of salespeople can't sell. Lots of product managers have no product vision. etc.
People who are actually good at non-technical jobs don't need to be lionized. They already have the money and power.
If you don't think any ISVs are making millions through the marketplace you're simply mistaken. I worked at Google Cloud and personally know at least one startup that made the majority of their revenue through cloud partnerships.
This isn't a death knell.
1. If you get into the marketplace, enterprises can spend their commit against you.
2. A few million in ARR is ~nothing to a hyperscale cloud, but meaningful to most startups. If you find the right positioning, you can get their sales team selling your solution on many deals.
This seems like a decent reason to stop committing the database to GitHub, but not a reason to move off SQLite.
If you have a small, read-only workload, SQLite is very hard to beat. You can embed it ~everywhere without any network latency.
I'm not sure why they wouldn't just switch to uploading it to S3. Heck, if you really want a vendor involved that's basically what https://turso.tech/ has productized.
URLs are not secrets. Don't treat them as such.
Typically, the LSP is notified on any file change and is responsible for keeping its own copy of the files. This way it doesn't need to request the "latest" files - on a keystroke, it just needs to update the actual file being edited.
It seems like the Deno LSP doesn't follow this push model for some reason, which is going to make it inherently unscalable in very large projects. I'm curious why.
It's just not enough money to sustain a VC-backed model or a large sales/support staff.
If OP is careful about managing expenses and doesn't set outlandish expectations for profit (or raise VC), a profitable niche is doable.
This is basically our whole business at grit.io and we also take a hybrid approach. We've learned a fair amount from building our own tooling and delivering thousands of customer migrations.
1. Pure AI is likely to be inconsistent in surprising ways, and it's hard to iterate quickly. Especially on a large codebase, you can't interactively re-apply the full transform a bunch.
2. A significant reason syntactic tools (like jscodeshift) fall down is just that most codemod scripts are pretty verbose and hard to iterate on. We ended up open sourcing our own codemod engine[1] which has its own warts, but the declarative model makes handling exceptions cases much faster.
3. No matter what you do, you need to have an interactive feedback loop. We do two levels of iteration/feedback: (a) automatically run tests and verify/edit transformations based on their output, (b) present candidate files for approval / feedback and actually integrate feedback provided back into your transformation engine.
[0] https://slack.engineering/balancing-old-tricks-with-new-feat...
[0] https://slack.engineering/balancing-old-tricks-with-new-feat...
Yes, it's hardly surprising that people find upvotes and direct social rewards more exciting than being slurped somewhere into GPT-4's weights.
That being said, the first time I had to edit this (even just do change the base string) I’d make the change.
If anything, I would go in the opposite direction. There's no need to use parameterized variables at all. Just write out the message 3 times:
private String generateGuessSentence(char candidate, int count) {
if (count === 0) {
return "There are no " + candidate + "s";
} else if (count === 1) {
return "There is 1 " + candidate;
} else {
return "There are " + count + " " + candidate + "s";
}
}
> And why do you think it's somehow better to have code behind a runtime branch (if) rather than a git branch?
1. It's a communication mechanism. Other people on your team should know what approaches you're exploring.
2. It is much easier to review small, incremental PRs than a massive PR dumped at the end of a project.
3. The lift from merge conflicts / integration work is less.
Of course, many tasks take more than a day to do well. That doesn't mean you can't break it up into atomic parts and ship each part every day (behind a feature flag).
I personally find the hubris of disappearing into a branch for many days without any feedback incredibly offputting. If you're working on a team, your team should be able to see your daily progress.