thoughtspile

7 ms·

1.
by thoughtspile 3y ago
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.
2.
by thoughtspile 3y ago
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 vaca
3.
by thoughtspile 3y ago
But then again, c++ hft and payment processing aren't exactly low-stress jobs either
4.
by thoughtspile 3y ago
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 prev
5.
by thoughtspile 3y ago
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
6.
by thoughtspile 3y ago
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
7.
by thoughtspile 3y ago
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
8.
by thoughtspile 3y ago
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
9.
by thoughtspile 3y ago
I've also seen horrible engineers whose code made entire teams miserable become amazing managers tho
10.
by thoughtspile 3y ago
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 removi
11.
by thoughtspile 3y ago
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,
12.
English learning game – built with AI(team-hugh-laurie.github.io)
1 points by thoughtspile 3y ago|0 comments
13.
Tiny JavaScript: a collection of libraries under 2 kB(github.com)
2 points by thoughtspile 3y ago|0 comments
14.
by thoughtspile 3y ago
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
15.
I built banditypes, the smallest TS validation library(blog.thoughtspile.tech)
2 points by thoughtspile 4y ago|0 comments
16.
BanditStash – a better way to use localStorage. Feedback welcome(github.com)
1 points by thoughtspile 4y ago|0 comments
17.
by thoughtspile 4y ago
Lol, this is brilliant!
18.
by thoughtspile 4y ago
I often use it to infer one generic parameter: type Output<Fn> = Fn extends ((a: unknown) => infer Out) ? Out : never;
19.
by thoughtspile 4y ago
Thanks! I use excalidraw: https://excalidraw.com/ I think most web-dev bloggers use it, makes me feel very boring
20.
by thoughtspile 4y ago
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 l
21.
by thoughtspile 4y ago
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.
22.
by thoughtspile 4y ago
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"
23.
by thoughtspile 4y ago
always, because "unknown" includes null / undefined, which don't allow property access at all.
24.
by thoughtspile 4y ago
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
25.
by thoughtspile 4y ago
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.pr
26.
by thoughtspile 4y ago
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",
27.
by thoughtspile 4y ago
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 }
28.
by thoughtspile 4y ago
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>
29.
by thoughtspile 4y ago
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 un
30.
Things you may not know about React's useState(thoughtspile.github.io)
2 points by thoughtspile 5y ago|0 comments

More ›