[agentultra]

The only thing that works well for me is: thinking hard (ie: writing some definitions, asking questions, editing, repeat) and then writing some code. Then repeat.

When working on a team, splitting up work across modules/contexts/domains works well. I’ll give you an API you tell me what works well, what you still need from it, what errors there are; I’ll address them.

Nothing works better than trust and autonomy. I don’t tell you how to do your job, you don’t tell me how to do mine. You want me on the team because of my expertise and some of my values overlap with everyone else’s.

When working alongside non-technical folks, communication and trust is key.

Trying to quantify developer productivity and sell a system is what the snake-oil hucksters have been selling since the 90s. Management consultants, process engineers, whatever you want to call them. They’re selling something.

We’re knowledge workers. We’re not manufacturing cars or widgets. We learn. We design. We think. Our output is knowledge, not widgets.

[dualogy]

> Nothing works better than trust and autonomy.

> Communication and trust is key.

> We learn. We design. We think. Our output is knowledge, not widgets.

That's a manifesto I would sign! But let's not make it into one, because back then the originally-similarly-spirited Agile Manifesto couldn't immunize itself against "adoption" by — management consultants, process engineers, whatever you want to call them =)