4 ms·

> If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make othe

> If you have a software engineer being promoted to senior software engineer (1 -> 2) without at least intermediate knowledge of the codebase, that'll make other seniors suspicious/wary. She clearly did. Without that she would not be able to onboard or contribute to the design discussions and would not be able to help customers out. You can't assume that customers implies non-technical. In mid to large orgs most of your customers are other teams with very technical needs. > if you hire a software engineer that does mainly/only glue work, you mis-hired No, it depends on what your team needed. You can't have a 5-person team where everyone is great at crunching code unless your only success metric is LOC produced. You need diverse set of skills to deliver and maintain the product. You mis-hired only if your glue competencies are already covered. In general I see this as a massive problem that many engineers believe that technical excellence is all that's needed to build a product. It isn't. Design reviews, code reviews, and onboarding for technical staff are very much technical. And simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once). If your glue person is picking them and you judge glue person's output by the complexity of those tasks (not technical enough!) then your metrics are wrong.

chrisweekly 6y ago
"success metric is LOC produced" == worst metric ever (even for strong programmers / IC's whose "only job" is writing code) -- and this is nearly universally accepted.
chrisweekly 6y ago
"simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once)" Given your technical seniority / superiority, whose time is better spent on tackling the thorniest challenges?
- sethammons 6y ago
  Depending on time sensitivity, the senior should be mentoring the junior on how to deal with the thorniest of challenges (appropriately scaffolded).
mattm 6y ago
> She clearly did. Without that she would not be able to onboard or contribute to the design discussions and would not be able to help customers out. You can't assume that customers implies non-technical. You'd be surprised. I've worked with some people that can say all the right things when it comes to design discussions. However, when it comes to them actually implementing the design discussions, that they themselves talked about, they struggle.
- kthejoker2 6y ago
  Why should I be surprised that there are people who are good at "do the right thing" but not "do the thing right" when so many SWEs are the opposite? Why do we keep expecting unicorn people who are good at everything both directly and indirectly related to their role? This is why we have cross disciplinary teams.
dragonwriter 6y ago
> You can't have a 5-person team where everyone is great at crunching code unless your only success metric is LOC produced You absolutely can. Software development is a field that requires a set of intellectual abilities that are mutually (broadly, though of course individuals vary) correlated, not anticorrelated. Being great at crunching code doesn't imply being bad at any other skill required of the profession.
- lowercase1 6y ago
  Once you factor in selection it probably does.

chrisweekly 6y ago

"success metric is LOC produced" == worst metric ever (even for strong programmers / IC's whose "only job" is writing code) -- and this is nearly universally accepted.

chrisweekly 6y ago

"simple technical tasks that are tedious and boring are still technical tasks. And as a senior I would never assign them to a junior developer unless there's a lesson to be learned by doing them (once)" Given your technical seniority / superiority, whose time is better spent on tackling the thorniest challenges?

sethammons 6y ago
Depending on time sensitivity, the senior should be mentoring the junior on how to deal with the thorniest of challenges (appropriately scaffolded).

mattm 6y ago

> She clearly did. Without that she would not be able to onboard or contribute to the design discussions and would not be able to help customers out. You can't assume that customers implies non-technical. You'd be surprised. I've worked with some people that can say all the right things when it comes to design discussions. However, when it comes to them actually implementing the design discussions, that they themselves talked about, they struggle.

kthejoker2 6y ago
Why should I be surprised that there are people who are good at "do the right thing" but not "do the thing right" when so many SWEs are the opposite? Why do we keep expecting unicorn people who are good at everything both directly and indirectly related to their role? This is why we have cross disciplinary teams.

dragonwriter 6y ago

> You can't have a 5-person team where everyone is great at crunching code unless your only success metric is LOC produced You absolutely can. Software development is a field that requires a set of intellectual abilities that are mutually (broadly, though of course individuals vary) correlated, not anticorrelated. Being great at crunching code doesn't imply being bad at any other skill required of the profession.

lowercase1 6y ago
Once you factor in selection it probably does.