Other the years of working in the software industry, I’ve seen a trend towards dichotomy. (This is speculation, mind you.) The theme is that programming folks being hired and kept are starting to fall into two role buckets:
- Architect – the person responsible for how all the parts fit together, knowing advanced software engineering concepts, SME on programming languages, and keeping an entire piece of software in their head.
- Benefits: Experienced, able to handle abstract problems and make decisions, can have vision, knows how to optimize programs while coding.
- Cons: Not enough people like this, rarely seen together with other Architects, detached from day-to-day processes, superiority complexes possible.
Architect from Pexels.com
- Code Monkey (CM) – the person told what to do and often how to do it; implementer of code on a line-by-line basis without understanding of how the program ought to work.
- Benefits: Cheap, plentiful.
- Cons: Unable to grasp conceptual discussions, cannot make meaningful decisions, likely to create more problems of correction for Architects if not given explicit instruction.
Monkeys from Pexels.com
Hear me out for what I’ve seen.
Let’s start in the 2000’s. From those learning to program along with myself, most had no grasp of the conceptual aspects of code (ie, they were Code Monkeys). They were many. Me, new and naive, could work my way out of a paper bag given enough time, but that’s that; far from Architect, but driven beyond the role of CM and surrounded by them.
Entering banking security, I created new systems from scratch, monitored their performance, and communicated the soul of the work to others. I was an Architect. But I also worked with other Architects (experts at the company), making new projects difficult to integrate.
Following up with healthcare work, I had the privilege to see Architects and CMs working together. Architects needed awe from the CMs because they were never wrong; when they were, things got expensive, dangerous, and people were reprimanded. The company I worked for also desired not Architects but CMs, many of them for cheap. To get the recruitment numbers, fresh college grads and foreign visas were required in astonishing numbers. (At least a strategy of making CMs into Architect-like persons continues to contribute to the long-term success of the company.)
For Microsoft, I got to be an Architect again! My insight provided solutions to numerous business cases, be they quarterly goals or daily challenges. This largely worked because I could move fast, deliver apps without butting heads with others, and created documentation such that persons in need could CM their way to a solution on their own for common issues. The rest of development wasn’t so lucky; this is where I saw Architects wielding CMs full-bore in the dichotomy trend.
Later in the gambling industry, I did the kinds of work done for Microsoft at a new company. I was half Architect being self-managed; half of my time was as a CM, maintaining and expanding the work of others from before me. Though, as my responsibilities grew and shifted, I get a front-row seat (too close for comfort?) to the Architect / Code Monkey trend and all its conflicts:
- Multiple Architects cannot agree on solutions.
- Architects abandon daily processes.
- CMs usually cause more work for the Architects in code reviews.
- CMs require constant check-in to ensure the right work is being done, or will reaffirm any course of action to the point of stagnation.

Now, there’s bleed between Architects and Code Monkey’s still. As mentioned, I used to both Architect and Code the solutions to problems. Architects and CMs I know typically still code or make design decisions on their own.
But their numbers are few and they are dwindling.
Am I correct in these observations? Really only time will tell. Meanwhile, the software industry I grew up with is shifting in my sight. Instead of agile cooperation between peers who are all on the same level, Architects compete against each other in a rat-race of expanding technologies while Code Monkeys exist as replaceable cogs. It’s George Orwell‘s 1984 worker dichotomy of the Party and the proles.
I hope to be wrong.
One thought on “Software Worker’s Dichotomy”