Has Capitalism killed the craft of Software Development?

I’ll preface this post with a big disclaimer — I am not a economics or political science grad, this post will not be an academic and thoroughly researched piece. It is the ramblings of a person who got called a Traditional Marxist by someone and decided to read Capital volume 1 to see if it resonated.

Photo by Lian Lianna Begett on Unsplash

In March of 2023 I had a very weird interaction. I had gone to see a friend’s band play at a pub well known for being on the left wing of the political spectrum and somehow I managed to strike up a conversation with the only Tory in the place.

The conversation started innocent enough as it turned out that we were both from South London but the discourse soon turned to politics as they were a Politics major and I guess eager to flex that particular muscle. I’ll spare the details of the conversation but it ended up with me being proclaimed a Traditional Marxist and Satanic.

Being declared Satanic was expected, I listen to metal, I dress almost exclusively in black with the only sprinkling of colour being some obscene graphic on a band t-shirt and I hold views around individual autonomy that freak the more conservative christians out.

But it was the first time I’d been called a Marxist, let alone a traditional one.

Am I a Marxist?

If I think about how I self-identify and it’s relationship to capitalism I see myself as working class kid done well. I was raised working class but the job I do is mostly populated by people who are middle class so now I exist in this weird limbo of not belonging at the table on either side (the joys of being British!).

When you grow up working class your parents condition you to have a certain relationship with work:

1. You’re a dead weight if you’re not earning money (and that means cash, not assets or options etc)
2. A job is a way to earn money and if you’re lucky you might earn enough to actually enjoy yourself
3. Your job will suck and the people you work for will upset you but you will always have a boss so learn to deal with it
4. Learn a trade, it’s going to allow you to do something creative in exchange for money
5. Your boss is doing you a favour by giving you a job, you should work hard to show them that you deserve to keep that job and by doing so you’ll be rewarded for the effort you expend

As soon as I could legally work I learned point 1, having a cash-in-hand paper round as a kid and then working in a kitchen at 15, the day my National Insurance Number turned up in the post. This was very quickly followed by learning point 3.

When I started my career in software development I utilised that 4th point, having given up my childhood dream of being a 3D animator (having to work means no time to build a portfolio) and instead applying the very basic coding skills taught in my art degree (I worked 40 hours a week while doing my BA to counter-balance the 1st point) to land a job as web designer.

In my first software development job I thought point 5 would hold up but this was where I got exposed to the NHS Career Progression Framework and realised that no matter the effort expended there were budgets that meant I was stuck on a certain salary.

It was that experience that made me realise that my mum was wrong about the relationship I was expecting to have with work and this led me to redefine how I viewed my job.

Since then I’ve come to redefine that relationship:

1. You’re a dead weight if you’re not making progress (monetary, knowledge, goal progression)
2. A job is a way to earn money and if you’re lucky you might learn enough while doing it to find a way to work for yourself or move towards something you care about
3. Your job only sucks as much as you let it suck, find a way to carve a path towards making it suck less
4. Learning a trade teaches you how to do a job, learn the craft behind the trade to be truly creative
5. Your boss isn’t doing you a favour giving you a job, they need you as much as you need them so approach the table knowing your worth and knowing your options for growth

I think it’s most likely the 5th point of my refined relationship with work that earned me that Marxist label from the person I was talking to at the pub.

Reading Capital Volume 1

In June 2024 I went on holiday to New Zealand, a trip that involved a lot of travelling across the North and South islands there and I decided it would be the perfect opportunity to see if my own beliefs aligned with those of Marx.

I am not an economist in the slightest. I have a very simple view on things:

• I work for my employer in exchange for a monthly salary
• I pay my taxes so that the social safety net is maintained
• I pay my expenses so that I can maintain my current lifestyle
• I put money away so that I can chase my dreams

Anything above that is kinda beyond me. So with that framing, sitting down to read a hefty tome like Capital was a little daunting.

