4 ms·

This is also the strategy I tend to take. Strong, broad fundamentals so I can quickly pick up specifics on the job.

by pcstl 6y ago

superbcarrot 6y ago
This still restricts you from getting many of the jobs that require narrow specialization. Specializing on the fly only works to a certain extent and only if you get the opportunity to do so in the first place.
- pcstl 6y ago
  In my experience, "narrow" professionals tend to heavily overestimate what they bring to the table, which makes them not very hard to outcompete.
  - username90 6y ago
    Switching technology is easy, switching domain is hard. You can't specialize in a technology, that is just nonsense, you specialize in a domain. Or several domains if they are simple enough. Like, the typical needs of a web product are simple enough that you master how to do the database, back end and front end. You wont be able to do the back end or database at Google scale, but you can master doing them at typical scale and I'd actually argue that Google scale is a different domain entirely with a different set of skills, you need a different specialist to handle that problem and he wont be able to efficiently solve your small scale needs either.
    - Ericson2314 6y ago
      I think one person can understand the backend at google scale. You shouldn't LARP solving problems you don't actually have (it's stupid to pay those costs, especially when the google state of the art isn't really that good) but you can still understand it. - Modern hardware realities (nearby network faster than disk they say, memory of all sort slow relative to CPU). My mental model is the good ol' hydrolic analogy, but with molasses. Wires are slow, components are hardly slower. Flash is slower still. Maybe also think of the machines being close relative to length of wires in CPU and mollases properties. - DB arch and similar. Well, if everything is molasses synchronizations is clearly hard. Rather than think about nifty hacks in isolation, think about what is the "business logic"'s actual expectations of synchronization. Remember financial settlement is the original example solution for this sort of thing, long predating computers.
treis 6y ago
IMHO, I just don't buy this. Every piece of technology has its own set of quirks, pitfalls, and shortcuts. You can jump around from Rails to Spring to iOS to whatever and be a decent individual contributor. But to be a real Senior/Lead engineer that can be responsible for a project you've gotta have the in depth knowledge.
- pcstl 6y ago
  Sure, but the time it takes to hit diminishing returns wrt different technologies seems greatly underrated to me. I've seen many engineers stick with a single technology so long that they were just memorizing standard libraries instead of actually learning anything.
- Ericson2314 6y ago
  - If you become senior manager of an existing project, learn from the rest of the team! - If you end senior manager of a new project, you probably shouldn't also be new at the company period, but at the very least, you start with something there is expertise somewhere on the team on. - New tech, new team, new org all at once: that's a terrible idea. The project shouldn't happen, or you shouldn't be the sole senior manager on it. All that said, if we have some team continuity across the industry, that should allow enough on boarding time for everyone to a be a non-pidgeonholed generalist. Just because there are derivative bounds doesn't mean we can't abandon change and pigeon-hole people in myopic specialist roles.

This is also the strategy I tend to take. Strong, broad fundamentals so I can quickly pick up specifics on the job.

by pcstl 6y ago

This is also the strategy I tend to take. Strong, broad fundamentals so I can quickly pick up specifics on the job.

This still restricts you from getting many of the jobs that require narrow specialization. Specializing on the fly only works to a certain extent and only if you get the opportunity to do so in the first place.

pcstl 6y ago
In my experience, "narrow" professionals tend to heavily overestimate what they bring to the table, which makes them not very hard to outcompete.
- username90 6y ago
  Switching technology is easy, switching domain is hard. You can't specialize in a technology, that is just nonsense, you specialize in a domain. Or several domains if they are simple enough. Like, the typical needs of a web product are simple enough that you master how to do the database, back end and front end. You wont be able to do the back end or database at Google scale, but you can master doing them at typical scale and I'd actually argue that Google scale is a different domain entirely with a different set of skills, you need a different specialist to handle that problem and he wont be able to efficiently solve your small scale needs either.
  - Ericson2314 6y ago
    I think one person can understand the backend at google scale. You shouldn't LARP solving problems you don't actually have (it's stupid to pay those costs, especially when the google state of the art isn't really that good) but you can still understand it. - Modern hardware realities (nearby network faster than disk they say, memory of all sort slow relative to CPU). My mental model is the good ol' hydrolic analogy, but with molasses. Wires are slow, components are hardly slower. Flash is slower still. Maybe also think of the machines being close relative to length of wires in CPU and mollases properties. - DB arch and similar. Well, if everything is molasses synchronizations is clearly hard. Rather than think about nifty hacks in isolation, think about what is the "business logic"'s actual expectations of synchronization. Remember financial settlement is the original example solution for this sort of thing, long predating computers.

treis 6y ago

IMHO, I just don't buy this. Every piece of technology has its own set of quirks, pitfalls, and shortcuts. You can jump around from Rails to Spring to iOS to whatever and be a decent individual contributor. But to be a real Senior/Lead engineer that can be responsible for a project you've gotta have the in depth knowledge.

pcstl 6y ago
Sure, but the time it takes to hit diminishing returns wrt different technologies seems greatly underrated to me. I've seen many engineers stick with a single technology so long that they were just memorizing standard libraries instead of actually learning anything.
Ericson2314 6y ago
- If you become senior manager of an existing project, learn from the rest of the team! - If you end senior manager of a new project, you probably shouldn't also be new at the company period, but at the very least, you start with something there is expertise somewhere on the team on. - New tech, new team, new org all at once: that's a terrible idea. The project shouldn't happen, or you shouldn't be the sole senior manager on it. All that said, if we have some team continuity across the industry, that should allow enough on boarding time for everyone to a be a non-pidgeonholed generalist. Just because there are derivative bounds doesn't mean we can't abandon change and pigeon-hole people in myopic specialist roles.