
We are a spectrum of jobs, not just one - zdw
http://rachelbythebay.com/w/2020/08/14/jobs/
======
ritchiea
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.

~~~
juped
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
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.

------
mapgrep
Ghetto-izing code reuse in programming as “VendorOps” and associating it with
the Peter Principle seems like a great way to discourage code reuse and reward
people who would rather rewrite code unnecessarily than read someone else’s
existing code (notoriously hard). Do you really want to make it a badge of
honor to reinvent the wheel?

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.

~~~
hoorayimhelping
> _I also would venture this will further marginalize people in tech who are
> already marginalized._

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.

~~~
ritchiea
It’s clear the author of the original post is taking an elitist stance on what
it means to work as a coder and trying to brand the work of others as less
important & give it a different job title. Essentially saying “a real
programmer does the job in this specific way I say a real programmer does.”
It’s not the kind of attitude that benefits anyone. It’s the kind of attitude
that does push people out in an industry already with a reputation for pushing
people out.

~~~
joejerryronnie
The irony is that I’m sure the author experienced elitism and discrimination
when she started her career in software development and now doesn’t realize
she is propagating the same.

~~~
ritchiea
Yea exactly, she seems to have reached a level of comfort with her technical
proficiency and years of experience that she's not even seeing how this kind
of talk can be discouraging to a junior who doesn't have the depth of
knowledge she has.

------
l0b0
My takeaway was that "software developer" is not a very useful job description
anymore. CRUD, web dev, games, HPC, embedded and other fields require vastly
different skill sets. Changing between these fields can be like starting your
first job out of college, learning to use not just different tools but also
focusing on very different priorities.

(" _$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.

~~~
rtlfe
> "$language developer" is only slightly more useful

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.

~~~
fractionalhare
_> Any good developer should be able to pick up any language quickly._

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.

~~~
mkoubaa
I think you'll find many professional C++ developers say they are crap at C++.
It isn't a reflection of their abilities

~~~
blub
Maybe they say that they don't master the language. If they're crap at it
they'd either get a different job or eventually get fired.

~~~
mkoubaa
Effectiveness at using a language =\= effectiveness at implementing useful
things in it

------
arwhatever
The title says "spectrum," but a lazy read of the content could suggest that
it is a dichotomy that is being described.

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.

~~~
tonyedgecombe
The problem is having a proper and publicly defined name for the concept could
piegon hole you. It might make it harder to escape in this world of hyper-
specialism.

------
LargeWu
One of the primary reasons I'm trying to move on from being a software
engineer is the expectation that I'm supposed to be fluent in dev-ops type
work as well. That domain, for me, is something I have absolutely no interest
in, and not much of an aptitude for.

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.

~~~
non-entity
What are you moving towards, if I might ask?

~~~
LargeWu
I just took a job that should put me on a management track, but I had been
fishing for product jobs as well. I think one way or another this will be my
last programming job.

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.

------
mettamage
I once told a friend of mine that I find "high level thinking" easy. He
scoffed at me asking: "how is that easy?"

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.

~~~
mkr-hn
It seems like a lot of disagreements stem from assuming shared definitions.

~~~
mettamage
That statement cuts so deep. In my experience, this is true for all
communication. I've experienced multiple times that I'm not speaking the same
Dutch (native) or English (second language) as the other person and it's
always quite an upsetting realization.

------
smoe
If it is a spectrum, why keep insisting to put arbitrary labels on parts of
it.

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.

~~~
rtlfe
> If it is a spectrum, why keep insisting to put arbitrary labels on parts of
> it.

Yeah the title of the article is "spectrum" but the contents are about a
dichotomy.

~~~
the8472
A spectrum can have sharp peaks.

------
huckleb3rry
I never comment on Hacker News posts but I found this blog post to be so
insightful that I had to give my two cents. VenderOps really is a different
job and as a "senior" dev in my career I can say that it is a job that I would
happily take at this point. I work for a small startup and there is no end to
the AWS, Docker and K8s shenanigans we are called on to do day in and day out.
The problem is no one wants to volunteer to do this kind of work so the CTO
(the most experienced engineer on our team) ends up doing most of it himself.
There are paid consultants who will gladly come in and Terraform all your shit
but we don't hire them. While some of us may not consider that "real
engineering" these professionals are essential to the success of your startup.
Once they put the pieces in place then your devs can run with a fully
automated CI/CD pipeline and deliver the features your customers want. Then as
adoption starts to take off you get into observability, Prometheus, Grafana
and the five nines. This is the point when the agile rock stars start to burn
out or bail and the need to bring in experienced SREs becomes inescapable.
This is the VenderOps state and it is the pit of success you want your startup
to be in even if you yourself have no interest in partaking in it. There will
always be a place for brilliant people who need to work and the hardest
problems but let's face it a lot of us are not that. I know I am not. A lot of
us are journeymen and women who just want put their kids through college and
hopefully retire comfortably.

------
npstr
I don't quite understand why we need to invent an new word for it? There are
people who program and optimize all day and write clever one-liners and create
libraries and frameworks only they understand (programmers), and people who
collaborate & have a holistic view on software development, and as a result
actually get stuff done in a solid way (engineers).

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.

[0]
[http://rachelbythebay.com/w/2018/10/09/moat/](http://rachelbythebay.com/w/2018/10/09/moat/)

~~~
lioeters
Couldn't one argue that most open-source projects are born as someone's "own
little castle"? If people didn't build their own little castles, we wouldn't
have, for example, UNIX.

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.

~~~
npstr
Absolutely. Doing the right calls here is very hard, and takes a lot of
experience. Btw - I'm not against building your own castles (I love doing
that, esp. in my free time) - I am just a bit triggered by the previous blog
post arguing unconditionally for it, and now the next one even saying these
are two (or even more) different professions. I don't think that is the case.
I think we need to understand the contexts, to know when each of the
approaches is a likely better fit. Sometimes its very clear, and sometimes you
won't know until much later. That's ok. I think it is important to document
why a route was chosen, and evaluate if it is still the correct one, once more
facts are available, or the environment changes. What I really don't like
seeing is ranting about a chosen approach, without informing oneself first
about how the decision was reached, and broad generalisations.

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.

~~~
lioeters
> I'm not against building your own castles (I love doing that, esp. in my
> free time) - I am just a bit triggered by the previous blog post arguing
> unconditionally for it..

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.

