Don't Put That Idea on Someone Else

What I Learned About Credit in Software Engineering

When I was first starting in software engineering, I was in a meeting where I tried to give a colleague credit for an idea they had expressed in private but I had mentioned first in the meeting. The reply from the others in the meeting was:

You brought it up, don’t put that idea on someone else.

It shocked me because that seemed to me to be going against the very point of giving credit to someone.

What does putting your name on your work mean? When would you do it? Why would you do it at all? I came to software engineering from History through a series of unusual jobs, and in each putting your name has meant something about you and your relationship to your colleagues. That moment says a lot about how the engineering world and the broader humanities world sees the idea of authorship, and how members of those respective communities view their intellectual relationship to one another.

Credit versus Responsibility

After that meeting I began thinking about how just about everyone put a comment block at the top of whatever file they were writing. Coming from a humanities background, I assumed that it was like putting your name on a paper. You want to tell people who wrote this code so they can reference it later if they’re using the ideas present in your code in their code.

In any sort humanities community (I’m using humanities here to describe any discipline where what is being produced is an idea, rather than a physical product, think writing or things where the outputs are abstract or hard to measure), authorship is about credit, credit for originating the idea. Putting your name on a piece of work is meant to claim that idea. Its a mark of skill, or intellectual capability. In the abstract disciplines, being credited with an idea is the only way to show your contribution to a collective effort (be that a local collective effort or one that’s more general like “the field”). When studying the humanities, it’s paramount to indicate when an idea is not your own.

However, in engineering, authorship is about responsibility. That name at the top of the module file is not so others can give credit for your brilliant code, its to find the person who’s responsible for fixing it when it breaks. In engineering there is an implicit expectation that ideas, in the form of designs or code, need to be maintained. What you produce has a life of its own outside of you. The fruits of your labor are likely going to be part of a larger system and used by others (either indirectly or directly) and those products may fail when exposed to the larger world. Putting your name on something is in effect a promise to fix it when it breaks. It’s these assumptions that drive a lot of the culture of their respective communities and frames that basis of trust for individuals in those communities.

A key point of engineering that a lot of engineers don’t often talk about is the need to trust their colleagues. In most situations, its very difficult if not impossible to know the entire system to the level of detail needed to quickly troubleshoot problems and solve emergencies. An engineer needs to trust that a system built by someone else (either within their company or a third party) will function and that the person responsible for that system knows enough about it to fix problems and will fix it if it’s the cause of a wider system failure. Putting your name on your work is a promise that that implicit contract can be fulfilled. That contract enables engineers to specialize in their respective systems, while still maintaining the integrity of the wider system.

In disciplines where authorship is about credit, trust relationships revolve around the theft of ideas. In such systems, work requires little or no maintinence and thus does not require the author after the work is finished. It also becomes easy for another author to use someone else’s ideas. In these communities trust revolves around the need for members to collaborate without stealing one another’s ideas. Collaboration isn’t possible if one cannot share their ideas without them being stolen. If a creator can be sure that they will recieve a share of the rewards for a successful idea (be they social or material), they can specialize or freely share their ideas to a wider group.

Being aware of the culture of authorship allows you to better navigate your organization. When I first switched careers, I quite often found the cultural aspects of working life in engineering much harder than the technical. Awareness of these issues can go along way towards briding the gap between the technical and non-technical parts of an organization. The simple act of the just putting you name on your work is bursting with meaning for you and your wider community.