Parlour Do We Need More Developers

+++ title = "Letter to my Parlour: Do we need more Developers?" author = ["emsenn"] date = 2019-03-12 tags = ["economics", "computer programming"] draft = false predecolonial = true +++

Introduction {#introduction}

Yesterday I was involved in a thread where someone was insistent that in order to solve the problems in the open-source development world, we need more developers:

The reality is that there are not enough developers coming forward to help, and that is a social problem that can be resolved by non-technical users.

For non-technical users to resolve the issue, they just need to... become technical users:

[T]here is a need for more folks to learn development so that these things can be tackled properly. Otherwise the single-developer problem will continue to exist until the end of time... Lack of developers is indeed the root of the problem.

This struck me as an exceptionally lazy suggestion of resolution. Everyone thinks that the parts of the economy which benefit themselves need more resources - of course programmers who benefit from an abundance of programmers think more programmers is the solution.

Is "lack of developers" really the _root_ of the problem?

The Implications of "More Developers," {#the-implications-of-more-developers}

Saying we need "more developers," implies we need:

more humans.

or a greater number of the current humans to have an interest in development

or a greater number of current hobbyist developers to do it professionally, and for professionals to do it as a hobby.

Any of those takes resources away from some other part of our economy. You just can't get _more_ developers: either other facets of the economy grow so it'll stay proportionally equal, or you're asking for an even-higher level of interest in computers and technology among the general population, and in my opinion, the general population nearly fetishizes computers.

Efficiency as an Alternative {#efficiency-as-an-alternative}

I don't think we need more developers, or more development.

I think we need more efficient development systems: rather than get more output by increasing the input, let's see where we can secure marginal gains.

Developers have already spent a lot of time on squeezing every millisecond of efficiency out of computers - regardless of if you're using Python or Rust, drag-and-drop visual programming or vim, any means of providing instructions to a computer is ridiculously fast.

What isn't so fast is all the other stuff around development. There's ample room to draw efficiency out of the interpersonal and decision-making aspects of software development, which take up far more of a developer's time than inputting instructions to a computer.

I advocate that developers invest an even greater amount of time learning about things like project management than variable typing: if you get one of those things wrong, you end up with a memory leak. If you get the other wrong, you might end up accidentally building software that collapses any given democratic republic, or simply spend a lot of time picking colors for links when it turns out it should've been underlines the whole time.

Conclusion {#conclusion}

It's easy to see things like transitors, compilers, interpreters, and so on as innovations - and I think a lot of developers spend a lot of time thinking about how to innovate from there.

It's a little trickier to see how things like bug reports and Agile are innovations, and I think a lot of developers could spend more time thinking about how to utilize those innovations.

Because, well, it seems like a woefully under-developed field, compared with our proficiency at giving computers instructions. And on a more worrisome note, most of the effort put into the field, so far, has been by large corporations and governments. I'd love to see the open-source world take a more keen interest in the meta- parts of programming, not as a defense against social justice warriors or having the project stolen by Apple, but out of a genuine belief those methods would benefit themselves, first and fore-most.