[groby_b]

As a manager who told folks that maybe they should consider what their main lane is: There's nothing wrong with learning a different lane. There's a lot wrong with showing up in a different lane as if you had all the answers.

Our industry is prone to the latter. By all means, explore other lanes, but don't be that guy. By all means, learn, but please do this from a place of curiosity and humility.

Ask people who live in that lane how you can grow. Volunteer for the scut work until you deeply understand it. Be a partner to the people who spent a lot of time growing in that lane, not an antagonist. (I'm sure PP is aware of that, I'm using the generic 'you', not the personal)

[frutiger]

> (I'm sure PP is aware of that, I'm using the generic 'you', not the personal)

The English language has a specific word for that: “one” instead of “you”, but sadly this word has become more and more antiquated.

[groby_b]

I'm aware we have "one", but I'm also aware I sound like my great-grandmother when I use it.

One has to make tradeoffs ;)

[moosedev]

> As a manager who told folks that maybe they should consider what their main lane is: There's nothing wrong with learning a different lane. There's a lot wrong with showing up in a different lane as if you had all the answers.

Also beware of neglecting to fulfil the responsibilities and expectations of the lane you are ultimately being evaluated in, especially earlier in your career. I've given the (common) advice to junior engineers to become the team expert in one thing relevant to the team (something akin to this was even in the SDE1-2 promotion rubric at Amazon), but occasionally that advice needs tempered by subsequent advice on not tunnel-visioning on that one thing (and/or choosing a more relevant thing).

Broadly agree with the article and the general advice here though!