caffeine

I would’ve found it similarly both racist and harmlessly humorous if the author was going to a party and said “I channeled my inner Jamaican and tried to dance.”

Or if she was going to the interview and said “I channeled my inner German and got there exactly on time.”

Like, it’s fine. Good-humoured stereotyping is fine. Self deprecation is fine. We don’t all have to be passive aggressive all the time just waiting for people to screw up so we can dunk on them.

I have seen a lot of people do more and better. But different work, not coding.

Like leading and managing people is very possible for some elite people to do for say 70 hours a week and mostly involves talking, persuading, answering emails and phone calls, and most importantly making good decisions.

The value of good leadership and good decisions is directly proportional to the number and quality of people being led.

So that could be a huge value. Doing twice as much of it could way more than double that value with compounding.

That doesn’t make any sense at all. His wealth isn’t made up of financial resources and opportunities that other people could have used - his wealth is the price that other people would be willing to pay him to own shares in the companies he created.

I think it’s a common misconception out there that paper billionaires like Elon and Jeff Bezos have like a giant pile of cans of food in a warehouse somewhere that they could give out to people but don’t because they like having the biggest pile.

That’s not really the case.

Like imagine Elon Musk works 80 hours a week and he doesn’t suffer any negative consequence, he just becomes the most productive human ever according to the market.

And then a bunch of other people work 80 hours and they do suffer burnout and become slightly less productive than if they had worked 40 hours.

If you say “What’s the expected value of working 80 hours rather than 40?” in that scenario, it’s extremely positive, because the tiny chance you become Elon and have half the wealth in America offsets the very high probability you become a burnout who does no better than average.

That would allow critical sections that happen to use a library not to need to audit all the code in the library for panics.

Interesting list of examples, I wouldn’t necessarily have grouped these together?

Have you applied for these at some point? I haven’t, but the emphasis seems quite different at each company

When the KCG thing came out, one of the new grads was renamed “Power Peg” for a few weeks.

I miss the 2010s. It was a lot more fun when people leaned into stuff instead of being scared all the time.

* Listening to each person’s specific concerns carefully and in detail, and then applying as much creativity and empathy as possible to help them come up with a resolution?

* Giving people increased responsibility and increased autonomy as a response to signs of burnout?

* Quickly transitioning coddlers (who stifle growth), complainers (who destroy motivation), victims (who destroy alignment), braggarts (who steal credit and poison achievement) out of teams?

* Managing the team competently so that forward progress is actually happening and the whole team can see it and sense it and take pride in it?

* Ensuring that the team’s mission, the company mission, and business value are all aligned, and making the team stakeholders to give them agency?

Personally, I find saying “the employees have burnout, they should work less and celebrate more” is pretty naive. It’s likely to make things worse.

Burnout isn’t overwork. It’s more like hopelessness. Effort is being made but the emotional reward for visible progress towards a valuable goal is not forthcoming. It can feel like overwork, but it’s more the work to reward ratio that’s a problem.

Now those firms are all in a completely competitive industry squeezing each other for basis points.

Meanwhile the definition of a FAANG is that it has an effective monopoly, and these companies are taking in way more money than the HFT industry. (Netflix is losing its monopoly but we can’t really drop N from the acronym without a replacement..)

The solution here is to rebrand it with some vague euphemism:

“Ah yes the component underwent a state calibration”

Do you have any particular rules about performance? I worry that accepting net improvements on functionality alone could result in “death-by-a-thousand-cuts” performance issues down the line (assume it’s a project where performance is one of the deliverables).

Would you ask a contributor to perform benchmarks or some other performance validation, for example?

Pitch them to the various JS conferences and go give the talks. Release them as YouTube videos, and blog posts. Mention the fact that you are available to help teams optimise their front end code, and love doing it.

I think this process would take 3-6 months and you would have a great brand from which to build your business.

You could have a great lifestyle and a great business after a few years of work and growing a team of skilled JS performance experts.

Eventually you would probably stumble your way into a solid product once you had solved enough customer problems to see the commonalities (or through your internal tooling etc).

Seems like they could’ve used that instead (plus a Kafka connector) and benefited from a lot of deep research into how to do this optimally

Yes we did this too for a while. In the end it slowed down dev velocity too much and we could afford to trade off some slight tail latency. Mind you this was back in like 2016, I haven’t used Java in trading for a while..

> it's going to end up stealing cache lines from the application core's L1 cache

This happened but in practice it wasn’t a big deal, it could be pretty effectively mitigated by consistently running the fast-path code to keep the caches hot.

In that scenario, you wouldn’t want the GC to run on that core, for sure.

They’re crazy because they are so unstable that you basically can’t reboot them and expect them to reliably come back up, so you are stuck on that given kernel version and firmware etc (important for eg the custom network cards that often want firmware updates).

You just turn it on, run it for like a year, and then it dies and you trash it and get a new one delivered.

I’ve done most of my interviewing in finance where:

1. The engineers are mostly really good

2. They almost never have side projects, and everything they have ever done is super secret and proprietary.

For this it makes sense to ask people to do a take-home, and then ask them questions about it when they come in.

I usually also ask them to add a simple feature to their code and just silently watch them code it. You learn a lot from watching how someone breaks down a simple problem, especially where they are expert (ie they are working in their own codebase).

Genuinely curious why you think this is? To me it seems a massive leap?

Trying to steel-man this, if:

1. The people who know best about the domain are not technical and don’t know algorithm thinking

2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it

This is basically the consulting scenario, which is where DDD came from (?) Then it would make sense - when the team leaves and the next guy comes in with no clue how it works, he can read it out to the domain expert who will roughly understand what it’s doing.

On the good teams I’ve seen, the domain experts and the people coding are the usually same people, the “domain vocabulary” is CS, and the team is looking for maximum leverage (trying to do with 10 ppl what others do with 100 people).

So it’s quite a different scenario than 100 ThoughtWorkers getting dropped into some vertical they know nothing about and being expected to model a bunch of existing business processes.

To me, Domain-Driven is sort of an extension of Object-Oriented fundamentalism that used to reign, especially in the Java world. You make a class or a micro-service for every concept in your world.

It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right. You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc.

Data-Driven is the idea of leaning in to the fact that fundamentally, your software is a program, running in computers. It is going to turn some input into some output. You design along the axis of what data you need, how it is represented, where it needs to go, what transformations need to be applied, what output needs to be produced, and what needs to be stored. It tends to look more like functional programming, although you can certainly also apply mutating transformations, usually for efficiency.

IMHO, the latter is a great way for smaller teams to produce modest amounts of code that accomplishes a great deal.

What is your take on why they failed?

If I’m curious how a company did something, searching for their job descriptions can turn up interesting stuff like what languages and frameworks they use, and often from there you can infer what their architecture might look like.