Hacker News Reader

Comment by LeoNatan25 | Hacker News Reader

I’ve become more of a lone wolf in my 30s, actually. A combination of gained knowledge and experience, teams not familiar with my tech stack, remote hours (both because of timezone difference and also my crazy work hours) and also, yes, less trust in other people’s opinions. This also happens. It’s not just teenagers that feel sometimes they have the most experienced opinion. After listening to bad discussion for long enough, one becomes burned out and cynical of the “team discussions” and just looks inward to find solutions for the most difficult problems.

View on HN

> teams not familiar with my tech stack

Not the other way around?

It’s all about perspective. In two companies now, I’ve been in teams that don’t really care about my tech stack. It was mutual, of course. You can blame the company for making these teams up (I did/do), but that how things are.

Normally the technology stack refers to the languages and frameworks underpinning the project.

It is very weird to be in a situation where (for example) we’re working on a project in python and one person refuses to use python. Weird enough that I’ve never seen anyone with a personal tech stack, most people just try to adopt the local custom of the team they’re hired into.

In my previous job, I was hired into a team of tech leads, each in their own field. In the current job, I was hired into a product team that was about a macOS app. After several reorgs, mergers and downsizing, the team is mostly web devs, backend devs (Go) and me, still developing the macOS app.

Why should I care about the teams’ other tech stacks (and vice versa)?

I understand now. In my terms, you're a team of one who happens to be sitting next to another team, maybe under the same manager. That sucks, I feel for you.

Do they not care about what happens if you decide you want more money, want to do something else, or just get frustrated and quit?

> teams that don’t really care about my tech stack

Relatable. I'd love to talk to them about my private Rust projects.

> You can blame the company for making these teams up (I did/do), but that how things are.

But... how did this work out in practice? There's a software project in language X, framework Y, domain Z, which everyone was familiar with, and you were brought in not knowing X and Y? That's like hiring for a Java position where the applicant couldn't care less for that the language. Strange.

In my previous job, I was hired in a team of tech leads, each in a different domain. But the development at large in that company was web development, which I didn’t know how much I’d end up disliking. So I focused on my things within the company minimizing interaction with tech stacks I didn’t care about.

Current job, I was hired in a team of macOS devs for a macOS product. Several reorgs, mergers and downsizing, my old team is basically gone, and I find myself in a team of web devs and backend engineers.

I do miss having people around who can keep up a conversation in my tech niche.

Saying that an entire team is unfamiliar with an IC's tech stack is indeed weird in most cases. But it can make sense, and largely depends on the relationship between the team and the person involved.

A good example from a recent gig: one of our scientists had a HUGE pile very complicated MATLAB, based on several dissertations worth of novel work on both numerical analysis and highly domain-specific mathematical modeling.

Our software engineers needed to either call into or directly use the MATLAB code. Sometimes changes were necessary. This caused a ton of friction for two reasons. First, our SWEs didn't know much MATLAB. Second, you'd have to read two or three papers of complicated mathematics to even understand what the code was doing prior to changing it, and most of our software engineers topped out with Calculus or maybe a Linear Algebra course. So our engineers were unfamiliar with both the tech stack and also the "knowledge" stack.

In that case, I think it's more accurate to say that the software engineers were unfamiliar with the scientist's tech stack than the other way around. There's no way in hell them or anyone else was going to come anywhere close to correctly rewriting the MATLAB code in any reasonable amount of time. And even if you could, the knowledge stack problem still exists.

You can think of hiring those types of scientists as one-man startups that are bringing in their own tech stack and debt that your existing org has no idea how to integrate. You need to plan that reality into both compensation amount and vesting/earning scheduling.

For compensation, err on the side of "way over asking", since this is going to suck harder than the scientist thinks. They are probably going to want to leave, and you need to be able to get them to stick around. (The dynamics here are similar to a startup founder or exec after a merger, but with slight difference: the scientist's "FU money" is a pretty much guaranteed cushy professor of practice gig.)

For vesting, err on the side of paying out bonuses or RSUs early but with a big vesting cliff 2-4 years out. So they get the cash before it vests. Get 'em hooked and don't let 'em leave until the work is caught.

And definitely bank on them leaving once the first cliff is hit.

Reply on news.ycombinator.com