7 ms·

It helps to read her previous post on the topic to understand her point. She complained about being accused of focusing too much on problems of scale as an ex-G

It helps to read her previous post on the topic to understand her point. She complained about being accused of focusing too much on problems of scale as an ex-Google/FB engineer. And she suggests her colleagues don’t have the engineering chops or desire to dig deeply into a problem the way she does. I don’t think the author understands her colleagues motivations. It may be the case that some of them are “vendorops” coders but I suspect it’s far more likely that at a company with resources like FB or Google, which is to say near infinite resources, you can dig into such problems regularly. At a smaller company such technical deep dives may be intellectually gratifying for the coder but may not be worth the limited resources of the people who pay you. And you literally need to grab some off the shelf libraries and code on the company’s domain problem to save time & money.

throwaway936482 6y ago
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.
stitched2gethr 6y ago
If I may provide what I believe is a different interpretation of what she is saying. Yes, sometimes there are really solid libraries that solve the problem you are facing well, but often engineers will reach for a Swiss army knife when all they need is a screwdriver. It has a screw driver on it, but because there is so much else there (trying to be all things for all people) the screwdriver isn't even that good. Moreover, solving a problem quickly is not the same as solving a problem forever, and we are responsible for every instruction we import, at some level. If the problem is small (see left-pad, etc.) the smaller total cost of ownership is often to write the specific implementation you need, if you are capable.
- blub 6y ago
  The screwdrivers on a Swiss army knife are of good quality, but you can only have so many sizes available and because of the way they're attached they are cumbersome to use in certain situations. Multi-tools like Victorinox Spirit come with a ratchet and bits. Leathermans also have bits, but they typically attach directly to the tool and therefore suffer from the same limitation regarding ease of use.
