fishtoaster

I only had one code sample.

As others have pointed out, there are a lot of problems:

- Many engineers don't write code outside of work and so don't have much code they can show off without breaching their employer's trust

- Those that do often don't have recent code.

- Those that have recent, personal code to show off have often written it to accomplish some goal and the code isn't necessarily a great example they feel like showing off

Really, the only people I've seen have good code samples are those who do extensive open-source work. And for those people, I'm probably already aware of that work when I checked their resume + opened their github.

> The problem ends up being, that I don't have any guarantee that the other side will spend any time on it.

This is a key thing for me. I consider it a moral obligation to give material feedback to anyone who does a takehome test for me - to invest at least some serious time evaluating it. Likewise, I would never give a takehome test until the candidate has at least had a phone screen with someone at the company and there's some level of investment on both sides.

On the other hand, I know a few junior devs right now who are submitting resumes and getting sent takehome tests off-the-bat. And, of course, after spending hours on those challenges, they get only form-letter rejections. I understand why companies do that - there's a glut of junior devs right now and any early-career role gets flooded with resumes that you need to somehow pare down - but I still consider it unconscionable.

I understand why you might not want to risk dealing with that.

I recently ran an interview process for a relatively senior eng role at a tiny startup. Because I believe different interview methods work better for different people, I offered everyone a choice:

1. Do a takehome test, targeted to take about 4 hours but with no actual time limit. This was a non-algorithmic project that was just a stripped-down version of what I'd spent the last month on in actual work.

2. Do an onsite pairing exercise in 2 hours. This would be a version of #1, but more of "see how far we get in 2 hours."

3. Submit a code sample of pre-existing work.

Based on the ire I've seen takehome tests get, I figured we'd get a good spread between all three, but amazingly, ~90-95% of candidates chose the takehome test. That matches my preference as a candidate as well.

I don't know if this generalizes beyond this company/role, but it was an interesting datapoint - I was very surprised to find that most people preferred it!

When possible, yeah. I imagine some sort of golden rule: "make PRs for others to review that you would like to review yourself." There's plenty of room for exceptions there - my coworker is currently reviewing a 1300-line PR after my apologies for it :)

But yes, we generally break things down into the smallest meaningful chunk possible to deliver. If that chunk is too small to understand the larger work that it's part of (as is usually the case for non-trivial work), we can discuss the larger work in another forum (ad-hoc verbally, via design doc, via meeting, etc).

I've been working through PRs since around 2011 and I don't think I've ever seen a place where PRs were intentionally used to handle design issues. Occasionally design problems will get brought up in PR, but that's always been considered a failure of earlier planning when it happens.

Depending on the company, the design discussion you're talking about has happened:

1. In verbal discussions with other devs before fingers ever touch keyboards

2. In long-form writing (Text docs, then Google docs, then later Notion)

3. In per-project slack channels

4. Out loud, on a whiteboard.

Right now it's very much #4 because my company is 2 devs and a founder. But even here, I wouldn't expect to get anything non-trivial into pull request before figuring out the overall structure with the other dev verbally or in writing.

This is hilarious and amazing. But moreso than most such cool hack projects, it has a great writeup. The author really did a great job walking through how it worked. Love it.

It's a fun, upbeat article, but as an actual case, I think it falls down here:

> Our abundance of weirdos creates diversity not only in supply, but also in demand.

That's certainly true (imo), but the author seems to implicitly expect the supply and demand to match up and I'm pretty thoroughly convinced that they do not.

Thinking narrowly about jobs, there are a lot more people that want to be artists than people that want to buy art, causing art to be a pretty hard industry to make a living in. This is equally true of any other niche where there are X people wanting it and Y people providing it: there's no reason to expect those to be equal and, as it turns out, they rarely are.

I'm inclined to support well-compensated non-competes, eg "you can't work in this industry for 1 year, but we'll pay you 100% of your salary for that year." That would allow non-competes for people where it really matters to a company (eg where they're willing to throw a lot of money after it), but ban it the rest of the time.

