There seem to be many parallels between academia and the world of software engineering, so what can academia learn from the development of ‘human factors’ in engineering.
I am sure that engineering and science attract similar kinds of people: independent problem solvers who are wary of conventional management. Perhaps because it tends to be more driven by money and tangible outcomes, it seems that engineering has tackled the issues associated with working in such an environment in a much more head-on manner.
The inevitable friction involved when multiple people come together is covered by the umbrella term ‘Human Factors’ – or in other words ‘things that people mess up’. So what lessons can academia (and from a personal point of view, physics research) learn from a human factors approach?
Learning from software engineering
A starting point might be a series of videos I stumbled across some time ago. Made by two Google employees ‘Fitz and Sussman’, who are also big contributors to open source software, the talks cover a range of topics such as dealing with difficult people, working in teams and leadership, as well as how to get what you want out of the organisation you work in.
Or as a playlist.
Perhaps not all of the examples they give are relevant, but I’m sure there are still many lessons that can be learned. I’ve encountered some of the problems they talk about (and probably contributed to some myself…) and I get the feeling that what is being codified in software engineering, and possibly other disciplines too, could be used and applied to scientific research.
Interestingly, similar themes of dealing with people are often written about in ‘Coding Horror‘, a blog which covers ‘programming and human factors’. One of my favourite posts ‘How to talk to human beings‘ recommends the classic parenting book How to Talk so Kids Will Listen, and Listen so Kids Will talk
So, if it works for software engineering, why not ‘research and human factors’?