Back in August, I wrote a slightly cynical post in which I pondered the use of Twitter for publicising news from a research project. My plan was to find out more about the dark arts of Twitter and report back. At the time, the Institute had just under 200 followers. Three months later, we have 600 followers, way more re-tweets and significantly more hits on our website. How did this magic happen?

For a workshop to be successful, there has to be one and only one local person who is ultimately responsible for the workshop. A host brings the attendees, the instructors and the helpers together in such a way that things get learnt and everyone enjoys themselves. Being the host sounds kind of glamorous, but really what it means is coming in early on both days to buy the donuts, set out the chairs and check that there are no builders drilling. (And on the second day this work will be done after at a night at the pub.) If this is you, or might be you, read on…

Whilst preparing for the workshop you go through the Software Carpentry modules and tick the boxes:

• shell scripting... yup, written some pretty complex ones
• SQL queries... been there, done that
• lists, dictionaries... sure, even implemented Floyd algorithm on weighted graphs.

Unless you have actually taught all of the above (in which case, why are you a helper rather than an instructor?!), the trick is that it is much more difficult to explain to others than being able to just do it. The practice is usually embedded in a lot of tacit knowledge which, even though it may seem trivial, is often incredibly difficult to articulate. It's even more difficult to articulate to someone who has no familiarity with the subject.

Make sure you understand well what is taught at the Software Carpentry workshops. Yes, the instructor is there to explain, but a helper should be ready to answer participants’ questions “When I did A, I got B and now I have C. How did THAT happen?”

In recent blog posts, I've outlined our top tips for the infrastructure required for developing research software. In this blog post, I'll summarise these posts to show how you can evolve your infrastructure as your software grows and develops.

The blog posts on infrastructure can be mapped to three phases of research software evolution:

1. What infrastructure do you need to start developing research software? covers research software in its early stages (maybe just a prototype) that will primarily be used by the researchers who wrote it.
2. Strengthen community engagement and deliver reliable software with the right infrastructure covers research software that is beginning to be used by thewider research community.
3. Infrastructure for closer collaboration - covers research software that is now developed by a number of projects or institutions within a research community, which may, or may not, include the original researchers who developed it.

What happens once your research software has become established and a number of developers, from a number of different projects, start working on it? What happens if you take the big step and open source your project? In this post, I follow our top tips on infrastructure needed to start developing research software and strengthen community engagement and deliver reliable software with top tips on infrastructure to foster closer and productive collaboration with developers.

Whether you're part of an international collaboration or just a solo researcher, infrastructure will make a valuable contribution to your development. Our tips will help you be unselfish: open, responsive, communicative and considerate to your fellow researchers to encourage them to engage with you and contribute to the onward development of your software and your research.

Researchers face significant challenges when trying to understand, reproduce or reuse research in which software played an integral part. One of these challenges is to simply understand what software was used. Here are our top ten tips for describing software in research papers

It doesn't matter whether you've just started to develop research software, you're close to a first proof of concept, or you're about to release a prototype, at some stage you will ask yourself what infrastructure do I need?. In this post, I'll present our top tips on the infrastructure to use when starting to develop research software.

You've put in the hard work, developed your software masterpiece and it's finally ready. How should you go about releasing it into the wild? In the rush to release your software it's easy to forget a few things. A few very important things! Let's take a look at five things you should consider prior to release...

You're about to embark on the development of a new piece of software. Of course, there's a whole host of things you should do. But let's look at the flip side of the coin: what shouldn't you do?