It's still harmful, but you're at least able to get compensated for the harm.

I came to this same conclusion some years ago while working on a side project.

Before anything LLM existed, I built a site[0] to generate fake "AWS Blog Posts." I trained a markov chain generator on all AWS announcement posts up to that point, copied the html + css of aws's standard blog posts, then glued them all together with some python + JS. It turned out, IMO, pretty funny! People familiar with AWS's blog posts would often get several sentences in before they realized they were looking at word-soup.

When GPT was new, I looked into using that to "upgrade" it. I spent a weekend messing around with Minimaxir's gpt-2-simple generating blog posts based on AWS content. What I found was, ultimately, it was way less fun. The posts were far too realistic to be interesting. They read like totally-real blog posts that just happened to not be true.

I realized then that the humor of those early markov generations was the ridiculousness. The point where, a few words or sentences in, you realized it was all nonsense. LLM's these days are too good for that - the text they generate is sometimes wrong, but rarely nonsense in a humorous way.

Markov chain content was wrong in a "kid's say the darndest things" way, while modern LLMs are wrong in a "My uncle doesn't know basic geography" way.

[0] https://totes-not-amazon.com/ - click any link to get a new one.

There's also a sequel to Lena, though not for free online. https://twitter.com/qntm/status/1732377446576435337

For what it's worth, I found it almost trivial to set up open telemetry and point it honeycomb. It took me an afternoon about a month ago for a medium-sized python web-app. I've found that I can replace a lot of tooling and manual work needed in the past. At previous startups it's usually like

1. Set up basic logging (now I just use otel events)

2. Make it structured logging (Get that for free with otel events)

3. Add request contexts that's sent along with each log (Also free with otel)

4. Manually set up tracing ids in my codebase and configure it in my tooling (all free with otel spans)

Really, I was expecting to wind up having to get really into the new observability philosophy to get value out of it, but I found myself really loving this setup with minimal work and minimal koolade-drinking. I'll probably do something like this over "logs, request context, metrics, and alarms" at future startups.

From use, it seems like "Source Available" generally means "it's not open source, but you can go and read the code somewhere." So it's more a definition by contrast, really. "Fair Source" is a new term defined more precisely by https://fair.io/about/ - it seems to refer to be a more specific term referring to this specific license type.

An increasingly common situation for open source projects is:

1. The FooLabs company creates the Foo open source software, which gets popular

2. FooLabs offers FooCloud, a paid, hosted, managed version of Foo for those who don't want to run Foo themselves.

3. AWS sees that Foo is popular and creates a competing paid, hosted, managed version of Foo (say, "AwsFoo").

4. FooLabs' hosted version doesn't really have much advantage over AWS and AWS has a huge base of existing customers, so it outcompetes FooLabs.

5. FooLabs perceives this as unfair. They did all the work creating + maintaining this software, but are unable to reap any rewards.

Different people have different opinions on #5, ranging from "Hell yeah, screw AWS!" to "What did you expect when you made this open source?"

As a result, there have been a wave of not-quite-open-source licenses aimed at preventing #3, often with a clause like "This license doesn't let you run a paid, hosted, managed version". GitButler's license is aimed at doing exactly that. People have been calling that "source available." Some people are trying to rebrand that as the cooler-sounding "Fair Source."

Some of these have caused huge community upsets because Foo is often popular because it's open source, and it feels like a bait-and-switch to suddenly yank that away once Foo reaches a certain point of growth. ElasticSearch is the biggest example that comes to mind: https://www.elastic.co/blog/licensing-change. GitButler, thankfully, is being much more up-front about it!

"Waymo operates about 300 driverless cars in the city, up from the roughly 250 robotaxis it used to start commercial service last August."

Sounds like a relatively small increase in actual cars over the last year despite a significant increase in use of those cars.

This looks very cool! Having implemented SAML before, it was definitely a pain and your tooling looks painless!

