For most of its history, the programming labor force has been passive and relatively submissive to its employers. There have been exceptions, but mostly before what we think of today as "the tech industry" really existed. Over the last 2-and-a-bit years, that's changed dramatically. We've seen the neveragain.tech pledge. We've seen repeated employee uprisings at Google over harassment, military contracts, and collaboration with authoritarian governments. We've seen employees fight to kill immoral contracts at Salesforce, Microsoft, and Amazon. We've even seen a small startup's developers vote to unionize.
As we wake to our own power and start trying to use it, I think we have a lot to learn. Given our industry's history and programmers' typical backgrounds, most of us have pretty limited exposure to the history and the theory of labor power. We shouldn't waste our time re-inventing the wheel. We need to study what labor learned over a century and a half of struggle. The conditions of a millworker in 1912 were very different from ours, but labor is labor and organization is organization where and whenever it happens. We have more in common with that millworker than we might think.
So what is labor? It's not "work", exactly, although they're related. There's many ways to define it, but one simple way is "work that produces something or directly operates some necessary system." Both "produces something" and "necessary system" can be construed pretty broadly, so service jobs are labor. It does exclude some common work, though, and that's key: directing other people's labor is not itself labor. In tech, most engineering managers also do some engineering work themselves, so they exist in a sort of middle ground of doing some labor and some non-labor. Executives (outside very small companies) generally don't perform labor, though.
This definition may seem arbitrary, but it's not. Managers, and particularly executives, often have roles and incentives that bring them into conflict with individual contributors. The conflicts are a direct result of the divide between labor and non-labor work. For example: We benefit when we have the autonomy to do the work we want, and do it in a way that we like. They benefit when we have less autonomy so that it's easier to bend our labor toward their particular ends.
This is why we as developers have something in common with that millworker. We have a little more freedom day to day, but it only goes so far. We only have as much say over the product of our labor as management decides to give us, and what say we do have goes up in smoke the moment we're in conflict with management's wishes. And on that front, we have something in common with low-level managers: they can tell us what to do, but their boss has just as much power over them as they have over us, and limits their freedom in much the same way.
header image courtesy of Wikipedia user Grendelkhan