smoe 6y ago
Besides resources, for companies that do not operate at an planetary scale like Google, Facebook et al., I'd argue we have reached a point where a lot of the common problems have been thoroughly solved in multiple ways for a while now and you can pick one. So it is not just to save time & money. Outside the core business and if the evaluation of third party products has been done decently well (which I think is more often the actual problem) there is often basically zero need or benefit to come up with something custom.
juped 6y ago
I find the idea that "engineering" is really about BIG SCALING really tiresome. Sure, careless throwing together of random libraries, packages, and stack overflow snippets goes against sound engineering principles, but so does nearly everything Google does (I would say "everything" but they do employ careful engineer Junio Hamano, though I'm pretty sure he gets to set his own culture himself).
- mattgreenrocks 6y ago
  This is a byproduct of the engineering culture being co-opted by the cult of agile. For some domains, the 80% solution is perfectly fine to launch with. For others, it is quite sloppy and you end up with paper cuts in normal use. Problems arise when you, as a consumer of a library, expect a 100% solution and discover it's only an 80% solution. Worse, most libraries do _not_ tell you what design decisions were made.
- ThrowawayR2 6y ago
  She already addressed what you said in her previous post. The original issue wasn't about "BIG SCALING" but just being designed and implemented safely and sensibly; the library used failed at smaller scales too, just with less frequency. Having worked at a FAANG-level company in systems contexts, I think that most people with similar experience would say Rachel is spot on.
aahortwwy 6y ago
This author consistently omits important context from their posts. When this is pointed out there is always a rebuttal (however unconvincing), never a change of perspective. When new insight is gained, it always confirms or elucidates an opinion that the author already held (as in this post). Introspection and reflection seem absent from this blog. Maybe that's intentional, I don't know. Resources are one obvious constraint. The stage a company is at in its lifecycle is another. There was a time when Google had security issues so egregious that if you bring them up to current employees you will be accused of lying. Company growth rate is a constraint. Why solve a problem perfectly now if you know you'll have to solve it again in a year when the company outgrows the current solution? Employee workload and performance assessment is another constraint. Employees will only give the company so much time, and if the company doesn't allocate enough of that time towards keeping the house in order then the house will not be kept in order. Cultural stigma is another constraint. Sometimes people are not willing to say why they are doing (or not doing) something in a certain way. If you file an internal bug, come away dissatisfied with the fix, and conclude that the fixer is some lesser-than-engineer who is lazy and doesn't care about doing things the right way you might be ignoring any of the above constraints or many more. Or they could be bad at their job. There are plenty of people like that in this industry, too.

throwaway936482 6y ago

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.

stitched2gethr 6y ago

If I may provide what I believe is a different interpretation of what she is saying. Yes, sometimes there are really solid libraries that solve the problem you are facing well, but often engineers will reach for a Swiss army knife when all they need is a screwdriver. It has a screw driver on it, but because there is so much else there (trying to be all things for all people) the screwdriver isn't even that good. Moreover, solving a problem quickly is not the same as solving a problem forever, and we are responsible for every instruction we import, at some level. If the problem is small (see left-pad, etc.) the smaller total cost of ownership is often to write the specific implementation you need, if you are capable.

blub 6y ago
The screwdrivers on a Swiss army knife are of good quality, but you can only have so many sizes available and because of the way they're attached they are cumbersome to use in certain situations. Multi-tools like Victorinox Spirit come with a ratchet and bits. Leathermans also have bits, but they typically attach directly to the tool and therefore suffer from the same limitation regarding ease of use.

smoe 6y ago

Besides resources, for companies that do not operate at an planetary scale like Google, Facebook et al., I'd argue we have reached a point where a lot of the common problems have been thoroughly solved in multiple ways for a while now and you can pick one. So it is not just to save time & money. Outside the core business and if the evaluation of third party products has been done decently well (which I think is more often the actual problem) there is often basically zero need or benefit to come up with something custom.

juped 6y ago

I find the idea that "engineering" is really about BIG SCALING really tiresome. Sure, careless throwing together of random libraries, packages, and stack overflow snippets goes against sound engineering principles, but so does nearly everything Google does (I would say "everything" but they do employ careful engineer Junio Hamano, though I'm pretty sure he gets to set his own culture himself).

mattgreenrocks 6y ago
This is a byproduct of the engineering culture being co-opted by the cult of agile. For some domains, the 80% solution is perfectly fine to launch with. For others, it is quite sloppy and you end up with paper cuts in normal use. Problems arise when you, as a consumer of a library, expect a 100% solution and discover it's only an 80% solution. Worse, most libraries do _not_ tell you what design decisions were made.
ThrowawayR2 6y ago
She already addressed what you said in her previous post. The original issue wasn't about "BIG SCALING" but just being designed and implemented safely and sensibly; the library used failed at smaller scales too, just with less frequency. Having worked at a FAANG-level company in systems contexts, I think that most people with similar experience would say Rachel is spot on.

aahortwwy 6y ago

This author consistently omits important context from their posts. When this is pointed out there is always a rebuttal (however unconvincing), never a change of perspective. When new insight is gained, it always confirms or elucidates an opinion that the author already held (as in this post). Introspection and reflection seem absent from this blog. Maybe that's intentional, I don't know. Resources are one obvious constraint. The stage a company is at in its lifecycle is another. There was a time when Google had security issues so egregious that if you bring them up to current employees you will be accused of lying. Company growth rate is a constraint. Why solve a problem perfectly now if you know you'll have to solve it again in a year when the company outgrows the current solution? Employee workload and performance assessment is another constraint. Employees will only give the company so much time, and if the company doesn't allocate enough of that time towards keeping the house in order then the house will not be kept in order. Cultural stigma is another constraint. Sometimes people are not willing to say why they are doing (or not doing) something in a certain way. If you file an internal bug, come away dissatisfied with the fix, and conclude that the fixer is some lesser-than-engineer who is lazy and doesn't care about doing things the right way you might be ignoring any of the above constraints or many more. Or they could be bad at their job. There are plenty of people like that in this industry, too.