The Craftsperson and the Scholar

ScholarAndCraftsman.jpgBy James Hetherington, Research Software Development Team Leader at University College London.

At Digital Research 2012, I presented a position paper with colleagues regarding the role of the Research Software Engineer. This paper followed on from a discussion I led at the Collaborations Workshop and some very interesting blog posts by Dirk Gorissen and Ilian Todorov. Rather than repeat these discussions, I've written this post for those who think the Research Software Engineer role could be for them.

A quick note about the Research Software Development Team at UCL

With the establishment of the Research Software Development Team at UCL, I hope we're on the way towards establishing a successful home for scientific programmers. If you love learning about cutting edge research, and enjoy crafting robust, readable and efficient code, then please apply to join the UCL team.

Bringing together the best of two archetypes

A good scientific coder combines two characters: the scholar and the craftsperson.

The first of these, the scholar, is the archetypical researcher who is driven by a desire to understand things to their fullest capability. Intellectually demanding problems attract, rather than deter, scholars. Thorough exploration of the research literature is part of their preparation for work. The scholar's curiosity is insatiable, and they prefer not to spend time on a topic once understanding has been acquired, though they enjoy passing on that understanding through teaching.

The craftsperson, on the other hand, desires to create and leave behind an artefact which reifies their efforts in a field. They feel pain when the things they make are fragile or ugly. They prefer to make things which explain themselves. Design for usability is a puzzle with a human factor. The craftsperson's work requires patience, and pride in doing a job well. They prefer not to complicate things beyond necessity, because complex systems are more likely to break.

Scientific software doesn't require a balance between these archetypes, it requires individuals who combine the best of both roles.

One can't create or maintain software without thoroughly understanding the system it describes. Scientific software requires the scholar's drive and ability to understand the research field. To be a research software engineer is extremely intellectually demanding, since it requires the ability to understand research literature across a huge range of research topics. Familiarity with the needs and attitudes of the research user-community is also vital.

However, the construction and maintenance of research software doesn't stop when you have code that works. Indeed, the program 'till it works attitude, where the point is curiosity about results, is responsible for the sorry state of much research software. The goal must be the creation of something which lasts, something which others can use. Sustainable software will produce research results faster in the long run, but it requires a craftsperson's emotional commitment to making things that last.

The role of research software engineer might be the solution for software engineers who are frustrated at the lack of intellectual meat in the problems they address, or researchers who are frustrated by the pressure to move on to the next research paper. You might not get quite the freedom or recognition you would as a researcher, or be as well rewarded financially as you would as a corporate software engineer, but if you get your kicks from understanding the complex and then making a robust, clear and efficient tool, you should consider becoming a research software engineer.

Whatever your role, you should still let your inner craftsperson and scholar express themselves. If you're a researcher, insist on time to make code that you're proud of, whether the incentives make it difficult or not. If you're an engineer, then take the time to study the research literature, and then implement that ever-so-clever algorithm that makes feasible a new feature that will delight your users.

Posted by s.hettrick on 9 November 2012 - 10:04am

The scholar usually finds the solution in a linear way, making use of the bibliography and the orthodox way of research when the craftsperson may create sth literally magic, having to spend a year or more afterwards, trying to organize and explain the way he/she did!! It's true that when combining these two personalities.."sky is the limit"

<a href=>αδυνατισμα</a&gt;

I'm not sure where you're getting your information, but great topic.
I needs to spend some time learning much more or understanding more.

Thanks for magnificent info I was looking for this information for my mission.

A motivating discussion is definitely worth comment.
There's no doubt that that you should write more on this subject matter, it may not be a taboo subject but usually people don't talk about these
topics. To the next! Best wishes!!

I do not even know the way I ended up here, however I assumed this post was great.

I do not realize who you might be but certainly you
are going to a famous blogger in the event you
are not already ;) Cheers!

Submitted by Software Devel… on 5 October 2017 - 2:03pm


I totally agree that sustainable software requires a craftsperson's emotional commitment. Without it, after awhile the software will not have the desired results for a long time.

Awesome article!


Add new comment

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.