Link: talk description and video
A lot of user questions for the Google Code project are along the lines of "how do I hide code until it's ready", "how can I wipe the history and start from scratch" and so on: they are about people's insecurities.
When you have elitism and anonymity, suddenly everyone is elite. There's a whole mythology that gets built around programming heroes (Torvalds, van Rossum, Walls).
There are no genius. The only thing this has created is a fear of showing mistakes. This insecurity inhibits progress, makes the process slower, brings lower quality and a lower bus factor.
Avoiding the trap
- Lose the ego
- Criticism is not evil: give and take it politely. You are not your code. People criticising your code are not out to get you.
- Embrace failure (just don't fail the same thing over and over!)
The speaker shared an interesting story (probably an aphorism?) of an executive that makes a mistake that costs his company 10 million dollars. The day after, he starts packing up his things and when the CEO summons him to his office, he's ready to hand in his resignation, saying there is no need to fire him. The CEO replies "Fire you? Why would I do that? I just spent 10 millions dollars training you!"
- Iterate quickly
- Practice is key
- Be a small fish, as in don't be the smartest person in your company. You'll learn much more and faster
- Be influenced. "Alpha" programmers think they know everything and won't ever listen -- you may find that you actually gain more influence, by being willing to be influenced!
- Be vulnerable, repeated vulnerability becomes a strength long term.
Tools
Tools won't solve sociological problems, but they may influence behaviours. Pay attention to the tools, they can influence culture and moral, for instance by encouraging "cave" behaviour where developers work on their own for a long time and dump a big chunk of code: it's bad for collaboration, reviewing, etc.
You don't need to hide a project until it's "ready." Simply don't advertise it. People may find you because they are looking for something like this.
Don't let people collaborate until it's too late: they may help with code reviews, or pointing out to you existing libraries you missed. If it's too late in the project, they have no possibility to drive, to be a strong part of the project and it's less likely they will contribute.
Certainly get a prototype ready, some running code and some design, but let it still be something that you're happy to step back on.
Conclusion
- Don't try to be a genius
- Collaborate early and often
- Pay attention to default behaviours (the ones encouraged by tools especially)
- Pay attention to timing
...and if you do all this, people will think you're a genius!
Some of the questions/responses
Make sure to write a manifesto with the direction you want for your project from early development, so there are no major clashes or misunderstandings later on when people get involved.
If you don't care about credit, wow will you go places. If someone "steals" your idea and they have more reach (e.g. more clout/connections), it's great! It means it's more likely the idea will be implemented, and you'll have more ideas anyway.
On influencing a new team you just joined with best/better practices: start by doing good work and building up a good reputation, then you get to pay it back on something you believe matters. You have to choose your battles, you can't step in front of every train (resistance to change is like a very fast train! Hard to stop.)