1. How to program Or, how to write better programs

2. Inspired by ● 'The pragmatic programmer' by Andrew Hunt and David Thomas – http://www.pragmaticprogrammer.com/ppboo k/ http://www.pragmaticprogrammer.com/ppboo k/ ● A long time writing (bad) code ● People I have learnt from

3. So thanks to ● John Ashburner (SPM) ● Andrew Holmes (SPM) ● John Bywater (Appropriate software) ● Fernando Perez (ipython and c) ● Brian Hawthorne (roving expert) ● John Hunter (matplotlib, pbrain)

4. Why talk? ● The book – There are many general lessons that can be learnt about programming (and there are a lot of books) ● My own experience – Programming well expands the range of what you can do enormously – Learning to program well is a very long process ● Programming in the CBU

6. Two programmers ● 'I already know how to program' – Which is often true – Which means you are unlikely to get better ● 'I want to learn to program better' – Which is often not true enough – Which means you may well get better

7. Why would you want to be a better programmer? ● Or 'Can't I just modify some batch scripts? I haven't got time for all that programming stuff' ● Programming is a fundamental tool for neuroscientists ● Being better at programming will increase the range of things you can do, or think of doing ● Better programs lead to better thinking – Programs as algorithms

8. Learning to program ● Is like learning to do anything else ● The analogy of woodworking – Learning to use your tools – Apprenticeship – Learning to recognize good work ● Not learning is wasted time – You will be programming – Learning how to learn

9. Fundament ● Think about your work – And arrange your work so you keep thinking ● Own it – Broken windows – Signing code ● Share it – Because it makes it more fun – Because it makes you think – Because it helps you learn

10. Another fundament ● Automate – 'Civilization advances by extending the number of important operations we can perform without thinking' ● Design – Prototypes – Rubber ducks ● Smoke – Er – or do something else

11. Some specifics ● Learn to use your tools – Choose a good editor and learn it well (you'll be using it for many years) – Read about the language you are using – Know what your language is good at and when to switch

12. Assume you will make mistaks ● Build tests into your code – mycode.m – test_mycode.m ● Always use source code control – Subversion

13. Learn to tear it up ● As you get better, you will realize your mistakes ● As you learn, you will learn new techniques ● Maintaining code is not just bug fixing, but constantly improving design ● Well-designed programs are easy to extend, and broken up into well-defined, independent parts ● Only well-designed code will provide you with tools you can work with – And will save you time

14. So, refactor ● Keep thinking how it could be done better ● When you see something that is badly done, fix it ● Don't hold on to old code. It will slow you down, and confuse you ● Example from marsbar

15. An example ● From marsbar...