That said, the pricing worries me a bit. This is a tool we'd have to build on top of. Which means that if it disappears later because you went out of business (or just changed your pricing in some way that hosed us), we'd have a whole big, unexpected engineering project to rewrite our SSO.

And given that you're giving a hosted product away for free, it seems pretty likely that you will either eventually go out of business or change your pricing.

I know it sounds silly, but as someone who'll probably have to add SSO to my current project in the next 6-12 months, I'd be a lot more comfortable betting on you if you had a sustainable-sounding paid tier other than "free for now" and "idk email us." It'd certainly make it easier to pitch to the rest of my team. :)

Oh, they can and were. But bad actors scrape github constantly for access keys. If you commit yours to a repo, some script somewhere will find those keys and use them to spin up EC2 boxes mining bitcoin or use SES to send scam emails within minutes. You can invalidate the keys and scrub your AWS account once you notice the issue - it just depends on how much damage the bad actors are able to do before you do that.

In my case, our CTO was messaging me (either Slack or Hipchat - whatever we were using at the time) within an our or two. Iirc they only managed to accrue a few thousand dollars in charges before we got it under control.

I once made a huge fuckup.

A couple years into my career, I was trying to get my AWS keys configured right locally. I hardcoded them into my .zshrc file. A few days later on a Sunday, forgetting that I'd done that, I committed and pushed that file to my public dotfiles repo, at which point those keys were instantly and automatically compromised.

After the dust settled, the CTO pulled me into the office and said:

1. So that I know you know: explain to me what you did, why it shouldn't have happened, and how you'll avoid it in the future.

2. This is not your fault - it's ours. These keys were way overpermissioned and our safeguards were inadequate - we'll fix that.

3. As long as it doesn't happen again, we're cool.

Looking back, 10 years later, I think that was exactly the right way to handle it. Address what the individual did, but realize that it's a process issue. If your process only works when 100% of people act perfectly 100% of the time, your process does not work and needs fixing.

Agreed. I've given a few conference talks and found judicious animations super helpful when I'm presenting code.

Showing 10 lines of code on a screen at once is a surefire way to have the audience either not read/understand it or to read it, but ignore what I'm saying. So I like to build up a slide full of code by starting with a couple line (eg the function definition), then adding a few more, then a few more, and then the whole thing. Subtly animating the new line in is a great way to highlight what's changing. Double-so if I'm reordering lines. Otherwise the code is just flashing from one state to another and it's not always obvious what happened.

Even better, I sometimes want to walk through the execution of code. I love having a red arrow highlighting what line we're on, and animating it between positions is a good way to highlight that we're moving from one thing to the next, especially with non-linear jumps (like from the end of a loop back to the top).

Animation is an easily-abused tool, but it's also a powerful one.

This is pretty much what I've come to over the years. It kinda feels like the "IQ Bell Curve" meme:

Beginner: I'll just create an if statement with 3 clauses.

Middle: No! that's clearly a ton of duplication - it's bad code!

Expert: I'll just create an if statement with 3 clauses.

And I can see how people get to the middle position. People often tell beginners to eschew duplication. They learn to see any trio of similar-looking lines as a code smell and jump to refactor. It takes a few years of doing that and getting burnt by it before you can really differentiate "this is duplicative and would benefit from refactoring" from "this only looks duplicative, and is actually cleanest with the repetition in place."

I feel this is a key thing that makes chat work really well for some remote workers and terribly for others: what's the expectation of responsiveness to chat?

For example, if you feel you need to respond to any DM (either implicitly due to company culture or explicitly because your boss has brought it up as a complaint about you), then slack is a huge interruption. You probably feel the need to have intrusive notifications enabled and/or a bouncing dock icon indicating new messages.

On the other hand, if the norm at your company is "slack is async so expect a response in 2-3 business hours," then yeah - it's rarely, if ever, interrupting.

Another goal (as I understand it) of the H1-B process is to allow foreigners who've come to the US for school to stay here and work after they've graduated. This seems (IMO) better than training a bunch of valuable people, then having them immediately go back home.