The material of Capital is very dry, there’s a lot of explaining how raw materials are refined into products and then how a worked transfers value as they do that refinement and how that value is reflected in the price when it enters the refined product is confronted by another commodity in the market.

I appreciated how Marx explained the economics of capitalism and how extracting surplus value is achieved and then looked at how that has impacted society from changes to the law that means better working lives to the social constructs and relationships.

The later chapters that dealt with the industrialisation and mechanisation of processes were very interesting though, especially the parts around the social impact of mechanisation and how it turned workers from craftspeople able to produce a product by themselves into specialised workers who only know the part of the production process they’ve been assigned to.

This made me think about the Software industry and how I could see Marx being blown away by the infinite reproducibility of the digital age and how a worker while no longer transferring their physical value into the product now transferring their mental value into a product for a set amount and the capitalist who commissions that work can now extract vast amounts of surplus value.

My main thoughts however were about the social impact of certain trends in Software Development and how they parallel with those changes brought by the mechanisation of production.

One passage especially resonated with me:

“The lifelong speciality of handling the same tool now becomes the lifelong speciality of serving the same machine. Machinery is misused in order to transform the worker, from his very childhood, into a part of a specialised machine. In this way, not only are the expenses necessary for his reproduction considerably lessened, but at the same time his helpless dependence upon the factory as a whole, and therefore upon the capitalist, is rendered complete.”

And this got me thinking about a few things.

The “AI Revolution”

The Machinery and Large-Scale Industry chapter of Capital was really interesting to me because of the impact that LLMs and so-called “AI” are having on multiple industries, including software development.

In the chapter Marx touches on the changes to the working day that factory work introduced and how the capitalist employed machines to speed up production but also increased the number of hours that production could happen in order to maximise the return in their investment in the machinery.

With the introduction of machinery there was a class division in the workforce based on the interaction with the machinery, there were those who used the machinery to complete a job, those who attend the machinery to feed it with raw material and those who maintained the machinery.

Over time the capitalist looked to mechanise the work of those used the machinery to complete a job so that those workers would find themselves moving into that attendant class of worker which benefited the capitalist as they could be paid less and be easily replaced.

While “AI” is dumb as bricks now I think it’s worth paying attention to the way that things worked in the past and identifying the types of work we do when building software. If you have a very specialised job it may be time to expand your skillset so that you can pivot when someone ultimately builds a tool that can replace your part in the process, lest you too become an attendant to it.

Lean and viewing software development as a manufacturing process

I like Lean, I think compared to the more waterfall software development methodologies it looks at ensuring that the process that is being followed to build software is continually improved and made more efficient.

I do think though that it may be forcing software development teams to frame the work in such a way that makes people to think of their jobs as specialisations so that the overall process runs smoother because they take an input, transfer their value into the product and send it to the next stage of the process.

To go back to the quoted passage from Capital

“In this way, not only are the expenses necessary for his reproduction considerably lessened, but at the same time his helpless dependency upon the factory as a whole, and therefore upon the capitalist, is rendered complete”.

If software developers work in a process that looks to remove the scope and variance of their inputs in order to increase their output it’s going to increase their dependency on such a process in order to be productive.

As “knowledge workers” it feels counter-intuitive that we’d limit our exposure to learning opportunities but I guess this is a side-effect of applying manufacturing sensibilities to the work we do.

Progression Frameworks and the “IC Track”

In most jobs there is a set of competencies that measure the ability of a worker in order to clarify the expected behaviours of workers at different levels and how much those workers are paid. This works for the company as they can measure a worker’s behaviour against a set of criteria and ensure they’re getting what they pay for and it works for the worker as they can see what they need to do to progress to the next level and earn more money.

In software development it’s common to hear progression framework referred to as the Independent Contributor Track, a term so widely used there are websites such as levels.fyi that translate the progression framework levels from different tech companies so you can plan your move accordingly.

