We are a spectrum of jobs, not just one
rachelbythebay.com
rachelbythebay.com
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/ 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.
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.
I think the OP has a fair point about one mode of development being substantially different than the other, but I don't think it's appropriate to partition them into separate roles. Part of engineering is knowing which path forward is most appropriate under uncertainty, given information about the team's skillset composition, available resources and time constraints.
A good software engineer is capable of holistically considering the options. If your third party library is considered like a paved road, this involves knowing when your vehicle can tolerate veering off the paved road, and knowing when you need to build a new road yourself.
Now maybe you read that and think I hadn't earned the kind of responsibility I was asking for. But 1) I had it at other companies previously, bigger companies than the last job 2) again, it was the type of responsibility they teased in the hiring process. I ended up leaving after a few months for a role at a company that actually offered me a leadership role with autonomy.
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.
Having worked at a FAANG-level company in systems contexts, I think that most people with similar experience would say Rachel is spot on.
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.
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.
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.
I also would venture this will further marginalize people in tech who are already marginalized. There’s enough hierarchy in programming already (and not particularly correlated with skill). IMO!
Also: the position (my summary) “People who disagree with my last blog post don’t REALLY know how to program and are covering up insecurity over their own incompetence” is an awfully convenient one to take. Maybe this is not as objective an assessment as it could be.
The performance review processes of FAANG-like companies tend to vastly favor building new things over any other type of code contribution. If you stay in those environments for long enough it's easy to internalize the ideology via those "best" practices in a way that feels like it was your own independent decisionmaking.
"What do you mean, throw off center? That's ridiculous! You throw the ball straight at their head if you want to hit them in the head. Everyone knows that."
Just a quick edit - if we were working at Google, of course we wouldn't use another vendor. Everything within google has a google solution. Rollbar, splitio, sendgrid, Google literally has an internal product for all of these things.
If someone’s narrative is all about the individual, it really doesn’t say anything flattering about them.
I generally like her work, and I’m more referring to the class of writing that generally invites comments like this.
Extraordinary claims require extraordinary evidence.
I'd venture that if you're going to say, "suggesting this marginalizes people," you should back it up with why you think that. It does no good for anyone to say something like that (and in doing so, heavily imply that the person making the statement is some kind of icky paraiah) and leave it at that.
Elitism would be saying "this group of people should be in charge because they know what they are doing; that group of people should not be in charge because they don't".
I think the author is in fact correctly recognising that different people enjoy a significantly different kind of software work from each other, and are unhappy with the other kind, and both kinds are valuable.
Recognising when there are different kinds of work and allowing people to choose for themselves which one suits them is not elitism.
Imagine if someone on a factory floor said "I've just realised that welding and painting are different kinds of work and most people greatly prefer one over the other. Perhaps we should label the jobs and let people gravitate to the kind they like so people aren't as unhappy."
Should we be up in arms and call that elitism? No, we should ensure both roles have equal status and recognition, but not hide the differences.
However, "VendorOps" does sound like a slightly derogatory word, so a better word might help.
> "I've just realised that welding and painting are different kinds of work and most people greatly prefer one over the other. Perhaps we should label the jobs and let people gravitate to the kind they like so people aren't as unhappy."
Except it's more like, "We hire people to design and assemble complex machines and some people make their own tools while others buy them. Anyway, the people who buy them are basically incompetent and when they claim to prefer focusing on producing the machines rather than tools for building them it's because they are scared of losing their jobs. Let's give them a new title, ideally that trivializes the work."
Anyway, if someone writes an article being a proponent for elitism they should have accomplishments to back it up. This person has done nothing and they don't deserve to be writing this kind of article. Maybe if this came from someone like John Carmack I would listen but I don't think he would be dumb enough to write this.
("$language developer" is only slightly more useful, especially for languages which are used across many different fields such as Python (web dev and science), C# (web dev and games), C (games and embedded), etc.)
The article revolves around the continuum from building everything yourself to importing a third party library whenever it can speed up delivering the current feature just a little bit. It's pretty clear by now that the many software development fields fall into different parts of that continuum.
I would argue that this is not a useful distinction at all. Any good developer should be able to pick up any language quickly. At the companies where I've worked, even the interns have no expectation of knowing the language before they're hired, and the vast majority of them learn quickly enough to ship useful code within their ~3 month internship.
I see this repeated very often without support, and I think it should be challenged. In my experience there are cases where it's true, and cases where it isn't.
Actual example: I have met highly competent software engineers who were (primarily) excellent Python programmers. They knew OOP well, they didn't typically over-abstract, but they could still leverage modular code for reusability, they tested early and often, they could dig into an existing codebase and maintain it, they could critically and constructively review others' code, they had a deep knowledge of the Python standard library and various domain-specific frameworks, etc. They were really good at all of this.
But by their own admission, they were crap at C++. They didn't really know memory management at all, and they didn't really get the whole "ethos" of C++. Moreover, they periodically tried (and failed) at picking up functional programming.
Now I believe if they were sufficiently motivated they could eventually pick these languages up. But they wouldn't "quickly" ramp up on a production codebase written in a C++ or Clojure. The idea that they're not a "good developer" because they wouldn't be able to quickly become productive in one of these radically different languages is therefore incongruous to me. I'm sure they could dive into a Ruby or JavaScript or even Java codebase. Or maybe C++ if it was strictly modern, 17+ and avoided raw pointers like the plague. But in general, no. It would take a lot of time, because some languages come with a lot of baggage that aren't just about the syntax. For someone who had always relied on Python's PIP, for example, the process of vendoring and importing C++ header libraries is already an obstacle.
The reason I'm going on about this is because it seems like received wisdom and is often stated as an accepted aside, but I really think it needs more nuance. Otherwise we run the risk of defining "good" software engineers by what is perhaps just a no true scotsman.
My CS education taught me those things (at least to a beginner level) in C. I suspect this would give me a major advantage at "C++" over someone who had never seen them. Even though we are both newbies to C++ itself.
Dependency management is a chore. Chores are different across language ecosystems, but it doesn't exactly stretch your mind to learn how they're done in different areas. Whereas minds really do catch on problems like pointers, locks, recursion, etc. and we can legitimately wonder whether someone is going to become okay at them anytime soon, or ever. I saw friends wash out of CS over these topics.
That seems normal and expected. Why would these people know memory management and c++ "ethos" if they've never worked with c++ in a professional capacity?
> Moreover, they periodically tried (and failed) at picking up functional programming.
Presumably the reason they didn't learn FP was because there wasn't sufficient motivation and assistance. I work at a company that does all FP and primarily hires people with no FP experience. We have a week-long FP training and tech leads spend a few hours per week with each new person helping them get ramped up. Of the hundreds of people we've hired in the past few years, I've never heard of anybody who failed to learn the language and our codebase style. There are plenty of reasons that certain people haven't worked out, but this is not one.
I think if you talk about the narrow scope of learning a language's syntax for greenfield projects, it might be true that people who know one language well can quickly learn any other language. But some languages force you to learn so much other "stuff" before you can be professionally productive in it, and I think there's some danger in just repeating that any good developer can pick up any language quickly.
My bottom line point: if I saw a developer who I knew to be very competent fail to quickly ramp up on a very different language in a professional setting, I probably wouldn't revise my assessment of them being "good."
I think this reinforces OP' point though: what we really need are descriptions more specific than "software developer" but less specific than "$language developer"
> some languages force you to learn so much other "stuff" before you can be professionally productive in it
And it's exactly that stuff that should be the focus of describing the role. e.g. you're looking for a low-level network software developer with proficiency in memory management. If you were recruiting someone to help you with a Go or Rust codebase in that domain, you wouldn't pass over someone with a ton of relevant experience via C++ who hadn't spent much time with Rust/Go yet.
Focusing on the language rather than the skills/application (even when there's a heavy correlation between the language and associated skills) excludes good candidates and includes irrelevant ones
For me, it would depend on what support systems are in place. If they're asked to learn on their own with no assistance, sure this failure doesn't mean much. But if they're put in a team full of experts on the new language who are eager to help them learn, and they still fail, then yes I'd update my opinion.
I could (re)learn Java in a weekend, but that doesn’t mean I’m going to be able to write an Android app.
Even for backend API development there is a leap from knowing C# to knowing how to correctly use all of the packages that surround it.
I'd be more worried about paradigm shifts like higher order functions, manual memory management, OOP, concurrency (also between "share by communicating" and "communicate by sharing"), glue code vs. algorithm code, monolith vs. microservices, embedded vs. server side.
So you would really hire me to be an Android developer who has only written 20 lines of production code in Java over 15 years ago and the only mobile development I’ve done is on ruggedized Windows CE devices almost a decade ago, over an experienced Android developer?
Let’s say I know AWS pretty well (which is the truth I work there as a consultant), and I do most of my AWS related scripting and development on top of AWS in Python. How useful would that combination of knowledge be if you told me to do the same type of thing on Azure or GCP? I wouldn’t even know where to start, I don’t know anything about either.
On the other hand, if you told me I had to build the same sort of solution in Rust, a language I’ve never even seen, I’m sure I could pick up the language in a weekend, include the appropriate SDK and be just as efficient as someone who has been working with Rust for years building the same type of solution on top of AWS.
I'm willing to accept that your mind works very differently from mine, but this is extremely surprising.
I take my concept-map of AWS, superimpose it on GCP, and start connecting the most similar nodes. I go looking for the VM service, the DB service, the load balancer service, the cache service, the firewall rules. I read the getting started guides for each, try to do with them the things I would do in AWS, check the reference manual when you I get stuck. Of course I may get burned if the corresponding services turn out to differ in important but subtle ways, particularly "folk wisdom" ways like quality and maturity. But I can definitely get started.
>So you would really hire me to be an Android developer who has only written 20 lines of production code in Java over 15 years ago and the only mobile development I’ve done is on ruggedized Windows CE devices almost a decade ago, over an experienced Android developer?
If I thought you were better at CS fundamentals and at least average at learning things, absolutely. Not to start an Android team - I'd want someone who has already learned the undocumented gotchas to be reviewing your code. But if I think you have the general muscle for learning software ecosystems, whether it's yet been applied to this exact one is a detail.
And then you would end up with a costly unoptimized solution that didn’t take advantage of what GCP had to offer just like the lift and shift “consultants” who first introduced me to AWS when I was a dev lead. They were a bunch of old school infrastructure guys who passed one multiple choice exam and thought they knew AWS (at the time unfortunately they knew more than I did).
They set up a few VMs and load balancers, and called themselves “moving us to the cloud” when in hindsight our product could have been much easier to maintain if they had any clue about how to leverage any of the native services that AWS had to offer.
(I’m talking way out of my league in the paragraph below).
If you didn’t have any GCP experience how would you know whether setting up VMs was the right answer or just use Google Cloud Functions? How would you know whether Firebase would meet their needs better? Would you know whether a certain pattern service met HIPAA compliance? Would you be sure that you set up your permissions securely? You went right to setting up VMs because that’s all you know about GCP. That’s all I know. Do you even know what you don’t know? Can you be sure that your decisions won’t cause a security breach? Cause the company to spend more money than necessary? Of course as I said before when it comes to GCP/Azure, I don’t know what any of the services do.
I’m sure someone who knows GCP/Azure could look at a problem and tell them a better solution than “set up a few VMs”. Just like I could with AWS.
Of course I may get burned if the corresponding services turn out to differ in important but subtle ways, particularly "folk wisdom" ways like quality and maturity. But I can definitely get started.
Knowing “where to get started” is not good enough when you have to worry about all sorts of compliance issues..,and your (theoretical you, I have no idea what you know or don’t know) solution would end up costing more just like every “lift and shift” solution with no optimizations seem to.
If I thought you were better at CS fundamentals and at least average at learning things, absolutely...
So instead of hiring an experienced Android developer - there are plenty - you’re going to trot someone in front of a whiteboard and have them reverse a binary tree?
When I was either responsible for hiring or could give the thumbs up or down in the real world at small companies where each IC was expected to hit the ground running, we weren’t going to spend six months letting them ramp up when we were growing fast and introducing new features (microservices) that could bring in revenue.
Of course you can do most all things in most all languages, but often times you can infer CRUD/web dev from PHP, for example, and would be far less likely to come across a PHP game developer.
I don't think that's true unless you've done a bad job at learning in your previous job. There are lots of thing you should be learning that aren't directly related to the domain of your code: how to debug existing codebases, how to read other people's code, how to do code review, general coding patterns, architecture principles, how to prioritize your work, how to work with other people, etc, etc, etc.
All of my jobs have been in very different domains, but the experience at each has made me much better at the next.
The situation described by the author is definitely a spectrum, however. I currently find myself in a position that is a bit far for my liking toward the "VendorOps" end of the spectrum, and I find the name given to this spectrum by the author to be immensely useful.
I've previously defined the spectrum to myself as a "build vs buy" spectrum.
My current job is not exactly "VendorOps" in the complete sense described in the article, but it is a bit far in that direction along the spectrum for my liking, I write and architect code projects, I write unit tests, build and deploy it all within CI/CD pipelines that I myself have built and designed.
But it's all in the service of gluing 3rd party software and vendor implementations together, and I do most of this work myself, with little interaction or overlap with the one other developer that is employed full-time at our company.
Much of my previous experience building what I would describe as "Building Proper Software Projects Together With A Team." And I miss that, and will seek that out in future roles. And having a proper (and publicly defined) name for this concept will be immensely useful.
The problem is that managing deployed environments is a completely different skill set and problem domain. Is it complementary? Sure. Useful to have? Yes. But it's ultimately orthogonal. I can still write great software without having to give a shit or know much about how our AWS environment is configured, much less do that work myself.
Being a programmer is a spectrum, yes, but it's multiple spectrums. Build vs configure is one. Product focus vs technology focus is another, one I happen to land much closer to the product side. Unfortunately, I think the pendulum is swinging the wrong way for me on that one, and it's soon going to signal the end of my programming career.
There was another vision of devops where it wasn't orthogonal: software engineers would write software to manage itself. Deployment, monitoring, resiliency, etc. would be woven into the application instead of being someone else's problem. Management would be done through APIs instead of config files and shells.
But containerization kind of cleaved the world between "making containers" and "running containers." Even if the same person does both, they don't look much like each other. Distributed systems problems are hard, and usually get outsourced to battle-tested commodity services (k8s, zookeeper, consul, etc) which need their own management. Knowing your own code inside and out doesn't really help you debug a loss of quorum; the consensus protocol is "over there." And the APIs turned out to be so complicated that we built config files and shells for them anyway (e.g. Terraform).
But, web dev seems to suck up all the air in the room, making you think that all jobs are that.
I focused into compilers, systems programming, and security. It took awhile to shift, find like-minded people, and know where to look for work. But now I see multiple avenues forward. Before, it looked like I had to leave tech because I couldn't stand web dev.
• "I work in DevOps managing a pipeline. I don't know how to program, but I was thinking of learning a language."
• "I write Python as a senior engineer and work closely with my company's devops systems. You write C? Wow, that's supposed to be really hardcore isn't it."
There clearly is more diversity in these lines of work than I would have guessed before attending.
There are some companies and teams that are looking for product focused devs that don't need to work on devops. If that's what you enjoy, look for that. I know finding another job isn't the most fun thing but it might be easier than giving up on your current profession entirely.
If the mgmt thing doesn't work out, (the opportunity I'm expecting doesn't open up, or I just find out it's not a good fit for me), then I'm not sure what I'll do.
In my job, high level thinking is that you look at a diagram with at most 10 different concepts that you already vaguely know, and on a high level that is good enough.
For example (I'm making this up):
- You have a client sending a request
- Which has a server receiving it that relays the request to the specific service
- But before that happens it is sent to the auth service and the auth service responds back to the server that the user is logged in
- The server then relays it to the specific service that the request needed to go to
- That particular service needs some info from yet a different service
- That different service sends it to the service
- The service sends everything back to the service
- The server does some final serialization (e.g. no silly fields should leak to the client) and sends it to the client
This is the most elaborate example I could think of, most of the time it's a lot easier, but I also find this type of thinking easy.
He responded with: oh that's not what I meant with high level thinking. In our case we need to know specifically: what protocols are being used (is it TCP or UDP, why?), how do services make each other known (e.g. broadcasting?), what component lives where in the world? And so on.
It turns out that my thinking was too high level and relatively useless in the field that he works in (he doesn't have anything to do with web dev and does something more low level, more performance related and more network related).
So that was quite an experience for the both of us that we meant something different with "high level" and that statements such as "I find xyz easy" can come across as very arrogant to the other person because to them you're kind of saying something impossible.
Every job has a different combination of tasks that make sense to be externalized and those that don't. Even the most NIH people will draw a line somewhere and don't do everything from scratch. And the combination changes for the same job over time as the product/project/company evolves.
Trying to capture the exact breadth of a given job in the title alone is in my opinion bound to just lead to endless bikeshedding.
But I'm wondering, if, long term, it ceases to be a spectrum and becomes clearly distinguishable areas of people writing the infrastructure, libraries, frameworks etc. and those that combine them to the final product.
Yeah the title of the article is "spectrum" but the contents are about a dichotomy.
Yes, you can tell what I think about this article (and the one before it).
If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. I don't see the author of this article writing their own OS from scratch, so why stop there? Why should all the auxiliary libs and frameworks be created from scratch? Because they don't like all the communities around the existing ones?[0] If everyone around you is the problem...maybe its you who is the problem. I've never had any pull requests with fixes or minor features rejected from upstream, so my view may be biased.
I prefer hiring and working with people who understand the value of contributing to OSS instead of building their own little castles.
Part of "holistic view on software" is recognizing how much garbage and reinventing the wheel there is out thee. Part of being an engineer is recognizing trade-offs: dependencies come with costs of their own, so it only makes sense to use them if you expect to get more from them than you're going to pay for them. And pay you will - dependencies have to be understood, managed, upgraded and deployed.
Rachel writes from the POV of reliability engineering; in her story, her problem is as much with a shitty dependency being used as with in-house people who consider vetting their dependencies and collaborating with dependency vendors to be outside their job description. But both are, in fact, a part of good engineering, and are a part of the price you should be paying when you link against a third-party library.
I agree about hiring and working with people ("engineers") who take full advantage of existing tools and libraries; and can contribute to well-documented and battle-tested libraries in the community.
But, as someone who (also) fits the description of a "programmer", I see the value in building our own little castles for fun and profit, to create libraries and frameworks for our own purposes. If existing solutions don't quite do the job, someone has to start these well-documented and battle-tested libraries to benefit the community - even if "only they can understand" it at the beginning.
Perhaps the contrast and tension between these approaches are about the inherent risk of innovation. In a team environment, we don't want people inventing their own language or operating system from scratch - unless it directly contributes to the core business, which is rarely the case.
For the largest tech companies, they can afford to risk the investment into innovation, to develop and maintain their own languages, frameworks, and libraries - if they bring competitive advantages. This caveat is often unclear though, whether this (re)invented thing actually delivers.
Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context.
I'd love to see an article from the author drawing from their experience on making that kind of decisions.
Yeah, I totally hear you. God knows I've built not only "castles" but immense, complicated and unsustainable architectures (or balls of spaghetti); deadend frameworks that started deprecating the moment I wrote it; under-documented or -tested (or not at all!) libraries with unclear interfaces..
As much I love creating things from scratch, experience has taught me to be cautious and conservative when deciding to do so - especially in a company/team environment. It's almost always better to research first, study what exists in the ecosystem/community, and use available tools and building blocks.
Many articles get posted on HN that describe how and why a company decided to build their own database, operating system, language, framework, or library.
It's not as exciting to read or write about using "boring technology" to build stable, reliable systems with a decade-old, tried-and-tested framework. But this latter is, and should be, the standard approach: mostly "engineering", with just enough "programming" to glue and orchestrate it all together.
As long as the priorities of your product align with the priorities of the library. If the product you're trying to ship is a critical control system and the only relevant libraries are written with a webdev approach of "move fast and occasionally crash" you might be done much quicker if you write your own version.
It's certainly not that clear cut because most of the largest tech companies primarily ship products but also have invented their own programming languages.
Otherwise if you want to write everything from scratch, you can always write embedded firmware for 8-bit MCUs. It better be in assembly, because otherwise you're just doing "vendor-ops" with a external IDE and some company's compiler. Although technically, you're doing "vendor-ops" for a chip made by someone else, so maybe you should make your own soft core in VHDL and use an FPGA... At some point either you'll be making your own transistors because that's the only way to be a Real Engineer, or you'll accept that there's no problem depending on external vendors as long as you understand how to use the tools you have.
We discovered in the course of his time on the project that he was physically incapable of maintaining other people's code (which he knew, going in, that he'd be required to do).
So he constantly argued that code that existed was fundamentally broken, and needed to be rewritten.
He wasn't on the web team, which I ran, but he often gave me crap about using Rails when I could just "write it all myself and it would be so much simpler". I did a class for the group describing Rails, and what it gives you, and why you'd use it.
His response? "You're not programming, you're just configuring it!". Sigh.
We don't talk about this enough because it feels taboo to even imply that this overly "communal" form of development isn't cutting it for some. We're so hyper-focused on vague values of community and accessibility when career development is intensely personal.
I said no to webdev in 2012. And it has paid off significantly for me.
I wonder if this distinction is going to be even more helpful as the low-code/no-code trend takes off and more jobs can be done by those with fewer skills.
IMO the correct thing is to hire people who are good at both and know when to use which approach. Otherwise the learn startups will never be able to transition to established companies. And likewise, the established companies have many problems to solve that don't require home-grown tools, so you don't want people who only know how to start everything from scratch.
(Clearly this is one perspective. It would be great to hire the best engineers from day one but sometimes that’s not practical.)
So it is OK to use libraries, but use well regarded ones that have large, established communities. And don't use libraries for simple small things that your team can do themselves.
Her point about depending on others to get your company's work done is a valid one and should be minimized as much as possible. This is why I prefer open source, standard languages and why governments still use C and C++. They are ISO standards that will be around and stable for decades.
In my experience, the trend of software development over time is division of labor into specializations for hard engineering problems, while creating paved roads and happy paths for good generalists. I use the term "generalist" charitably here, whereas the author's description feels (to me) to be a little disparaging.
To your point, I think it's good we have this trend in software development. Having all these libraries is a net good which saves time and results in fewer footguns. I believe the problem she is describing is more productively considered by looking at it as a problem of using a vendored library in a way that it isn't designed to be used (i.e. "driving off the paved road"). There are often good reasons to drive off the paved road, but you need to really understand your problem and the solution space to pull it off competently. I think the author's experience is therefore caused by two things:
1. Businesses which are not at Google and Facebook scale, and thus can't afford to build much in-house from scratch.
2. People who try to duct tape APIs together without a strong understanding of the underlying limitations of each library, and the design boundaries of each.
All of that said, you're obviously correct that some people just paste together unstable things they have put forth zero effort to evaluate, and that's a problem.
Microsoft by themself have at least 8 types of strings for their various libraries...
https://docs.microsoft.com/en-us/cpp/text/how-to-convert-bet...
The string library in C++ is literally one of its worst libraries. Neither LLVM nor Clang use it.
We got rid of most of the DBAs, Architects, and QA. Any of those would be better than having someone whose only job is wrangling third party code.
Really a bummer; this is the rare case of a social issue that does have a technical solution!
* Analyze dependency updates for breaking and performance impacts
* Coordinate the cleanup of deprecated API use
* Feedback to upstream
* Resolving integration issues (usually by delegation and controlling)
This guy does not write significant amounts of code but will still create lots of commits.
This post further asserts that folks who like the fact that libraries are easily available are "not very good at something being discussed" and have "Peter Principled" themselves. It also states that they are, "almost rational."
What you're describing is an under-performer, or perhaps someone who is working specifically in a maintenance capacity (likely with a title that reflects that!). I don't think that is what the original post is talking about, but perhaps I have misread.