A system based entirely on salary would bias towards only senior roles, preventing the handling of that scenario at all.

Yeah, General Mental Ability tests are well-supported as the most effective way to measure candidates, but you're right: it's a legal gray area. And even if it weren't, devs absolutely hate them.

So no matter how predictive they are, it's ineffective to use them because you'll identify good engineers... who will never want to work for you ¯\_(ツ)_/¯

I feel like 99% of eng interview advice sounds just like this: "I've interviewed a bazillion people, everyone else is doing it wrong, here's the one good way."

Honestly, I think a lot of it is akin to medieval quackery. "I've treated hundreds of patients with leeches and the large majority of them eventually recovered - you should listen to me!"

I wish that we, as an industry, would spend less time reinventing interviewing from first principles. There are decades of research on how to interview people effectively. I highly recommend Schmidt + Hunter's meta-analysis (https://www.researchgate.net/publication/232564809_The_Valid...) as a starting point.

From my read of the research:

1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way.

2. Use structured interviews. Engineers love to just have loose conversations and judge people based on that, but structured > unstructured. Plus (just my guess here), I suspect unstructured interviews leave a lot more room for bias.

3. Plenty of techniques are effective on their own (eg references), but add minimal effectiveness when you're already doing a more effective test (eg work sample) and are therefore pretty much wastes.

You say "buy out" like it's a bad thing. Presumably that's a huge win for you if you started (or have equity in) the company - and if not, you can just... not accept the buyout offer?

One role of representative democracy (vs direct democracy) is to balance competing desires. Eg everyone wants good roads, but no one wants higher taxes. If you allow people to directly vote on each, people vote for higher costs and less revenue. So instead, we elect representatives to take a mix of popular (give us things) and unpopular (take things from us to pay for those things) positions at the same time.

Housing policy is the same thing. People widely support "cheaper housing" as a concept. If you magically halved the cost of all houses in the bay area, a lot of people would jump for joy and move to larger/nicer houses. On the other hand, roundly reject the things necessary to accomplish that - eg big housing complexes next door to them. It's the role of elected representatives to balance those desires.

That's where the moral authority to override a specific local desire comes from.

The idea of using CSS-triggered requests for analytics was really cool to me when I first encountered it.

One guy on twitter (no longer available) used it for mouse tracking: overlay an invisible grid of squares on the page, each with a unique background image triggered on hover. Each background image sends a specific request to the server, which interprets it!

For fun one summer, I extended that idea to create a JS-free "css only async web chat": https://github.com/kkuchta/css-only-chat

I love putting hilbert curves into various simulation and building games - you often get interesting results! And if you don't, it at least looks cool.

One time I wrote some ruby and some lua to generate a hilbert curve in Factorio - I'm pretty happy with the result: https://github.com/kkuchta/factorio_hilbert

> This honestly looks simple enough that a developer/DevOps team could manage it. With the other 'hyperconverged' infrastructure offerings you will still need a dedicated team of trained ops professionals to manage it.

That seems like the best explanation of the value here I've heard so far! I could definitely see a number of SMBs whose use cases are expensive in AWS/etc and would be a good fit for a few racks in a datacenter, but who don't want the cost of a team to manage them. If this significantly lowers the skill threshold necessary to run servers in a datacenter, I could see that being a huge value prop.

That idea is covered in the bottom of the article.

The problem is that it also biases towards much more senior roles.

One scenario we generally want to handle is: a person comes to the US, gets an advanced degree in a high-demand field at a US university... and then is immediately kicked back to their country of origin. H1Bs can help that person stay here and put down roots. But a fresh college grad is never going to be able to compete in a salary-based auction like you're describing, so pretty much all young, ambitious, well-educated people will get the boot.

> This is the only way I've found to attack the structural problem of tipping without hurting the workers.

That's my big problem. I hate tipping, but I still tip well - to do otherwise is to punish the people with the least ability to change the system.

The only good way I know of to attack the structural problem is to preferentially frequent the few restaurants with a non-tip policy.