thoughtspile

I think that's the optimal EM career path TBH. It's a shame many companies don't have an official middle-to- manager switch mechanism.

If you want to build a decent team, you really have to relax your grip on the tech part.

You don't fix every problem yourself, but have someone who can fix it available. Otherwise, people don't grow, and you can't take a vacation. You totally need a general (middle / senior level) understanding of technology, but having a separate person with strong technical chops is key.

> In which company does this happen, I wonder!

As a staff engineer on a design system for a top 50 website, roughly half my job was detailing a tech roadmap and identifying what can break across the codebase, something you can do perfectly well on grass.

But then again, c++ hft and payment processing aren't exactly low-stress jobs either

I even think this is sometimes in good faith, as in "this is some serious shot, better handle it myself to avoid failure".

My favorite pattern is what I call "code sheriff" lead, who does all code reviews himself to prevent bad code from reaching trunk. Then proceed to complain how you can't go on a vacation because all processes stop.

Good point on the control over your promotions, it's something I experienced when moving into an EM role. Banging my head until hitting an actual growth team.

I come from Russia, we're not exactly known for great people management, and I'd say management up to department head is expected to handle the tech part as well even in larger companies such as Yandex / VK. This fits your definition of normal companies perfectly.

Thanks for the feedback! I must say I've never worked in real big tech, and I've never worked with an IC beyond staff level. I'd imagine promotions to principal / fellow are quite rare as well? Besides, most "normal" companies don't have these grades, at all.

By transferable, I mean skills that are useful outside of our big tech bubble. You might not want to go out as money is very nice, but still good to know you can do something beside computer beep bop.

Man, people have a hard time talking to each other indeed. I might have to resort to some silly kindergarten games to make that happen

Not saying management is harder than engineering, at all. It's just another nice big area to learn something new.

Big companies tend to be quite prescriptive about role boundaries, so if you're an FE engineer, you can learn design and provide input as much as you want, but you won't likely get to design a new screen from scratch instead of your regular designer.

I mean, over the last few years as an IC I fiddled with CI setups and automated QA, wrote some CLI codegens, but after some time you really notice you start inventing problems to have some fun.

I've also seen horrible engineers whose code made entire teams miserable become amazing managers tho

Well, it's well known that to become a team lead you must eat the previous team lead)

To be fair, some managers over-optimize to protect against people undermining them, not sharing knowledge and responsibility and even actively removing top performers with leadership ambitions

I haven't had any luck applying to leadership positions without prior experience. Your best bet is finding a fast-growing product: when the team triples, you'll need some new managers. I got to move around 2 months into my IC job, and now my team has grown to have another 3 leadership slots.

Note this is not a map of people or sub-teams, but of roles seen in a product team.

In an organization, you typically have several product teams, some infrastructure teams (like security or dev tooling) that don't directly ship to users, and a management structure of EMs and C-levels on top.

Lol, this is brilliant!

I often use it to infer one generic parameter:

type Output<Fn> = Fn extends ((a: unknown) => infer Out) ? Out : never;

Thanks!

I use excalidraw: https://excalidraw.com/

I think most web-dev bloggers use it, makes me feel very boring

I'm afraid you're confusing something!

The intersection of all types is never, because, say, number and string don't intersect. The union of all types is unknown.

any doesn't show set-like properties and yields ternary logic in clauses like any extends T, which makes it a paradox.

Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.

Exactly, that's why I wrote the article =) Makes perfect sense in "set world", but not in "common sense" based on your feeling of the word "never"

always, because "unknown" includes null / undefined, which don't allow property access at all.

Almost every case where you use the value results in an error with unknown, but not with any:

  let danger: any;
  // These all compile:
  danger(), 9 / danger, danger.access, danger.map(x => x \* 2)

  let safe: unknown;
  // These all explode in TS:
  safe(), 9 / safe, safe.access, safe.map(x => x \* 2)

Saying a value is "unknown" means making no assumptions about the value. It might be a null, a number, a function, you don't care because you aren't going to do anything with this value. If you call() it, or read.some.property, TS complains because you're making assumptions about the object that TS did not ensure.

You're making the same mistake as I sometimes do, thinking in terms of "object shape" or "functionality". Here, I use "subset" in a sense of "all values that belong to Sub also belong to Super", in line with a set-theoretic view of types in the post. Also see subsets on wiki: https://en.wikipedia.org/wiki/Subset

Try this one: A is subset of B iff all the values that belong to A also belong to B. In your example (and in real life), every dog is an animal, so dogs are a subset of animals.

Here, you expect obj to have a property called "value", so I'd say you do care about the type of obj. A valid type would be obj: { value: blah }

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record<string, unknown> or P extends Promise<unknown>

Fair enough, "is assignable to" is another synonym for "is subset of". I find it much easier to reason about things I can visualize, like sets, which is why I love my set interpretation.

Edit: besides, it's quite unintuitve that "never" is assignable to anything. How can never be something?

Next steps links should be fixed now. The problem with conflicting scroll / orbit on mobile needs more thinking, thanks for the feedback.

GH pages cache can be very annoying sometimes.

Fixed — thx and hugs!

I did use axonometry in the early versions. While it did work well for surfaces with faces, lines and particles floating in 3D space were extremely confusing because you couldn't tell what's closer. Supporting different projections (and generally exposing the lower-level renderer details like controls) is a great idea, and should be a quick fix — I've made an issue https://github.com/thoughtspile/grafar/issues/7

You can style the container via CSS. There is actually a huge pile of examples in the repo: https://github.com/thoughtspile/grafar/tree/master/examples Some of them are for older versions and need to be updated, and I just couldn't find a quick way to slap a gallery into the docs, but I might get to it someday.