Frequent versus infrequent developers (in languages and so on)
Yesterday I mentioned the phrase 'infrequent developer' in an aside in my entry. Today I'm writing about what I mean by that and by its opposite, the frequent developer, and why I care about this.
What I'm calling frequent developers here in the context of, say, a language (such as Go) are people who routinely work with code or programs written in that language. When you're a frequent developer, you naturally develop expertise in that language's operation and often a development environment for it, because you use it often. You know the commands, you remember their options (or at least the ones that you need), you've run into some of the somewhat obscure corners and things that can go wrong. You know your way around things. You'll naturally learn and master even relatively complex procedures.
For a frequent developer, setting up and running some special piece of software to help work on the language is both okay and perfectly sensible. It may take a bit more time to learn and operate, but you use things frequently enough that the extra overhead is only a small portion of the time you spend dealing with the language. It's worth setting up caches and CI and so on, because you'll get enough benefit out of them. You are well up the XKCD 'is it worth the time' table. Frequent developers tend to accumulate a halo of tools that make their lives easier and often improve their results; they know about the linters, the checkers, the formatters, and so on.
An infrequent developer is someone who does not fit this profile. Sure, they have some software written in Go, or Python, or using Django, or whatever, but mostly it sits there working and they don't have to think about it very often. They only modify it or rebuild it or update its dependencies or the like once in a while. Since they're only occasional users of a language environment, infrequent developers generally don't maintain expertise in the finer details of the language's operation, although they can probably remember (or look up) how to do the common things and the basics. They won't remember how to deal with the unusual cases, and in fact may never have run into them. Complex procedures will probably have to be re-learned nearly every time they're needed (or re-Googled for).
Since infrequent developers spend relatively little time dealing with the language, setting up and running additional pieces of software is a much higher overhead for them and is generally not worth it if they have a choice. They get hit on both sides compared to frequent developers; they're less familiar with the software so working on it takes longer, and they use the language much less so the same amount of absolute time spend on additional software is proportionally much higher. Infrequent developers object strongly to thing 'just run this caching proxy, it only takes a bit of time to manage'. Overheads that are small to frequent developers loom very big for infrequent ones. Infrequent developers usually do not have the halo of tools that frequent developers do, and mostly stick to the basics (and as a result they miss out on various things).
It's quite easy and natural for a language community to think first and foremost about frequent developers. Frequent developers are your most active and best users, and generally they are the ones that talk to you most, have the most to say, and are the best informed about the current state of affairs and what their options are. But at the same time, focusing on frequent developers is a limited point of view and will cause you to miss what causes pain for infrequent developers. Worse, it can cause you to design only for frequent developers.
If you're only thinking about frequent developers, it's easy to create a system that assumes that of course people will set up this or that software, or that some particular pain point doesn't really matter because everyone will have tools that cover it over, or that a complex procedure is the right answer because of the power it exposes. To pick on something other than Go, it won't matter that your language refuses to mix spaces and tabs because everyone can just run an editor plugin to fix it automatically (or to automatically indent only with spaces).
(As far as complex procedures go, well, Git is famously full of them. And I say this as someone who considers himself in the 'frequent developer' camp with git, including having tools for dealing with it.)
As I mentioned in my aside yesterday, I have wound up feeling that the perspective of these infrequent developers is often overlooked and not widely heard from. I think that this is not a great thing; to summarize why, I think there are probably more infrequent developers for any popular language than you might think.
(The perspective of infrequent developers is similar to beginners in the language, but I don't think it's quite the same and I'm not sure that being beginner friendly will make you friendly to infrequent developers too.)
A sysadmin's perspective on Go vendoring and
One big thing in the Go world lately has been Russ Cox's writings
on adding package versioning to the core of Go through what is
currently being called Versioned Go,
vgo for short. His initial plans were for
vgo to completely
drop Go's current vendoring feature. If you
wanted to capture a local copy of your external dependencies, you
would have to set up your own proxy server (per his article on
vgo would come
with one). According to the vgo & vendoring golang-dev thread
opinions have since changed on this and the Go team accepts that
some form of vendoring will stay. My interest in vendoring is
probably different from what normal Go developers care about, so I
want to explain my usage case, why vendoring is important to us,
and why the initial proxy solution would not have made me very
We are never going to be doing
ongoing Go development, with a nice collection of Go programs and
tooling that we work on regularly and build frequently. Instead,
we're going to have a few programs written in Go because Go is the
right language (enough so to overcome our usual policy against it). If we're going to have local
software in a compiled language, we need to be able to rebuild it
on demand, just in case (otherwise it's a ticking time bomb). More
specifically, we want people who aren't Go specialists to be able
to reliably rebuild the program following some simple and robust
process. The closer the process is to 'copy this directory tree
/tmp, cd there, and run a standard
command', the better.
Today you can get most of the way there with vendoring, but as I
discovered this only works if you're working
from within a
$GOPATH. This is less than ideal because it means
that the build instructions are more involved than 'cd here and run
go build'. However, setting up a
$GOPATH is a lot better than
having to find and run an entire proxy just to satisfy
proxy makes sense if you routinely build Go programs (and running
it in that case is not a big deal), but we're only likely to be
building this program (or any Go program) once every few years.
Adding an entire daemon that we have to run in order to do our
builds would not make us happy, and even magic
would be kind of a pain (especially if we had to manually populate
and maintain the cache directory).
The good news for me is that Russ Cox's posting in golang-dev is pretty much everything I want here. It appears to let me create entirely self contained directory trees (of source code, with no magic binary files) that include the full external dependencies and that can be built with a simple standard command with no setup required.
(This entry was basically overtaken by events. When Russ Cox published his series of articles, my immediate reaction was that I hated losing vendoring and I was going to object loudly in an entry. Now that the Go team has already had enough feedback to change their minds, the entry is less objecting and more trying to explain why I care about this and describe our somewhat unusual perspective on things as what I'll call 'infrequent developers', a perspective that I think is often not widely heard from.)