Programmer Identity Crisis?
Reflecting on my journey in software engineering, I’ve realized that our educational path often emphasizes the beauty of code—its quality, elegance, and maintainability. We are taught to be artisans, custodians of the craft. Numerous books on design patterns, clean code, and the pragmatic programmer reinforce this idea. But once we enter the professional world, the reality hits hard: professional software development is not about craftsmanship.🚫
The Realization: It’s Not Craftsmanship in a Professional Context
I’ve come to a critical realization: software engineering is not a craft when done in a professional capacity. Why? It’s all about the law of diminishing returns. Writing and verifying code takes time, leading to a clash between two forces: business and engineering.
The Two Opposing Forces
- Business Force: This side is all about speed to market, maximizing revenue, and minimizing costs.
- Engineering Force: This side focuses on delivering quality, maintainable code, reducing operational overhead, and minimizing churn (i.e., experienced developers leaving and new joiners onboarding).
These opposing forces often cancel each other out and rarely align perfectly. Since the core of any business is to make a profit, the business force often overshadows the engineering force. No matter how strong your engineering culture or leadership is, the balance tends to favor business objectives. This results in immense pressure on software developers to deliver under less-than-ideal conditions, leading to:
- Higher technical debt
- Increased operational overhead
- More churn
A More Balanced Perspective
Well, this sounds depressing. But it doesn’t have to be! By acknowledging that software engineering is not purely a craft in a business context, we can work towards a better balance among these opposing forces. Here are four insights that have helped me thrive throughout my career:
1. Shift Your Perspective
It’s not “you vs. them,” it’s “you and them.” Business and engineering are part of the same equation. It’s our job as engineers to advise on technical aspects while understanding business constraints.
2. Negotiate for Business Outcomes
Focus your negotiations on business outcomes driven by technical objectives. For example, refactoring a service can drastically reduce incident costs and improve long-term stability.
3. Upskill Strategically
Statements like “I’m not a business person; I just want to write code” are limiting. The more streamlined the communication between technical and business contributors, the better the outcomes for everyone. Developing skills that enhance communication and coordination can lead to better results.
4. Find Your Crafting Space
Find other avenues to practice programming as a craft. For me, side projects, teaching about the industry, and building tools help scratch that itch. If you can elevate your programming practice to an artisan level while generating revenue, you’ve unlocked the ultimate stage of being in this industry.
What are your thoughts on this?!