------
chrisrhoden
I guess I am stuck trying to understand if the assertion being made here is
that folks who use a library to connect to PostgreSQL are not really writing
software, but maintaining vendor garbage.

~~~
chris_st
Worked with a guy who made pretty much exactly that assertion.

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.

------
mattgreenrocks
I'd argue when a developer moves toward the mid-career mark, some will
discover that they no longer want to be gluing code together all the time at
their job. That is expected and healthy for some. They're not better devs like
the article implies. They just need something different.

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.

------
benjaminjosephw
This is a really helpful distinction. I have worked across a few different
jobs with differing expectations across this spectrum. The really lean
startups want to get places quickly and blending together a dependency soup is
usually the most efficient way to get there. More established companies
sometimes have the resources to allow more R&D and home-grown libraries and
tools. They are really different jobs in a lot of ways but we haven't done a
lot to distinguish them in how jobs are presented.

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.

~~~
rtlfe
> The really lean startups want to get places quickly and blending together a
> dependency soup is usually the most efficient way to get there. More
> established companies sometimes have the resources to allow more R&D and
> home-grown libraries and tools. They are really different jobs in a lot of
> ways but we haven't done a lot to distinguish them in how jobs are
> presented.

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.

~~~
derwiki
Maybe seed round/earlier you can’t hire those folks? In my experience, the
engineer who liked being on an early team does not enjoy being part of a 100+
eng org. So dependency soup engineers churn and you end up with a different
type of engineer when they transition to a real company.

(Clearly this is one perspective. It would be great to hire the best engineers
from day one but sometimes that’s not practical.)

