Back

Software is made by humans for humans.

Most software is made by teams. All software involves interacting with other people. When you use a tool, a programming language, you’re interacting with the people who made it; when people use your software, they’re interacting with you. When software works or doesn’t work, that’s the decisions of others, the work of others that you’re experiencing. It’s people all the way down.

2/

Most software is made by teams, and software development is an •intensely• social activity. Software projects stand and fall on the relationships between the humans who create it: whether they understand each other, whether they collaborate well, how they make each other feel.

Computers don’t fill in the gaps and misunderstandings for us with common sense; when we don’t understand each other, we •codify• that misunderstanding in our code, fix it in place and turn it loose.

3/

@inthehands I sometimes say that software reifies particular ideas into code, because in code, it's a real measurable thing in the world, whereas before code, it was an idea that floated in the use and communication of the concept between people and their society.

@Wikisteff @inthehands I say that too (really! It's nice to see the same thought out in the wild) and usually the response is "is reify a real word?" (yes, it's the essence of software)

@inthehands @Wikisteff all of my roles now come down to either translating between domains (idea and implementation, developer/user/expert expectations, dev teams/IT requirements, management/staff etc) or QAing the accuracy of those translations. No one else but me sees it that way, but that's what it is: reducing errors in conceptual translation layers.

Reification is a beautiful and straightforward concept and I certainly agree it's a shame we don't have a more common clear term for it.