4 ms·

This. She is used to working in a none (to a first approximation) resource constrained environment, in terms of time, money and probably most importantly domain

This. She is used to working in a none (to a first approximation) resource constrained environment, in terms of time, money and probably most importantly domain experts that she can draw on to create from scratch the bits that she can't. That is not the case outside of planet faang.

vii 6y ago
From the outside, big organisations have massive resources and access to experts. But inside there is intense competition for those resources and people. The people are expensive and there are many opportunities so you need to justify spending their time, especially in the FAANG impact ecosystems. Despite this pressure people may misallocate their time and it can look weird if you don't hear the justifications but they are really trying hard to spend time on the right things, and they do feel constrained - there are so many rapidly growing areas that need investment, there's actually always a shortage if you think about what could be done. Using a library versus building internally is a tough trade-off and can have long term consequences. I think everybody is comfortable with the downsides of building. But we sometimes forget the costs of dependencies. My framework is that introducing a new concept whether written internally or through a dependency has a cost. Each class hierarchy, external tool, build system, etc. has a cost and we must weigh this cost against the benefits. Dependency sprawl is expensive especially in languages like Python or JS where libraries break backward compatibility on a frequent basis. I like that Rachel is bringing up the longterm cost of dependencies, they can often be more expensive than just writing a simple function or HTTP call without supporting libraries. Building may be cheaper. Some people just hate managing systems they can't fix. Other people enjoy the challenge of reverse engineering complex systems and squeezing the best out of them. It is only reasonable to ask for the job expectations to be explained upfront. Rachel's post about onboarding https://rachelbythebay.com/w/2020/05/22/boarded/ https://rachelbythebay.com/w/2020/05/22/boarded/ goes into this idea in more depth. There's so many differences even in Silicon Valley. Companies should share more honestly what the day to day will be and their appetite for building. This would restrict recruiting funnels upfront but make people happier. The problem is that inside a company there are many perspectives. The representatives of the build faction may achieve a temporary ascendancy and will obviously try to hire then and paint a rosy picture, but then the buy faction will see the hires and become highly incentivised to point out the lack of immediate results and trammel scope, causing the conflict Rachel is writing about.
- throwaway936482 6y ago
  Yeah, I think that part of what makes a good engineer / good employee generally is the ability to recognise and work within the constraints of the organisation / team without spending all your time whingeing or proselytizing for the One True Way of doing x. This is quite difficult as developers as a breed have a tendency towards binary thinking and engaging in doctrinal disputes. I actually agree that dependency sprawl / hell is a problem best avoided... which is why I avoid web development like the plague. I think Rachel's broader point that the terms we use to describe developers / software engineers are very broad and sometimes unhelpful is right. I think she's being a snob in wanting to retain the high status term for what she does, while dismissing the stuff that she obviously struggles with as being not engineering, but I do think we shall take care to distinguish between high level engineering that largely consists of integrating existing libraries / modules etc. and lower level engineering that she engages in because they are different skills.
  - ritchiea 6y ago
    Some of us even have jobs that are a mix of high and low level engineering and we have to have the good judgement to choose when to do one or the other.
    - throwaway936482 6y ago
      Now that is a valuable skill.
      - ritchiea 6y ago
        It depends? Certainly for some companies but I wouldn't be the right fit if you need a highly specialized infrastructure person at Netflix or AWS or something. Sometimes it can feel like I'm only a good fit at startups which isn't great for earnings potential.
      - jlokier 6y ago
        I think it's valuable in the sense that it creates value. It gets things built that work well, and fit into the bigger picture needed by the company. It might even be one of the essential skills in building a successful tech company. But I don't think it's valued much on the open market. As in, it's hard to be recognised for that kind of skill. Established, larger companies tend to have a structure in place and, at least on the open market, try to fit people into narrower roles. Even if there's a laundry list "tech stack", it's usually a narrow role. As ritchiea said, it can seem as if the only place where the range is a good fit is at early-stage startups, with plenty to do and good judgement needed, but limited earnings on offer.

vii 6y ago

From the outside, big organisations have massive resources and access to experts. But inside there is intense competition for those resources and people. The people are expensive and there are many opportunities so you need to justify spending their time, especially in the FAANG impact ecosystems. Despite this pressure people may misallocate their time and it can look weird if you don't hear the justifications but they are really trying hard to spend time on the right things, and they do feel constrained - there are so many rapidly growing areas that need investment, there's actually always a shortage if you think about what could be done. Using a library versus building internally is a tough trade-off and can have long term consequences. I think everybody is comfortable with the downsides of building. But we sometimes forget the costs of dependencies. My framework is that introducing a new concept whether written internally or through a dependency has a cost. Each class hierarchy, external tool, build system, etc. has a cost and we must weigh this cost against the benefits. Dependency sprawl is expensive especially in languages like Python or JS where libraries break backward compatibility on a frequent basis. I like that Rachel is bringing up the longterm cost of dependencies, they can often be more expensive than just writing a simple function or HTTP call without supporting libraries. Building may be cheaper. Some people just hate managing systems they can't fix. Other people enjoy the challenge of reverse engineering complex systems and squeezing the best out of them. It is only reasonable to ask for the job expectations to be explained upfront. Rachel's post about onboarding https://rachelbythebay.com/w/2020/05/22/boarded/ https://rachelbythebay.com/w/2020/05/22/boarded/ goes into this idea in more depth. There's so many differences even in Silicon Valley. Companies should share more honestly what the day to day will be and their appetite for building. This would restrict recruiting funnels upfront but make people happier. The problem is that inside a company there are many perspectives. The representatives of the build faction may achieve a temporary ascendancy and will obviously try to hire then and paint a rosy picture, but then the buy faction will see the hires and become highly incentivised to point out the lack of immediate results and trammel scope, causing the conflict Rachel is writing about.

throwaway936482 6y ago
Yeah, I think that part of what makes a good engineer / good employee generally is the ability to recognise and work within the constraints of the organisation / team without spending all your time whingeing or proselytizing for the One True Way of doing x. This is quite difficult as developers as a breed have a tendency towards binary thinking and engaging in doctrinal disputes. I actually agree that dependency sprawl / hell is a problem best avoided... which is why I avoid web development like the plague. I think Rachel's broader point that the terms we use to describe developers / software engineers are very broad and sometimes unhelpful is right. I think she's being a snob in wanting to retain the high status term for what she does, while dismissing the stuff that she obviously struggles with as being not engineering, but I do think we shall take care to distinguish between high level engineering that largely consists of integrating existing libraries / modules etc. and lower level engineering that she engages in because they are different skills.
- ritchiea 6y ago
  Some of us even have jobs that are a mix of high and low level engineering and we have to have the good judgement to choose when to do one or the other.
  - throwaway936482 6y ago
    Now that is a valuable skill.
    - ritchiea 6y ago
      It depends? Certainly for some companies but I wouldn't be the right fit if you need a highly specialized infrastructure person at Netflix or AWS or something. Sometimes it can feel like I'm only a good fit at startups which isn't great for earnings potential.
    - jlokier 6y ago
      I think it's valuable in the sense that it creates value. It gets things built that work well, and fit into the bigger picture needed by the company. It might even be one of the essential skills in building a successful tech company. But I don't think it's valued much on the open market. As in, it's hard to be recognised for that kind of skill. Established, larger companies tend to have a structure in place and, at least on the open market, try to fit people into narrower roles. Even if there's a laundry list "tech stack", it's usually a narrow role. As ritchiea said, it can seem as if the only place where the range is a good fit is at early-stage startups, with plenty to do and good judgement needed, but limited earnings on offer.