> The core of hacking is not writing the code but working out what needs to be written.
It's really difficult for me to get certain of my co-workers to work out what needs to be written. Mostly it seems we discuss minutia and get off on tangents rather than work out the whole thing; it's difficult to get them to look at it from anything but a low level (arguments about how an API should work takes an hour). Do you have any advice on how to get people to discuss the work in a realistic, high level way?
Culture is difficult to build - either from scratch or from an established base. I have practised mutual respect - a meritocracy. Although formally I was a "group leader" or "supervisor" I regarded my colleagues - whether students of research assistants as my peers.
I was prepared to be told when I was "wrong" and think about it. Gradually we built a culture where the culture - as well as the people - determined what we did and how we worked. My group reorganised how we ran weekly meetings and I followed their practice. (Of course things like lab safety and secure practice have to be taken ultra-seriously as do basic human relations - gender, race, etc.).
I am very proud of the people who went through "my" / our group. They all went into hi-tech IT - companies, scientific organisations and none into formal academia. Most are in the UK and therefore directly contributing to our wealth and my pension.
The Friday pub sessions are really valuable. Nothing as formal as an "away day". It helped that many of us played cricket (I gave up two years ago - made it to 70), and I introduced them to the Guardian crossword.
It depends very much on the goal of your group. If you have a chance to develop new ways of doing things, do so. If there is no slack in the system then the daily work is likely to turn out competent but no inspiring code.
If you can do one thing go on a Software Carpentry course (you might be able to count it as training). If not, can you run a dojo? If your organisation provides training you may be able to bring in someone (or travel) to provide the experience. fresh views help.
Ultimately you have to aim for respect, and flexibility. I don't make major mistakes or have failures - I have experiments which don't work out at the time. JUMBO has been through 6 revisions over 20 years. I'm very lucky - I have that luxury to keep going at something which isn't critical for my income. When I was earning an income through consultancy/training I had to make sure that I had some slack in which to learn.
Avoid individualism but try to give everyone space in which to make their own identifiable contribution. I would normally start projects, then suggest that group members worked =on them, and when the left, they retained the "guru-ship" of the project.
It's really difficult for me to get certain of my co-workers to work out what needs to be written. Mostly it seems we discuss minutia and get off on tangents rather than work out the whole thing; it's difficult to get them to look at it from anything but a low level (arguments about how an API should work takes an hour). Do you have any advice on how to get people to discuss the work in a realistic, high level way?