------
_wldu
I agree with her that lots of libraries on the internet are bad. But expecting
companies to write their own is worse. I remember years ago that everyone
wrote their own C string libraries. There were hundreds of them. Most were
bad. Then C++ matured and provided a pretty good (and safe) standard string
class. Having that standard library was way better than everyone writing their
own (mostly bad) string solutions.

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.

~~~
fractionalhare
I think what it comes down to is the way these libraries are used.

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.

~~~
ilonski
As one of the generalists, I'd like to add to this comment. I see two kinds of
problems: open and closed. Closed problems are sort of "traditional"
engineering problems. They're math heavy, they have a precise, indisputably
correct answer, and they probably require some kind of algorithm to solve.
These are very challenging and interesting problems to dive into, and I
certainly have some interest in them, but they are not my primary interest. I
like to use software to solve business problems, which sometimes involve a
closed element but more typically are open. They involve human beings and have
fuzzy definitions of correctness. I like understanding my users and the weird
little worlds they inhabit and how I can make their day a little better. To do
that, I need the sorts of tools that the closed problem engineers provide. Now
you can absolutely be a great open AND closed problem engineer. I'm studying
some more math and algorithms to try to improve at that. I'm also willing to
dive in and debug some complex messy library code when I need to, and I do
agree it's my job to evaluate the maturity and reliability of a library before
I add it as a dependency. All that said, I take issue with the notion that I'm
not a good engineer if I choose to outsource some of my problems—especially
these closed problems that require a lot of work and experience and attention.
Software is not special. In business, every decision involves tradeoffs and
opportunity costs. It's completely unhelpful to take potshots at engineers
making a conscious choice not to tackle some problem when they can have it
solved by someone else.

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.

------
tlarkworthy
Having worked in a FAANG and in consulting for normal companies. Yes, vender
ops is the mainstream model that bings most value for normal companies.
However, it's a bit disenginous as even in FAANG stuff was mostly built from
infra Lego sourced from someone else's engineering. So there was a quite a
high amount of internal vendor's too, but the quality was much less hit and
miss. But it's really only a path the FAANG can walk, being absurdly
expensive. I am comfortable in both worlds, deep engineering is fun, but
sharing the powers broadly has more positive impact overall I think.

------
dasil003
So instead of engineers making informed decisions on buy-vs-build taking into
account uniqueness of requirements, maturity and stability of the ecosystem,
and resourcing constraints, we should say one group doesn't know how to do the
latter and should stay in their lane and only take jobs where they are
guaranteed not to have to build anything?

------
CincinnatiMan
Further specialization reduces job mobility and I believe is one of many
factors in wage stagnation.

------
hinkley
A role encompasses a set of responsibilities. When we try to make the
responsibilities too narrow it creates lots of space for myopia. Narrower
still, and the person starts to guard it jealously, because it’s all they
have.

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.

------
Ericson2314
As a Nix user, it's depressing to see that the rest of the industry due to
terrible package managers has fallen into terrible trade offs between "not
writing the same thing again and again" and "understanding what the hell is
going on and not being an alienated pretender".

Really a bummer; this is the rare case of a social issue that _does_ have a
technical solution!

------
scoot_718
Didn't even bother to describe the two different jobs. What a waste of time
this article was.

------
brian_herman
Now all we need is an acronym to describe the jobs we have.

~~~
gmfawcett
Maybe it's time to revive and refresh the Geek Code:

[https://en.wikipedia.org/wiki/Geek_Code](https://en.wikipedia.org/wiki/Geek_Code)

------
walterbell
Software Supply Chain engineer?

~~~
scsilver
Technical Accountant

------
notadev
So DevOps then?

~~~
qznc
It is about replacing the "Dev" part with "buying/downloading" thus VendorOps.

~~~
chrisrhoden
Pretty wild assertion that using rust crates eliminates development.

~~~
qznc
I can imagine a big Rust project where there is person who does nothing but
updating dependencies. Trivial changes in the code he will do but most is
delegated to the developers. The job includes:

* 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.

~~~
chrisrhoden
As near as I can tell, the post is a response to comments in reply to a
previous post which essentially states that the _existence of cargo_ is bad
because there are bad libraries available.

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.

