Enlightened Developer vs Engrossed Developer (11/30)

I'm writing 30 posts in 30 days. This is number 11.

I want to talk about two kinds of developers — Alice and Bob. Both Alice and Bob are your average, run-of-the-mill web developers who were born in the 80s, grew up in the 90s, and straddle that nebulous boundary that separates the Gen-Xers and the millenials. They both work in the same software company and have the same level of skills professionally. Anything that’s professionally relevant, let us assume Alice and Bob are, for all purposes, the exact same. The only difference is that Alice is what I want to call an Enlightened developer. Bob is an Engrossed developer. Let’s start with Bob.

Meet Bob — the Engrossed Developer

Bob loves tech. And he often attacks problems given to him from his managers like a dog on a bone. His favorite is to come up with complicated diagrams and often aims to please as many stakeholders as possible. Tradeoff is a dirty word to him. He’s known for his persistence, his tenacity, and his drive. His team mates love him for the passion he brings to the job, though they are sometimes scared by his intensity. He’s like a whirlwind of energy and sometimes leaves just as much destruction in his wake as he zips around multiple projects. There’s always a project that needs an extra pair of hands and Bob is generous with his energy and time.

What management starts to notice is that in his haste, Bob sometimes makes things worse by adding more tech than needs to. Bob spends a lot of time in his off time reading and catching up on the latest in technology trends and open source software. Whenever he catches a fancy on some new technology trend that’s about to breakout, he cannot help himself but want to implement that in the project he’s on. Even if it’s a mission critical project. He often lobbies the senior management to form something like a tiger team. A tiger team is a separate team of developers investigating the latest trends and tries to figure out how to use the latest technology in a productive manner. Once they can figure out the productive part, they can then go “install” this newly learned technique to each time, he argues. Most teams have little time to do discovery work. They are always in delivery mode. Having a separate team to focus on discovery and then teaching that to the project teams can keep the company on the cutting edge and ahead of the competition.

Meet Alice — the Enlightened developer

Alice loves tech as well. Unlike Bob, whenever Alice is given a problem by her managers, she doesn’t immediately jump in. She seems to do some form of triage by asking a series of questions to her managers. Is this an urgent request? Who does this affect if it’s not done at all? When is this needed? What do I need to postpone on my Work in Progress so I can slot this in? Is there an easier way to achieve the same outcome but without any technology at all? How does this align with the business goals of the company? Like Bob, Alice thinks sometimes a dilemma is a false dilemma — there is a way to satisfy seemingly contradictory needs. Unlike Bob, Alice doesn’t think tradeoff is a dirty word. Because Alice knows the solution that manages to reconcile two contradictory needs is often one that trades off on a third dimension that nobody cares about. At the highest level, there is no true problem solving — only problem tradeoffs.

What management notices is that while Alice appears to be far more languid in her body language than her peers, projects that she takes on are always complete. Not necessarily successful, mind you. Projects, after all, are complex and rely on myriad factors and people to pull off successfully in the commercial sense. But things get done when they land in her work in progress.

There’s a quiet confidence that Alice exudes and she’s not afraid to say “I don’t know.” Alice also has this uncanny ability to code-switch when she talks with different audiences — non-technical customers, deadline-focused product managers, and technical developers. People like her to be on their team.

Like Bob, Alice also thinks a tiger team — separate team of developers that doesn’t just focus on project delivery is a good idea. But her idea for a tiger team is different from Bob’s. First, she thinks Acme (the company both Alice and Bob work in) executive management needs to make a decision about the direction of the company in the next five years. Acme is primarily in the B2B software space and has a dozen product lines. As they mature into a medium-sized company, they start to face competition from both startups and giant behemoths like Microsoft.

Acme’s challenge

Startups compete with them by offering lower pricing and greater customizations than Acme can afford. After all, their newest product codebase has at least three major version upgrades. This does mean their product suite has a certain maturity, but it also means it’s not always easy to change or customize for today’s rapidly changing landscape.

Behemoths compete with them by leveraging heavily into their network and distribution. They saw how Microsoft Teams quickly overtook Slack in terms of usage and installation once Microsoft focuses on the inter-team communications space. While Acme is well-entrenched in the industries that they cater to, there’s no knowing whether that will be quickly eroded by the Microsofts or Salesforce of the world.

Alice wants Acme executive management to decide if they are going to be a pure tech-focused company like the way Google is or a pure B2B software company like the way Salesforce is. Because deciding which route they want to be allows them to focus and be the best versions of themselves. Splitting resources and efforts between two different visions means neither will succeed. A tiger team can help refocus each individual project team to better align with the vision.

Run Less Software

Currently, every project team owns their own technology stack. Which gives individual team a lot of freedom, but that also leads to a lot of wastage. It’s this very freedom that initially attracted Bob to join Acme. At the same time, this freedom means there’s no economy of scales when it comes to common infrastructure such as spinning up a new LAMP stack or a new job queue. Developers find it hard to move from team to team because each team seems to have its own mini tech culture leading to a lot of relearning. Alice proposes after deciding whether they want to be a pure tech-focused company or pure B2B-focused company, they can then align how some of the common infrastructure should be consolidated and standardized across each project team.

Alice admires particularly the Run Less Software philosophy advocated by Intercom. She thinks Acme ought to take a leaf out of the same approach. Not all software is equal. Depending on the direction the company wants to take, and their progress, some software choice is better off standardized, some best decided by the best developers of the company, and others left to the individual teams to decide. Every once in a while, this mix is re-evaluated once again to ensure the technology mix makes sense to the strategic direction the company is going into.

Who is better? Engrossed or Enlightened?

The answer is it depends. I can easily imagine a scenario where it’s better to have the engrossed Bob and another scenario where it’s better to have the enlightened Alice. Given the unequal length of words I have devoted to the description of Bob and Alice, you can tell which one I lean towards.

But, I’m actually closer to the engrossed Bob than the enlightened Alice. The enlightened Alice is the model I aspire to become and the engrossed Bob reminds me of the past me I wish to leave behind. There are many aspects to the both archetypes I like to explore further and I ran out of time to do that here. The key aspect I want to highlight is that Bob thinks that the most important thing about tech is tech itself whereas Alice thinks the most important thing about tech is everything and anything else that tech depends on to be successful.

The difference in the actions, attentions, and attitudes of Alice and Bob simply flows from this fundamental difference.