The engineer as a social type
What it means to "write code" in the platform economy, and who the work quietly turns you into.
An engineer is used to thinking about himself technically. I solve problems, I design systems, I write code. All of that is true. The trouble is that it leaves things out. A profession is also a social type, a bundle of habits and outlooks that grow straight out of the work, and that the worker usually stops noticing, because by now they feel as natural to him as breathing.
What code does to thinking
Anyone who writes code long enough starts to see the world as a system that comes apart into pieces. Any problem tugs at you to decompose it: split it into modules, kill the duplication. It is a strong way of seeing. It is also not neutral.
It works beautifully where the boundaries are clean, and it stalls where ambiguity, history and a living context matter more. The engineering type tends to overrate whatever can be formalised and to distrust whatever refuses. I catch myself doing it when I am talking to product people, and sometimes to my wife, and I have already started building a little dependency graph in my head while the person across from me just wanted to be heard. The skill that feeds me gets slightly in the way of living, right in those moments.
Autonomy and its limits
Engineering work looks autonomous. You decide how the code is arranged, you are valued for expertise, there is no conveyor belt above you. But the autonomy is only partial. What to build, for whom, on what terms: almost none of that is the engineer's call. You are left with the how, while the what and the why arrive from above. It is a comfortable construction. It hands you a feeling of self-direction without handing over any control of the direction itself.
A case from practice. A couple of years ago I inherited the admin panel of an internal tool, and inside it a screen for managing access. The task sounded strictly technical: design a matrix of roles, who can do what in production. I spent half a day fussing with checkboxes and inherited permissions, and at some point it hit me that I was really deciding which of my colleagues on the next team over even had the right to touch the live switch, and which of them had to go and ask. That is not about code anymore. It is a small political decision, neatly dressed up as a technical one. And honestly, I enjoyed making it. Power hidden inside an interface still feels like power.
Out of this comes the tension that runs through the profession. The engineer is proud of his craft and, at the same time, often half-senses that the craft is serving ends he never chose and sometimes does not share.
The platform changes the type
In the platform economy this type shifts noticeably. The work is ever more tightly mediated by tools that are themselves built like platforms: issue trackers, CI/CD, dashboards, metrics. Productivity now gets measured and drawn out on graphs. The engineer builds the systems of observation and turns into one of their objects at the same time.
For a few years I was the one growing our Unleash, a feature-flag platform, adding A/B tests on top of it, wiring in CI/CD. A flag is a tiny lever: switch new logic on for five percent of users, watch the metrics, roll it out further or roll it back. Convenient, and almost invisible. We once set up one such flag for an experiment. The experiment ended, and nobody remembered to turn the checkbox off. It hung there, on, for about a year. It surfaced at night, during an on-call shift: strange errors on a minuscule share of requests, half an hour of quiet panic, and in the end that same forgotten flag, still routing part of the traffic into code everyone had long assumed was dead.
What got under my skin in that story was not that we had messed up. Messing up is normal. What got to me was that the lever outlived the decision that created it. Someone, at some point, chose to split users into groups, and that choice went on acting on its own, with no author, baked into the system as a default. That is exactly how a platform works: it turns our momentary decisions into infrastructure that other people later inherit. And it quietly files us into the reporting too. The very dashboards I built to watch a rollout were the ones a manager down the hall opened to watch how fast we worked.
Put next to this the figure of the entrepreneur from the neighbouring texts. The engineer is more and more often invited to treat his career like a startup, his skills like capital, himself like a project to be developed and sold at a good price. The profession soaks up entrepreneurial logic even where the person formally stays a salaried employee with a steady paycheck and a mortgage.
"But this is just good engineering"
It is easy to object here, and I have objected to myself more than once. All of this, a sober colleague would say, is elegant overcomplication. Decomposition is a working method, it saves time. The limits of autonomy are a truism, that is how any organisation runs, a bakery included. Dashboards exist so you do not ship broken things to production. What does a "social type" have to do with any of it? Am I not inventing drama out of thin air?
The objection is fair, and part of it I accept. The method really does work, the dashboards really are useful, and I am not throwing out either one. But a "mere method" stops being merely a method once you apply it eight hours a day for years. A tool you use for long enough slowly starts using you: it sets which questions strike you as meaningful and which as background noise. And the fact that limits on autonomy are everywhere does not make them invisible. It makes them familiar, and the familiar is precisely the hardest thing to see. In one respect the objection helps me. It keeps me from sliding into the pose of a victim. Nobody enslaved me. Half of these dashboards I built myself, with pleasure, and I still think they came out well.
Why see this
I have been in the profession for years now, and I love it. I am writing all this to give it back its volume. An engineer who sees himself only technically turns easily into the executor of other people's decisions, carrying a craftsman's pride and a clear conscience. An engineer who understands himself as a social type can ask questions harder than a refactoring: what am I actually building, whom does it serve, which consequences am I leaving in by default, like that flag.
I am not sure the view makes anything easier. Probably the opposite. Before, you could honestly hide behind a formula: my job is the code, product and management decide the rest. You cannot say that anymore, the excuse does not hold. What appears instead is something like authorship. Code is a social practice, and the engineer turns out to be a participant in how the shared life is arranged, even when all he is doing is nudging a checkbox in an admin panel.