There’s one problem I have with the IC track and it’s tied into this notion of specialisation. In most IC Tracks once you hit a certain point (usually after Senior Developer) there’s usually a choice to be made around moving into management or moving into a specialist role where you’re expected to have deep knowledge of something so the business can justify paying you more and you don’t have to take on managing people.

I’ve worked with some great people who have chosen the latter and have focused their careers on becoming experts in the area of their choosing.

Technology is constantly evolving though and some of those people failed to learn new, radically different technologies that became the direction the industry had headed and those people could no longer find work that fulfilled them and in one case, couldn’t find work at all.

And after reading Capital I worry that this emphasis on specialisation and not generalisation in order to prove your worth to the business to progress on the IC track will result in raising a cohort of software developers who don’t see the benefits of understanding the craft of building software but instead want to hone in on a specialisation as soon as possible in order to coordinate a smoother journey up the IC track.

To quote Marx:

“Machinery is misused in order to transform the worker, from his very childhood, into a part of a specialised machine.”

Abstractions, Frameworks and Developer Experience

Unless you belong to a very small subset of the programming community you most likely make use of abstraction layers in order to ensure you’re building a high quality product at a decent rate of progression by letting you focus on what you want the program to do instead of how it interacts with things like the file system or the various networking layers.

Frameworks are another abstraction layer that are used in programming. They provide a set of tools you can use to build your software. Some frameworks have strong opinions on how they should be used and there are benefits to using an opinionated framework as it’s often easier to see when code is written in a way that does match that opinion which in turn makes it easier to keep your codebase maintainable.

It’s quite common when reviewing a developer’s CV to see not only programming languages but also frameworks listed under their technical knowledge. It makes sense to do this as the automated screeners will often look for these words in order to ensure low quality candidates don’t make it to the initial stages of a job application.

I have a concern, similar to the one around the way the IC track forces developers into a specialisation that we’re now teaching developers how to use frameworks instead of exposing to the underlying technologies and then showing the conveniences the framework provides.

I think this is particularly prevalent in the JS community, with developers taking JSX and React and creating frameworks to abstract over writing client side code, server side code and mobile applications.

This is being done under the banner of “Developer Experience”, a term used to describe efforts to remove variance and complexities in the approach to writing code so that developers can have a nice experience taking the paradigms they know from one framework and apply that to a different domain.

I can see the benefits of not having to expend the effort learning a new language or a new paradigm in order to take advantage of tools in a new domain. I’ve used React Native to build apps in the past and it’s given me a massive productivity boost by using my existing React skills and not having to learn Swift and Kotlin.

Aligned with my concerns about removing variance in the software development process is a concern that by removing the variance in the code written by developers we not only remove their exposure to new ideas but we increase their dependency on the paradigms used.

To quote Marx:

“The lifelong speciality of handling the same tool now becomes the lifelong speciality of serving the same machine”

Software Development’s arts and crafts movement

In the 19th Century there was a reactionary artistic movement called the Arts and Crafts movement that looked to correct the perceived decline in quality associated with machine and factory produced goods.

Now I’m not suggesting that developers hand flip their own bits in order to get back to the basics of computing but I think we need to bring the craft back into software development and choose to take the time to hone our craft and learn to master the variances instead of trying to flatten them out in the name of efficiency.

If we keep turning software development into a factory process by removing variance and seeing generalisation as a weakness then we run the risk of producing developers who are no better off than the cottage industry workers who took up job in the factories in the 18th and 19th century, doing one specialised job in the larger production process and then find their job mechanised and their autonomy removed as they become attendants to the machine.

I know that sounds far-fetched but we’re already seeing “Prompt Engineers” who’s job is to feed prompts to get “AI” tools to do the work of graphic designers, coders and other parts of the software development process and then check the output.

To paraphrase the Agile Manifesto “Individuals and interactions over processes and tools”. Let’s not focus on the processes and tools that form the way we work but focus on ourselves and the interactions we have as part of building software together.